Restaurant website technical SEO checklist, the operator’s audit.

Type “restaurant technical SEO” into any search engine and the first ten results are written by SEO agencies, SaaS-platform marketing teams, or affiliate sites that need you to buy a tool. The advice is generic by design — it has to fit a law firm, a SaaS dashboard, and a dental clinic at the same time. A restaurant website is none of those things. The pages are few, the menu carries the weight, the visitor is on a phone deciding where to eat in twenty minutes. The technical SEO audit shaped to that operating reality is what follows: eight passes through the site, each with a yes-or-no verdict, and a twelve-point self-audit at the end that an operator can run, write down, and walk into a rebuild conversation with.

What “technical SEO” actually is (and why a restaurant needs it)

Technical SEO is the layer that decides whether Google can read your site at all. It sits below the words, the menu, the photos — the on-page work — and asks a simpler question: can the crawler reach the page, render it, and understand what it is.

For a restaurant the distinction matters because the on-page work and the technical work tend to be in different people’s hands. The chef-owner writes the menu copy, the GM picks the photos, the website is whatever the builder shipped. The technical layer is invisible until it isn’t — until the menu page does not show up for the restaurant’s own name, until the new lunch hours never make it into the AI Overview, until the reservation page loads slow enough that the diner closes the tab. None of those failures are content failures. They are technical failures shaped like content failures, which is what makes them hard to diagnose without a checklist.

The eight passes below are how the studio walks a site before a rebuild conversation. Each one is shaped to a specific question Google’s own crawler asks. If the audit clears all eight, the site does not need a rebuild — it needs content work, which is a separate library piece. If the audit fails three or more, the rebuild quote will be cheaper than the lost-orders bill. For the broader local-SEO frame this sits inside, read restaurant local SEO; for the schema-specific drill-down, restaurant schema markup is the companion piece.

The page speed audit: Core Web Vitals on a real phone

Core Web Vitals are Google’s three public page-experience metrics: LCP (how fast the main image draws), CLS (how much the page jumps as it loads), and INP (how fast the page responds to a tap). All three are measured on the mobile audit.

The numbers Google publishes as “good” thresholds: LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds. A restaurant site that clears all three on a mid-range Android phone is in the green band; one that clears none of the three is the median, not the exception. The two upstream metrics worth knowing — because they are the ones the audit fixes drive — are Time to First Byte (the host’s response speed; over 600 milliseconds points at a slow host) and First Contentful Paint (when something first appears; under 1.8 seconds is good).

The way to run the audit is at PageSpeed Insights: paste the URL, run the mobile audit (not the desktop one — mobile is what Google ranks against), and read the three metrics at the top of the page. The tool also lists the specific fixes ranked by impact, which is the part most operators skip. The top three fixes on a typical restaurant audit are the same week after week: the hero image is too large and the wrong format, a layout shift comes from the reservation widget or the social-proof carousel loading after the page renders, and a third-party script — usually the analytics or a chat widget — is blocking interaction. Each fix is a single change, not a rebuild. For the verification dashboard that confirms the audit moved the metrics in the field, see how to read restaurant Google Search Console.

Is your site mobile-first ready? The five checks Google runs

Mobile-first indexing has been Google’s default rule since 2019: the crawler reads the mobile version of your site and ranks based on that. Whatever the desktop view does well no longer counts if the mobile view does not match.

The five checks Google’s own crawler runs — in plain terms, not the documentation’s language — are the ones that decide whether the mobile audit passes. First, the viewport meta tag is in the <head>: the single line <meta name="viewport" content="width=device-width, initial-scale=1"> tells phones to render the page at phone width instead of zooming a desktop layout. Second, responsive design is the rule, not a separate mobile site — same URL, same content, the layout reflows based on screen width. Third, the body text size is at least 16 pixels — smaller than that and iOS Safari zooms in every time a guest taps the reservation field, breaking the layout on the way back out. Fourth, the tap targets — every button, every link in a list — are at least 44 by 44 pixels with space between neighbors; smaller than that and the fat-finger taps send lunch to the wrong order. Fifth, the content is the same as desktop. A separate mobile site that shows less than the desktop site fails mobile-first indexing on principle, because Google cannot rank what the mobile crawler cannot see.

The check that catches the most restaurants is the second one. Sites built on a builder template often look polished on desktop and disastrous on phones because the template was designed at desktop width and reflowed badly — a hamburger menu hides the hours, the reservation button overflows the screen, the menu PDF that opens fine on desktop becomes an unreadable zoomed-out image on mobile. None of those failures show up on the desktop preview the operator built the site on. All of them show up in Google’s mobile crawler, and what the crawler sees is what gets ranked. The fix is not always a rebuild; sometimes it is a single CSS adjustment. The audit is what tells you which.

