One slow API turned 3,000 pages blank — only for the crawler.

One slow API turned 3,000 pages blank — only for the crawler.

A real-estate platform wrapped its listing details in a Suspense boundary with an error fallback. If the data fetch failed, users saw a friendly 'try again' message. Reasonable. Then 3,000 listing pages dropped out of the index in a month.

The symptom: the pages users loaded looked fine on retry, but URL Inspection's rendered HTML showed the error fallback — 'Something went wrong' — for most of them.

Turns out Googlebot renders with tight resource limits and no patience for retries. The listing API was slow under crawl load; when the fetch exceeded the render timeout, Suspense tripped the error boundary, and Googlebot indexed the fallback. Every page that timed out during render became, to Google, an error page with no listing content. Users never hit it because they'd retry — the crawler renders once.

We moved the listing fetch to the server render with a generous timeout and a cached fallback to last-known-good data, so the crawler always got real content, never the error UI.

Indexed listings recovered from 'error fallback' to full content over five weeks. The 3,000 pages came back. Organic to listings +61% over two months.

Your error boundary is a real page to Googlebot. Make sure it's not the one it indexes.