Restaurant SEO: The Technical Half Local Guides Leave Out

For a restaurant, most search traffic is decided by two things: your Google Business Profile, and whether a search engine can read your menu. The first is well covered everywhere. The second is where almost every restaurant site quietly fails, because the menu is a PDF.

Local SEO advice for restaurants converges on the same list: claim the profile, keep the hours accurate, get reviews, build citations. That list is correct and you should do all of it. It is also the half that agencies sell, which is why the technical half — the part that costs nothing and is entirely within your control — goes unmentioned.

Table of contents

• Get the Google Business Profile right first
• The menu-as-PDF problem
• Schema markup that search engines actually use
• Speed, which is a hosting decision
• Content that matches how people actually search
• Owning the domain and the content
• How this fits the rest of the stack
• FAQ

Get the Google Business Profile right first

For a restaurant, the map pack is the search result. Three listings appear above everything else for anything resembling a local food query, and the site below them gets a fraction of the clicks. Everything else in this article is secondary to being in that block.

The essentials, quickly:

• Name, address, and phone number exactly consistent everywhere they appear — your site, the profile, directories, delivery platforms. Suite 3 in one place and Ste. 3 in another is a real inconsistency to an automated system.
• Correct primary category. Italian Restaurant, not Restaurant, if that is what you are.
• Hours including holidays, and special hours set before the holiday rather than after.
• Photographs, added regularly. Profiles with recent images perform better and the effect is not subtle.
• Reviews, and replies to them. Reply to the bad ones especially, briefly and without argument.
• The menu link and the ordering link, both pointing at pages you control.

One thing worth naming: your profile should link to your own menu page, not to a third-party delivery platform’s copy of it. Sending your best traffic to a platform that charges commission and owns the customer relationship is a decision, and it should be a deliberate one.

The menu-as-PDF problem

This is the single biggest technical mistake restaurant sites make, and it is nearly universal. The menu is designed in a print tool, exported to PDF or an image, and uploaded.

To a search engine, a menu image contains no words. Every dish name, every ingredient, every description — the exact vocabulary people search for — is invisible. A PDF is marginally better because text can sometimes be extracted, but it renders badly on a phone, it downloads instead of opening, and it will not appear as a normal search result.

The searches you are losing are specific and high-intent. Somebody looking for cacio e pepe near me, or a gluten free pizza in your neighbourhood, or whether you do a set lunch. Those queries match dish names, and your dish names are inside a picture.

The fix is to publish the menu as HTML. Real headings for sections, real text for dishes and descriptions, prices as text. Keep the beautiful PDF as a download for people who want to print it, but the canonical menu should be a web page.

This one change tends to do more for a restaurant’s organic traffic than any amount of link building, because it takes a page with no indexable content and turns it into one with several hundred highly specific terms on it.

Schema markup that search engines actually use

Structured data tells search engines what your page means rather than making them infer it. For restaurants there are well-supported types that feed rich results directly.

Restaurant schema, on the homepage or a dedicated location page, carrying the name, address, phone, opening hours, cuisine, price range, and accepted payment methods:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Trattoria Example",
  "servesCuisine": "Italian",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "Springfield",
    "postalCode": "12345",
    "addressCountry": "US"
  },
  "telephone": "+1-555-0100",
  "openingHours": ["Tu-Sa 17:00-23:00", "Su 12:00-16:00"],
  "acceptsReservations": "True",
  "hasMenu": "https://example.com/menu"
}

Then Menu and MenuItem schema on the menu page itself, which is only possible because you published the menu as text in the previous section. The two changes reinforce each other.

Add FAQ schema for the questions you get asked constantly — parking, dietary options, whether you take walk-ins, group bookings. These are real searches and answering them on the page in a structured way makes the answers eligible to appear directly in results.

The hours in your schema, on your profile, and in your page footer must agree. When they disagree, search engines pick one, and it will not reliably be the right one.

Speed, which is a hosting decision

Restaurant sites are opened on phones, usually on mobile data, frequently by someone standing outside deciding whether to come in. They are also, as a category, among the heaviest sites on the web, because they are built around full-screen food photography.

The usual profile of a slow restaurant site:

• A hero image exported at 4000 pixels wide and several megabytes, displayed at 400 pixels on a phone.
• A gallery loading every image at full resolution on page load.
• Two or three web fonts, each with several weights, blocking text from rendering.
• A third-party reservation or ordering widget loading its own framework before anything appears.
• A video background, which is the single most expensive thing a restaurant site can do to a mobile visitor.

Fixing it is unglamorous and effective. Resize images to display size, serve WebP or AVIF, add srcset, lazy-load below the fold, set explicit dimensions to stop layout shift, subset the fonts to the characters you use, and load third-party widgets after the page renders rather than before.

The reservation widget deserves particular attention. Many are heavy, and if one blocks rendering, the visitor sees a blank screen while the script that exists to take their booking is still downloading. Load it lazily, or on interaction, so the page is useful before the widget arrives.

Content that matches how people actually search

Beyond the menu, a small number of pages capture a disproportionate share of real queries.

• A location page per site if you have more than one, each with its own address, hours, schema, and photographs. Never one page listing five branches.
• A page for what you are known for. If you are the place for a particular dish, that dish deserves a page rather than a line on the menu.
• Practical pages: parking, accessibility, private hire, large groups, dietary options. These are searched constantly and answered by almost nobody.
• Genuine local content — a supplier you work with, a neighbourhood event you cater. This is where local links come from, and local links are the ones that move the map pack.

Write in the words customers use, not the words the industry uses. Nobody searches for artisanal small-plates concept. They search for tapas near me, best brunch, and whether you are open on a Monday.

And keep it current. A page advertising a Christmas menu in June is a stronger signal that the business is not paying attention than no page at all.

Owning the domain and the content

A last point that is not strictly SEO but determines whether any of it accumulates.

If your site lives on a restaurant-platform subdomain, every bit of authority you build belongs to that platform. If the platform registered the domain in its own name, the same is true of the domain. Both are common, and both surface at the worst moment: when you want to change providers and discover that leaving means starting from zero.

Register the domain in the restaurant’s name, keep the registrar login, and make sure whoever manages the site is a delegate rather than the owner. This costs nothing and prevents the single most expensive mistake in this whole area.

The same applies to content. Photographs, menu text, and reviews you have collected should exist somewhere you control, not only inside a platform’s database with no export.

How this fits the rest of the stack

Restaurant SEO is roughly half profile management and half making the site readable and fast, and only the first half is usually sold to you. Publishing the menu as text and getting a photo-heavy page to load quickly on mobile data are one afternoon of work each with a longer tail than any campaign. If that work also means moving off a platform subdomain onto your own domain, the RunxBuild hosting calculator puts static hosting and bandwidth as separate line items, which is the right way to think about a site that is mostly photographs of food.

Useful related references:

• GitHub Pages SEO: What You Can Fix and What You Cannot
• Domain Forwarding and SEO: Redirects That Keep Your Rankings
• Netlify and SEO: The Platform Settings That Actually Affect Rankings
• Services on RunxBuild

FAQ

Should my restaurant menu be a PDF or a web page?

A web page. A PDF or image menu is invisible to search engines, so every dish name and description — the exact terms people search for — contributes nothing. Publish the menu as HTML with real headings and text, and keep the PDF as an optional download for people who want to print it.

What is the most important thing for restaurant SEO?

The Google Business Profile, because the map pack sits above organic results for nearly every local food query. Accurate name, address, phone, hours, correct category, recent photographs, and replies to reviews. After that, an indexable text menu is the single highest-return change on the site itself.

Does site speed matter for a restaurant website?

Considerably, because these sites are photo-heavy and opened on phones over mobile data, often by someone deciding whether to walk in. Oversized hero images, video backgrounds, and render-blocking booking widgets are the usual culprits. Resizing images and deferring third-party scripts fixes most of it.

What schema markup should a restaurant use?

Restaurant schema with the address, hours, cuisine, price range, and a link to the menu; Menu and MenuItem schema on the menu page; and FAQ schema for common questions about parking, dietary options, and bookings. Make sure the hours in your schema match your Business Profile and your footer exactly.

Should I link my Business Profile to my own menu or to a delivery app?

Your own menu page. Sending your highest-intent traffic to a third-party platform hands over both the commission and the customer relationship. Keep the ordering link if you use a platform, but the menu link should point at a page you own and can optimise.