Problemas de indexación SEO: causas y cómo solucionarlos

Indexación SEO: el filtro que decide qué “existe” en Google

En los dos capítulos anteriores dejamos dos cosas claras: primero, que Google pueda llegar a tus URLs (rastreo). Segundo, que Google pueda ver y procesar el contenido y sus señales (renderizado).

Ahora toca la capa que suele romperte la cabeza porque es menos “mecánica” y más de decisión:

Indexación es cuando Google decide si una URL merece entrar (o permanecer) en su índice… y con qué versión se queda.

Esto es importante porque, por muy bien que esté tu contenido, si no se indexa (o si Google elige otra URL como canónica), para efectos prácticos esa página no existe en la parte visible del buscador.

Rastreo vs renderizado vs indexación (y por qué se confunden)

Una forma rápida de no mezclar capas:

• Rastreo: ¿Google puede acceder a la URL y a sus recursos sin bloqueos, 5xx/429 o timeouts? (Si no, vuelve a problemas de rastreo.)
• Renderizado: ¿Google procesa el contenido principal y las señales SEO como tú esperas? (Si no, vuelve a problemas de renderizado.)
• Indexación: ¿Google decide guardar esa URL y mostrarla? ¿O la excluye, la agrupa como duplicada, o elige otra canónica?

Síntomas típicos: “la URL está bien, pero no aparece”

La indexación suele presentarse con frases como estas:

• “La URL responde 200 y se ve perfecta, pero no sale en Google.”
• “Search Console dice duplicada / Google elige otra canónica.”
• “Está en el sitemap, pero aparece como ‘detectada’ o ‘rastreada’ y no indexada.”
• “Indexa unas sí y otras no, y parecen iguales.”
• “Nos indexa parámetros o versiones raras, y no la URL que queremos.”

Este artículo está diseñado para que salgas de ese pantano con un método: triaje (acotar patrón), diagnóstico (motivo real de exclusión/elección) y corrección (alinear señales sin romper otras capas).

Triaje en 30 minutos: cómo acotar el patrón y dejar de ir URL por URL

La indexación castiga el “modo pánico”: revisar una URL, luego otra, luego otra… y acabar con 40 pestañas abiertas sin una conclusión clara.

El triaje te saca de ahí con un objetivo muy concreto: en 30 minutos deberías ser capaz de decir una frase como esta:

“Las URLs de la plantilla X están siendo tratadas como duplicadas (Google elige la canónica Y) por un patrón de parámetros y enlazado interno.”

Muestra de URLs + segmentación por plantilla/directorio

Necesitas una muestra pequeña pero representativa. Te recomiendo:

• 6 URLs “afectadas” (que no indexan, o que Google trata como duplicadas, o que tienen canónica rara).
• 2 URLs “control” (misma web, plantilla similar, que sí indexan y funcionan).
• 2 URLs críticas (money pages o páginas que te importa recuperar sí o sí).

Ahora etiquétalas por patrón (sin complicarte):

• Plantilla: categoría / ficha / post / landing / búsqueda interna…
• Variantes: con parámetros, con paginación, con filtros, con trailing slash, etc.
• Profundidad: ¿están bien enlazadas o dependen de paginación/filtros?

Plantilla de triaje (para no perderte)

Patrón sospechoso:
- Plantilla/directorio:
- Variantes (parámetros, filtros, paginación, slash):
- Desde dónde se enlaza:
- Fecha aproximada de inicio:
- "Qué cambió" (deploy, migración, reglas, contenido):
Muestra (10 URLs):
- Afectadas:
- Control:
- Críticas:

Qué mirar primero en Search Console (sin obsesionarte con un informe)

En indexación, Search Console es útil… si no la usas como un oráculo. Lo que queremos es evidencia operativa.

Para el triaje, céntrate en dos cosas:

1. El estado general por tipo (qué grandes grupos están indexados/excluidos).
2. La inspección de URL para confirmar el motivo real en tu muestra.

Orden recomendado (para no perder tiempo)

1. Informe de indexación: identifica el/los motivos dominantes
   Ejemplos típicos: duplicadas, “rastreada actualmente no indexada”, soft 404…
