Errores de rastreo: guía de diagnóstico y solución

Un error de rastreo ocurre cuando Googlebot intenta descargar una URL de tu sitio y la petición no se completa como debería: el servidor responde con un código de error, la conexión falla, la respuesta tarda demasiado o el propio robots.txt le impide siquiera intentarlo. Es un problema de acceso, no de contenido.

Eso lo distingue de un problema de indexación, y la diferencia importa porque cada uno se diagnostica de forma distinta. Una página puede rastrearse perfectamente bien —respuesta 200, contenido descargado sin incidentes— y aun así no aparecer en el índice, porque lleva una etiqueta noindex, porque un canonical apunta a otra URL, porque Google la considera duplicada o simplemente porque decide que no aporta valor suficiente para mostrarla. Rastrear es si Google consiguió llegar a la página; indexar es si, una vez la vio, decidió guardarla y mostrarla en resultados. Confundir ambos lleva a perder horas revisando la velocidad del servidor o el robots.txt de una página que en realidad se descargó sin ningún problema y fue excluida por una razón completamente distinta.

Dónde se detectan: Search Console y los logs del servidor

El informe de páginas de Search Console agrupa las URL por el motivo de exclusión: "Error del servidor (5xx)", "No encontrada (404)", "Error de redirección", "Bloqueada por robots.txt", "Error de DNS" y varios más. Al entrar en cada motivo se ve una muestra de URL afectadas, útil para detectar patrones —por ejemplo, si todas comparten una plantilla o un directorio.

El informe de estadísticas de rastreo, dentro de Configuración, muestra las peticiones por código de respuesta a lo largo del tiempo, desglosadas por tipo de archivo y por si el rastreo fue de descubrimiento o de actualización. Es más sensible que el informe de páginas: puede mostrar un pico de errores días antes de que ese patrón se refleje en las URL individuales, porque Search Console no vuelve a probar cada URL de inmediato.

Los logs del servidor son la fuente más fiable de todas. Muestran cada petición real hecha por Googlebot —verificable por su rango de IP mediante DNS inverso—, incluidas URL que Search Console nunca llega a mostrar porque solo trabaja con una muestra. El análisis de logs detecta cosas que el panel no ve: errores 500 intermitentes que se resuelven solos en segundos, peticiones que se cortan antes de terminar, o rastreo insistente sobre URL que nunca estuvieron en tu sitemap.

Errores de servidor (5xx): la categoría que exige más urgencia

Un código 500, 502, 503 o 504 significa que el servidor no pudo entregar la página, no que la página no exista. Las causas más comunes son sobrecarga durante ráfagas de rastreo, agotamiento de conexiones a la base de datos, un despliegue que tumbó el sitio unos minutos, o una capa de caché mal configurada que reenvía peticiones a un origen caído.

Para diagnosticarlo, primero hay que saber si el error es constante o intermitente: revisa las marcas de tiempo en los logs y compáralas con los picos de tráfico o con el horario de tus despliegues. Si el error se concentra en una plantilla o un rango de URL concreto —por ejemplo, todas las páginas de un filtro de producto—, el problema suele estar en esa ruta de código, no en el servidor en general.

Si el corte es intencional y breve, como una ventana de mantenimiento, la respuesta correcta es un 503 explícito con cabecera Retry-After, no dejar que el servidor devuelva un error genérico sin control. Google interpreta un 503 puntual como "vuelve más tarde" y no penaliza la página por ello. El problema real aparece cuando los 5xx se sostienen durante días: Google reduce la frecuencia de rastreo de forma progresiva y, si continúa, puede terminar retirando esas URL del índice.

Página no encontrada (404): qué importa y qué es ruido normal

Un 404 no es, por sí solo, un problema. Es el comportamiento esperado de la web: las páginas se retiran, las campañas terminan, los productos se descontinúan. Un 404 en una URL que eliminaste a propósito no necesita ninguna acción, salvo redirigir si existe un destino realmente equivalente para el usuario que llega ahí.

El 404 que sí merece atención es el que no debería existir: un enlace interno con una URL mal escrita, una migración que rompió rutas, un fallo de paginación, o una ruta gestionada por JavaScript que devuelve 404 para una página que en realidad es válida.

La forma de distinguir uno de otro es mirar el origen de la petición. Search Console y los logs indican cómo Googlebot llegó a esa URL: enlace interno, sitemap o enlace externo. Un 404 con varios enlaces internos apuntando hacia él, o presente en tu propio sitemap, es un fallo real que hay que corregir en el origen del enlace, no solo en el destino. Un 404 sin ninguna referencia interna, ausente del sitemap y con rastreo cada vez menos frecuente, es ruido de fondo: Google lo visitará con menos frecuencia con el tiempo y acabará dejándolo fuera sin que tengas que intervenir.

Redirecciones problemáticas: cadenas y bucles

Una cadena de redirección es una URL A que redirige a B, que a su vez redirige a C antes de llegar al destino final. Cada salto añade latencia, consume presupuesto de rastreo y diluye la señal que se transmite entre versiones de la URL. Lo correcto es que A redirija directamente al destino final, en un solo salto.

