Problemas de rastreo: cómo depurarlos y resolverlos

Problemas de rastreo: qué son y por qué se depuran antes que nada

En la guía pilar dejamos clara una idea: la depuración SEO funciona por capas. Y la primera capa es siempre la misma: rastreo.

En esta parte vamos a depurar la pregunta más básica (y más importante): ¿puede Google llegar a tus URLs y dedicarles recursos de forma eficiente?

Cuando hay un problema de rastreo, se suele notar de dos formas:

• Problema de acceso: Google no puede llegar (bloqueos, errores, timeouts, respuestas raras).
• Problema de eficiencia: Google podría llegar… pero pierde tiempo (URLs infinitas, redirecciones en cadena, arquitectura que obliga a demasiados pasos, lentitud).

Ambos son graves. El primero es un “muro”. El segundo es una fuga de recursos que, con el tiempo, acaba dejando fuera lo importante.

Rastreo vs indexación: cómo no confundir capas

Una confusión habitual es llamar “problema de indexación” a cualquier cosa que implique que una URL no aparece en Google. Pero el rastreo va antes.

Esto importa porque cada capa tiene sus propias “pistas” y sus propios arreglos. En rastreo, las preguntas suelen ser:

• ¿Estoy bloqueando sin querer? (robots.txt, reglas, seguridad, cabeceras).
• ¿Estoy fallando al responder? (5xx, 429, timeouts).
• ¿Le estoy dando a Google demasiadas URLs inútiles? (parámetros, facetas, búsquedas internas, calendario infinito).
• ¿Lo importante está suficientemente cerca? (enlazado interno, profundidad, sitemaps).

Si lo que te ocurre es que “Google sí llega, pero no guarda lo que quieres”, entonces el capítulo que necesitas es el de problemas de indexación. Pero antes, asegúrate de que realmente no estás en rastreo.

Síntomas típicos: “Google no llega”, descubrimiento lento, picos de errores

Los problemas de rastreo tienen síntomas bastante reconocibles, aunque a veces se camuflan como “caída de SEO”. Estos son los más habituales:

• URLs nuevas que no aparecen (o tardan demasiado) pese a estar enlazadas o en sitemap.
• Directorios completos que se “apagan”: bajan impresiones de golpe en un área concreta del sitio.
• Errores de servidor (5xx) o de rate limiting (429) que aparecen por tandas o en horarios concretos.
• Patrones de 404 persistentes (enlazado roto, migraciones incompletas, URLs generadas automáticamente).
• Rastreo desperdiciado: Google rastrea muchísimo, pero no lo importante (parámetros y combinaciones sin fin).
• Señales intermitentes: “a veces funciona, a veces no” (cadenas de redirección, timeouts, WAF agresivo).

Una pista muy valiosa: cuando el problema afecta a un directorio o a una plantilla, muchas veces es rastreo (o renderizado/indexación), no “posicionamiento”. El patrón suele delatar la capa.

En esta guía no vamos a convertir el rastreo en una lista infinita de checks. Vamos a trabajar como en el pilar: acotar, formular hipótesis y confirmar con evidencias.

La regla de la guía: si no rastrea, no hay nada que posicionar

Hay un motivo por el que el rastreo es el primer capítulo: es el tipo de problema que puede hacerte perder semanas si no lo detectas pronto.

Así que en este artículo vamos a depurar el rastreo desde cuatro ángulos:

1. Bloqueos (robots.txt, directivas, cabeceras y conflictos).
2. Respuestas del servidor (5xx, 429, timeouts).
3. Eficiencia (TTFB, crawl budget, velocidad de respuesta).
4. Desperdicio (URLs infinitas, parámetros, facetas, redirecciones y arquitectura).

Y si al final de estos checks confirmas que el rastreo está estable, el siguiente paso lógico de la guía será depuración de problemas de renderizado, porque muchas webs “parecen” accesibles… pero lo que Google procesa no coincide con lo que tú ves.

En el siguiente bloque vamos a entrar en modo operativo: un triaje rápido en 30 minutos para incidencias de rastreo. Ideal cuando hay presión y necesitas ordenar el diagnóstico.

Triage rápido en 30 minutos para incidencias de rastreo

Cuando sospechas un problema de rastreo, lo peor que puedes hacer es empezar por “mirar un poco de todo”. El rastreo se depura bien cuando acotas y haces pruebas que te dan respuestas claras.

Define alcance y patrón (dominio/directorio/plantilla/país/móvil)

El primer paso es separar “todo el sitio” de “una parte del sitio”. Esa distinción cambia completamente el diagnóstico.

• Todo el dominio: suele apuntar a infra (servidor, CDN/WAF, DNS, reglas), cambios globales (robots, headers) o incidentes de disponibilidad.
• Un directorio (/blog/, /categoria/, /producto/): suele ser bloqueo por patrón, cambios en plantillas, reglas específicas o generación de URLs “malas”.
• Una plantilla (solo fichas, solo categorías, solo landings): suele ser un cambio de CMS/front, paginación/facetas o enlaces que dejaron de existir.
• Un país o un dispositivo: puede ser geoblocking, reglas de seguridad, rendimiento desigual o variaciones de contenido/recursos.

