PageSpeed Insights no disponible

Qué comprueba esta verificación

Marca auditorías donde la API de PageSpeed Insights devolvió un error o un payload vacío en lugar de una ejecución de Lighthouse. Es una comprobación informativa, no un pass/fail.

Cuando PSI no está disponible, cada métrica de rendimiento dependiente — puntuación de Lighthouse, LCP, INP, CLS, tiempo de respuesta del servidor — se queda sin datos contra los que puntuar y se omite.

Por qué importa

El rendimiento es la mitad de la auditoría que mapea directamente a la experiencia de usuario y al ranking por Core Web Vitals. Si PSI no puede cargar tu página, la auditoría se apaga en todo el módulo de Performance. Peor: la causa suele ser algo que también golpea al propio crawler de Google — es decir, el mismo fallo que bloqueó PSI probablemente esté perjudicando la indexación, a los crawlers de IA y a los usuarios reales.

Trata este aviso como el inicio de una checklist, no como un hipo puntual de la API.

Cómo arreglarlo

Pasa por la checklist de diagnóstico en orden. La primera coincidencia suele ser la causa.

1. Reproduce manualmente.

Abre pagespeed.web.dev, pega la URL exacta que auditó MetricSpot y ejecútala. Tres salidas:

• PSI funciona en el navegador. Probablemente un timeout transitorio o un rate limit. Reintenta la auditoría de MetricSpot en 30 minutos.
• PSI muestra el mismo error. La propia infraestructura de Google tampoco puede cargar la página. Sigue por la checklist.
• PSI devuelve una URL distinta (tras redirecciones). Tu canonical puede estar redirigiendo en bucle o a un 404. Ver causa #2.

2. Comprueba bloqueos en robots.txt.

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

PSI se identifica como Chrome-Lighthouse. Si tu robots.txt lo bloquea (o bloquea * en la ruta auditada), PSI falla en silencio. Mira la comprobación de robots.txt para la configuración segura.

3. Busca bucles o cadenas de redirección.

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

PSI sigue como mucho unas pocas redirecciones antes de rendirse. Infractores habituales: cadenas HTTP→HTTPS→www→non-www, redirecciones de locale que rebotan indefinidamente, redirecciones de marketing a /landing/$utm_source. Arréglalas con las comprobaciones de cadenas de redirecciones y redirigir HTTP a HTTPS.

4. Busca muros de auth y bloqueos geográficos por IP.

PSI corre desde los data centers de Google. Si tu página requiere login, está detrás de un challenge de bot de Cloudflare, está geo-restringida a un país, o tu WAF rate-limitea las IPs de Google, PSI recibe un 401/403/429 y falla.

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

Un 200 aquí significa que el user-agent de PSI pasa. Un 403 o una cabecera cf-mitigated: challenge es tu culpable.

5. Comprueba estado de respuesta y timeout.

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

PSI considera cualquier respuesta no-2xx un fallo. Los timeouts de servidor por encima de ~30 segundos también fallan. Si la página tarda al primer byte, arregla el problema de tiempo de respuesta del servidor antes de reintentar.

6. Cuándo reintentar vs. investigar.

Reintenta una vez tras 30 minutos si:

• PSI funciona en el navegador con la misma URL.
• curl -I devuelve 200 con el user-agent de Lighthouse.
• No ha habido cambios recientes en robots.txt, reglas de WAF o DNS.

Investiga ya si:

• PSI falla con la misma URL en el navegador.
• curl -I devuelve 4xx/5xx para Chrome-Lighthouse.
• El fallo persiste entre varias auditorías.

Preguntas frecuentes

¿Por qué falla PSI de forma intermitente en páginas que normalmente funcionan?

La API pública de PSI tiene un rate limit por IP (alrededor de 25 000 consultas al día con API key, mucho menos sin autenticar). El tráfico de auditoría en ráfagas — el tuyo más el de otras herramientas que comparten la misma IP de salida — puede agotar la cuota brevemente. Un solo reintento 15–30 minutos después casi siempre funciona.

¿Que PSI no esté disponible me hace daño en el ranking?

Que PSI no esté disponible no, en sí. Pero las causas — bloqueos en robots.txt, bucles de redirección, muros de auth, geo-bloqueos, TTFB lento — sí, porque Googlebot se choca contra el mismo muro. Trata el aviso como un “puede que Google tampoco esté renderizando esta página” y revisa los hallazgos de tiempo de respuesta del servidor, HTTPS y robots.txt antes que nada.

¿Puedo obtener datos de rendimiento sin PSI?

Para una sola página, ejecuta Lighthouse directamente en Chrome DevTools — se salta la API por completo. Para monitorización continua, el Chrome User Experience Report (CrUX) expone datos de campo de usuario real vía BigQuery y la API de CrUX incluso cuando las ejecuciones de lab de PSI fallan. MetricSpot hoy solo consume PSI, así que la auditoría sigue omitiendo esas métricas; los datos existen, simplemente no entran en este informe.