> For the complete documentation index, see [llms.txt](https://speedyindex-1.gitbook.io/speedyindex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://speedyindex-1.gitbook.io/speedyindex-docs/es/errores-5xx-de-googlebot-en-los-logs-como-encontrarlos.md).

# Errores 5xx de Googlebot en los logs: cómo encontrarlos

Cómo encontrar errores 5xx de Googlebot en los logs del servidor: verificar visitas reales, agrupar por hora y plantilla y decidir qué corregir primero.

Buscar errores 5xx de Googlebot en los logs del servidor es la forma más directa de saber qué vio realmente el rastreador de Google cuando visitó tu web. Search Console te avisa de que hubo problemas de disponibilidad, pero solo con una muestra de URL; el log de acceso, en cambio, guarda cada petición con su hora, su código de estado y su user-agent. Esta guía explica cómo filtrar las visitas reales de Googlebot, aislar las respuestas 500, 502, 503 y 504, agruparlas para encontrar el patrón y decidir qué corregir primero.

## Por qué los 5xx importan más que otros errores

Un 404 le dice a Google que una página no existe. Un 5xx le dice algo distinto: que el servidor no pudo responder. Según la documentación de Google sobre códigos de estado HTTP, los errores 5xx y el 429 hacen que sus rastreadores reduzcan temporalmente la frecuencia de rastreo, y la reducción es proporcional al número de URL que devuelven error. El contenido que llega con un 5xx se ignora. Las URL que ya están indexadas se conservan durante un tiempo, pero las que devuelven error de forma persistente terminan saliendo del índice. Cuando el servidor vuelve a responder con 2xx, Google aumenta el rastreo de nuevo de forma gradual.

Hay un caso especial: el archivo robots.txt. Si robots.txt devuelve 5xx, la ayuda del informe de estadísticas de rastreo indica que durante las primeras 12 horas Google deja de rastrear el sitio y solo sigue pidiendo robots.txt; entre 12 horas y 30 días usa la última versión que pudo descargar; y pasados 30 días el comportamiento depende de si la página principal está disponible. Por eso un 503 en robots.txt es más grave que un 503 en una ficha de producto suelta.

Google también documenta un uso intencionado de estos códigos: para frenar el rastreo de forma urgente durante unas horas o uno o dos días, se puede devolver 500, 503 o 429 en lugar de 200. No recomienda mantenerlo más tiempo, porque si Googlebot ve esos códigos en la misma URL durante varios días, la URL puede salir del índice. Si en tus logs aparecen 503 «planificados» que duran una semana, ahí tienes el primer problema.

## Paso 1: quedarte solo con el Googlebot real

Cualquiera puede escribir «Googlebot» en el user-agent. Antes de contar errores, separa las visitas verificadas de las falsas; si no, acabarás depurando 5xx que en realidad provocó un scraper agresivo.

Google describe dos métodos de verificación:

1. **DNS inverso y directo.** Haz una búsqueda inversa de la IP (`host 66.249.66.1`), comprueba que el nombre termina en `googlebot.com`, `google.com` o `googleusercontent.com`, y después haz una búsqueda directa de ese nombre para confirmar que devuelve la misma IP.
2. **Rangos de IP publicados.** Compara la IP con los archivos JSON que publica Google, por ejemplo `common-crawlers.json` para los rastreadores habituales como Googlebot.

Con miles de líneas, hacerlo a mano no es práctico. Si no quieres montar un script, puedes [analizar los logs de acceso en el navegador](https://indexfixtools.com/es/googlebot-log-analyzer/) con un analizador gratuito que contrasta cada IP con los rangos de Google y muestra los accesos por día, código de estado y URL, incluida una tabla de URL que devolvieron 4xx o 5xx a Google. Así trabajas solo con peticiones que de verdad vienen de Google.

## Paso 2: extraer las respuestas 5xx

En un log en formato combinado (Apache o Nginx), una línea típica tiene este aspecto:

```
66.249.66.1 - - [28/Oct/2026:03:14:07 +0000] "GET /categoria/zapatillas?page=7 HTTP/1.1" 503 512 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
```

El código de estado es el noveno campo. Un primer filtro rápido con herramientas de línea de comandos:

```
grep "Googlebot" access.log | awk '$9 ~ /^5/ {print $4, $9, $7}' > googlebot_5xx.txt
```

Esto da fecha, código y ruta de cada error. Recuerda que el filtro por user-agent no verifica nada: crúzalo con la lista de IP validadas del paso anterior antes de sacar conclusiones.

## Paso 3: agrupar para ver el patrón

Una lista de 2.000 errores no sirve de mucho. Lo que necesitas son grupos, y casi siempre encajan en uno de estos cuatro:

* **Por hora.** Si los 503 se concentran entre las 03:00 y las 03:30, piensa en copias de seguridad, tareas cron o despliegues nocturnos que saturan el servidor.
* **Por plantilla de URL.** Si fallan sobre todo `/buscar?q=`, `?page=` o los filtros de una categoría, el problema suele ser una consulta lenta a la base de datos en esa plantilla, no el servidor entero.
* **Por código.** Un 502 o 504 apunta a la capa intermedia (proxy, balanceador, CDN, tiempo de espera de PHP-FPM o del servidor de aplicaciones); un 500 apunta a un fallo de la propia aplicación; un 503 suele ser saturación o modo mantenimiento.
* **Por proporción.** Diez errores sobre 50.000 peticiones no es lo mismo que diez sobre cien. Calcula el porcentaje de 5xx sobre el total de peticiones verificadas de Googlebot por día.

Con un `sort | uniq -c` sobre la ruta sin parámetros o sobre la hora redondeada ya se ve qué grupo pesa más.

## Paso 4: confirmar qué responde ahora el servidor

El log cuenta lo que pasó, no lo que pasa ahora. Antes de abrir una incidencia, vuelve a pedir esas URL. Para una lista corta de URL afectadas, puedes [comprobar qué responden esas URL a Googlebot](https://es.speedyindex.com/comprobador-errores-5xx/) con un comprobador de errores 5xx que envía la petición con user-agent de Googlebot; es útil para detectar cortafuegos o reglas de seguridad que bloquean a los bots pero dejan pasar a un navegador normal. Si la URL responde 200 desde tu navegador y 5xx con el user-agent de Googlebot, el problema no es de capacidad, sino de configuración.

Después, compara con Search Console. El informe de estadísticas de rastreo (disponible solo para propiedades de nivel raíz) agrupa las respuestas por tipo, entre ellas los errores del servidor (5XX), y muestra el estado del host de los últimos 90 días. Las URL de ejemplo no son exhaustivas, y Google avisa de que sus totales pueden no coincidir con los de tus logs. Usa el informe para confirmar la tendencia y el log para encontrar las URL concretas.

## Paso 5: corregir por orden de impacto

Un orden razonable:

1. **robots.txt y página principal.** Si alguno devuelve 5xx, es lo primero.
2. **Plantillas con más URL indexables afectadas.** Categorías, fichas de producto, artículos.
3. **Errores en horas fijas.** Mueve las tareas pesadas, limita la concurrencia o añade caché a la plantilla lenta.
4. **Bloqueos de seguridad.** Revisa reglas del WAF o del CDN que traten a Googlebot verificado como tráfico sospechoso.
5. **Mantenimiento.** Si necesitas cortar el servicio, usa 503 con cabecera `Retry-After` y que sea breve.

Cuando el servidor vuelva a responder con normalidad, no hace falta hacer nada especial: Google recupera la frecuencia de rastreo de forma gradual. Sigue revisando el log unos días para confirmar que la proporción de 5xx baja de verdad.

## Errores habituales

* Contar como Googlebot cualquier línea que lo mencione en el user-agent, sin verificar la IP.
* Mirar solo Search Console y dar por buena su muestra de URL como lista completa.
* Devolver 200 con una página de error en lugar de un 5xx real: Google puede tomarla por contenido válido o marcarla como soft 404.
* Usar 503 como «pausa» durante semanas en una migración o rediseño.
* Arreglar URL una a una cuando el fallo está en una plantilla compartida.

## Lista de comprobación rápida

* [ ] Visitas de Googlebot verificadas por DNS o por rangos de IP.
* [ ] Errores 5xx extraídos con fecha, código y ruta.
* [ ] Errores agrupados por hora, plantilla y código.
* [ ] Porcentaje diario de 5xx calculado.
* [ ] URL afectadas comprobadas de nuevo con user-agent de Googlebot.
* [ ] robots.txt y página principal responden 200.
* [ ] Tendencia confirmada en el informe de estadísticas de rastreo.

## Fuentes

* Google Search Central: [Cómo afectan los códigos de estado HTTP a los rastreadores de Google](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes)
* Google Search Central: [Reducir la frecuencia de rastreo de Googlebot](https://developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate)
* Ayuda de Search Console: [Informe de estadísticas de rastreo](https://support.google.com/webmasters/answer/9679690)