Your PDF menu is costing you customers.

Pull up your restaurant's website on your phone. Go on, I'll wait. Tap the menu. If a PDF opens and you're pinching and dragging to read a burger description, you're losing people at the exact moment they were deciding where to eat tonight.

This is the most common thing I see on restaurant sites and the easiest to fix. It's also worth knowing that it hurts you twice, and the second one is the expensive one.

Problem one: it is miserable on a phone

PDFs were built for paper. They hold one fixed layout no matter what opens them, which is exactly the wrong instinct on a screen someone is holding in one hand while walking.

Picture the person in a parked car, deciding between you and the place across the street. To read your menu, they have to:

• Wait for a file to download, often on cell service rather than wifi
• Watch it open in a separate viewer that leaves your website entirely
• Pinch, zoom, and drag around to read anything
• Find their way back to your site to see hours or tap to call

Every one of those steps is an exit. And the person who takes it doesn't leave a note. They just eat somewhere else, and you never find out.

Problem two: search engines mostly cannot use it

This is the part that costs you people you never even knew were looking.

When the menu lives in a PDF, every dish name, ingredient, and price is basically locked in a box. Search engines can peek at some PDF text, but it's a weak signal compared to a real page, and none of it can be marked up as a menu. Google doesn't know your smash burger exists. Neither does anyone searching for one.

Those long, oddly specific searches are the ones with an actual hungry person on the other end. They're also the ones with almost no competition, because everybody else's menu is locked in a PDF too. It's a wide open lane and nobody's in it.

What a real menu page does instead

An HTML menu is just a normal web page. Sections, dishes, descriptions, prices, all as honest-to-goodness text.

That one change buys you a surprising amount:

• It reads instantly on a phone. No download, no zooming, no leaving your site.
• Every dish becomes findable. Your menu items are now content a search engine can read and match against what people type.
• It can carry structured data. Menu schema tells Google explicitly that this is a menu, these are the sections, these are the items and prices.
• You can update it in minutes. Price change or seasonal special becomes a text edit rather than a redesign, re-export, and re-upload.
• It works for people using screen readers. A scanned or image-based PDF is often completely unreadable to them.

The objection I hear most

"We change the menu constantly, the PDF is easier."

It feels easier because you already know the program and the design's already done. But actually updating a PDF means opening the layout, editing, exporting, uploading, and hoping the cache clears. Updating an HTML menu means changing a line of text. Once it's built right, the page is the fast one. The PDF just feels fast because you've done it forty times.

"Our menu is designed, it needs to look a certain way."

Fair. Protect it. Keep the designed PDF as a download for people who want it and for printing. Just don't make it the only way to find out what you serve.

What to do this week

1. Pull up your own site on your phone and try to find the price of one specific dish. Time yourself.
2. Search Google for one of your signature dishes plus your city. See whether you appear at all.
3. If either answer stings, converting the menu to real pages is usually the highest-return change you can make to a restaurant site. It's also rarely a big project. Usually a day.