When a competitor menu won't read
Restaurants run on every kind of website. Crisp HTML pages read perfectly; heavy app-style sites where the menu only appears after clicking around can’t be navigated.
The rule
A failed read never hides what you already captured, and never costs you credits. Uploading your own photos is always available as the way in.
What each message means
- “We couldn’t reach that link” — the site is down or the URL changed.
- “This site blocks automated reading” — a bot wall. The system already retried with a real browser, which gets through most; you only see this when even that was refused.
- “That link didn’t look like a menu” — it’s a homepage or blog. Find a URL ending in
/menuinstead. - “We don’t have any menu photos from Google yet” — run Refresh from Google on the Google tab first.
Each message carries the fastest working next step — a Try their Google menu photos button if they have any, Upload their menu instead if not.
Sites that block repeatedly
After several refusals the tab stops offering a retry — a site that’s turned us away four times won’t open on the fifth. You still get the working routes up front, and you can paste a different link if the stored one was simply wrong.
What it costs
- A read that fails refunds itself. Retrying a hostile site costs nothing.
- When a bot-walled site does open on the browser retry, that retry adds a few credits per page, shown as its own line on your usage.
- If it still fails after those pages, they’re refunded too.
- The automatic monthly refresh quietly stops re-trying a site that keeps blocking, and picks back up the moment it lets us in.
If it seems stuck
A read takes 15–30 seconds. A stalled one clears itself within minutes — you don’t need to refresh.
Two things make an upload read cleanly first time: a page or two at a time, and normal phone photos rather than huge scans, which the reader can reject.
Related features
- Competitor menus — capturing a menu in the first place
- Comparing menus with Nina — what to do once you have one