PageSpeed Insights indisponível

O que esta verificação faz

Assinala auditorias em que a API do PageSpeed Insights devolveu um erro ou payload vazio em vez de uma corrida Lighthouse. Esta é uma verificação informativa, não um pass/fail.

Quando o PSI está indisponível, cada métrica de desempenho a jusante — pontuação Lighthouse, LCP, INP, CLS, tempo de resposta do servidor — não tem dados para pontuar e é saltada.

Porque é importante

O desempenho é a metade da auditoria que mapeia diretamente para experiência do utilizador e rankings de Core Web Vitals. Se o PSI não consegue carregar a tua página, a auditoria fica às escuras em todo o módulo de Desempenho. Pior, a causa é normalmente algo que o próprio crawler da Google também encontra — o que significa que a mesma falha que bloqueou o PSI provavelmente está a magoar a indexação, crawlers de IA e utilizadores reais.

Trata este aviso como a frente de uma checklist, não como um soluço pontual da API.

Como corrigir

Percorre a checklist de diagnóstico por ordem. A primeira correspondência é normalmente a causa.

1. Reproduz manualmente.

Abre pagespeed.web.dev, cola o URL exato que o MetricSpot auditou e corre. Três resultados:

• PSI funciona no navegador. Provavelmente timeout transitório ou rate limit. Repete a auditoria do MetricSpot em 30 minutos.
• PSI mostra o mesmo erro. A própria infraestrutura da Google também não consegue carregar a página. Continua pela checklist.
• PSI devolve um URL diferente (depois de redirecionamentos). O teu canonical pode estar a redirecionar num ciclo ou para um 404. Vê causa #2.

2. Verifica robots.txt para bloqueios.

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

O PSI identifica-se como Chrome-Lighthouse. Se o teu robots.txt o bloquear (ou bloquear * no caminho auditado), o PSI falha silenciosamente. Vê a verificação ficheiro robots.txt para a configuração segura.

3. Verifica ciclos ou cadeias de redirecionamento.

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

O PSI segue no máximo alguns redirecionamentos antes de desistir. Infratores comuns: cadeias HTTP→HTTPS→www→non-www, redirecionamentos de locale que saltam indefinidamente, redirecionamentos de páginas de marketing para /landing/$utm_source. Corrige com as verificações cadeias de redirecionamento e redirecionar HTTP para HTTPS.

4. Verifica auth walls e bloqueios geo de IP.

O PSI corre a partir dos data centers da Google. Se a tua página exige login, está atrás de um challenge de bots do Cloudflare, está geo-restrita a um país, ou o teu WAF aplica rate-limit a IPs da Google, o PSI recebe 401/403/429 e falha.

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

Um 200 aqui significa que o user-agent do PSI passa. Um 403 ou cabeçalho cf-mitigated: challenge é o teu culpado.

5. Verifica o status de resposta e timeout.

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

O PSI considera qualquer non-2xx uma falha. Timeouts de servidor acima de ~30 segundos também falham. Se a página é lenta a entregar o primeiro byte, corrige o problema de tempo de resposta do servidor antes de tentar de novo.

6. Quando repetir vs investigar.

Repete uma vez após 30 minutos se:

• O PSI funciona no navegador para o mesmo URL.
• curl -I devolve 200 com o user-agent do Lighthouse.
• Sem mudanças recentes em robots.txt, regras WAF ou DNS.

Investiga imediatamente se:

• O PSI falha para o mesmo URL no navegador.
• curl -I devolve 4xx/5xx para Chrome-Lighthouse.
• A falha persistiu em várias auditorias.

Perguntas frequentes

Porque é que o PSI falha intermitentemente em páginas que normalmente funcionam?

A API pública do PSI tem um rate limit por IP (cerca de 25.000 queries por dia com uma chave de API, muito menos sem autenticação). Tráfego de auditoria em rajadas — o teu mais outras ferramentas a partilhar o mesmo IP de saída — pode esgotar brevemente a quota. Reentradas únicas 15–30 minutos depois quase sempre funcionam.

O PSI estar indisponível prejudica os meus rankings?

A indisponibilidade do PSI em si não. Mas as causas — robots.txt a bloquear, ciclos de redirecionamento, auth walls, geo-blocks, TTFB lento — normalmente sim, porque o Googlebot bate na mesma parede. Trata o aviso como “a Google pode não conseguir renderizar esta página também” e verifica os resultados de tempo de resposta do servidor, HTTPS e robots.txt antes de qualquer outra coisa.

Posso obter dados de desempenho sem o PSI?

Para uma página única, corre o Lighthouse diretamente no Chrome DevTools — contorna a API totalmente. Para monitorização contínua, o Chrome User Experience Report (CrUX) expõe dados de campo de utilizadores reais via BigQuery e a API do CrUX mesmo quando as corridas de laboratório do PSI falham. O MetricSpot apenas consome PSI hoje, pelo que a auditoria continua a saltar essas métricas; os dados existem, apenas não neste relatório.