Fecha de inicio + “qué cambió” (deploy, CDN/WAF, hosting, reglas)

Una incidencia de rastreo rara vez aparece “por magia”. Casi siempre coincide con un cambio. El objetivo aquí es encontrar la fecha aproximada del punto de inflexión y preguntar: ¿qué pasó esa semana?

Checklist rápido de cambios típicos que afectan a rastreo:

• Cambios en robots.txt o en reglas de acceso.
• Activación o ajuste de CDN/WAF (bloqueos por user-agent, rate limiting, reglas anti-bot).
• Actualizaciones de CMS/plugins que cambian rutas, paginaciones o generan URLs nuevas.
• Migraciones (HTTPS, dominio, estructura, nuevas plantillas).
• Cambios en infraestructura: hosting, balanceador, caché, base de datos.
• Publicaciones masivas o cambios de enlazado interno que disparan el número de URLs.

Regla de supervivencia: si no sabes qué cambió, estás depurando a ciegas. Aunque el cambio no sea “SEO”, puede ser la causa (seguridad, infra, front).

Checklist express por señales (GSC + analítica + logs si hay)

Para triaje, te interesa una combinación mínima de señales:

Si tienes acceso a logs, aquí suelen ser el “juez” cuando hay discusión: confirman si Googlebot está llegando, con qué frecuencia y qué respuestas recibe. Si no hay logs, trabajas con evidencias indirectas (y por eso hay que ser aún más disciplinado con el orden).

Criterios de “urgencia” (bloqueo total vs degradación de eficiencia)

No todas las incidencias de rastreo tienen la misma urgencia. Te dejo una escala práctica:

Salida del triaje: 3 hipótesis como máximo (y una “siguiente prueba”)

El triaje debe acabar con un documento simple: 2–3 hipótesis y la siguiente prueba más barata para confirmarlas.

Hipótesis 1:
- ...
Prueba:
- ...
Criterio de éxito:
- ...

Hipótesis 2:
- ...

Ejemplos de hipótesis de rastreo bien formuladas:

• Bloqueo: “Robots.txt bloquea /categoria/ desde el deploy del viernes”.
• Servidor: “El WAF está respondiendo 429 a Googlebot en horas punta”.
• Eficiencia: “Los filtros generan URLs infinitas y consumen el crawl budget”.

En el siguiente bloque entramos en el primero de los grandes culpables: robots.txt y directivas robots. Veremos cómo se bloquea sin querer, cómo se crean conflictos y cómo probarlo rápido.

Robots.txt y directivas robots: conflictos que bloquean sin querer

Si tuviera que elegir un “culpable habitual” cuando Google deja de rastrear un directorio, empezaría por aquí: bloqueos involuntarios. A veces son obvios (un Disallow: /). Y otras veces son sutiles: un patrón demasiado amplio, un wildcard mal puesto o una directiva en cabecera que nadie recuerda haber activado.

En este bloque vamos a depurar cuatro focos:

1. Errores típicos en robots.txt que bloquean más de la cuenta.
2. Bloqueo de recursos (CSS/JS) que luego “parece” un problema de renderizado.
3. Conflictos entre robots.txt, meta robots y X-Robots-Tag.
4. Cómo probar rápido una URL sin depender de suposiciones.

Errores típicos en robots.txt (patrones demasiado amplios, slashes, wildcards)

Un robots.txt “bienintencionado” puede acabar bloqueando media web si se escribe con prisa. Estos son los fallos que más se repiten:

• Bloqueo global accidental:
  Disallow: / dentro de User-agent: * (o en el user-agent equivocado).
• Patrones demasiado amplios:
  bloquear /categoria cuando querías bloquear /categoria/, o bloquear un prefijo que comparten otras rutas.
