ERRORED_DOCUMENT_REQUEST high
Lighthouse returned error: ERRORED_DOCUMENT_REQUEST
PageSpeed could not fetch the page's main HTML document, so the run failed before any analysis started.
What you see
Lighthouse returned error: ERRORED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Status code: 403)
What’s actually happening
PageSpeed errors out immediately and the message often includes a status code or a net:: error. Unlike NO_FCP, the page never even started rendering — Lighthouse couldn't get a usable response for the document request itself. The URL opens normally for you because the block is aimed at Google's fetcher, not at human browsers. The status code in parentheses is the single most useful clue, so read it before doing anything else.
Common causes
- A 403 or 406 from a WAF, bot-protection rule, or security plugin that flags Google's PageSpeed user-agent as a scraper
- net::ERR_TIMED_OUT — the server accepted the connection but never finished sending the document within the budget
- A geographic or firewall rule that rejects traffic from Google's testing data-center IP ranges (us-central, etc.) while allowing your country
- A redirect loop or a redirect to a URL that itself errors, so the final document request never returns 200
- TLS/SSL handshake failure on the fetched URL — expired cert, missing intermediate chain, or protocol mismatch that the browser tolerates but the fetcher does not
How to fix it
- Read the status code and reproduce it as a botRun `curl -A "Mozilla/5.0 (compatible; Chrome-Lighthouse)" -I https://yoursite.com`. If curl gets a 403 while a normal browser gets 200, a bot rule is the cause. A hang means a timeout; a cert warning means TLS.
- Allowlist the Lighthouse/Google fetcherIn Cloudflare, Sucuri, Wordfence, or your WAF, add an exception for the `Chrome-Lighthouse` user-agent and for Google's published IP ranges. Turn off 'Under Attack' mode and aggressive bot-fight settings while testing.
- Check for redirect chains and loopsRun `curl -ILk https://yoursite.com` and follow every hop. Collapse http→https→www→trailing-slash chains into a single 301 and confirm the final hop returns 200, not another redirect or a 4xx/5xx.
- Validate TLS from outsideTest the exact URL at SSL Labs or with `openssl s_client -connect yoursite.com:443 -servername yoursite.com`. Fix an incomplete chain (add the intermediate cert) or an expired certificate — Lighthouse's fetch is stricter than a forgiving browser.
- Rule out geo/firewall blockingIf curl from your machine works but PageSpeed fails, the block is likely IP- or country-based. Temporarily relax the geo rule, or test from a Google data-center region, to confirm before changing production firewall config.
Stop it recurring
Keep a documented allowlist for known good crawlers (Googlebot, Lighthouse) so security tightening never silently breaks testing and indexing.
Related errors