If you eat out a few times a week, you've felt it. You pull up a restaurant's site, decide on a dish on the way over, sit down, and find out it's not on the menu anymore. Or worse: the website shows a six-month-old PDF that bears no resemblance to what just got dropped in front of you.
We took a Sunday and surveyed 100 independent restaurants across San Francisco, Portland, Austin, and Charleston. One criterion: does the menu on the website match what the kitchen is serving tonight?
The numbers:
- 38 sites had a menu that matched within the last week
- 22 had a menu stale by 30 days or more
- 17 linked to a PDF dated 2023 or earlier (one was from May 2019)
- 14 had no menu at all on the site
- 9 redirected to a third-party platform — Yelp, Toast, Square — and that menu didn't match either
So roughly two in five sites lie. Not maliciously. Nobody at the restaurant wants the wrong dish listed. They lie by omission, because keeping a website current is somebody's job that never gets done.
Why menus drift
Three reasons, in order of how often we see them:
The chef changes the menu but the website is on a different system. The chef updates a Google Doc shared with the front of house. The Doc gets printed. The print sits in a folder on the host stand. The website lives in WordPress with a custom theme nobody wants to touch, edited by an agency on retainer that bills for menu updates. A specials section gets added Tuesday; the website still says they don't do specials.
The menu is a PDF. Once a menu is a PDF, it's a snapshot. Updating it means opening it in InDesign — or more often these days, Canva — making the change, re-exporting, uploading, and hoping the cached version expires. Half the time the PDF link 404s and nobody notices for months because nobody at the restaurant clicks it from outside the office.
The website hasn't been touched since the redesign. A new owner comes in. They hire an agency for the rebrand. The rebrand ships. Two years go by. The site is identical to launch day, including the soft-launch menu the chef wrote in week one.
What it costs
The obvious cost: a guest shows up expecting tagliatelle, doesn't get it, complains, leaves a three-star review naming the dish. You can't reply to that review effectively — the dish isn't on the menu anymore.
The less obvious cost is the part that hurts more over time. Google indexes your old menu. Voice search reads it. Apple Maps quotes from it. A would-be guest searches "vegetarian restaurant near me" and you don't surface because last year's menu was meat-heavy. You've already pivoted in the kitchen, but the search engines haven't pivoted with you.
The least obvious cost is reputation drift. People stop trusting your menu page. They text the restaurant before coming in. The host has to read the menu over the phone. The phone rings during prime service. Eventually the menu page stops being load-bearing and the restaurant operates without one.
What works
The restaurants whose menus do match the kitchen are mostly the ones whose menu lives in exactly one place — a single source of truth — edited by the chef, and propagated automatically to every surface that needs to know about it.
That surface chain is the hard part. If it's "edit a Google Doc, then SOMEONE has to remember to update the website," it's going to drift. The fix isn't a more committed somebody. The fix is removing the step.
We're building MenuPublish because we think that surface chain should not be SOMEONE's job. It should be a side effect of cooking. The chef snaps a photo of the new menu, texts it in, and everything downstream updates itself — website, schema.org data, Apple Maps feed, the lot.
If you run a restaurant and the above sounds painfully familiar, the demo's here. Text us a photo of your menu and see what comes out the other side.