2. Inspección de URL (en la muestra): confirma si hay canónica elegida por Google distinta, si la URL está en sitemap, si se rastreó, etc.
3. Repite el patrón: si 7 de 10 URLs cuentan la misma historia, eso es tu diagnóstico inicial.

Salida del triaje: 3 hipótesis máximo (y la siguiente prueba más barata)

En este punto deberías poder escribir 2–3 hipótesis. Ejemplos típicos:

• Duplicidad/canónica: “Google elige una URL alternativa porque el enlazado interno apunta a esa versión y el sitemap envía otra.”
• Calidad percibida: “La plantilla produce páginas muy similares (thin/repetitivas) y Google prioriza indexar una parte.”
• Señales contradictorias: “Hay noindex/robots/canonicals que se pisan entre sí, y Google opta por excluir.”

Y para cada hipótesis, define una prueba que te dé un “sí/no” sin un proyecto gigante:

Hipótesis 1:
Prueba barata:
- (p.ej. comparar canónica declarada vs seleccionada en 10 URLs; revisar enlazado interno hacia versiones; limpiar sitemap)
Criterio de éxito:
- (p.ej. Google alinea canónica; la URL deja de aparecer como duplicada; aumenta coherencia)

En el siguiente bloque nos metemos con el corazón del capítulo: motivos de exclusión y cómo interpretarlos sin autoengañarte. Ahí veremos duplicadas, “no indexada”, soft 404 y cómo se conectan con causas reales.

Motivos de exclusión más comunes y cómo interpretarlos sin autoengañarte

En indexación, el error típico es leer un motivo de Search Console como si fuera “la causa”. Muchas veces es solo la etiqueta final de una historia más larga.

En este bloque vamos a traducir los motivos más habituales a lo que realmente significan en la práctica, y qué preguntas deberías hacerte antes de actuar.

Duplicadas y “canónica elegida por Google”

Este es uno de los motivos más frecuentes: Google considera que tu URL es una variante de otra y decide indexar otra versión como canónica.

Lo importante aquí no es enfadarte con Google. Es preguntarte:

• ¿Por qué existen varias versiones (parámetros, slash/no-slash, mayúsculas, filtros, paginación)?
• ¿Cuál de ellas estás reforzando con enlazado interno?
• ¿Qué versión estás enviando en sitemap?
• ¿La canonical declarada coincide con la que Google elige?

En el siguiente bloque entraremos a fondo en esto con un enfoque operativo: cómo alinear canonicals, enlazado interno y sitemaps para que Google no tenga dudas.

“Detectada, actualmente no indexada” / “Rastreada, actualmente no indexada”

Estas etiquetas generan mucha ansiedad porque suenan a “Google me ignora”. En realidad, suelen indicar una de estas situaciones (o una mezcla):

• Prioridad: Google ha descubierto la URL, pero no la considera prioritaria para indexarla todavía.
• Calidad percibida: la página aporta poco valor diferencial (thin content, duplicidad semántica, plantillas muy repetidas).
• Señales contradictorias: canonicals, enlazado interno y sitemaps no cuentan la misma historia.
• Inestabilidad: a ratos la página renderiza mal, falla, o cambia (esto conecta con renderizado y rastreo).

En el bloque 6 hablaremos de “elegibilidad” y calidad percibida, porque muchas veces este estado aparece cuando Google no ve valor suficiente para dedicar espacio de índice a toda la colección.

Soft 404 y páginas “vacías con 200”

Un soft 404 es cuando la URL responde con 200 (o con un status “no-error”), pero el contenido que se entrega parece una página vacía, inexistente o sin valor.

Ejemplos típicos:

• Listado sin resultados, pero con 200 y sin alternativas útiles.
• Ficha de producto agotado con una plantilla “muerta” y sin sustitutos.
• Páginas generadas por parámetros/filtros que no aportan contenido real.
• Contenido principal que no se renderiza (y queda un esqueleto).

Tabla rápida: etiqueta vs preguntas que debes hacerte

En el siguiente bloque vamos a la causa más “rentable” de corregir en indexación: canónicas y duplicados. Veremos por qué Google elige otra URL y cómo construir coherencia entre canonicals, enlaces internos y sitemaps para forzar una historia única.

