94% of US restaurant sites have no menu markup

What we did

Published restaurant guides covering Atlanta, Austin, Chicago, Dallas, Los Angeles, New Orleans, New York and Seattle. Eleven guides resolved; fifteen more returned 404 and were skipped, which the harvester records rather than hides.

Every outbound domain was extracted, then publishers, directories, ordering platforms, social networks, asset hosts and ad-tech removed. That left 213 candidate restaurant domains, of which 190 responded on 31 October 2026.

Each site had its homepage fetched and every JSON-LD block parsed. Where the homepage linked to a menu page, that page was fetched too, so no restaurant was marked down for keeping its menu markup where it belongs.

What we found

Finding	Sites	Share
No menu markup, homepage or menu page	179/190	94%
No FAQ markup	188/190	99%
No opening hours as structured data	175/190	92%
Never declares itself a restaurant	173/190	91%
No breadcrumb markup on the homepage	169/190	89%
No booking or ordering action declared	151/190	79%
No stable identifier on the business	146/190	77%
Describes a business, but only generically	98/190	52%
No business entity described at all	75/190	39%
No structured data whatsoever	41/190	22%
Claims an aggregate rating	5/190	3%
Broken, unparseable markup	0/190	0%

The numbers did not move when the sample grew

We ran this twice. The first pass covered 124 sites from five cities. The second covered 190 from eight, with a corrected business-type test and a cleaned sample.

94% and 91% both times. A figure that survives a 53% increase in sample size and a change of cities is measuring something real about how restaurant websites get built, not an artefact of which guides we happened to pick.

The menu number is the one that matters

A restaurant’s menu is the most valuable content it owns. It is what people search for, what they compare, and what an assistant needs in order to recommend the place to someone asking where to eat nearby.

In this sample, 94% of it is unreadable by machine. Not missing - the menus are all there, as photographs, as PDFs, as beautifully typeset HTML with no markup attached. Readable by people, opaque to everything else.

Eleven sites out of 190 did it properly. The best of them declares Restaurant on the homepage and Restaurant plus Menu on the menu page, which is what the whole sample should look like. Another emits nothing at all on its homepage and Restaurant, Menu and FAQPage on its menu page - which is why following the menu link mattered, and why a study that judged homepages alone would have reached the wrong answer about it.

Nine in ten never say what they are

173 of 190 sites never declare that they are a restaurant. 75 describe no business entity at all, and a further 98 describe one only as a generic Organization or LocalBusiness - a description equally true of a dentist, a law firm and a scrapyard.

Schema.org has had a Restaurant type for over a decade. It inherits everything the generic types carry and costs nothing to use. The local business schema guide covers why the specific type is always the right call.

What almost nobody gets wrong

Two findings cut the other way, and they are worth stating because they contradict the usual agency pitch.

Nothing was broken. Zero sites had an unparseable JSON-LD block. When these restaurants emit structured data, it is valid. The problem is omission, not malformation, and anyone selling you a “fix your broken schema” audit is solving a problem this population does not have.

Almost nobody is faking reviews. Five sites claimed an aggregate rating. Fabricated ratings are the one structured-data mistake that attracts a manual penalty, and this population is not making it.

No restaurant is named here

Not the ones that failed, and not the eleven that got it right. These are small businesses that did not ask to be in a study, and a site whose entire argument is about doing this honestly should not build its credibility by listing other people’s mistakes under their trading names.

The aggregate is the finding. If you want to know how your own site does, run the audit against it

• the script is below and it takes a minute.

Limitations, stated plainly

The sample flatters the population. These restaurants were chosen because a publication wrote about them, which correlates with having a budget and someone competent building the site. A random sample of US restaurants would almost certainly be worse.

Homepage and menu page only. A site could carry excellent markup on a reservations or locations page and still be counted as failing the things we checked elsewhere.

One point in time. Measured 31 October 2026. Sites change.

Eight cities, not the country. Enough to say the pattern is overwhelming. Not enough to put a decimal point on it, which is why no figure here has one.

Hotels were attempted and abandoned. Eight of twelve hotel guides refused our requests, which left the sample dominated by one article whose outbound links were mostly its own publisher’s international editions and a pile of ad-tech. Roughly seven genuine hotels survived, all in a single city. The honest move was to drop the vertical rather than publish 100% of 30 when a third of that 30 were not hotels.

Reproduce it

Both scripts are in this site’s repository, along with the list of guides the sample was drawn from. The sample itself is not committed - it is a list of real businesses, and the point of the previous section is that we do not publish those. You regenerate it, which also means you are checking our harvesting rather than trusting it.

npm run harvest scripts/samples/guides-restaurants.txt restaurants \
  > scripts/samples/us-restaurants.txt
npm run audit scripts/samples/us-restaurants.txt

The audit refuses to print percentages from fewer than 30 reachable sites. That guard is aimed at exactly this kind of study: easy to run badly, and easy to publish a confident number from a sample that cannot carry one.