Un bucle de redirección es el caso extremo: A redirige a B y B redirige de vuelta a A, sin salida. Googlebot abandona el intento después de varios saltos y esa URL queda registrada como error, sin que se sepa a qué contenido debía llegar.

Se detectan revisando los logs en busca de códigos 30x repetidos para la misma URL, o con una herramienta de rastreo que siga las redirecciones hasta el final. La causa más habitual de un bucle accidental es acumular varias reglas de normalización —forzar HTTPS, forzar www o sin www, añadir o quitar la barra final— en un orden que no es coherente entre sí, de modo que cada regla deshace lo que hizo la anterior.

Bloqueado por robots.txt, y fallos de DNS o conectividad

Cuando una URL coincide con una regla Disallow, Google la respeta y ni siquiera intenta descargar el contenido, así que no puede saber si ese contenido cambió. A veces es intencional —bloquear rutas de administración, carritos o combinaciones de filtros que no aportan valor de búsqueda— y a veces es un accidente heredado de un entorno de pruebas, como un Disallow: / que se quedó activo tras mover el sitio a producción. Se comprueba probando la URL exacta contra el robots.txt que está en vivo en ese momento.

Los fallos de DNS y de conectividad son distintos a todo lo anterior: Googlebot no llega a recibir ni siquiera un código de error, porque el dominio no resuelve o la conexión no se establece. Las causas incluyen una configuración de DNS incorrecta, un servicio de protección contra bots que bloquea el rango de IP o el user-agent de Googlebot, o una caída completa del hosting.

Son errores poco frecuentes pero graves: suelen afectar a todo el sitio, no a un patrón de URL concreto, así que cualquier aviso de DNS o conectividad en Search Console merece prioridad alta aunque el recuento de URL afectadas parezca pequeño. El informe tiende a mostrar solo una fracción del problema real cuando la caída es de sitio completo.

Soft 404: la página que responde bien pero no lo está

Un soft 404 es una URL que devuelve un código 200 —técnicamente correcto— pero cuyo contenido se parece a una página de error para quien la lee: un resultado de búsqueda vacío, un aviso de "producto ya no disponible" sin más contenido alrededor, o una plantilla que se quedó sin datos que mostrar. Google la trata como si estuviera rota, aunque el servidor nunca haya devuelto un error real.

Suele aparecer en páginas de categoría o de resultados de filtro que quedan vacías sin cambiar de código de estado, en fichas de producto descatalogado que se dejan publicadas con un texto genérico, o en páginas que dependen de JavaScript y no llegan a cargar el contenido real, dejando solo la estructura vacía de la plantilla.

La solución depende de si la página debería seguir existiendo. Si sí, dale contenido real y verificable. Si no, la respuesta correcta es un 404 o un 410 honesto en vez de un 200 vacío disfrazado de página válida.

Cómo priorizar una lista larga en vez de intentar dejarla en cero

En un sitio real, activo y con historial, la lista de errores nunca llega a cero, y perseguir ese objetivo es tiempo mal invertido. Lo que importa es ordenar la lista por impacto real, no por volumen de URL afectadas.

Tres preguntas ordenan casi cualquier lista: ¿la URL afectada genera tráfico o posiciona hoy, o está enlazada desde páginas importantes o desde el sitemap? ¿es un patrón que se repite en miles de URL de la misma plantilla, o un caso aislado? ¿pertenece a una categoría urgente —5xx sostenidos, fallos de DNS— o a una categoría de fondo, como un 404 en contenido que retiraste a propósito?

• Prioridad alta: 5xx sostenidos, errores de DNS o conectividad, y cualquier patrón que se repita en una plantilla completa.
• Prioridad media: cadenas o bucles de redirección en rutas con tráfico, y soft 404 en páginas que deberían tener contenido real.
• Prioridad baja o ninguna acción: 404 aislados sin enlaces internos, en contenido retirado a propósito y sin presencia en el sitemap.

Cómo confirmar que el arreglo funcionó de verdad

Que la página ya no dé error al probarla en el navegador no confirma nada por sí solo; hay que verificarlo desde la perspectiva de Google. La herramienta de inspección de URL de Search Console permite pedir un rastreo en vivo y comprobar el estado real que Googlebot ve en ese momento, no el que veías en el informe hace semanas.

Después de corregir el origen del problema, usa la opción de validar la corrección dentro del informe de páginas correspondiente: eso le indica a Google que revise ese grupo de URL con prioridad, en vez de esperar a su ciclo normal de reastreo. Aun así, la validación no es instantánea —puede tardar entre varios días y un par de semanas en completarse—, así que no interpretes que un arreglo falló solo porque el recuento no bajó al día siguiente.

En paralelo, vigila la tendencia del código de error en el informe de estadísticas de rastreo durante las semanas siguientes. Una caída sostenida del código correspondiente es la confirmación más fiable de que el arreglo funcionó a escala, más allá de la muestra puntual que revisa la validación.