Site Health Report

Murphy's Taproom

murphystaproom.com   |   Reviewed 2026-06-30   |   Non-intrusive scan (viewed public pages only, no probing or testing)
Overall: nothing critical
A quick word on the "you can't fix it, it's the platform" excuse: it is often overstated, and you are right to be skeptical. But it is not all bluff either. Your site runs on Toast Sites (Toast's built-in restaurant website tool), which is more locked down than Shopify: there is no theme code to edit and no app store. So the honest picture is a short list you can genuinely act on, and a set of items that only Toast can change and that you should push their support to fix. Both are below, separated cleanly.
Correction from a first look: the map on the Entertainment page is fine. An earlier automated pass showed it failing, but loading the page directly, the map loads and renders correctly. No action needed. (Verified, not assumed.)

What you can do on your end (actionable now)

Fix the "undefined" in your Gift Cards & Loyalty links Low

Those two buttons currently link to URLs containing utm_source=undefined. A value was left blank when the link was built. The buttons still work, but the tracking is broken and it looks sloppy.

Do this: In the Toast Sites editor, open the Gift Cards and Loyalty buttons and look at the link field. If the URL is editable, remove utm_source=undefined (or set a real value). If the button link is auto-generated and locked, it becomes a Toast item to report.

Confirm your footer / booking links actually open Verify

The Privacy, Terms, Cookie Policy, gift-card, and OpenTable links returned "forbidden" to the automated scan. That is almost certainly just bot-blocking by Toast/OpenTable, not a real break.

Do this: Click each one in a normal browser. If they all open, you are done. If any genuinely fails for a real visitor, that is a broken link to fix or report.

Lock down your Google Maps key (if it is yours) Low

The map works, but the API key sits in the page source. Maps keys are meant to be public, as long as they are restricted so nobody else can use them.

Do this: If you added the map (the key is in your Google Cloud account), set an HTTP-referrer restriction to murphystaproom.com on that key. If Toast placed the map, it is their key, and this one is on them.

Try adding a Referrer-Policy yourself Low

One of the missing security headers can sometimes be added without Toast.

Do this: If your Toast editor has any "custom HTML," "embed code," or "code block" option, drop this into the page head: <meta name="referrer" content="strict-origin-when-cross-origin">. If there is no such option (likely on Toast), this moves to Toast's list.

Bonus: hardening you fully control at your DNS Optional

Your domain's DNS is at GoDaddy, which is yours (even though the website itself is on Toast's servers). That gives you a couple of free wins independent of Toast:

  • Add a CAA record so only your certificate authority can issue certs for the domain.
  • If this domain also sends email, confirm SPF / DKIM / DMARC are set (separate from this website scan, but it is the highest-value security item you fully own).

What is Toast's to fix (open a support ticket)

Every page throws React "hydration" errors Med

Across all pages, the site logs recoverable React errors (#418 and #423). Visitors usually will not notice, but these can cause a brief flicker, occasionally drop a piece of interactivity, and are a known drag on SEO and page speed. This is Toast's page-rendering code. You cannot fix it in the editor. It is the single most consistent defect on the site and worth naming specifically in a ticket.

Two missing security headers Low

Permissions-Policy and Cross-Origin-Opener-Policy are absent. These can only be set as server response headers, which Toast controls. (The important ones, CSP and HSTS, are already present.) Ask Toast to add them.

Two cookies missing Secure / HttpOnly flags Low

Toast's own cookies __ssid and toast-sites-experiment-id are set without the Secure and HttpOnly flags on an HTTPS site. Set by Toast's servers, so it is theirs to correct. (Cloudflare's cookies are set correctly.)

A leftover developer address in the security policy Low

The site's Content-Security-Policy still lists http://localhost:36867, a developer machine address that should not ship to production. Harmless to visitors, but it is Toast's config to clean up. A good, specific thing to mention in a ticket.

The Referrer-Policy header Low

If the meta-tag trick on the left is not available in your editor, adding this header is Toast's job.

The "advanced" lever, and why it is shaky here

In theory, since you own the DNS, you could route the domain through your own Cloudflare (or similar) and inject the missing headers and cookie flags there, without waiting on Toast. In practice this is risky on Toast Sites: your domain currently has to point straight at Toast's servers, and slipping your own proxy in front of theirs is fragile and may break the site or be unsupported. I would not recommend it just to add two low-severity headers. Push Toast instead. It is mentioned only so you know the option exists and is not being hidden from you.

What is already good