Crawlability: what robots, sitemaps, and canonical tags do for you

Three small files decide whether Google’s crawler can read your site at all: robots.txt, the XML sitemap, and the canonical tag on each page. Each one is one line of code most operators have never opened.

A robots.txt file at yourdomain.com/robots.txt tells crawlers which parts of the site they can read. Most restaurant sites need exactly five lines: User-agent: *, Allow: /, a blank line, Sitemap: https://yourdomain.com/sitemap.xml. The most common mistake is a leftover Disallow: / line from a staging environment, which tells every crawler to skip the whole site — and which makes the entire technical-SEO audit moot until that one line is deleted. Open the file in a browser; if it reads “Disallow: /” on its own line, the page is invisible to Google by your own instruction, and the fix is a one-line edit.

The XML sitemap at /sitemap.xml lists every page you want indexed plus the date each one last changed. Submit it once in Google Search Console (verify the property first, paste the sitemap URL in the Sitemaps tab) and Google reads it on every crawl after. A restaurant site with seven pages still benefits — new pages, menu updates, and a refreshed events page get discovered the same day instead of waiting for the organic crawl to find them. The canonical tag is the third file, embedded in the <head> of every page: <link rel="canonical" href="https://yourdomain.com/this-page/" />. It tells Google the canonical URL for the page even if a tracking parameter or a campaign link sent the visitor to a duplicate. On a restaurant site where the reservation widget appends ?source=facebook to the URL, the canonical tag is what keeps the page from competing with itself in the index.

The three files together are the crawl-and-index contract. Get any one of them wrong and the rest of the audit does not matter, because Google is not reading the pages the audit is testing. The good news is that all three are auditable in five minutes — open the URLs, read the files, fix the obvious problems — and the broken ones are usually broken in the same way: the staging-environment Disallow line, the missing sitemap, the absent canonical. None of those is a rebuild; all three are a one-line fix.

The HTML head: title, description, Open Graph, schema — what’s mandatory vs. nice-to-have

The <head> of each page is where Google and the AI assistants pick up the metadata. Four blocks are mandatory; four more are nice-to-have. The audit is whether the mandatory four are present and the optional four are filled where they make sense.

The four mandatory blocks on every page: a title tag under 60 characters that names the page and the location (“Dinner Menu — Tacombi Bethesda” not “Menu”); a meta description under 155 characters written for the click, not for the algorithm; the canonical link from the section above; and the viewport meta tag from the mobile-first section. Miss any of the four and the page either does not show up in search at all or shows up with a Google-generated snippet that probably is not what you would have written.

The four nice-to-have blocks come next. Open Graph tags (og:image, og:title, og:description) are what iMessage, WhatsApp, Slack, Facebook, and the rest read when a regular shares your URL — without them the link previews as a plain grey box, which is the difference between a friend-of-friend booking the table and ignoring the message. Restaurant JSON-LD schema — specifically the Restaurant type with address, openingHours, menu, and servesCuisine properties — is what feeds the structured data Google uses for the sidebar panel and the AI Overview citation. A favicon at four common sizes (16, 32, 192, 512 pixels) is the small icon that appears in the browser tab, the bookmark, and the Google search result — a missing favicon reads as an unfinished site at a glance. And breadcrumb structured data (BreadcrumbList in JSON-LD) lets Google replace the long URL in the search result with a clean trail.

The schema is the lever that compounds. Plain HTML tells Google what the page looks like; the JSON-LD schema tells Google what the page is. The restaurant whose homepage is marked up as a Restaurant with the right cuisine, address, opening hours, and menu URL is the one that gets cited in the AI Overview answering “Italian restaurant in Silver Spring open late” — because the model can read the schema and answer the question literally. The restaurant whose homepage is plain HTML has to compete on the prose alone, which is a harder fight. For the full schema walk — which properties belong on which page, which ones to skip, and the Rich Results Test workflow — see restaurant schema markup.

Internationalization: when (and how) hreflang matters for a single-location restaurant

hreflang is the HTML attribute that tells Google which language a page serves and which version to show a search visitor whose browser is set to a different language. It is necessary only when the same restaurant publishes pages in more than one language.

