Una URL que devuelve un código de error HTTP no siempre indica el mismo problema. Entre una solicitud mal formada (400), una página eliminada (404) y un servidor saturado (503), la causa, el impacto en la indexación y los pasos que hay que seguir son radicalmente distintos. Medir las diferencias entre estos códigos permite priorizar las correcciones y limitar los daños en el posicionamiento.
Códigos de error HTTP: diferencias de impacto entre las familias 4xx y 5xx
El primer dígito del código de estado determina dónde se encuentra el problema. Las familias 4xx y 5xx no tienen en absoluto el mismo impacto en el rastreo de un sitio por parte de los robots de Google.
| Código | Familia | Origen del problema | Consecuencia en la indexación |
|---|---|---|---|
| 400 | 4xx (cliente) | URL mal formada, caracteres sin codificar, parámetro ausente | La página se trata como inexistente y se elimina del índice tras varios intentos |
| 403 | 4xx (cliente) | Acceso denegado por el servidor (permisos, .htaccess) | La página no se indexa mientras el acceso siga bloqueado |
| 404 | 4xx (cliente) | Página eliminada, URL modificada sin redirección, enlace roto | La página se elimina del índice de forma progresiva |
| 500 | 5xx (servidor) | Error interno: script defectuoso, configuración dañada | Se ralentiza el rastreo de todo el sitio |
| 502 | 5xx (servidor) | El proxy o la pasarela recibe una respuesta no válida | Igual que el 500: el rastreo se ralentiza |
| 503 | 5xx (servidor) | Servidor no disponible (mantenimiento, sobrecarga) | El rastreo se suspende y las páginas indexadas podrían eliminarse si el error persiste |
La idea clave: un error 5xx persistente puede provocar la eliminación de páginas ya indexadas. En cambio, un 404 aislado no tiene consecuencias reales para el resto del sitio.
Google señala que las respuestas 5xx y 429 ralentizan temporalmente sus robots de rastreo. Si el problema persiste, el impacto se extiende a las demás URL del host. En esta guía detallada se explica cómo corregir una URL de servidor no válida, distinguiendo con precisión cada familia de códigos.
Error en robots.txt: el caso que bloquea el rastreo completo de un sitio
La competencia rara vez aborda este escenario, aunque es el que puede causar los daños más extensos. Una respuesta 5xx en el archivo robots.txt suspende el rastreo de todo el host. Google intenta recuperar este archivo antes de cada sesión de rastreo. Si recibe un error del servidor, prefiere no rastrear nada antes que arriesgarse a acceder a páginas prohibidas.
Por tanto, el diagnóstico empieza por este archivo. Comprobar que se puede acceder a él solo lleva unos segundos: basta con hacer una solicitud directa desde el navegador (tudominio.com/robots.txt). Si la página devuelve un código 200 y contenido legible, el problema está en otra parte.
Cuando el proxy oculta la causa real
Un error 502 o 504 en robots.txt puede deberse a un intermediario (proxy inverso, CDN), y no al servidor de la aplicación. Para aislar el origen, hay que examinar la comunicación entre el proxy y el servidor de origen. Los registros del proxy (Nginx, Varnish, Cloudflare) indican si la solicitud llegó al servidor de origen o si expiró durante el trayecto.
Confundir un timeout del proxy con una caída de la aplicación lleva a realizar cambios innecesarios en el código, cuando el problema está en la configuración de red.
Detectar URL no válidas: métodos y herramientas que conviene combinar
Una sola herramienta no basta. Cada fuente ofrece una perspectiva distinta de la detección y combinarlas permite evitar puntos ciegos.
- El informe «Estadísticas de rastreo» de Google Search Console muestra la frecuencia de los errores que encuentra Googlebot, su tipo (5xx, 404, timeout de DNS) y su evolución a lo largo del tiempo. Es la perspectiva del motor de búsqueda.
- Los registros del servidor (access.log, error.log) ofrecen información detallada sin procesar: dirección IP del cliente, URL solicitada, código devuelto y hora exacta. Permiten detectar picos de errores relacionados con un despliegue o una sobrecarga.
- Un rastreador como Screaming Frog o Sitebulb recorre el sitio siguiendo los enlaces internos y señala cualquier URL que devuelva un código anómalo. También detecta enlaces rotos en el enlazado interno que no son visibles en Search Console.
Combinar Search Console con los registros del servidor sigue siendo el método más fiable. Search Console señala las URL a las que Google no ha podido acceder; los registros revelan por qué y cuándo devolvió el servidor el error.
Error de DNS o timeout: cómo distinguir los falsos positivos
Un problema de DNS no significa que el servidor esté caído. Es posible que no se pueda acceder temporalmente al servidor DNS aunque el sitio funcione con normalidad. Google señala estos casos en Search Console como «Error de DNS». Antes de modificar nada en la aplicación, comprobar la resolución DNS con una herramienta como dig o nslookup permite descartar esta posibilidad.
Corregir errores del servidor: priorizar según el código y la duración
No todos los errores requieren la misma urgencia. Un 503 temporal con una cabecera Retry-After es menos grave que un 500 permanente en una página con mucho tráfico orgánico.
Mantenimiento programado y cabecera Retry-After
El estándar HTTP establece que un servidor puede responder con un 503 e incluir una cabecera Retry-After para indicar a los robots cuándo deben volver. Sin esta cabecera, Google trata el 503 como una incidencia normal y ralentiza el rastreo sin saber cuándo volver a intentarlo. Añadir esta cabecera durante un mantenimiento programado limita las consecuencias para la indexación.
Redirecciones 301 para los errores 404 recurrentes
Una página eliminada que recibía enlaces entrantes pierde todo su valor SEO si sigue devolviendo un 404. Una redirección 301 a la página más pertinente transfiere la mayor parte de las señales. En cambio, redirigir todos los 404 a la página de inicio es contraproducente: Google acaba ignorando estas redirecciones genéricas.
La selección se hace cruzando dos datos: el número de enlaces entrantes a la URL con error (mediante Search Console o Ahrefs) y el volumen de tráfico que generaba antes de eliminarse. Las URL sin enlaces ni tráfico pueden seguir devolviendo un 404 sin consecuencias.
La conclusión principal es que los errores 5xx persistentes afectan al rastreo global del sitio, mientras que los errores 4xx se limitan a la página afectada. Comprobar que se puede acceder a robots.txt y cruzar los informes de Search Console con los registros del servidor son las dos verificaciones prioritarias ante cualquier incidencia.