Canónicas y duplicados: cuando Google elige otra URL

Si en el bloque anterior había una etiqueta que se repetía una y otra vez, era esta: duplicada / Google ha elegido otra canónica.

Y aquí va una realidad incómoda (pero útil): en muchos sitios, Google elige otra URL porque tú mismo le estás contando dos historias distintas. Una historia en la canonical “declarada” y otra historia en el enlazado interno, el sitemap, los parámetros o las redirecciones.

Señales que provocan elecciones raras (parámetros, facetas, trailing slash…)

Antes de “arreglar canonicals”, identifica por qué existen varias versiones. Las causas típicas son muy repetitivas:

• Parámetros de filtros/orden/paginación: ?sort=, ?filter=, ?page=, etc.
• Facetas que generan combinaciones casi infinitas (sobre todo ecommerce).
• Slash vs no slash (o inconsistencias por URLs con y sin barra final).
• Mayúsculas/minúsculas (URLs distintas para el mismo recurso).
• Versiones históricas por migraciones: rutas antiguas que aún “viven” (aunque redirijan raro).
• IDs de sesión o tracking (si llegan a indexarse o a enlazarse internamente).

Este punto conecta fuerte con el capítulo 2 de la serie (rastreo): si hay explosión de parámetros/facetas, no solo es un problema de indexación; también puede ser rastreo desperdiciado. Si ves infinitud de variantes, revisa problemas de rastreo para atacar la causa raíz.

Cómo alinear canonicals, enlazado interno y sitemaps

La canonical es una sugerencia muy fuerte… pero pierde fuerza si el resto del sitio empuja en otra dirección. La depuración aquí consiste en que todas las señales apunten a la misma URL “ganadora”.

1) Define la URL ganadora (y escríbelo como norma)

Antes de tocar nada, define una política explícita:

• Versión (https, www/no-www).
• Slash o no slash.
• Política de parámetros (qué se permite y qué no).
• Qué facetas pueden existir (si alguna) como páginas indexables.

2) Canonicals coherentes (y sin contradicciones)

Lo obvio, pero con matices:

• La canonical debe apuntar a una URL 200, indexable y consistente.
• Evita canonicals que incluyen parámetros “accidentales”.
• Si hay paginación o series, decide si cada página es canónica de sí misma o si hay consolidación (según el caso).

3) Enlazado interno: el voto que más pesa en la práctica

Si el enlazado interno apunta a la variante “mala”, Google recibe un mensaje claro: “esta es la que usas de verdad”.

• Actualiza enlaces en menús, listados, breadcrumbs y módulos repetidos para que apunten a la URL ganadora.
• Evita que filtros/ordenadores generen enlaces rastreables a variantes que no quieres consolidar.
• Reduce enlaces hacia URLs con parámetros, especialmente desde zonas fuertes (home/categorías madre).

Si además detectas que tienes enlaces internos rotos, cadenas raras o arquitectura que esconde la versión correcta, puede venirte bien revisar (fuera de esta serie) la parte de enlazado interno y errores, por ejemplo un contenido específico sobre errores 404 en SEO.

4) Sitemaps: solo la versión ganadora

El sitemap no es un “cajón de sastre”. Es un mapa de URLs que quieres que Google trate como canónicas. Por tanto:

• Incluye solo URLs canónicas.
• Evita parámetros, facetas no deseadas, paginaciones inútiles o versiones alternativas.
• Si tienes varios tipos de contenido, segmenta sitemaps por tipo (ayuda mucho a depurar).

Qué hacer cuando “todo parece correcto” y aun así Google elige otra

Si canonicals, enlazado interno y sitemaps apuntan a la misma URL y aun así Google elige otra, suele haber una causa subyacente:

• Contenido realmente duplicado (dos URLs con el mismo contenido y la “otra” está mejor enlazada o tiene más señales).
• Redirecciones/normalizaciones inconsistentes (terminas en otra URL sin darte cuenta).
• Renderizado inconsistente: la señal existe a veces y a veces no (vuelve a renderizado).
• Arquitectura que refuerza la variante alternativa (paginación, filtros, rutas paralelas).

