
You have a menu. It's a PDF, or a designed graphic, or a photo of the printed one — and you've worked out that Google can't read a word of it. The fix isn't a redesign and it isn't expensive. For most restaurants it's an afternoon of careful work, and a good deal of that afternoon is just typing.
This is the practical version: what to gather, how to get the text out, how to lay the page out, and the two steps at the end that almost everyone skips. If you want the reasoning behind it first, we covered that in why your designed menu is invisible to Google. This is the how.
Half the reason this job stalls is that people begin without deciding things they'll have to decide anyway.
The menu you actually serve today. Not the file from 2023. Walk the kitchen, confirm what's still on and what's gone, and settle the prices before you type a single one. If you're going to raise prices next month, do it now and type the new ones.
A decision about tax. In the Dominican Republic your customer will want to know whether ITBIS and any service charge are included. Decide how you'll state it and state it once, clearly, at the top or bottom of the menu. This one line prevents more friction than anything else on the page.
Both languages, if you serve both. Get the English translation done properly before you build, not after. Retrofitting a second language is far more work than doing them together.
Photos, optionally. They help, but they're not required and they shouldn't hold you up. A text menu with no photos beats a beautiful PDF nobody can read.
Three situations, in increasing order of effort.
If your PDF has real text, this is easy. Open it, select all, copy, paste into a plain document. Test it first: try to highlight a dish name with your cursor. If it highlights, the text is there and copy-paste will work.
If your PDF is a flat image — which it often is when a designer exported it — nothing will highlight. You have two options. Retype it, which for a typical menu is 30–60 minutes and produces the cleanest result. Or run it through an OCR tool that extracts text from images; several are free. If you use OCR, proofread everything, because it reliably mangles accents, prices and dish names — exactly the parts that must be right.
If you only have the printed menu, photograph it in good flat light and OCR that, or just retype it. Retyping is genuinely fine. It's an hour once.
Whichever route, you're aiming for one plain document containing every section heading, every dish name, every description and every price, as ordinary text. Don't format anything yet.
Two workable shapes.
One page, all sections works for most restaurants. Everything on yoursite.com/menu, with section headings the customer can scroll or jump to. It's simpler, and there's only one page to update.
A page per menu makes sense when you genuinely have separate menus — lunch and dinner, or food and a substantial drinks list, or a tasting menu alongside à la carte. Give each its own address: /menu/lunch, /menu/drinks. Each one can then be found on its own for the searches that match it.
What doesn't work is burying the menu inside another page, or hiding it behind a click labelled something clever. The word "Menu" in your main navigation, going to a page whose address contains the word menu. Don't be inventive here.
The mechanics matter less than the fact that every word is text. But some structure choices help.
Section names become headings. Entradas, Platos Principales, Mariscos, Postres. Real headings, not just bold text — that's what lets a screen reader and a search engine understand the shape of the page.
Each dish is a line of text: name, then a short description, then the price. Keep descriptions short and specific — what's in it, how it's cooked. This is also the text that will match what someone searches, so "mofongo con camarones al ajillo" does more for you than "our house special."
Prices as text, next to the dish. Not in a separate image, not in a column that turns into a picture.
Mark the things people filter on: vegetarian, gluten-free, spicy, contains shellfish. A simple label after the dish name is enough.
Say what "market price" means. If lobster is priced by weight, say so and give the current per-pound figure if you can. "Precio según mercado" with no number sends people to ask, and many don't.
The best menus in our study of 64 Dominican restaurants all did this, and it costs nothing:
• Whether prices include ITBIS and service, stated plainly
• Per-pound pricing for seafood, with the current rate
• Any surcharge — gluten-free bread, milk substitutes, extra protein
• Whether the menu differs at lunch and dinner
• Portion notes where it matters, especially for sharing dishes
These sound like small print. They're the difference between a customer deciding and a customer messaging you to ask, then not following up.
If you serve foreign visitors, the English menu needs to be its own page at its own address — /menu and /en/menu, or equivalent — not a button that swaps one image for another.
That's not a preference; it's how search works. Two real pages can each be found by people searching in that language. One page with a toggle can be found by nobody in the second language. It's the same principle we set out in bilingual SEO, applied to the page that matters most.
You don't have to throw it away, and you shouldn't. Some customers want to print it; some staff want to send it on WhatsApp. Put a "Download menu (PDF)" link at the bottom of the web page.
The mistake was never having a PDF. It was having only a PDF.
Once the menu is text, you can tell search engines explicitly what it is. Schema.org defines a Menu type for exactly this — a structured representation of the food and drink a restaurant offers, with sections and items and prices nested inside it — and Google's local business documentation recommends pointing at your menu URL.
This is a job for whoever maintains your site rather than something to hand-write, and the important thing to know is the sequence: it only becomes possible once the menu is real text. You cannot mark up a picture. Get steps one to five right and this one takes a developer minutes; skip them and it's impossible. We go further into what's worth marking up in schema beyond the basics.
This is the step that gets skipped, and it wastes everything above.
Open your Google Business Profile and put the new menu URL in the menu field. Then go and check it as a customer would: search your restaurant on your phone, and click the menu link in the panel.
In our study of 64 Dominican restaurants, one in six had a Google website or menu link pointing at something useless — a deleted Drive file, an expired domain now parked for sale, a 2020 flipbook, a Facebook address with an email pasted onto the end. If your listing still points at the old PDF host, the work you just did is invisible to most of the people looking for you. Our thirty-minute profile audit covers the rest of that listing while you're in there.
The advantage of a text menu is that changing a price takes seconds instead of a trip back to a designer. Use it.
Set a habit: whoever changes a price on the printed menu changes it on the web menu the same day. Once a season, read the whole page as a customer and remove what you no longer serve. And if you have a downloadable PDF, remember it's a second copy that also needs updating — that's the one thing a web menu makes slightly worse, and the fix is just remembering it exists.
Honestly, it depends on your site.
If you can edit your own pages — most modern sites let you — this is a genuinely reasonable DIY job. The typing is the bulk of it, and nobody knows your menu better than you. Do steps one to six yourself, then ask your developer for the structured data.
If your site is old, or you can't edit it, or nobody knows who built it, then this small job runs into a bigger one. That's worth knowing early rather than discovering halfway through, and it may be the nudge that tells you something larger needs fixing.
Either way, the ten Dominican restaurants that got this right in our study — Adrián Tropical, Waterfront Playa Alicia, Vagamundo, NLB Nelson's, Zola, Casa Veintiuno, Jellyfish, El Lugar, El Conuco, Onno's — are not doing anything technically impressive. Their menus are text, with prices, in the right languages, with taxes stated, linked properly from Google. That's the whole standard, and most of it is typing.
At DR Web Studio we build restaurant sites where the menu is real text in both languages, priced, marked up properly and wired to your Google listing — with the first year of maintenance included, so updating a price is a message rather than a project. If you have a PDF menu and would rather hand this over than spend the afternoon, contact us for a free consultation.