For a single-location restaurant in English alone, the hreflang section is the easy one: skip it. The tag is meant to pair language variants, not invent them. For a bilingual restaurant — an English/Spanish site in DC, an English/French site in Montreal, an English/Korean site in Annandale — the tag is what tells Google to send the Spanish-speaking searcher to the Spanish version of the menu page instead of the English version. The shape of the tag goes in the <head> of both pages, pointing at each other, plus an x-default for searchers whose language Google cannot identify: <link rel="alternate" hreflang="en" href="https://yourdomain.com/menu/" />, <link rel="alternate" hreflang="es" href="https://yourdomain.com/es/menu/" />, and <link rel="alternate" hreflang="x-default" href="https://yourdomain.com/menu/" />. The most common mistake is a one-sided tag — the English page points to Spanish but the Spanish page does not point back. Google reads that as a broken pair and serves the wrong page to roughly half the searchers it would otherwise route correctly.

The pattern to remember for the audit: hreflang is the right call only when the same content exists in two languages on two URLs. A restaurant that translates its homepage and not its menu page should not stamp hreflang on the homepage — the unpaired hreflang sends Google looking for a menu translation that does not exist, and Google penalizes the broken pair by showing neither version reliably. The audit answer is yes only when both pages are real, both pages point at each other, and both pages serve the same restaurant identity. For most single-location English-speaking restaurants the section is a clean skip, which is itself worth knowing — the audit clears with a no, not with an absence.

Footer hygiene: the year, the SSL, the tap targets, the legal links

The footer is where four of the smallest signals live, and where most restaurant sites lose trust in the last visible pixel. The audit covers four things: the copyright year, the SSL certificate, the contact-link tap targets, and the legal-page links.

A stale copyright year — “© 2022 Joe’s Pizza” in a 2026 footer — reads to an out-of-town diner as a business that may have closed during the pandemic and never reopened. The fix is a one-line JavaScript snippet that renders the current year automatically: document.getElementById('year').textContent = new Date().getFullYear();. Pair that with a last-updated signal on the menu page — a small “Spring 2026 menu” badge, a dated specials block — and the freshness reads in seconds. The audit verdict: pass if the year renders dynamically and the menu has at least one dated freshness marker; fail otherwise.

The SSL certificate is the lock icon next to the URL. A site that loads at http:// instead of https:// shows a “Not secure” warning in every modern browser, which is enough to bounce a reservation that was about to convert. Every host worth using ships free SSL via Let’s Encrypt; if the site is not on HTTPS, the fix is a free certificate and a redirect rule. The third footer check is the tap targets on the contact links — phone number, email address, the map link — which should be at least 44 by 44 pixels on a phone with space between them. A phone number that is rendered as small grey text without a tel: link is a tap target that does not work; the fix is to wrap it in <a href="tel:301-555-0100">. The fourth is the legal-link block — privacy policy, terms, accessibility statement — which Google and the AI assistants read as a trust signal that the site is being maintained. A footer with no legal block reads as a site that was set up once and never touched.

A sticky mobile footer — a thin bar pinned to the bottom of every mobile page with one or two key actions (Call, Reserve, Order) — is the optional fifth check that earns its keep on a restaurant site. The diner scrolling halfway down the menu wants to act with one thumb tap, not scroll to the top to find the reservation button. None of these five footer checks is a rebuild. All five are an afternoon’s edits in whichever platform the site runs on. The last small piece worth naming alongside them is a professional email address on the contact link — hello@yourdomain.com reads as a real business; a Gmail address in the footer of an otherwise polished site reads as a side project, which is enough to lose a catering inquiry to the next result. For the menu-page treatment that makes all of this matter, see restaurant online menu best practices.

The 12-point self-audit (close)

Walk the twelve checks in order. Each one has a yes-or-no verdict, color-coded to the same teal-warn-rust palette Google uses on its own Core Web Vitals dashboard. Write down a verdict per check; the artifact is what a follow-up rebuild quote will price against.

The audit takes about an hour the first time and about fifteen minutes on a re-audit once the obvious failures are fixed. The order is deliberate — foundational checks first (TLS, viewport, robots), structural checks second (titles, descriptions, hierarchy), measurable checks last (Core Web Vitals). A failure in the first four blocks the audit at the foundation; a failure in the last three is fixable with a focused performance pass.

Read the verdicts as a group, not as twelve isolated grades. A site that passes the first nine and fails the last three is a fast-CSS-and-image-pass problem, not a rebuild. A site that fails the first three is a rebuild because the foundation is the part the rest stacks on. A site whose audit is mostly warns is the most common pattern — small fixes everywhere, no single catastrophe — and the right move there is to schedule an afternoon to walk down the warns one at a time. None of the twelve checks needs an agency. All twelve need a written verdict, in your own handwriting, before any rebuild conversation starts.