Checklist para cerrar “canónicas y duplicados”

¿He definido una URL ganadora (https, www, slash, parámetros)?
¿La canonical declarada apunta a la ganadora (200, indexable)?
¿El enlazado interno (menús, listados, breadcrumbs) apunta a la ganadora?
¿El sitemap contiene solo URLs ganadoras (sin variantes)?
¿Se han reducido/evitado enlaces a parámetros/facetas no deseadas?
Criterio de éxito:
- Menos "Google eligió otra canónica" + consolidación consistente por plantilla

En el siguiente bloque veremos otra fuente de decisiones contradictorias: noindex, robots y bloqueos. Es el típico caso en el que una señal dice “no indexes” y otra dice “sí, está en el sitemap”, y Google responde… como puede.

Noindex, robots y bloqueos: decisiones que se pisan entre sí

Si “duplicadas y canónicas” es la parte más frecuente, esta es la parte más peligrosa: señales que se contradicen. Y cuando se contradicen, Google no “te hace caso” porque, literalmente, no hay una instrucción clara.

Los tres sospechosos habituales son:

• Noindex (meta o cabecera) para decir “no me indexes”.
• robots.txt para controlar qué se puede rastrear.
• Bloqueos de infraestructura (WAF/CDN) que afectan al acceso y al procesamiento.

Noindex bien aplicado (meta / X-Robots-Tag)

Noindex es la herramienta adecuada cuando tu objetivo es claro: “esta URL no debe aparecer en Google”. Puede aplicarse de dos formas habituales:

• Meta robots en el HTML: <meta name="robots" content="noindex,follow">
• X-Robots-Tag en cabecera HTTP (útil para PDFs, recursos o reglas por patrones): X-Robots-Tag: noindex

Buenas prácticas para noindex en depuración:

• Usa noindex,follow cuando quieras que Google no indexe esa página pero sí siga enlaces hacia contenido importante.
• Evita noindex “temporal” que luego se olvida (muy típico en entornos de pruebas).
• Aplica noindex en páginas realmente prescindibles (filtros, búsquedas internas, páginas de sesión, etc.).

Robots.txt: cuándo ayuda y cuándo te estropea el plan

robots.txt es útil para controlar el rastreo y evitar desperdicio, pero puede ser un desastre si lo usas para “resolver indexación”.

Los conflictos típicos:

• URL bloqueada por robots pero con noindex dentro del HTML (Google no puede ver el noindex).
• URL bloqueada por robots pero incluida en sitemap (señales contradictorias).
• Bloqueo de recursos (JS/CSS) que rompe renderizado y crea “páginas vacías” (soft 404). Aquí conecta con renderizado.

Y, por coherencia con esta guía por capas: si sospechas que robots está afectando al acceso o al render, vuelve a problemas de rastreo y revisa bloqueos y estabilidad.

Bloqueos de infraestructura: WAF/CDN que afectan al acceso y al procesamiento

En indexación, a veces la causa es menos “SEO” de lo que parece. Un WAF o CDN puede:

• Devolver 403 a determinados user-agents o IPs.
• Aplicar rate limiting (429) a recursos o a URLs “de patrón” (por ejemplo, muchas URLs con parámetros).
• Servir contenidos distintos según condiciones (geo, cookies), creando inconsistencias.

¿Qué tiene que ver con indexación? Mucho:

• Si Google no puede acceder, no puede indexar (rastreo).
• Si Google no puede descargar recursos o endpoints, renderiza mal (renderizado).
• Si el contenido cambia o falla de forma intermitente, Google desconfía y prioriza menos.

Mapa rápido de conflictos (para no dispararte en el pie)

Checklist para cerrar “noindex + robots + bloqueos”

¿Estoy usando noindex para no indexar (y no robots)?
¿Hay URLs bloqueadas por robots que también están en sitemap?
¿Bloqueo recursos críticos (JS/CSS) que afectan al render?
¿Hay 403/429/5xx intermitentes por WAF/CDN que rompen el pipeline?
¿Las señales (noindex/canonical) se ven de forma consistente al rastrear?
Criterio de éxito:
- Menos contradicciones + decisiones de indexación más coherentes

