Guía para decidir mejor

Cómo detectar errores 5xx que afectan al rastreo de Google

Un informe histórico no demuestra que la URL siga fallando hoy.

Un error 5xx significa que el servidor o una capa intermedia no entregó correctamente la respuesta en ese momento. Si afecta a páginas importantes cuando Google las solicita, puede dificultar el rastreo y la actualización del índice. No infieras la causa por el número: un 500 de PHP, un 502 del proxy y un 503 durante sobrecarga requieren revisar registros distintos.

Confirma que el fallo sigue ocurriendo

En Search Console anota URL, tipo de error y fecha de detección. Prueba la URL pública sin sesión y desde otra red. Repite una muestra de páginas, no una ráfaga que empeore una saturación. Los informes de Google tienen retraso: la inspección en vivo muestra el estado actual de esa URL, mientras el informe histórico puede seguir mostrando el problema anterior. Conserva la hora exacta para comparar con logs.

Separa aplicación, servidor y intermediarios

Un 500 puede coincidir con una excepción PHP o base; abre el log de aplicación sin activar mensajes sensibles para visitantes. Un 502/504 suele implicar respuesta fallida o tardía del origen hacia proxy o CDN; comprueba proceso, tiempo y conexión. Un 503 puede representar saturación o mantenimiento, pero verifica quién lo emitió. Revisa CPU, memoria, procesos PHP, base, disco y reglas WAF a la misma hora. No atribuyas toda respuesta 5xx a bots o al hosting sin evidencia.

Relaciona la incidencia con el rastreo

En logs, verifica si el agente que se identificó como Googlebot era legítimo según la guía oficial de verificación; el nombre del agente se puede falsificar. Comprueba si solo fallaron unas URLs, una ruta dinámica o todo el sitio. Una página cacheada puede responder 200 mientras el origen falla para otras. Si hay un pico de rastreo real, no uses errores 5xx prolongados como herramienta de gestión de carga; corrige capacidad, errores o rutas ineficientes.

Corrige y demuestra recuperación

  1. Identifica el primer fallo con URL y hora.
  2. Aplica el cambio mínimo en la capa responsable y conserva plan de reversión.
  3. Prueba 200 en la URL afectada y en páginas similares; verifica HTML completo, canonical y robots.
  4. Observa logs y métricas durante un periodo representativo para detectar fallos intermitentes.
  5. Solicita validación en Search Console cuando la incidencia esté resuelta; no prometas que el estado histórico cambiará de inmediato.

La lectura de logs y el checklist postmigración completan la investigación. Si necesitas soporte, comparte URL, hora, código y registro saneado, no contraseñas ni datos de clientes.