• Uso de comodines sin pensar el “alcance”:
  un Disallow: /*? puede ser útil para parámetros, pero también puede cargarse páginas válidas si tu CMS usa querystrings para paginación o tracking interno.
• Reglas contradictorias:
  combinar Disallow y Allow sin comprobar cuál aplica realmente a una URL concreta.
• Versiones duplicadas del archivo:
  cambios en staging, CDN o rutas que hacen que se sirvan robots distintos (por ejemplo, uno para HTTP y otro para HTTPS, o por subdominio).

Si quieres una referencia práctica sobre cómo estructurarlo y evitar errores típicos, aquí encaja bien enlazar a la guía de robots.txt (sobre todo si hay varias áreas del sitio con reglas diferentes).

Bloqueo de recursos (CSS/JS) que después “parece” un problema de renderizado

Este caso es traicionero porque el síntoma final no parece “rastreo”. Tú ves la página perfecta… pero Google procesa una versión incompleta porque no puede acceder a recursos necesarios (CSS/JS) o a endpoints que alimentan contenido.

¿Cómo lo detectas sin complicarte?

• Si tu web es JS-heavy y el contenido “vive” detrás de scripts, revisa si robots está bloqueando rutas como /static/, /assets/, /js/ o dominios de recursos.
• Si usas un subdominio para recursos (CDN), confirma que no tiene su propio robots bloqueando.
• Si el problema aparece tras cambios de front, sospecha de reglas nuevas o refactors que cambiaron rutas de assets.

En el siguiente artículo de la guía (renderizado) profundizamos en “lo que ve Google vs lo que ves tú”. Pero aquí el matiz es importante: antes de depurar renderizado, confirma que Google puede acceder a los recursos necesarios para renderizar.

Conflictos robots.txt vs meta robots vs X-Robots-Tag (y cómo detectarlos)

Para depurar rápido, conviene entender qué controla cada mecanismo. Te dejo una tabla “de nevera”:

El conflicto más común (y más destructivo) es este:

“He bloqueado el directorio en robots para que no aparezca en Google”.

Si bloqueas en robots, Google puede dejar de rastrear esas URLs, pero eso no garantiza que desaparezcan del índice de la forma que esperas. Y, lo más importante: si también has puesto noindex en la página, Google no podrá verlo si no puede rastrear el HTML.

Cómo probar rápido: robots, cabeceras y rastreo con crawler

Cuando hay dudas, no te quedes en “creo que”. Prueba. Aquí tienes un orden rápido que funciona bien:

1. Comprueba si la URL está bloqueada por robots
   Revisa el archivo /robots.txt y testea la URL con un verificador de robots (o con un crawler configurado como Googlebot).
2. Revisa la respuesta del servidor
   ¿Responde 200? ¿Hay redirecciones? ¿Aparecen 5xx o 429? Un “bloqueo” a veces es simplemente un fallo de disponibilidad.
3. Mira cabeceras HTTP
   Busca X-Robots-Tag y confirma si hay noindex, nofollow u otras directivas aplicadas por regla.
4. Mira el HTML (si la URL es accesible)
   Busca <meta name="robots" content="..."> o directivas específicas.
5. Rastrea a escala pequeña
   En vez de revisar una URL suelta, rastrea un conjunto de URLs del mismo directorio/plantilla. Los problemas de robots suelen ser patrones, no casos aislados.

Mini-checklist de diagnóstico (para pegar en tu documento de incidente)

URL afectada:
Directorio/plantilla:
¿Robots bloquea? (sí/no)
¿Status code? (200/3xx/4xx/5xx/429)
¿X-Robots-Tag? (sí/no + valor)
¿Meta robots? (sí/no + valor)
¿Patrón repetible en 10-50 URLs similares? (sí/no)
Siguiente prueba:

En el siguiente bloque pasamos al otro gran culpable de rastreo: respuestas del servidor. Veremos qué pasa cuando Googlebot se encuentra 5xx, 429 o timeouts, por qué a veces es “intermitente” y cómo encontrar patrones para corregirlo.

Respuestas del servidor que espantan a Googlebot: 5xx, 429, timeouts

Si robots.txt es el “muro” más típico, los errores de servidor son el “suelo que se hunde”: hoy funciona, mañana no; a ratos responde 200, a ratos devuelve 5xx; y cuando hay carga, aparecen timeouts o rate limiting.

En depuración de rastreo, esto es crítico porque Googlebot aprende: si tu servidor responde mal o de forma intermitente, el bot ajusta su comportamiento para no tumbarlo. Traducción: pasa menos, reintenta más tarde y prioriza menos.

Qué significa realmente “volveré luego” en términos de rastreo

Cuando Googlebot se encuentra errores del lado servidor, suele pasar una de estas cosas:

• Reduce la tasa de rastreo (para no sobrecargarte).
• Reintenta más tarde (pero no siempre cuando tú quieres).
• Se queda “atascado” en un directorio o plantilla que falla y retrasa lo importante.

Mapa rápido de códigos y qué hacer primero

Cómo encontrar patrones (no “errores sueltos”): picos, directorios, horarios

El objetivo aquí no es contar errores. Es responder: ¿qué tienen en común?

Estos son los patrones más útiles (y los que más rápido te llevan a causa raíz):

• Por directorio o plantilla: “falla solo en /producto/” suele apuntar a queries pesadas, inventario, APIs o render server-side.
• Por horario: “falla de 10:00 a 13:00” suele apuntar a picos de tráfico, jobs en background, backups o límites de recursos.
• Por tipo de agente: “solo falla a bots” suele ser WAF/CDN o reglas anti-bot mal calibradas.
• Por país: geoblocking, routing, CDN regional o problemas de latencia.
• Por endpoint específico: “falla cuando hay parámetros” suele ser facetas, filtros o búsquedas internas.

Checklist de evidencias (lo mínimo que deberías sacar)

1. Ejemplos concretos de URLs afectadas (10–20, no 1).
2. Ventana temporal (cuándo empezó y en qué franjas se reproduce).
3. Código de respuesta (5xx, 429, timeout, etc.).
4. Qué componente responde (app, CDN, WAF, balanceador).

Patrón detectado:
- Directorio/plantilla:
- Horario:
- Código/s:
- Componente sospechoso:
- Ejemplos de URLs:

Causas comunes: hosting corto, rate limiting, WAF/CDN, app/DB

Una vez tienes patrón, suele caer en una de estas “familias”:

Plan de corrección en 2 pasos: perspectiva Google (GSC) + evidencia técnica (logs)

Para arreglar incidencias de rastreo por servidor, funciona muy bien este enfoque en dos pasos:

Paso 1: mirar el problema “como Google”

• ¿A qué URLs afecta? ¿un directorio o todo?
• ¿Es persistente o intermitente?
• ¿Hay señales de “Google pasa menos”? (esto lo veremos en el bloque de eficiencia y crawl stats).

Paso 2: confirmar la causa “como ingeniería”

• Logs: requests reales, códigos, user-agent, timing.
• Monitorización: picos de CPU/memoria/DB, latencia.
• Infra/CDN/WAF: reglas que disparan 429/403 o bloquean bots.

Mini-árbol de decisión (rápido)

1. ¿Ves 429 o 403 con patrón? → revisa WAF/CDN/rate limiting.
2. ¿Ves 5xx/timeout por horario? → revisa carga y recursos (infra/app/DB).
3. ¿Ves 5xx solo en una plantilla? → revisa backend/DB/endpoint de esa plantilla.
4. ¿No hay patrón? → aumenta muestra de URLs y revisa si hay cadenas/redirecciones o URLs infinitas (bloques siguientes).

En el siguiente bloque pasamos del “puede/no puede” al “puede, pero le cuesta”: TTFB y eficiencia de rastreo. Ahí es donde se detectan los casos en los que Google no está bloqueado, pero reduce su actividad porque el sitio responde lento o se atasca.

TTFB y eficiencia de rastreo: cuando Google sí puede… pero pasa menos

Hay incidencias de rastreo que no son un “muro”. Google puede acceder, las URLs responden 200… y aun así notas que Google pasa menos, descubre más lento o refresca contenidos con menos frecuencia.

Esto suele ocurrir cuando el sitio es lento de servir (especialmente en backend) o cuando la arquitectura hace que el bot pierda tiempo. En términos prácticos: si tu web “consume” demasiados recursos por request, Google tiende a moderar el ritmo de rastreo para no saturarte (y para optimizar su propio tiempo).

Qué es TTFB y por qué afecta al crawl budget

TTFB (Time To First Byte) es el tiempo que tarda el servidor en empezar a responder. No mide el tiempo total de carga, sino el momento en el que llega el “primer byte”.

En depuración de rastreo, el TTFB es relevante por dos razones:

• Escala: Googlebot hace muchas peticiones. Si cada una tarda más de la cuenta, el coste total de rastrear tu sitio aumenta.
• Estabilidad: cuando hay picos de latencia o timeouts, el bot interpreta que el servidor puede estar al límite y reduce la agresividad.

Cómo medir sin autoengañarte (lab vs real; bot vs usuario)

TTFB es una métrica fácil de malinterpretar si solo miras una herramienta o una sola URL. Para depurar, te interesa medirlo con criterio:

Si quieres profundizar en performance desde una perspectiva más amplia (usuario + SEO), aquí encaja enlazar a la guía de Core Web Vitals. Pero en este capítulo nos centramos en cómo la respuesta del servidor afecta al rastreo.

Cómo leer señales de eficiencia: cuándo sospechar que Google “pasa menos”

Además de sentirlo por síntomas (descubrimiento lento, refresco tardío), hay señales que suelen acompañar problemas de eficiencia:

• Sube el tiempo de respuesta de forma sostenida, especialmente en ciertos directorios.
• Aparecen intermitencias (time-outs, picos de 5xx) en horas concretas.
• Se multiplica el coste por URL (páginas que disparan consultas a DB, llamadas a APIs, etc.).
• Hay demasiadas redirecciones o pasos antes de llegar al 200 final (lo veremos en el bloque de cadenas).

Quick wins habituales (cache, DB queries, CDN, recursos)

Cuando confirmas que el problema es de eficiencia, hay dos enfoques: reducir el coste por request y reducir el número de requests inútiles (lo segundo lo tratamos en el bloque de URLs infinitas).

En cuanto a reducir coste por request, estos “quick wins” aparecen una y otra vez:

1. Caché donde tiene sentido
   Cachear HTML o fragmentos (o el resultado de consultas pesadas) suele ser el mayor acelerador si el contenido no cambia cada segundo.
2. Optimización de base de datos
   Índices, consultas N+1, joins innecesarios, y endpoints que hacen demasiado trabajo por visita (o por bot).
3. CDN y configuración de origen
   Si usas CDN, revisa TTL, cache-control, compresión y que el origen no esté haciendo trabajo “caro” en cada request.
4. Recursos y dependencias críticas
   Reducir llamadas externas y dependencias frágiles (APIs de terceros) mejora estabilidad y evita timeouts.
5. Estabilidad antes que perfección
   Una respuesta consistente “medio rápida” es mejor para rastreo que una respuesta “rapidísima” que cae a ratos.

Checklist para cerrar esta capa (eficiencia)

¿El problema es global o por plantilla/directorio?
¿TTFB alto sostenido o picos por horarios?
¿Hay timeouts/5xx asociados a picos de latencia?
¿El coste por request viene de app/DB/terceros/CDN?
¿Hay quick win de caché o reducción de trabajo por request?
Criterio de éxito:
- Menor tiempo de respuesta + menos intermitencia + rastreo más estable

En el siguiente bloque vamos a tratar el gran devorador silencioso del rastreo: crawl waste. Es decir, cuando Google gasta energía en URLs infinitas (parámetros, facetas, buscadores internos, calendarios) y deja de priorizar lo que te interesa.

Crawl waste: URLs infinitas, parámetros, facetas y buscadores internos

Si tuviera que elegir el problema de rastreo más “silencioso” (y con más capacidad de drenarte a largo plazo), sería este: rastreo desperdiciado. No porque Google no pueda entrar, sino porque entra… y se pierde.

El patrón suele ser el mismo: el sitio genera demasiadas variaciones de URLs (parámetros, filtros, combinaciones) y el bot se pasa el día recorriendo versiones que no aportan valor, mientras lo importante (categorías clave, landings, productos top) se refresca tarde o se descubre lento.

Señales claras de “rastreo desperdiciado” (patrones en logs / millones de combinaciones)

El rastreo desperdiciado no se detecta bien mirando una URL suelta. Se detecta mirando patrones. Estas señales son bastante delatoras:

• Explosión de URLs con parámetros: ?color=, ?talla=, ?orden=, ?page=, ?utm=, etc., combinados sin control.
• Facetas encadenables: filtros que generan miles de combinaciones (marca + color + talla + precio + stock…).
• Buscador interno indexable: páginas de resultados de búsqueda que crean “casi infinitas” variaciones por query.
• Calendarios o paginación sin fin: parámetros que permiten navegar a años futuros/pasados, o paginaciones que se generan aunque no haya productos.
• URLs duplicadas por pequeños cambios: trailing slash, mayúsculas/minúsculas, orden de parámetros, IDs de sesión.

Mini-test (rápido) sin logs: ¿tu sitio “fabrica” infinitud?

Si no tienes logs a mano, aún puedes encontrar pistas:

1. Haz un rastreo parcial del directorio con un crawler y mira cuántas URLs tienen parámetros.
2. Comprueba si el mismo contenido aparece con múltiples URLs (solo cambia el orden de parámetros o un filtro).
3. Busca patrones que se repiten: ?sort=, ?filter=, ?page=999, ?q=.

Qué atacar primero: lo que genera infinitud (no el síntoma)

Cuando detectas rastreo desperdiciado, hay una tentación peligrosa: aplicar un “parche” rápido (por ejemplo, bloquear todo con robots) y dar el tema por cerrado. A veces funciona, pero otras veces solo cambias el síntoma y te cargas el descubrimiento de páginas importantes.

Por eso, el orden recomendado es:

1. Identifica el generador: ¿son facetas? ¿buscador interno? ¿parámetros de orden? ¿paginación que se autogenera?
2. Define qué variaciones sí tienen valor (si las hay): por ejemplo, filtros “indexables” que capturan demanda real (marca X + categoría Y).
3. Reduce combinaciones: limita, normaliza y consolida URLs.
4. Después aplicas directivas (robots/noindex/canonicals) con criterio y pruebas.

Estrategias (con matices): robots, canonicals, noindex, configuración CMS, paginación

No hay una única “solución”. Hay combinaciones, y dependen del tipo de web. Aquí va una guía práctica con matices (para no dispararte en el pie):

Si, durante el diagnóstico, ves conflictos de canónicas o noindex (o dudas sobre qué debería indexarse), lo natural es apoyarte en el capítulo de depuración de problemas de indexación. Aquí nos centramos en el rastreo: en que Google no se pierda y no desperdicie recursos.

Caso especial: ecommerce (filtros) y calendarios (crawl infinito)

Hay dos “monstruos” que se repiten:

Checklist para cerrar “crawl waste”

Generador principal de infinitud:
- Facetas / buscador / paginación / calendario / parámetros

¿Hay patrones claros de URLs inútiles?
¿Existen variantes que sí deban ser accesibles/indexables?
¿Podemos limitar desde origen (CMS/producto) antes de bloquear?
¿Robots bloquea solo lo que debe (sin cortar recursos o rutas críticas)?
¿Hay canonicals/noindex coherentes (si aplican) y sin conflictos?
Criterio de éxito:
- Menos URLs inútiles rastreadas + más foco en URLs clave + descubrimiento más rápido

En el siguiente bloque pasamos a otro motivo por el que Google “podría rastrear” pero no llega a lo importante: descubrimiento. Es decir, cuando la arquitectura y el enlazado interno hacen que las páginas clave estén demasiado profundas, huérfanas o “ocultas” para el bot.

Descubrimiento: cuando Google podría rastrear, pero no encuentra lo importante

Hay un tipo de problema de rastreo que desespera porque “no hay nada roto”: el servidor responde bien, robots no bloquea y no ves 5xx. Sin embargo, Google tarda en encontrar páginas nuevas o no refresca bien las que te interesan.

En muchos casos, la causa no es técnica “dura”. Es de descubrimiento: Google podría rastrear, pero no encuentra (o no prioriza) lo importante, porque la arquitectura y el enlazado lo guían hacia otro sitio.

Enlazado interno y profundidad: páginas huérfanas y “demasiados clics”

En depuración de descubrimiento, hay dos conceptos que conviene tener siempre presentes:

• Profundidad: cuántos clics (o saltos de enlaces) hacen falta para llegar a una URL desde la home o desde nodos fuertes.
• Orfandad: páginas que existen, pero no reciben enlaces internos reales (o casi ninguno).

Checklist práctico para detectar un problema de descubrimiento por arquitectura:

1. ¿Las páginas clave están enlazadas desde nodos fuertes? (home, categorías principales, hubs).
2. ¿Dependen de una paginación profunda? (por ejemplo, llegar a un producto solo desde la página 12 de una categoría).
3. ¿Hay enlaces rotos o cadenas raras? (si una parte del enlazado interno está degradada, Google se queda sin “mapa”).
4. ¿Existen páginas huérfanas? (solo están en sitemap o solo se accede desde búsqueda interna).

Enlazado interno y rastreo están mucho más conectados de lo que parece: un enlazado sano ayuda a que Google descubra y priorice, y un enlazado roto genera cascadas de 404 que ensucian señales y desperdician recursos. Si te interesa el impacto de enlaces rotos, aquí encaja bien la guía de error 404 en SEO.

JS links, navegación filtrada y arquitectura que oculta categorías

En webs modernas, a veces la arquitectura “lógica” existe para el usuario, pero no para el bot. ¿Por qué? Porque el acceso a ciertas zonas depende de:

• Menús o listados generados por JS sin enlaces HTML claros.
• Botones que disparan acciones (onclick) en vez de enlaces reales.
• Filtros que construyen resultados sin URLs estables o sin enlaces rastreables.
• Navegación “infinita” (scroll infinito) sin paginación accesible.

Ojo: esto no significa “evitar JavaScript”. Significa diseñar para que el bot no tenga que adivinar. Y si te encuentras con que la ruta existe pero el contenido no se procesa como esperas, ahí ya saltas al siguiente capítulo: depuración de problemas de renderizado.

Sitemaps como “mapa de descubrimiento” (no como parche)

Los sitemaps son una herramienta muy útil… con un matiz: funcionan mejor como refuerzo de un buen enlazado interno, no como sustituto.

Buenas prácticas de sitemaps orientadas a rastreo (sin convertirlo en religión):

• Solo URLs canónicas y útiles: si metes basura, estás invitando a Google a perder tiempo.
• Segmentación por tipo: por ejemplo, sitemap de categorías, de productos, de posts… (facilita diagnóstico cuando algo “se apaga”).
• Actualización real: si el sitemap no refleja lo que existe, deja de ser un mapa y se vuelve ruido.
• Coherencia con tu arquitectura: el sitemap no debería “inventar” una web paralela.

Si quieres una referencia más amplia (y práctica) sobre cómo plantearlos, puedes apoyar esta sección con la guía de sitemaps.

Señales para priorizar dinero: categorías, landings, fichas clave

En depuración no se trata de “arreglar toda la web”. Se trata de recuperar control sobre lo importante.

Si estás en una incidencia de descubrimiento, prioriza así:

1. URLs que generan negocio (categorías principales, servicios, landings, fichas top).
2. Hubs que distribuyen autoridad interna (categorías madre, guías pilar, listados clave).
3. Fresh content que debería entrar rápido (nuevas URLs que dependen del ciclo de rastreo).

Checklist para cerrar “descubrimiento”

¿Las páginas clave tienen enlaces internos desde nodos fuertes?
¿Hay páginas huérfanas que dependan solo de sitemap o búsqueda interna?
¿La navegación usa enlaces rastreables (no solo JS/acciones)?
¿La paginación y los listados permiten acceso claro a contenido profundo?
¿Los sitemaps están limpios, segmentados y actualizados?
Criterio de éxito:
- URLs clave descubiertas y rastreadas antes + refresco más consistente

En el siguiente bloque vamos a otro foco de desperdicio y fallos intermitentes: redirecciones y cadenas. Ahí es donde el rastreo se convierte en un laberinto y Google gasta recursos en “llegar” en vez de procesar.

Redirecciones y cadenas: el laberinto que consume rastreo

Las redirecciones no son “malas”. Son necesarias: migraciones, consolidaciones, cambios de estructura… El problema aparece cuando las redirecciones se convierten en un sistema en sí mismo: cadenas, bucles, saltos innecesarios, inconsistencias entre versiones (http/https, www/no-www) y patrones que hacen que cada request cueste el doble o el triple.

En rastreo, esto se paga caro: Googlebot gasta su tiempo en llegar a la URL final en lugar de procesar contenido. Y cuando ese coste se multiplica por miles o millones de URLs, el efecto se nota.

Cadenas y bucles: por qué drenan presupuesto y generan fallos intermitentes

Una cadena es cuando una URL redirige a otra, que redirige a otra… hasta llegar al destino final. Un bucle es cuando la redirección te devuelve a un punto anterior (o te deja rebotando entre dos URLs).

¿Por qué esto afecta tanto al rastreo?

• Cada salto es un request extra. Si tienes cadenas largas, multiplicas el coste por URL.
• Aumenta la probabilidad de fallo. Si alguno de los saltos da timeout o 5xx, la URL final se vuelve “intermitente”.
• Ensucias señales. El bot tiene que decidir qué versión es la “real”, y eso puede afectar a descubrimiento y a indexación.

Checklist corto para detectar cadenas:

1. Rastrea el sitio (o un directorio) y revisa la columna de redirecciones.
2. Filtra por URLs con 2+ saltos (o con rutas que pasan por varias versiones).
3. Busca patrones repetidos: http → https → www → slash → URL final.

301/302/307 y consistencia (HTTP/HTTPS, www, slash, parámetros)

En depuración de rastreo, el foco no es “qué código es mejor” de forma abstracta. El foco es: ¿estás siendo consistente?

Problemas típicos de consistencia que generan cadenas o duplicidades:

• HTTP → HTTPS pero además no-www → www (o al revés), y luego trailing slash.
• Slash/no slash que se resuelve con un salto extra por página.
• Parámetros que disparan redirecciones a versiones “limpias” (pero mal implementadas).
• Mayúsculas/minúsculas que fuerzan normalización (y a veces generan bucles raros).

Una forma simple de pensarlo:

Define una versión canónica de URL (https, con o sin www, con o sin slash, política de parámetros) y asegúrate de que cualquier otra versión llegue a ella en un solo salto.

Limpieza práctica: “una redirección, un salto” (y por qué)

Cuando haces limpieza de redirecciones, intenta que el resultado final cumpla estas reglas:

1. Un salto máximo desde cualquier variante hacia la URL final.
2. Sin rutas intermedias que ya no existen o que solo “heredan” migraciones antiguas.
3. Coherencia con tu arquitectura y con tu enlazado interno (idealmente, enlazar directamente a la URL final, sin pasar por redirecciones).

Y ojo con un punto que conecta rastreo con indexación: si hay varias versiones accesibles (y no redirigidas), entras en terreno de duplicados, canónicas y elecciones de Google. Si detectas que Google está eligiendo “otra URL” distinta a la que tú quieres, probablemente también necesitas revisar problemas de indexación (capa superior).

Checklist para cerrar “redirecciones y cadenas”

¿Hay cadenas de 2+ saltos en URLs importantes?
¿Existen bucles o redirecciones intermitentes?
¿Hay consistencia de versión (https, www, slash, parámetros)?
¿El enlazado interno apunta a URLs finales (sin redirecciones)?
¿Se han eliminado redirecciones heredadas innecesarias?
Criterio de éxito:
- Menos saltos por URL + menos errores intermitentes + rastreo más eficiente

En el siguiente bloque veremos cómo validar que el rastreo se ha recuperado (sin cantar victoria pronto): qué señales mirar primero, cómo medir estabilidad, y cómo dejar alertas mínimas para que el problema no vuelva.

Cómo validar que el rastreo se ha recuperado (sin cantar victoria pronto)

Una de las razones por las que la depuración SEO se vuelve frustrante es esta: arreglas algo, lo publicas… y quieres ver el resultado “ya”. Con rastreo, eso rara vez es inmediato a nivel de tráfico, pero sí puedes validar recuperación de forma ordenada.

Qué mirar primero (señales técnicas), y qué mirar después (impacto orgánico)

Para no confundirte, valida en dos niveles:

Si la recuperación técnica no se ve, la orgánica no llegará. Y si la técnica se ve pero la orgánica no, probablemente el problema real estaba en otra capa (renderizado/indexación/posicionamiento).

KPIs por capa (requests, tiempos, errores, directorios activos)

En coherencia con la guía pilar, aquí no vamos a perseguir “métricas bonitas”. Vamos a elegir KPIs que te digan si la capa de rastreo está sana.

Qué señales te indican que “ya puedes subir una capa”

Una pregunta muy práctica: ¿cuándo dejo de mirar rastreo y paso a renderizado o indexación?

Normalmente, cuando se cumplen estos puntos:

• No hay bloqueos involuntarios (robots y reglas) en rutas críticas.
• Los errores 5xx/429/timeouts se han eliminado o reducido a niveles residuales y sin patrón.
• La respuesta del servidor es consistente (sin picos salvajes de latencia en plantillas clave).
• El rastreo desperdiciado está bajo control (o al menos identificado y en contención).
• Las URLs importantes vuelven a aparecer en ciclos de rastreo y refresco razonables.

Alertas mínimas y documentación para que no se repita

La depuración no termina cuando “vuelve”. Termina cuando reduces la probabilidad de recaída. Para rastreo, las alertas mínimas que merecen la pena suelen ser:

• Alerta de 5xx/429 cuando supera un umbral (y segmentada por directorio).
• Alerta de latencia/TTFB (sobre todo p95/p99 en plantillas críticas).
• Alerta de explosión de URLs (parámetros/facetas/buscador interno que se disparan).
• Alerta de cambios en robots (cada cambio debería quedar registrado y revisado).

Lo que se documenta, se depura mejor. Si no hay change log, la próxima vez volverás a empezar desde cero.

Plantilla mínima de validación (para cerrar el incidente)

Incidencia de rastreo:
Fecha inicio:
Ámbito (directorio/plantilla):
Causa raíz:
Arreglo aplicado:
Prueba de recuperación (técnica):
- Ejemplos de URLs (200 estable)
- Errores (5xx/429/timeouts) reducidos
- Latencia/TTFB estable
Validación orgánica (si aplica):
- Impresiones/visibilidad por directorio
Acción preventiva:
- Alerta / checklist / cambio de proceso

En el siguiente bloque vamos a listar los errores comunes al depurar rastreo: los que más hacen perder tiempo o empeoran el problema (bloquear demasiado, confundir rastreo con indexación, tocar muchas cosas a la vez, etc.).

Errores comunes al depurar rastreo y cómo evitarlos

La depuración de rastreo tiene un problema: parece “simple”. Y por eso se cometen errores que no se ven hasta que ya han impactado.

Este bloque es una lista corta de errores frecuentes (los que más incendios crean) y cómo evitarlos sin volver esto burocrático.

Bloquear demasiado (y cargarte descubrimiento)

Es el error número 1: detectas URLs inútiles (parámetros, facetas, paginación) y bloqueas con robots “a lo grande”. A veces aciertas. Pero otras veces bloqueas rutas por las que Google accedía a páginas importantes.

Cómo evitarlo:

• Bloquea por patrón fino, no por directorio completo salvo que tengas certeza.
• Comprueba rutas críticas (categorías, servicios, landings) antes de publicar el cambio.
• Usa una muestra (20–50 URLs) para confirmar que el patrón bloquea lo que quieres y no más.

Intentar “arreglar indexación” solo con robots

Este error viene de confundir capas. Bloquear una URL en robots puede reducir rastreo, pero no es una herramienta “limpia” para controlar qué se indexa.

Si bloqueas rastreo, también bloqueas la capacidad de Google de ver señales dentro de la página (como noindex, canonicals o contenido).

Cómo evitarlo:

• Si el objetivo es no aparecer en Google, prioriza soluciones de indexación (noindex/canonicals) y deja robots para controlar acceso y eficiencia.
• Si hay dudas, consulta el capítulo de depuración de problemas de indexación antes de tomar decisiones que sean irreversibles.

Tocar varias cosas a la vez y perder trazabilidad

En incidencias de rastreo, la presión empuja a “hacer muchas cosas”: ajustar robots, cambiar CDN, tocar caché, limpiar redirecciones, reconfigurar sitemaps… y luego nadie sabe qué arreglo funcionó (o qué cambio rompió otra cosa).

Cómo evitarlo:

1. Define 2–3 hipótesis máximo (como en el triaje).
2. Una prueba por vez cuando sea posible.
3. Documenta el cambio: qué se cambió, cuándo y qué se espera observar.

No usar logs cuando el sitio es grande (y depurar a ciegas)

En sitios grandes, depurar rastreo sin logs es como arreglar una tubería sin ver de dónde sale el agua. Se puede… pero cuesta más, tardas más y te equivocas más.

Cómo evitarlo (sin complicarte):

• Si hay una incidencia real, pide un extracto de logs de 24–72 horas con: URL, status code, user-agent, tiempo de respuesta, timestamp.
• Segmenta: directorio/plantilla primero. No intentes “leer todo”.
• Usa logs para confirmar el patrón y para validar que desaparece tras el arreglo.

Confundir “accesible” con “eficiente”

Que una URL responda 200 no significa que el rastreo esté sano. Puedes tener un sitio 100% accesible, pero con:

• TTFB alto (Google pasa menos).
• Redirecciones en cadena (cada URL cuesta 2–3 requests).
• URLs infinitas (Google se pierde y no prioriza).

Cómo evitarlo:

• Mide estabilidad y coste por request (latencia, saltos, patrones de URLs).
• Haz un “mapa” de qué parte del rastreo se dedica a dinero vs basura.
• Aplica la pirámide: si rastreo está “medio”, no subas con confianza a capas superiores.

Checklist final anti-errores (antes de cerrar el capítulo)

¿Estoy bloqueando solo lo necesario (y he probado URLs críticas)?
¿Estoy usando robots para lo que es (rastreo), no para “arreglar indexación”?
¿He hecho cambios de forma trazable (hipótesis → prueba → criterio)?
¿He buscado patrones (directorios/horarios/plantillas), no casos sueltos?
¿He validado recuperación técnica antes de esperar recuperación orgánica?

En el siguiente (y último) bloque haremos el puente natural dentro de la serie: si rastreo ya está controlado, el siguiente paso de la pirámide es renderizado. Te dejo el enlace directo al capítulo 3.

Preguntas frecuentes sobre problemas de rastreo

Siguiente paso en la guía: depuración de problemas de renderizado

Si has validado que el rastreo está sano (Google puede acceder, el servidor es estable, el desperdicio está bajo control y lo importante se descubre con normalidad), lo lógico es subir un nivel en la pirámide de depuración SEO.

Ahí entra el siguiente capítulo de la guía:

Depuración de problemas de renderizado

En ese artículo veremos casos típicos de SEO “invisible” en webs modernas:

• Contenido que depende de JavaScript y no se renderiza como esperas.
• Recursos bloqueados o fallos de carga que dejan páginas “vacías” para el buscador.
• Diferencias entre lo que ve el usuario y lo que procesa Google (y cómo probarlo).
• Patrones por plantillas que hacen que unas páginas funcionen y otras no.