Not just websites. Experiences.

A PDF menu on your restaurant website makes phone users pinch and zoom. Here's why a real HTML menu page wins for customers, Google and screen readers.
Somewhere right now, a hungry person is standing in a parking lot, pinching and zooming a PDF menu like they’re trying to read a treasure map through a keyhole. The kitchen is open. The food is great. And the website is making them work for a burger.
A PDF menu feels like the easy answer. You already had the file from the print shop, so you uploaded it and called it a day. I get it. But that one file quietly costs you customers, search visibility and a fair amount of goodwill.
The short version
Not bad on its own, just bad as the main event. A PDF is a printed page pretending to be a web page, and phones can tell.
Here’s what I see all the time: the menu link opens a file that’s formatted for an 11 by 17 sheet of paper. On a phone, the text is microscopic. You zoom in, lose your place, scroll sideways, zoom out, and somewhere in there the specials column disappears off the right edge of the planet. Some phones download the file instead of showing it, so now the menu lives in a Downloads folder next to a boarding pass from 2022.
Nobody complains about this. They just pick the place down the street whose menu they could actually read. That’s the part that stings, because you never find out it happened.
Yes, Google can read PDFs. Google lists PDF right there in its file types it can index. So the file isn’t invisible. It’s just a worse version of what you could have.
A PDF doesn’t give you a proper page title, meta description, internal links to your hours and location, or the kind of clear structure that lets a search engine (or ChatGPT, or Google’s AI answers) say “yes, this place has a gluten free pizza and it’s twelve bucks.” When someone asks their phone where to get fish tacos, you want your fish tacos written out in plain text on a page that also says where you are and when you’re open.
And if the menu is a scanned image saved as a PDF? Then it’s basically a photo of words. Good luck to everybody involved.
Because updating a PDF is a pain in the ass, so nobody does it. That’s the real reason PDF menus go stale.
To change one price, somebody has to find the original design file, remember which program it was made in, edit it, export it, upload it, and then hope the old file doesn’t stay cached or keep showing up in search under a different name. So the price change gets put off. Then the seasonal menu gets put off. Then a customer shows up asking for the shrimp special you dropped in March, and your server gets to be the bad guy.
An HTML menu on a page you control turns that into a two minute edit. Change the number, hit update, done. When the fix is that easy, it actually gets done, which is the whole point.
Most PDF menus don’t work well with screen readers, and that’s a bigger deal than it sounds.
A designed menu PDF usually has text in floating boxes, prices in a separate column, decorative fonts and no reading order, so a screen reader can jump around or read nothing useful at all. If the PDF is a scan, there’s no text to read, period. A real web page with headings, lists and plain text works with assistive tech without anyone doing anything special.
The WCAG guidelines are the standard most accessibility audits and ADA website complaints point to, and a menu nobody can read with a screen reader is an easy thing to flag. I’m not a lawyer and I won’t pretend to be one, but I’ll say this: cover your ass and give every customer a menu they can actually use. If you want the bigger picture, I wrote up what I check on my ADA compliance page.
A simple page with your menu written out as real text, grouped under clear headings, with prices next to the dishes. That’s it. No magic.
Starters, mains, drinks, desserts, each as its own section. Dish name, a one line description that sounds like food and not a legal disclaimer, the price. Note dietary stuff right on the item (vegetarian, gluten free, spicy) so people don’t have to call and ask. Put your hours, address and a tappable phone number on the same page, because the person reading your menu is about two minutes from deciding to come in. (While you’re in there, make sure that phone number actually dials. I have a whole rant about phone numbers that don’t tap.)
Keep the PDF if you like it. Link to it at the bottom as “printable menu” for the folks who want to print it or stick it on the fridge. It’s a nice extra. It’s just a lousy front door.
One more thing: food photos. A couple of real shots of the actual dishes, plated and looking like dinner, will do more for that page than any fancy menu design. Skip the stock photo of a salad nobody in your kitchen has ever made.
No need. Keep it as a printable option and link to it from your menu page. Just make sure the HTML menu is the main one and that both say the same prices.
They help people find you, but you don’t control them, and they’re often out of date. Your own site should have the official version, so there’s one place that’s always right.
Every time the real menu changes, same day. If that sounds like a hassle, that’s a sign your menu is stuck in a format that’s too hard to edit.
Your food deserves better than a file people have to squint at. If your menu lives in a PDF and you’d rather it lived on a real page that works on phones, shows up in search and takes two minutes to update, I can build that for you. Tell me a little about your place over on start a project and I’ll take a look. I’ll even read the whole menu without zooming, which is more than most websites can promise.