En el siguiente bloque veremos la parte menos “técnica” y más decisiva: calidad percibida y elegibilidad. Porque, incluso con señales perfectas, Google puede decidir no indexar colecciones enteras si no ve valor suficiente.

Calidad percibida: indexación no es “premio”, es elegibilidad

Este es el punto que más cuesta aceptar cuando llevas tiempo depurando: Google no indexa “porque sí”, y tampoco indexa todo lo que puede rastrear.

En colecciones grandes, Google se comporta como un editor con espacio limitado: prioriza lo que considera útil, diferente y coherente dentro de tu sitio. Por eso digo que la indexación no es un premio: es una decisión de elegibilidad.

Thin content, plantillas repetitivas, contenido poco útil

El “thin content” no es solo “poco texto”. En indexación, thin suele significar: poca utilidad o poca diferencia frente a otras URLs de la misma colección.

Patrones típicos que disparan problemas de elegibilidad:

• Listados sin sustancia: páginas que solo repiten tarjetas y cambian mínimamente por filtro.
• Landings clonadas: misma estructura y copy con la keyword cambiada.
• Páginas sin intención clara: variantes que no responden a una búsqueda real (combinaciones de facetas infinitas).
• Fichas “huecas”: poca información real, sin diferenciación, sin entidad.
• “Sin resultados” tratadas como páginas normales (y encima con 200).

Señales de valor: entidad, intención, diferenciación

¿Qué cambia la percepción de elegibilidad? Que la página sea claramente útil para una intención y que aporte algo que no aportan sus vecinas.

En la práctica, suele venir de tres palancas:

Qué hacer cuando una colección es demasiado grande para indexarse completa

Esto pasa muchísimo con facetas, filtros, tags, combinaciones por ciudad/barrio, paginaciones profundas, etc. En esos casos, la solución suele ser una combinación de estrategia + técnica:

1. Define un subconjunto indexable: páginas con intención clara y demanda razonable.
2. Consolida variantes: canonical o redirección hacia la versión ganadora.
3. Desindexa lo prescindible: noindex (cuando no aporta valor).
4. Reduce generación de URLs desde origen (arquitectura, filtros, buscador interno).

Checklist para cerrar “calidad percibida”

¿La página responde una intención clara o es una variante sin sentido?
¿Aporta valor diferencial respecto a URLs vecinas (o es plantilla clonada)?
¿Hay páginas sin resultados tratadas como “normales” (200)?
¿Estoy intentando indexar una colección infinita (facetas/filtros/tags)?
¿He definido qué subset merece ser indexable y por qué?
Criterio de éxito:
- Menos "detectada/rastreada no indexada" por colección + más coherencia del índice

En el siguiente bloque veremos una palanca que, sin ser “glamurosa”, suele ser decisiva para indexación: arquitectura y enlazado interno. Es decir, cómo le dices a Google qué es importante y qué no.

Arquitectura y enlazado interno: lo que le dices a Google que es importante

Si tuviera que elegir una sola palanca “silenciosa” que decide indexación en muchísimos sitios, sería esta: cómo está enlazado el sitio.

La arquitectura y el enlazado interno son el sistema nervioso del SEO. No solo ayudan a descubrir URLs: también ayudan a Google a decidir cuáles son prioritarias, cuáles son canónicas y cuáles son prescindibles.

Páginas huérfanas: cuando existen pero nadie las respalda

Una página huérfana es una URL que existe (y quizás está en el sitemap), pero prácticamente no recibe enlaces internos desde páginas relevantes del sitio.

¿Qué suele pasar con páginas huérfanas?

• Se descubren tarde o solo por sitemap.
• Se rastrean menos.
• Se indexan de forma irregular (o no se indexan si compiten con otras).

Si detectas páginas huérfanas en zonas importantes (servicios, categorías, guías estratégicas), la corrección suele ser simple: darles un lugar real en la arquitectura.

Profundidad y “señales contradictorias”: cuando lo importante está enterrado

La profundidad no es una métrica mágica, pero sí es un síntoma: cuanto más lejos está una URL de la home y de hubs relevantes, más fácil es que:

