PageSpeed Insights indisponible

Q: L'indisponibilité de PSI nuit-elle à mes classements ?

L'indisponibilité de PSI en elle-même non. Mais les causes — blocage robots.txt, boucles de redirection, murs d'authentification, géo-blocages, TTFB lent — généralement oui, parce que Googlebot rencontre le même mur. Traitez l'avertissement comme « Google ne peut peut-être pas rendre cette page non plus » et vérifiez temps de réponse serveur, HTTPS et les constats robots.txt avant tout.

Ce que vérifie ce contrôle

Signale les audits où l’API PageSpeed Insights a renvoyé une erreur ou un payload vide au lieu d’un run Lighthouse. C’est un contrôle informatif, pas un pass/fail.

Quand PSI est indisponible, chaque métrique de performance en aval — score Lighthouse, LCP, INP, CLS, temps de réponse serveur — n’a aucune donnée à scorer et est sautée.

Pourquoi c’est important

La performance est la moitié d’un audit qui mappe directement à l’expérience utilisateur et aux classements Core Web Vitals. Si PSI ne peut pas charger votre page, l’audit s’éteint sur tout le module Performance. Pire, la cause est généralement quelque chose que le propre crawler de Google rencontre aussi — ce qui signifie que la même défaillance qui a bloqué PSI nuit probablement à l’indexation, aux crawlers IA et aux vrais utilisateurs.

Traitez cet avertissement comme le début d’une checklist, pas comme un hoquet d’API ponctuel.

Comment corriger

Parcourez la checklist de diagnostic dans l’ordre. La première correspondance est généralement la cause.

1. Reproduire manuellement.

Ouvrez pagespeed.web.dev, collez l’URL exacte auditée par MetricSpot et lancez-la. Trois issues :

PSI fonctionne dans le navigateur. Probablement un timeout transitoire ou une limite de débit. Relancez l’audit MetricSpot dans 30 minutes.
PSI montre la même erreur. L’infrastructure de Google elle-même ne peut pas charger la page. Continuez la checklist.
PSI renvoie une URL différente (après redirections). Votre canonique boucle peut-être ou redirige vers un 404. Voir cause #2.

2. Vérifier robots.txt pour blocage.

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

PSI s’identifie comme Chrome-Lighthouse. Si votre robots.txt le bloque (ou bloque * du chemin audité), PSI échoue silencieusement. Voir le contrôle robots.txt pour la configuration sûre.

3. Vérifier les boucles ou chaînes de redirection.

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

PSI suit au plus quelques redirections avant d’abandonner. Coupables courants : chaînes HTTP→HTTPS→www→non-www, redirections de locale qui rebondissent indéfiniment, redirections de page marketing vers /landing/$utm_source. Corrigez avec les contrôles chaînes de redirection et redirection HTTP vers HTTPS.

4. Vérifier les murs d’authentification et géo-blocages IP.

PSI tourne depuis les data centers de Google. Si votre page nécessite une connexion, est derrière un challenge bot Cloudflare, est restreinte géographiquement à un pays, ou si votre WAF limite les IP Google, PSI reçoit un 401/403/429 et échoue.

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

Un 200 ici signifie que l’user-agent de PSI passe. Un 403 ou un en-tête cf-mitigated: challenge est votre coupable.

5. Vérifier le statut de réponse et le timeout.

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

PSI considère tout non-2xx comme un échec. Les timeouts serveur au-dessus de ~30 secondes échouent aussi. Si la page est lente au premier octet, corrigez le problème de temps de réponse serveur avant de réessayer.

6. Quand réessayer vs investiguer.

Réessayez une fois après 30 minutes si :

PSI fonctionne dans le navigateur pour la même URL.
curl -I renvoie 200 avec l’user-agent Lighthouse.
Aucun changement récent à robots.txt, règles WAF ou DNS.

Investiguez immédiatement si :

PSI échoue pour la même URL dans le navigateur.
curl -I renvoie 4xx/5xx pour Chrome-Lighthouse.
L’échec persiste sur plusieurs audits.

Questions fréquentes

Pourquoi PSI échoue-t-il par intermittence sur des pages qui fonctionnent habituellement ?

L’API publique PSI a une limite de débit par IP (autour de 25 000 requêtes par jour avec une clé API, bien moins sans). Du trafic d’audit en rafale — le vôtre plus d’autres outils partageant la même IP de sortie — peut brièvement épuiser le quota. Une seule relance 15-30 minutes plus tard réussit presque toujours.

L’indisponibilité de PSI nuit-elle à mes classements ?

L’indisponibilité de PSI en elle-même non. Mais les causes — blocage robots.txt, boucles de redirection, murs d’authentification, géo-blocages, TTFB lent — généralement oui, parce que Googlebot rencontre le même mur. Traitez l’avertissement comme « Google ne peut peut-être pas rendre cette page non plus » et vérifiez temps de réponse serveur, HTTPS et les constats robots.txt avant tout.

Puis-je obtenir des données de performance sans PSI ?

Pour une page unique, lancez Lighthouse directement dans Chrome DevTools — il contourne l’API entièrement. Pour le monitoring continu, le Chrome User Experience Report (CrUX) expose des données de terrain réelles via BigQuery et l’API CrUX même quand les runs lab de PSI échouent. MetricSpot ne consomme que PSI aujourd’hui, donc l’audit saute toujours ces métriques ; les données existent, juste pas dans ce rapport.