Skip to content

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 /menu instead.
  • “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.