Nobody talks about this, but Google Maps menus are photos, not data
A delivery catalogue lead can name every restaurant on a street. What they cannot name, without opening Maps and squinting at a JPEG, is what those kitchens actually charge for a carbonara.
The listing looks structured. Stars, hours, a phone number. The menu is a photograph someone took under a lamp.
The catalogue was never in the tab
Food-tech teams treat Google Maps as the public inventory of a city. Aggregators bootstrap coverage from pins. A chain analyst compares a competitor's lunch set across fifty locations. A dietary database wants the ingredients line, not a vibe.
The workaround is always the same. Open the place. Hope there is a menu tab. There often isn't. Save the photos that look like boards. Drop them in a shared drive. Run desktop OCR, or a summer intern, or both. Paste names into a sheet. Discover in March that the lunch board was replaced in November and the sheet still has last autumn's prices.
That pipeline fails for a boring reason. Maps did not forget to ship you a menu field. For a huge share of independent restaurants, the menu never existed as text on the page. A guest or the owner uploaded a picture of the card. The prices live in pixels.
Nobody talks about this, but Google Maps menus are photos, not data. An HTML pass returns empty because there was nothing to scrape.
Read the photo, keep the source
Once you treat the image as the record, the job gets narrower. Collect the menu photos for a place. Read the visible items. Merge the same pizza that appears on two boards. Keep the photo URL so a person can check a weird price against the pixels it came from.
That is the Google Maps Menu Scraper API. You give it place URLs, Place IDs, or a search like brunch in Austin. You get a flat row per dish: name, description, price, category, language, and the source photo.
Three beats, then you stop:
- Point it at the places you already care about — a list of URLs, or a query that finds them.
- It pulls menu photos and reads what is printed.
- You download items, not a folder of screenshots.
I built it because I was tired of watching teams rebuild OCR folders for a job the photos already contained.
Who this is for, and who should walk away
If you fill menus for a delivery or aggregator catalogue, this is for you. If you track dish prices across a city for hospitality research, this is for you. If a restaurant group asked you to see what the independents nearby charge for the same plate, this is for you.
If you need a legally certified, human-verified menu for live checkout, this is not that. Vision misreads names, invents a special, drops a zero. Handwritten boards and dark photos come back thin. Places with no menu photos produce nothing — that is a missing album, not a bug.
Treat the file as input to your own QA: confidence filters, a spot-check against the photo, a human pass before anything customer-facing. Input, pricing, and the rest of the caveats live on the Apify Store README for Google Maps Menu Scraper.
Tripadvisor is a parallel hole with a different album. If your coverage is traveller reviews more than Maps pins, I wrote separately about extracting menus from Tripadvisor photos.
A screenshot folder is not a menu database
The old cost is not the intern's afternoon. It is the catalogue that silently ages while the board on the wall does not. You cannot diff a JPEG in a shared drive.
If the place is public and the menu is on a photo, read the photo.
The other vision posts on rainminer sit on the same idea: the useful record is often the image the site already published.