How is your
restaurant website
actually doing?
Last verified:
Operator sheets that use this tool — printable, fillable, exports to CSV.
Part of Storefront Health — the composite score that pairs this signal with five others on one scorecard.
Drop your URL below and I'll run a real mobile audit in about thirty seconds — performance, SEO, accessibility, and the specific checks that matter for a restaurant. The full report renders on this page — no sign-up, no email, no tracking. (An optional form at the bottom emails you a PDF copy if you want one.)
Powered by Google's PageSpeed Insights API plus our own restaurant-specific scanner — ordering platforms, reservation widgets, maps, click-to-call, and mobile menu readability. Works on any publicly accessible URL (no staging environments or login walls).
Running your audit…
This usually takes 15–40 seconds.
Deep scan continues after the report (1–2 min): security headers, site age, real-user data, Google reviews, email-deliverability.
- 1 Submitting your site for the speed test
- 2 Mobile speed test (Google PageSpeed)
- 3 Reading your menu, hours, ordering, and Google profile
- 4 Writing your report
We couldn't audit that URL.
Check the address and try again. The site needs to be publicly reachable — if it's behind a login or a local network, the audit can't see it.
—
Knock these two out this weekend. Your checkmarks are saved on this device — come back Sunday night, re-run the audit, and you'll see exactly which numbers moved.
Your top 3 fixes all need a web person — there isn't a self-fix in the list this weekend. If you don't have someone, email don@muntin.digital and we'll route it.
Turn this audit into a plan you can work through
Your highest-leverage gaps, split across three horizons. Check each off as you tackle it — your progress is saved on this device and survives re-audits.
How much of your revenue stays with you?
Every gap below forces customers through a commission-taking path instead of your own margin-preserving one. Aggregators typically take 15–30% per order; your net margin is 3–5%. Closing these leaks keeps the money with the kitchen.
Where orders are leaking:
No leaks detected — your site is set up to keep the margin in-house on every order.
Want to run the actual math on your own numbers? Margin Math covers the unit-economics decisions (DoorDash / price-raise / prime-cost / break-even). The Menu Engineering Matrix takes the next step — paste your menu items, prices, and units sold to find which dishes are pulling weight. The Menu Copy Inspector closes the loop — once you know which items to fix, the Inspector teaches you how the language is dragging the sale. And Open Hours is the 15-minute fix-up for the most thankless drift on your site — getting your hours right everywhere from Google to your front door. All four run in your browser.
What's actually dragging your score down
Every finding below comes straight from Google Lighthouse. They're grouped by category and sorted by estimated impact — fix the top items first.
What do these numbers actually mean?
Performance (0–100)
How fast your pages load and become usable on a phone. This is the metric that quietly costs restaurants the most money — Google's own research found that 53% of mobile visitors leave a page that takes longer than three seconds to load. A higher score means more people stick around long enough to see your menu.
Good: 90+ · Needs work: 50–89 · Failing: <50
Based on: How Lighthouse scores performance · The 3-second mobile load rule
Accessibility (0–100)
Whether people with vision impairments, motor differences, or screen readers can actually use your site. Half of this is legally required in many states. The other half is just good manners — about one in five of your customers benefits directly from an accessible site, and everyone benefits indirectly (better text contrast makes your site easier to read in sunlight too).
Target: 100. Anything less means real people are being shut out.
Modern & secure setup (0–100)
Whether your site is built on a modern, secure foundation — HTTPS, no vulnerable libraries, no deprecated browser features. A well-built site should score 100 here by default. A score under 90 usually points at one specific thing worth fixing, like a missing security header or an old plugin.
Target: 100.
SEO (0–100)
The technical SEO fundamentals — a working title tag, a meta description, a crawlable URL, a mobile-friendly viewport, structured data. This score measures whether Google can rank your site. It doesn't measure whether you do rank for specific keywords — that's a longer-term question about content and inbound links.
Target: 100. Anything less is leaving ranking signals on the table.
Restaurant Readiness (0–100)
Our own rubric, specific to independent restaurant websites. Covers nine checks that matter for turning a mobile visitor into a booked table: a working mobile viewport, tap-target size, text contrast, legible font sizes, a tappable phone number, an embedded map or directions link, online ordering or reservations (either a known platform like Toast/OpenTable or a self-hosted equivalent), an HTML menu (not a PDF or image), and Restaurant schema.org markup for local search. Each check is weighted by its conversion impact — a pass earns full weight, a fail earns zero. Anything we honestly couldn't verify is excluded from both sides of the average, so "unknown" never penalizes you. Non-restaurant sites show "N/A" here and don't count this category toward their overall score.
Core Web Vitals
Five specific timing and interactivity measurements. Three of them (LCP, CLS, INP) are the current Core Web Vitals Google uses for mobile search ranking. Each card shows either real-user data (the 28-day median of actual visitor experiences that Google collects from Chrome) or a lab estimate (a simulated mobile run) — real-user data is preferred when available, since it reflects the site your customers actually experience. New or low-traffic restaurant sites usually only have lab data until they accumulate enough visits.
- LCP — Largest Contentful Paint. How long until the biggest visible thing on the page (usually a hero image or headline) shows up. Good: under 2.5s · Poor: over 4s.
- CLS — Cumulative Layout Shift. How much the page jumps around while loading. Shifting layouts are the reason you sometimes tap "Reserve" and accidentally hit an ad because the ad loaded a second late and pushed everything down. Good: under 0.1 · Poor: over 0.25.
- INP — Interaction to Next Paint. How long the page takes to respond to a tap or click — the third Core Web Vital, replacing FID in 2024. Field-only: requires enough real visits to report. Good: under 200ms · Poor: over 500ms.
- TBT — Total Blocking Time. The lab-only proxy for INP. How long the page is frozen while JavaScript runs during the simulated load. Useful when CrUX hasn't collected INP yet. Good: under 200ms · Poor: over 600ms.
- FCP — First Contentful Paint. How long until the very first pixel renders. Often earlier than LCP — this is "the page is doing something" versus "the page is usable." Good: under 1.8s · Poor: over 3s.
Based on: How Lighthouse scores performance
What we can verify about this restaurant
Every sentence links to the verified signal it came from. Hover any citation to see the source.
Google reviews snapshot
What real visitors actually experience
Page load, response time, and layout stability — measured from real Chrome visitors over the last 25 weeks. We only show this when Google has enough samples to publish a real trend, so a brand-new or low-traffic site may not have data here yet.
Will your reservation confirmations land in spam?
Gmail, Outlook, and Yahoo silently route booking confirmations and newsletters to spam unless your domain proves it can send mail. The three rows below are the proofs they look for.
We didn't classify this as a restaurant site
The four Lighthouse categories above (Performance, Accessibility, Best Practices, SEO) still apply — they're universal. We just didn't find the signals we look for to confirm a restaurant: a known ordering or reservation platform (Toast, OpenTable, Resy…), Restaurant schema markup, or clear restaurant language on the page.
If this is a restaurant and we got it wrong, tell us and we'll run the restaurant-specific checks on it.
Auto-detected from schema markup, ordering/reservation platform, and page content. If we got it wrong, pick the right one — the checks below will update live.
Google-published hours
Your name, address, and phone don't line up across sources
Google ranks local businesses higher when their Business Profile, website schema, and on-page text all match. Every mismatch below is a citation inconsistency search engines can see — pick the canonical value and unify.
How your site looks when shared on social
How well can Google read your menu, hours, and address?
Restaurant-priority checks
—How do you stack up?
Add up to three competitor restaurants and we'll audit each one side-by-side. Lets you see exactly where you're winning and where they're beating you.
Auditing competitor 1 of 3…
Each competitor takes 15–40 seconds. We run them one at a time so Google doesn't rate-limit us.
| Metric |
|---|
Something went wrong.
Email me the PDF.
Drop your email and I'll send the full printable PDF right away, with a short note on what jumped out at me. If something in the audit warrants a longer look, I may follow up personally. No drip, no newsletter.
Your email stays with me. No list, no marketing drip.
Remind me to re-audit in 30 days
Audits are snapshots. A friendly reminder in 30 days helps you see which fixes actually moved the score. One email, nothing else.
Your email lives only on the scheduled message. We don't store it on our end — no list, no drip, no follow-up.
Show this score on your own site
Paste this snippet into your site footer. The badge refreshes to match whatever audit you run next — no manual updating.
How we calculate these numbers
The overall score
The overall score is a weighted average of five pillars. Performance is weighted 2× the others because a slow mobile site is materially worse for a restaurant than an imperfect SEO score — 53% of mobile visitors bounce from pages that take more than 3s to load. The Restaurant Readiness pillar is only included when we have enough confirmed checks to trust it; otherwise the score falls back to a simple 4-pillar average so one detected platform plus eight unverified checks doesn't inflate the overall number.
How we detect your restaurant subtype
Ten subtypes are recognized: fine-dining, casual-dining, fast-casual, cafe, bakery, bar-pub, pizzeria, food-truck, ghost-kitchen, and catering-only. Detection combines schema.org @type hints, the presence of subtype-specific platforms (Slice for pizzerias, Resy for fine-dining, etc.), and keyword patterns in the page text. Each signal contributes to a score; the highest-scoring subtype wins. Confidence is reported in the subtype card so you can override it if we got it wrong.
Check weights
Each of the 20+ restaurant-priority checks carries a weight from 0 (not applicable to this subtype) to 2.0 (critical). Viewport is 2.0 across every subtype because a missing viewport breaks every phone visitor's experience. Conversions (online ordering or reservations) is 1.5 for most subtypes but 2.0 for fine-dining (reservations) and 2.0 for fast-casual (ordering). Age-gate is 0 for every restaurant subtype — bars and restaurants don't legally need them in most jurisdictions, unlike alcohol retailers.
"Unverified" checks (where we honestly couldn't tell) count at HALF weight against the denominator, zero credit toward the numerator. This prevents a site we couldn't fully scan from inflating its score past a clean-scanning site with the same pass count. The penalty is disclosed on the score ring as "N unverified checks."
The "typical sites score" benchmark
Per-subtype benchmark medians are currently operator estimates from manual review of roughly 100 restaurant sites in each subtype. They're provisional — the refresh pipeline that replaces each subtype with a real sample size (drawn from live audits this tool runs) is future work. The benchmark chip's ⓘ tooltip carries the provenance on every render. Numbers are anchors for expectation-setting, not statistical claims.
The revenue-at-risk chip
Every actionable finding carries an "Est. $X–Y/yr at risk" chip. The range is the product of three inputs:
(1) a per-check revenue-at-risk coefficient based on published funnel-dropoff research; (2) your restaurant's estimated annual revenue, which starts from a subtype-aware default (fine-dining ~$2M, cafe ~$860k, food-truck ~$230k) and is automatically adjusted when Google Places tells us something more: priceLevel scales the per-ticket average (0.55× for $, 2.4× for $$$$), and userRatingCount scales daily covers logarithmically (clamped to 0.40×–2.50× so viral outliers don't project chain volume); (3) a confidence-widening layer that stretches the range when any of the Places signals aren't available, so an audit with thin data produces an explicitly wider chip instead of a falsely precise one.
Nothing in this chain asks you to type numbers. Every adjustment reads from signals the audit already fetches during the fast scan.
What "confidence-widened" means
When Google Places didn't find your listing, or didn't publish a price level, or hasn't accumulated at least 50 reviews, the revenue chip's low and high values are stretched to reflect the genuine uncertainty. A well-resolved audit might show Est. $12k–18k/yr at risk; a nothing-resolved audit of the same check shows Est. $5k–37k/yr at risk. The range width itself is the honesty layer — we'd rather show you a wide span we can defend than a tight one we can't.
What this audit does NOT do
It runs on one Lighthouse pass (simulated phone, default throttling) plus a follow-up crawl of up to eight internal pages. It does not test ordering flow end-to-end, place a real reservation, verify your DoorDash profile, or measure real-user traffic beyond what Google's CrUX report publishes. It does not scrape Yelp or TripAdvisor (their terms forbid it). It does not claim your revenue-at-risk numbers are precise — they're order-of-magnitude estimates, always shown as ranges with "Est." up front.
Found an error in a weight, a benchmark, or the revenue math? Tell us — the whole tool is open and the explanation above is linked from every audit so the methodology travels with the score.
Why this tool exists.
Every check this tool runs maps to a specific concept in the Library. Two starting points — one definition, one playbook.
Core Web Vitals
CWV
Google's three performance scores for a real page load on a phone — one for loading speed (LCP), one for layout stability (CLS), and one for…
Read the definition GlossaryLighthouse
Google's audit engine
The open-source auditing tool Google ships inside Chrome and inside PageSpeed Insights. It simulates a mobile page load and scores your site…
Read the definition GlossaryLargest Contentful Paint
LCP
How long it takes for the biggest visible chunk of your homepage — usually the hero image or the headline — to finish drawing on a phone. Un…
Read the definition GlossaryCumulative Layout Shift
CLS
A score that measures how much your page jumps around as it loads — when a banner slides in, an image arrives late, or a late-loading font n…
Read the definition ArticleHow to Tell If a Restaurant Tool Is Safe
A 5-test framework + 4-tier data model + a worked example. Verifiable in your own browser, under a minute per test.
Read the playbookI build restaurant websites
that ace this audit.
If the audit found more red than you're comfortable with, let's talk. Twenty minutes on Zoom, I'll walk through your results live, tell you what I'd do in what order, and give you a realistic budget and timeline. No pitch, no pressure.