PageSpeed Insights unavailable

Q: Does PSI being unavailable hurt my rankings?

PSI unavailability itself doesn't. But the causes — robots.txt blocking, redirect loops, auth walls, geo-blocks, slow TTFB — usually do, because Googlebot hits the same wall. Treat the warning as "Google might not be able to render this page either" and check the server response time, HTTPS, and robots.txt findings before anything else.

What this check does

Flags audits where the PageSpeed Insights API returned an error or empty payload instead of a Lighthouse run. This is an informational check, not a pass/fail.

When PSI is unavailable, every downstream performance metric — Lighthouse score, LCP, INP, CLS, server response time — has no data to score against and gets skipped.

Why it matters

Performance is the half of an audit that maps directly to user experience and Core Web Vitals rankings. If PSI can’t load your page, the audit goes dark on the entire Performance module. Worse, the cause is usually something Google’s own crawler hits too — meaning the same failure that blocked PSI is probably hurting indexing, AI crawlers, and real users.

Treat this warning as the front of a checklist, not a one-off API hiccup.

How to fix it

Run through the diagnostic checklist in order. The first match is usually the cause.

1. Reproduce manually.

Open pagespeed.web.dev, paste the exact URL MetricSpot audited, and run it. Three outcomes:

PSI works in the browser. Likely a transient timeout or rate limit. Retry the MetricSpot audit in 30 minutes.
PSI shows the same error. Google’s own infrastructure can’t load the page either. Continue down the checklist.
PSI returns a different URL (after redirects). Your canonical might be redirecting in a loop or to a 404. See cause #2.

2. Check robots.txt for blocking.

curl -sI https://yourdomain.com/robots.txt
curl -s https://yourdomain.com/robots.txt | grep -i -E "user-agent|disallow"

PSI identifies as Chrome-Lighthouse. If your robots.txt blocks it (or blocks * from the audited path), PSI silently fails. See the robots.txt check for the safe configuration.

3. Check for redirect loops or chains.

curl -sIL https://yourdomain.com/page | grep -E "^HTTP|^location:"

PSI follows at most a few redirects before giving up. Common offenders: HTTP→HTTPS→www→non-www chains, locale redirects that bounce indefinitely, marketing-page redirects to /landing/$utm_source. Fix with the redirect chains and redirect HTTP to HTTPS checks.

4. Check for auth walls and IP geo-blocks.

PSI runs from Google’s data centers. If your page requires login, sits behind a Cloudflare bot challenge, is geo-restricted to one country, or your WAF rate-limits Google IPs, PSI gets a 401/403/429 and fails.

curl -sI -H "User-Agent: Chrome-Lighthouse" https://yourdomain.com/page

A 200 here means PSI’s user-agent gets through. A 403 or cf-mitigated: challenge header is your culprit.

5. Check the response status and timeout.

curl -sI -o /dev/null -w "%{http_code} %{time_total}s\n" https://yourdomain.com/page

PSI considers anything non-2xx a failure. Server timeouts above ~30 seconds also fail. If the page is slow to first byte, fix the server response time issue before retrying.

6. When to retry vs investigate.

Retry once after 30 minutes if:

PSI works in the browser for the same URL.
curl -I returns 200 with the Lighthouse user-agent.
No recent changes to robots.txt, WAF rules, or DNS.

Investigate immediately if:

PSI fails for the same URL in the browser.
curl -I returns 4xx/5xx for Chrome-Lighthouse.
The failure has persisted across multiple audits.

Frequently asked questions

Why does PSI fail intermittently on pages that usually work?

The PSI public API has a per-IP rate limit (around 25,000 queries per day with an API key, far less unauthenticated). Bursty audit traffic — yours plus other tools sharing the same egress IP — can briefly exhaust the quota. Single retries 15–30 minutes later almost always succeed.

Does PSI being unavailable hurt my rankings?

PSI unavailability itself doesn’t. But the causes — robots.txt blocking, redirect loops, auth walls, geo-blocks, slow TTFB — usually do, because Googlebot hits the same wall. Treat the warning as “Google might not be able to render this page either” and check the server response time, HTTPS, and robots.txt findings before anything else.

Can I get performance data without PSI?

For a single page, run Lighthouse directly in Chrome DevTools — it bypasses the API entirely. For continuous monitoring, the Chrome User Experience Report (CrUX) exposes real-user field data via BigQuery and the CrUX API even when PSI’s lab runs fail. MetricSpot only consumes PSI today, so the audit still skips those metrics; the data exists, just not in this report.