• Google la rastree menos.
• La considere menos prioritaria.
• Quede fuera cuando hay mucha competencia interna (colecciones grandes).

Pero el problema no es solo “estar profundo”. Es que, a menudo, lo profundo está ahí por una razón: depende de parámetros, de paginación o de rutas que no están diseñadas para ser indexables.

Enlazado interno y elección de canónica: el “voto” que se nota

Esto conecta directamente con el bloque 4: canónicas y duplicados.

Si tu web enlaza de forma sistemática a:

• URLs con parámetros,
• versiones con trailing slash distinto,
• rutas alternativas por historiales,
• o incluso UTM/trackings,

…Google recibe un mensaje claro: esa es la versión “real” en tu sitio.

Cómo depurarlo sin reventar el sitio

1. Identifica el patrón: ¿dónde se generan los enlaces “malos”? (plantillas, filtros, migas, módulos globales).
2. Corrige en origen: cambia el generador, no enlaces uno a uno.
3. Refuerza hubs: crea páginas “madre” que enlacen a las “hijas” importantes de forma estable.
4. Evita enlaces rastreables a variantes prescindibles: si no quieres que compitan, no las conviertas en “rutas de navegación”.

Qué hacer con paginación y filtros (sin destruir descubrimiento)

Paginación y filtros son una fuente enorme de duplicidad. Aquí no hay una regla universal, pero sí un marco:

• Si una combinación tiene intención clara y valor (y no explota en infinitud), puede ser indexable.
• Si es una variante de navegación (ordenar por precio, filtros arbitrarios), suele ser prescindible y conviene consolidar.
• Si hay riesgo de infinitud, prioriza control desde origen y evita enlaces rastreables a combinaciones “inútiles”.

Checklist para cerrar “arquitectura y enlazado interno”

¿Hay páginas importantes huérfanas o casi sin enlaces internos?
¿Lo importante está enterrado en profundidad excesiva o detrás de filtros?
¿El enlazado interno empuja a la URL ganadora (no a variantes)?
¿Los módulos globales (menú, breadcrumbs, listados) apuntan a URLs canónicas?
¿Estoy generando enlaces rastreables hacia combinaciones infinitas?
Criterio de éxito:
- Más coherencia de rutas + más prioridad para páginas clave + menos duplicidad interna

En el siguiente bloque veremos cómo usar sitemaps de forma inteligente: cuándo ayudan a indexación y cuándo solo añaden ruido, especialmente en sitios con variantes y colecciones grandes.

Sitemaps: cuándo ayudan y cuándo solo añaden ruido

En indexación, el sitemap puede ser una herramienta excelente… o un generador de confusión.

Cuando está bien hecho, un sitemap le dice a Google: “estas son mis URLs canónicas, son importantes y quiero que las proceses”. Cuando está mal hecho, le dice: “aquí tienes 200.000 URLs, muchas duplicadas o prescindibles, apáñatelas”.

Sitemaps limpios: solo canónicas (y por qué esto reduce problemas de indexación)

Un sitemap “limpio” cumple tres cosas:

• Solo incluye URLs que quieres indexar (las ganadoras).
• No incluye variantes (parámetros, facetas no deseadas, versiones con slash distinto, etc.).
• No incluye URLs contradictorias (noindex, redirecciones, 404, soft 404).

Si hoy tienes problemas de duplicidad, un sitemap limpio hace dos cosas:

1. Reduce el ruido (menos variantes compitiendo).
2. Refuerza la historia (la URL ganadora aparece como recomendada).

Segmentación por tipo: el truco que hace la depuración más fácil

Cuando el sitio crece, un sitemap único se vuelve un saco de cosas. La segmentación te permite depurar por “familias” de URLs.

Ejemplos de segmentación útil:

• sitemap-servicios.xml (landings críticas)
• sitemap-categorias.xml
• sitemap-fichas.xml
• sitemap-blog.xml

Cuándo un sitemap NO arregla la indexación (y qué indica)

Hay casos en los que, aunque tu sitemap sea perfecto, muchas URLs siguen sin indexarse. Eso suele indicar que el problema real está en otra parte:

• Calidad percibida baja en la colección (bloque 6): páginas demasiado similares o sin valor.
• Arquitectura débil (bloque 7): páginas huérfanas o enterradas sin señales internas.
• Señales contradictorias (bloque 5): noindex/robots/canonicals que se pisan.
• Renderizado inconsistente: el contenido o las señales no llegan siempre (volver al capítulo 3).

Checklist de “sitemap sano”

¿Incluye solo URLs canónicas que quiero indexar?
¿Excluye parámetros, facetas y variantes prescindibles?
¿No contiene URLs con noindex, redirecciones, 404 o soft 404?
¿Está segmentado por tipo (para depurar por plantillas)?
¿El enlazado interno apunta a las mismas URLs que el sitemap?
Criterio de éxito:
- Menos ruido + más coherencia + decisiones de indexación más estables

En el siguiente bloque veremos cómo validar la recuperación: qué mirar primero (señales técnicas y coherencia) y qué mirar después (indexación y rendimiento), para no confundir progreso real con “picos” temporales.

Validar recuperación: qué mirar primero y qué mirar después

La indexación puede mejorar… y aun así engañarte. A veces sube el número de URLs indexadas, pero Google sigue eligiendo canónicas raras. O deja de marcar “duplicadas”, pero empiezan a aparecer “rastreada no indexada”.

Por eso la validación aquí tiene que ser por capas, igual que en toda la guía: primero confirmas coherencia, luego observas respuesta del índice, y por último conectas con visibilidad y clics.

Qué confirmar primero (coherencia de señales)

Antes de mirar gráficos, valida estas tres cosas en una muestra (como hicimos en el triaje):

1. URL ganadora definida (https, www/no-www, slash, parámetros).
2. Señales alineadas: canonical, enlazado interno y sitemap apuntan a la misma versión.
3. Ausencia de contradicciones: noindex/robots no se pisan, no hay redirecciones raras o cadenas.

Checklist express de validación (por URL)

URL:
¿La canonical declarada apunta a la versión ganadora? (sí/no)
¿Google selecciona la misma canónica? (sí/no)
¿La URL está en sitemap (solo si debe indexar)? (sí/no)
¿El enlazado interno principal apunta a la ganadora? (sí/no)
¿No hay noindex/robots contradictorios? (sí/no)

Qué confirmar después (movimiento del índice por patrón, no por anécdotas)

Cuando las señales están alineadas, lo que buscas es que el comportamiento cambie por plantilla o por directorio, no solo en una URL.

Señales típicas de progreso real:

• Disminuye el volumen de “Google eligió otra canónica” en el patrón afectado.
• Disminuye el número de URLs del patrón que aparecen como duplicadas o alternativas.
• Si la colección es elegible, aumenta el conjunto indexado (pero de forma gradual).
• Se estabiliza la relación sitemap → indexadas (sin picos erráticos).

Qué mirar por último (visibilidad y clics)

La indexación es una capa intermedia. Una URL indexada no garantiza posicionamiento. Pero sí es condición necesaria para competir.

Cuando el índice se estabiliza, entonces sí tiene sentido mirar:

• Impresiones del patrón recuperado.
• Consultas donde la plantilla tiene intención clara.
• Clics y CTR (si además optimizas snippet). Esto conecta con el futuro capítulo de problemas de clics.

Plantilla de validación (para documentar y no “olvidar”)

Patrón (plantilla/directorio):
Cambio aplicado:
Fecha:
Muestra validada:
Resultado técnico:
- Señales alineadas (sí/no)
Resultado en el índice:
- Menos duplicidad / menos canónicas raras (sí/no)
Observación de rendimiento:
- Impresiones/consultas/clics (tendencia)
Siguiente paso:
- (posicionamiento o clics según síntoma)

En el siguiente bloque veremos los errores comunes al depurar indexación: los que hacen que “parezca” que mejoras, pero en realidad estás añadiendo ruido o contradicciones.

Volver al pilar: Guía de depuración SEO.

Errores comunes al depurar indexación

La indexación es el terreno perfecto para los “parches rápidos” que empeoran el problema. Porque muchas acciones aquí tienen efectos masivos y, si no hay coherencia, Google termina eligiendo lo que puede (no lo que tú quieres).

Estos son los errores más frecuentes que veo en depuración de indexación y cómo evitarlos.

Obsesionarte con una sola URL (y perder el patrón)

La indexación se depura por clases de URLs: una plantilla, un directorio, un tipo de parámetro, una colección.

Cómo evitarlo:

• Siempre usa muestra (10–15 URLs) + 3–5 de control.
• Describe el problema como patrón: “todas las categorías con filtro X…”
• Corrige el generador (plantilla/regla), no enlaces uno a uno.

Creer que el sitemap “obliga” a indexar

Un sitemap es una recomendación, no un comando. Si el conjunto es duplicado, thin o contradictorio, Google no indexará todo.

Usar robots.txt para “desindexar”

Bloquear rastreo no es lo mismo que desindexar. Si bloqueas una URL con robots, Google puede dejar de rastrearla y, por tanto, no ver señales como noindex o canonical dentro.

Cómo evitarlo:

• Si quieres que no aparezca: noindex (meta o X-Robots-Tag).
• Si quieres consolidar: canonicals + enlazado + sitemaps + redirecciones.
• Usa robots para eficiencia de rastreo, no como botón “desaparecer”.

Canonical “correcta” con enlazado interno “incorrecto”

Este error explica gran parte de “Google elige otra canónica”: tu sitio enlaza a una variante (parámetros, slash distinto) y la canonical declara otra. Google suele seguir la señal dominante: enlaces internos.

Intentar indexar colecciones infinitas (y luego frustrarte)

Facetas, filtros, combinaciones por ciudad/barrio, tags, paginación profunda… Si intentas indexar todo, Google te va a obligar a elegir (aunque no quieras).

Cómo evitarlo:

• Define un subconjunto indexable (intención clara + valor diferencial).
• Consolida o noindexa variantes de navegación.
• Controla generación desde origen (evita enlaces rastreables a combinaciones inútiles).

Tomar decisiones sin validar “lo que Google procesa”

A veces el problema “parece” indexación, pero el origen es renderizado: el contenido o las señales no llegan siempre, o dependen de JS y fallan por patrón.

Cómo evitarlo:

• Confirma que el contenido principal y señales existen de forma estable (capítulo de renderizado).
• Si hay bloqueos/5xx/429, vuelve a rastreo.

Hacer demasiados cambios a la vez (y no saber qué funcionó)

Es tentador: canonicals, sitemaps, robots, redirecciones, enlaces… todo en un deploy. Pero luego no sabes qué cambió el comportamiento (o qué rompió algo).

Cómo evitarlo:

• 2–3 hipótesis máximo.
• Cambios por lotes + validación con la misma muestra.
• Documenta: qué se cambió y qué esperas observar.

Checklist final anti-errores (indexación)

¿Estoy trabajando por patrón (plantilla/directorio) y con una muestra?
¿El sitemap contiene solo URLs canónicas deseadas?
¿No estoy usando robots.txt para desindexar?
¿Canonicals, enlazado interno y sitemaps cuentan la misma historia?
¿He definido qué subset de la colección merece ser indexable?
¿He validado que el contenido y señales llegan (render) y que no hay bloqueos (rastreo)?
¿He cambiado por lotes y he validado antes/después?

En el siguiente bloque incluiremos las FAQs del capítulo (recuerda: siempre antes del “Siguiente paso”), y luego cerraremos con el puente al capítulo 5: problemas de posicionamiento.

Preguntas frecuentes sobre problemas de indexación

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

Si ya has conseguido que Google:

• acceda a tus URLs sin bloqueos,
• procese el contenido y las señales de forma consistente,
• y además indexe la versión correcta (canónica),

…entonces la siguiente pregunta natural no es “¿por qué no indexa?”, sino:

“Vale, ya está en el índice… ¿por qué no posiciona como debería?”

Ese es el capítulo 5 de esta serie, donde hablaremos de intención, relevancia, competencia, señales internas y externas, y errores típicos que hacen que una página indexada no consiga visibilidad:

Depuración de problemas de posicionamiento

Y si quieres volver al mapa general de la pirámide y navegar por todos los capítulos, aquí tienes el pilar:

Guía de depuración SEO: cómo solucionar problemas de visibilidad