Conflictos en el sitemap, señales de indexabilidad contradictorias, cadenas canónicas y problemas de paginación: las 18 reglas avanzadas de crawlability que determinan si Google rastrea e indexa tu web correctamente.
Resumen: Rastrear una web es como explorar un terreno desconocido con un mapa lleno de contradicciones. Los conflictos entre sitemap y señales de indexación, las cadenas canónicas que se alargan sin llegar a ningún sitio y la paginación sin estructura adecuada son los obstáculos que hacen que Googlebot abandone el recorrido antes de tiempo. Esta guía detalla las 18 reglas avanzadas de crawlability que debes auditar para que los rastreadores puedan mapear tu web sin ambigüedades.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Antes de entrar en las reglas, vale la pena trazar bien el mapa del terreno. Crawlability (rastreabilidad) e indexabilidad son dos etapas distintas del proceso de posicionamiento que a menudo se confunden:
Crawlability es la capacidad de Googlebot de descubrir y visitar tus páginas. Se refiere a si el rastreador puede físicamente llegar hasta una URL: si la ruta no está bloqueada, si hay enlaces que conducen hasta ella, si el servidor responde correctamente. Una página con mala crawlability ni siquiera se evalúa para indexar.
Indexabilidad es la capacidad de una página de ser incluida en el índice de Google una vez ha sido rastreada. Una página rastreable puede no ser indexable si tiene una etiqueta noindex, un canonical que apunta a otra URL o una directiva HTTP que impide la indexación.
La confusión entre ambos conceptos lleva a diagnósticos erróneos: muchos SEO piensan que un problema es de indexabilidad cuando en realidad el rastreador ni siquiera está llegando a esa parte del sitio. Y al revés: configuran correctamente el rastreo pero envían señales de indexabilidad contradictorias que anulan ese trabajo.
El proceso completo tiene este orden: rastreo → indexación → posicionamiento. Un fallo en cualquier punto bloquea los siguientes. Estas 18 reglas cubren específicamente los puntos de fallo más frecuentes y más difíciles de detectar en las fases de rastreo e indexación.
Para cubrir las bases del SEO técnico — robots.txt, sitemap básico, páginas 404 y códigos de error — consulta nuestra guía de 13 reglas de SEO técnico. Esta guía da un paso más allá y profundiza en los conflictos avanzados que esa base no cubre.
El sitemap es el mapa que le entregas a Google para que conozca el terreno de tu web. Pero un mapa con rutas imposibles, senderos que no llevan a ningún sitio o instrucciones contradictorias hace más daño que no tener mapa. Estas cinco reglas auditan la coherencia interna del sitemap.
Esta es la contradicción más frecuente en sitemaps de sitios con algo de complejidad. El sitemap le dice a Google «quiero que visites estas páginas» mientras que la etiqueta noindex le dice «no incluyas esta página en el índice». El resultado es que Google gasta presupuesto de rastreo visitando páginas que luego no puede indexar.
Lo más problemático no es el gasto de crawl, sino la señal que genera: Google interpreta la presencia en el sitemap como una indicación de que la página tiene valor. Cuando llega y encuentra un noindex, registra la inconsistencia como una señal de desorganización del sitio.
Los casos más habituales donde aparece esta contradicción:
<!-- ❌ Contradicción: esta URL tiene noindex pero está en el sitemap -->
<url>
<loc>https://tudominio.com/tag/seo/</loc>
</url>
<!-- Y en esa página: -->
<meta name="robots" content="noindex, follow" />Cómo detectarlo: Screaming Frog puede rastrear el sitemap (Mode → Spider → en Configuration, cargar el sitemap como fuente) y mostrar qué URLs del sitemap tienen directivas noindex. También se puede exportar el sitemap, rastrear cada URL y cruzar los datos.
✅ escala14.com supera esta regla: el sitemap solo incluye páginas indexables. Las páginas de etiquetas y otros archivos auxiliares no tienen representación en el sitemap.
Si robots.txt tiene un Disallow para una ruta y el sitemap incluye URLs dentro de esa ruta, los rastreadores se encuentran ante una instrucción ambivalente: el mapa de tráfico les dice que el camino está cerrado, pero el plano del terreno les indica que hay algo interesante al final de ese camino.
El resultado práctico es que Googlebot puede ignorar el Disallow para esas URLs (porque el sitemap indica que quieres que las visite) o ignorar el sitemap (porque el robots.txt dice que no puede acceder). Ninguna de las dos resoluciones es la que quieres.
La fuente del problema suele ser temporal: la ruta se bloqueó en robots.txt durante el desarrollo, se olvidó quitar el bloqueo al lanzar o, al revés, se añadió el bloqueo después de que el sitemap ya estuviera configurado sin actualizar este.
# robots.txt
User-agent: *
Disallow: /tienda/outlet/
# sitemap.xml
<url>
<loc>https://tudominio.com/tienda/outlet/coleccion-verano/</loc>
</url>Cómo detectarlo: Screaming Frog en modo List, cargando las URLs del sitemap, muestra qué URLs están bloqueadas por robots.txt (columna “Blocked by Robots.txt”). Google Search Console también alerta de este conflicto específico en el informe de Sitemaps.
✅ escala14.com supera esta regla: no hay conflictos entre el sitemap y las directivas de robots.txt. Ambos documentos son coherentes.
El sitemap debe contener las URLs de destino final, no las URLs que redirigen a esas destinos. Incluir una URL con redirección 301 en el sitemap provoca que Google visite dos URLs en lugar de una: primero la del sitemap, luego la de destino. Es gasto de presupuesto de crawl duplicado sin ningún beneficio.
Además, una redirección en el sitemap es una señal de desactualización: indica que el sitemap no se actualiza cuando se hacen cambios de URL, lo que genera desconfianza sobre la fiabilidad del resto del mapa.
Los escenarios más habituales:
<!-- ❌ URL con redirección 301 en el sitemap -->
<url>
<loc>https://tudominio.com/blog/post-antiguo/</loc>
<!-- Esta URL redirige a /nuevo-post/ — el sitemap debería tener la URL de destino -->
</url>Cómo detectarlo: Screaming Frog en modo List cargando el sitemap detecta automáticamente las URLs con código de respuesta 3xx y muestra la URL de destino final. Se puede exportar el informe filtrado por status code 301/302.
✅ escala14.com supera esta regla: el sitemap contiene únicamente las URLs canónicas y de destino final. No hay redirects en el sitemap.
Esta es una variante de la contradicción de la regla 1, pero más sutil. Una URL puede ser perfectamente indexable (sin noindex) pero tener un canonical que apunta a otra URL diferente. En ese caso, incluirla en el sitemap es incoherente: estás sugiriendo que esa URL tiene valor propio mientras que el canonical dice que la URL de valor real es otra.
El impacto es similar al de las URLs con noindex en el sitemap: Google gasta crawl presupuesto visitando la URL del sitemap, llega, ve que el canonical apunta a otro sitio y consolida la autoridad en esa otra URL. La URL del sitemap queda como un intermediario innecesario.
Los casos más frecuentes:
/categoria/?color=rojo) tiene un canonical que apunta a la categoría base (/categoria/), pero el sitemap las incluye a ambas.<!-- ❌ URL en sitemap cuyo canonical apunta a otra URL -->
<url>
<loc>https://tudominio.com/categoria/?color=rojo&talla=m</loc>
</url>
<!-- Y en esa página: -->
<link rel="canonical" href="https://tudominio.com/categoria/" />Cómo detectarlo: rastreo con Screaming Frog del sitemap en modo List, cruzando la columna “Canonical URL” con la columna “Address”. Las URLs donde ambas columnas difieren deben revisarse.
✅ escala14.com supera esta regla: todas las URLs del sitemap son las URLs canónicas de sus respectivas páginas. No hay URLs con canonical externo en el sitemap.
En sitios con más de 50.000 URLs (o con múltiples tipos de contenido), es habitual usar un sitemap index: un fichero XML que apunta a múltiples sitemaps secundarios (uno para posts, otro para productos, otro para páginas, etc.). Si alguno de esos sitemaps secundarios está inaccesible — devuelve 404, 500 o está temporalmente caído — Google no puede procesar esa porción del sitio.
El problema es que el sitemap index puede parecer correcto desde fuera (responde con 200 y tiene estructura XML válida) mientras que uno o varios de los sitemaps que referencia están rotos. Es un error silencioso: Google Search Console sí lo detecta, pero solo si revisas el informe de Sitemaps con detalle.
<!-- sitemap-index.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://tudominio.com/sitemap-posts.xml</loc> <!-- ✅ accesible -->
</sitemap>
<sitemap>
<loc>https://tudominio.com/sitemap-productos.xml</loc> <!-- ❌ devuelve 404 -->
</sitemap>
</sitemapindex>Cómo detectarlo: en Google Search Console → Sitemaps, cada sitemap secundario aparece listado con su estado de procesamiento y el número de URLs enviadas vs. indexadas. Un sitemap con estado de error indica que no se pudo acceder. También puedes acceder manualmente a cada URL de sitemap secundario para verificar que responde con 200.
✅ escala14.com supera esta regla: el sitio usa un único sitemap generado automáticamente por Astro, sin sitemap index. No hay sitemaps secundarios que puedan quedar inaccesibles.
Las señales de indexabilidad son las instrucciones que le das a Google sobre qué páginas incluir en su índice. El problema no es solo tenerlas mal configuradas — es tenerlas en conflicto entre sí o mal ubicadas, de manera que Google recibe mensajes contradictorios y resuelve la ambigüedad de la peor manera posible para tu posicionamiento.
Una página huérfana es una URL que no recibe ningún enlace interno desde otras páginas del sitio. Puede existir en el sitemap, puede ser completamente indexable, pero si ninguna otra página la enlaza, Googlebot tiene muy pocas posibilidades de encontrarla en el rastreo habitual.
La importancia de los enlaces internos para el rastreo es fundamental: el presupuesto de crawl de Googlebot se distribuye siguiendo la estructura de links del sitio. Una página sin enlaces entrantes internos es, desde la perspectiva del rastreador, una ruta sin señalizar en el mapa del terreno.
Las páginas huérfanas más frecuentes:
Cómo detectarlas: Screaming Frog puede identificar páginas huérfanas si le proporcionas el sitemap como fuente de URLs además del rastreo estándar. Las URLs que aparecen en el sitemap pero no en ninguna lista de enlaces entrantes son candidatas a revisión. Google Search Console → Cobertura también puede mostrar URLs enviadas en sitemap pero no descubiertas por rastreo.
✅ escala14.com supera esta regla: todas las páginas del sitio tienen al menos un enlace interno. La estructura de navegación y los links de artículos relacionados garantizan que ninguna página quede desconectada.
La etiqueta <meta name="robots"> es la señal de indexabilidad más directa que existe. Un error en esta etiqueta puede desindexar páginas importantes o, al contrario, permitir que se indexen páginas que no deberían aparecer en los resultados.
Los errores más frecuentes en la configuración de meta robots:
Uso incorrecto de noindex, nofollow juntos: el valor nofollow en meta robots no solo impide la indexación sino que también le dice a Google que no siga los enlaces de esa página. En páginas de categorías o de archivo que no quieres indexar pero que enlazan a contenido importante, usar noindex, follow (sin nofollow) es más correcto: Google no indexa la página pero sí sigue los links hacia el contenido que sí quieres posicionar.
noindex heredado de una plantilla: en CMS con plantillas para tipos de contenido, es frecuente que la configuración de noindex para páginas de administración o de prueba quede heredada en plantillas de producción tras una migración.
Inconsistencia entre entornos: configuraciones de noindex diseñadas para el entorno de desarrollo o staging que no se eliminaron correctamente antes del lanzamiento en producción.
<!-- ✅ Página de categoría: no se indexa pero sigue los links -->
<meta name="robots" content="noindex, follow" />
<!-- ❌ Página de categoría con nofollow: bloquea el rastreo de los links también -->
<meta name="robots" content="noindex, nofollow" />
<!-- ✅ Página de servicio que sí quieres indexar -->
<meta name="robots" content="index, follow" />Cómo auditarlo: rastreo con Screaming Frog exportando la columna “Meta Robots” para todas las URLs. Filtra por páginas con noindex y verifica que cada una realmente deba tenerlo. Presta especial atención a páginas de categorías, tags, y páginas de servicios o landing pages.
✅ escala14.com supera esta regla: la configuración de meta robots es coherente en todo el sitio. Las páginas de etiquetas usan noindex, follow correctamente y todas las páginas de contenido principal tienen index, follow.
El header HTTP X-Robots-Tag es el equivalente de la meta robots pero a nivel de servidor. Se puede configurar para cualquier tipo de fichero (incluyendo PDFs, imágenes o documentos) y tiene la misma capacidad de bloquear la indexación. Lo problemático es que es invisible en el HTML de la página: no aparece en el código fuente que ves en el navegador, solo en las cabeceras HTTP de la respuesta.
Un X-Robots-Tag: noindex configurado en el servidor web (Apache, Nginx) puede estar bloqueando la indexación de páginas que parecen completamente normales si las inspeccionas en el navegador. Es uno de los problemas más difíciles de detectar en una auditoría superficial.
Los casos donde aparece este problema:
add_header X-Robots-Tag "noindex" aplicada al location / bloquea todo el sitio.X-Robots-Tag por defecto en ciertas condiciones.# Cómo verificar el X-Robots-Tag con curl
curl -I https://tudominio.com/pagina-importante/
# Respuesta con problema:
HTTP/2 200
x-robots-tag: noindex
# Respuesta correcta:
HTTP/2 200
# Sin header X-Robots-Tag, o con:
x-robots-tag: index, followCómo detectarlo: Screaming Frog muestra los headers HTTP en la pestaña “Response Headers” de cada URL. También puedes usar el comando curl -I en terminal. La herramienta de inspección de URLs de Google Search Console también indica si hay directivas noindex de cualquier fuente.
✅ escala14.com supera esta regla: el servidor no incluye headers X-Robots-Tag con directivas que bloqueen la indexación de páginas relevantes.
Una señal contradictoria ocurre cuando una misma página recibe instrucciones de indexabilidad incompatibles entre sí. Los casos más frecuentes:
noindex + URL en el sitemap: ya cubierto en la regla 1, pero desde el punto de vista de la página es la misma contradicción.index: el canonical le dice a Google que la URL canónica es otra, pero el meta robots dice que esta también debe indexarse. Google resolverá con el canonical, pero la señal contradictoria puede retrasar el procesamiento.noindex: poner un canonical que apunta a la misma URL junto con un noindex es una contradicción interna. El canonical confirma que esta es la URL oficial; el noindex pide que no se indexe. Google interpreta el noindex, pero el canonical hace ruido innecesario.La regla general: cada página debe tener una sola instrucción coherente sobre su indexabilidad. Si quieres que se indexe, no pongas señales que contradigan eso. Si no quieres que se indexe, elimínala también del sitemap.
Cómo detectarlo: Screaming Frog permite filtrar por combinaciones de columnas (canonical, meta robots, inclusión en sitemap) para identificar inconsistencias. Un análisis sistemático cruzando estas cuatro señales en cada URL detecta la mayoría de contradicciones.
✅ escala14.com supera esta regla: las señales de indexabilidad son coherentes en todas las páginas del sitio. No hay contradicciones entre meta robots, canonicals y presencia en sitemap.
El atributo rel="nofollow" en un enlace le indica a Google que no debe seguir ese link ni transferir autoridad a través de él. Si una página recibe únicamente enlaces internos con nofollow, Googlebot tiene pocas razones para rastrearla con profundidad, y la autoridad de esa página en el gráfico interno del sitio es prácticamente nula.
El problema es especialmente grave en páginas que sí quieres posicionar. Es más frecuente de lo que parece porque algunos frameworks o plugins añaden nofollow por defecto en ciertos tipos de links (links de paginación, links en widgets de sidebar, links en el footer).
Los escenarios problemáticos:
nofollow en los links del menú principal, bloqueando la transferencia de autoridad desde la home a las páginas de servicio.<!-- ❌ Links internos con nofollow en navegación principal -->
<a href="/agencia-seo/" rel="nofollow">Agencia SEO</a>
<!-- ✅ Links internos sin nofollow -->
<a href="/agencia-seo/">Agencia SEO</a>Cómo detectarlo: Screaming Frog exporta todos los links con sus atributos rel. Filtra por rel="nofollow" y revisa si algún link interno importante lo tiene. También puedes buscar en el código fuente de la plantilla si hay nofollow global en algún elemento de navegación.
✅ escala14.com supera esta regla: los links internos de la navegación, el footer y los artículos relacionados no tienen el atributo nofollow. La autoridad fluye correctamente por toda la arquitectura del sitio.
Los canonicals son la señal más poderosa para gestionar el contenido duplicado y consolidar la autoridad de URL. Pero cuando se implementan mal generan cadenas, bucles y contradicciones que consumen crawl presupuesto sin resolver el problema que pretendían solucionar.
Una cadena canónica ocurre cuando la URL A tiene un canonical que apunta a B, y B tiene un canonical que apunta a C. En lugar de una sola señal clara, hay una cadena que Googlebot debe seguir paso a paso para llegar a la URL definitiva.
El impacto es doble: por un lado, consume más crawl budget (Google tiene que visitar varias URLs para resolver la cadena); por otro, la señal de consolidación de autoridad se debilita cuantos más eslabones tiene la cadena.
Las cadenas canónicas aparecen frecuentemente en:
<!-- ❌ Cadena canónica de tres eslabones -->
<!-- En /pagina-a/: -->
<link rel="canonical" href="https://tudominio.com/pagina-b/" />
<!-- En /pagina-b/: -->
<link rel="canonical" href="https://tudominio.com/pagina-c/" />
<!-- ✅ Correcto: todos los canonicals apuntan directamente a la URL final -->
<!-- En /pagina-a/: -->
<link rel="canonical" href="https://tudominio.com/pagina-c/" />
<!-- En /pagina-b/: -->
<link rel="canonical" href="https://tudominio.com/pagina-c/" />Cómo detectarlo: Screaming Frog tiene un informe específico de “Canonicals” que muestra las cadenas. En el menú Reports → Canonical, puedes ver las URLs donde el canonical apunta a una URL que a su vez tiene un canonical diferente.
✅ escala14.com supera esta regla: no hay cadenas canónicas en el sitio. Todas las etiquetas canonical apuntan directamente a la URL de destino final.
Un bucle canónico es el escenario más problemático de todos: la URL A apunta canónicamente a B, y B apunta canónicamente a A. El resultado es que Google no puede determinar cuál es la URL definitiva, descarta ambas señales y decide por sí mismo cuál considera la canónica — normalmente con resultados imprevisibles.
Los bucles canónicos son menos frecuentes que las cadenas, pero más difíciles de detectar porque el problema se manifiesta en dos URLs distintas y la conexión entre ellas no es evidente si no revisas los canonicals sistemáticamente.
Las causas más comunes:
/pagina/ tiene canonical a /pagina y /pagina tiene canonical a /pagina/.Cómo detectarlo: Screaming Frog detecta los bucles en el informe de Canonicals cuando encuentra que la URL de destino del canonical tiene a su vez un canonical que vuelve al origen. Se puede también hacer una búsqueda manual: para cualquier URL sospechosa, sigue la cadena de canonicals manualmente verificando el código fuente de cada URL.
✅ escala14.com supera esta regla: no hay bucles canónicos en ninguna URL del sitio.
La especificación de canonicals permite tanto URLs absolutas como relativas, pero las relativas presentan problemas en la práctica. Una URL canónica relativa como <link rel="canonical" href="/pagina/"> depende del contexto de la página para su resolución. Si la página se sirve desde subdominios distintos, si hay múltiples versiones del dominio (www / no-www) o si se canonicaliza contenido sindicado, las URLs relativas pueden resolverse de forma diferente a lo esperado.
Google en su documentación oficial recomienda usar siempre URLs absolutas en la etiqueta canonical para evitar ambigüedades. Las URLs absolutas incluyen protocolo, dominio y ruta completa, y son inequívocas independientemente del contexto en que se resuelvan.
<!-- ❌ Canonical relativo — puede causar problemas en ciertos contextos -->
<link rel="canonical" href="/agencia-seo/" />
<!-- ❌ Canonical relativo con protocolo omitido -->
<link rel="canonical" href="//escala14.com/agencia-seo/" />
<!-- ✅ Canonical absoluto — inequívoco -->
<link rel="canonical" href="https://escala14.com/agencia-seo/" />El problema con los canonicals relativos es especialmente agudo en:
Cómo verificarlo: en el código fuente de cualquier página, busca rel="canonical" y verifica que la URL empieza con https://. Screaming Frog muestra la columna “Canonical URL” con la URL ya resuelta, pero también puede mostrar si el canonical era relativo en el código original.
✅ escala14.com supera esta regla: todos los canonicals del sitio son URLs absolutas con protocolo HTTPS y dominio completo.
Un canonical cross-domain apunta a una URL en otro dominio diferente al de la página que lo contiene. Se usa legítimamente cuando publicas contenido sindicado en otro sitio y quieres que la autoridad se consolide en tu dominio original. El problema surge cuando aparece de forma no intencionada.
Los canonicals cross-domain no intencionados son especialmente peligrosos porque transfieren toda la señal de autoridad de tus páginas hacia un dominio externo. Si una página de tu sitio tiene <link rel="canonical" href="https://otro-dominio.com/pagina/">, le estás diciendo a Google que esa página externa es la versión oficial y que la tuya es la duplicada. El resultado es que Google puede dejar de indexar tu versión y transferir el valor SEO al otro dominio.
Las causas más frecuentes:
blog.tudominio.com/post/ apunta a tudominio.com/blog/post/, técnicamente es cross-domain aunque sean parte del mismo proyecto.Cómo detectarlo: Screaming Frog muestra en la columna “Canonical URL” cualquier URL canónica. Filtra las filas donde el dominio del canonical difiere del dominio del sitio que estás rastreando. Google Search Console también puede alertar de canonicals externos si detecta señales contradictorias.
✅ escala14.com supera esta regla: todos los canonicals apuntan a URLs del mismo dominio (escala14.com). No hay canonicals que apunten a dominios externos.
Esta regla aborda una contradicción específica: una página marcada con noindex tiene un canonical self-referential (que apunta a sí misma). El canonical self-referential es una buena práctica en páginas que quieres indexar: refuerza que esa es la URL oficial y consolida la autoridad. Pero en una página con noindex, el canonical self-referential envía una señal confusa.
La combinación noindex + canonical self-referential equivale a decir: «no quiero que indexes esta página, pero sí considero que esta URL es la versión oficial de sí misma». Google resuelve esta ambigüedad con el noindex (no indexa la página), pero la presencia del canonical genera procesamiento adicional innecesario.
La solución es coherente: si una página tiene noindex, elimina el canonical self-referential (o en todo caso, que el canonical apunte a la URL indexable que sí quieres que aparezca en los resultados, si existe).
<!-- ❌ Señales contradictorias -->
<meta name="robots" content="noindex, follow" />
<link rel="canonical" href="https://tudominio.com/pagina-no-indexable/" />
<!-- ✅ Coherente: noindex sin canonical self-referential -->
<meta name="robots" content="noindex, follow" />
<!-- Sin etiqueta canonical, o canonical apuntando a la página indexable equivalente -->Cómo detectarlo: cruza en Screaming Frog las columnas “Meta Robots” y “Canonical URL”. Las filas con noindex y canonical self-referential (donde la URL canónica es igual a la dirección de la página) son las que necesitan revisión.
✅ escala14.com supera esta regla: las páginas con noindex no tienen canonicals self-referential contradictorios.
La paginación es una de las áreas más conflictivas del crawlability SEO. Un blog con 50 artículos tiene quizá 5-10 páginas de paginación; una tienda online puede tener miles. Gestionar mal esas páginas genera contenido duplicado, dispersa la autoridad y desperdicia presupuesto de crawl en páginas sin valor propio.
Este es uno de los malentendidos más extendidos en la gestión de paginación SEO. Durante años, la práctica habitual fue poner un canonical en todas las páginas paginadas apuntando a la página 1 (/categoria/ o /categoria/pagina/1/). La lógica parecía razonable: consolidar toda la autoridad en la primera página.
El problema es que esta práctica le dice a Google que las páginas 2, 3, 4… son copias de la página 1. Google puede entonces ignorarlas completamente, lo que significa que el contenido de esas páginas (los artículos del blog, los productos de la tienda) no se rastreará a través de esos links de paginación.
La práctica correcta recomendada por Google desde 2019 (cuando deprecó los atributos rel=next/prev) es que cada página paginada tenga un canonical self-referential que apunte a sí misma. Esto indica que cada página paginada es una URL independiente con contenido propio (los artículos o productos de esa página).
<!-- En /campamento-base/pagina/2/: -->
<!-- ❌ Incorrecto: canonical a la página 1 -->
<link rel="canonical" href="https://escala14.com/campamento-base/" />
<!-- ✅ Correcto: canonical self-referential -->
<link rel="canonical" href="https://escala14.com/campamento-base/pagina/2/" />Cómo verificarlo: accede manualmente a una página de paginación (por ejemplo, la página 2 de tu blog) y revisa el canonical en el código fuente. Screaming Frog con rastreo del sitio filtrando las URLs con /pagina/ o /page/ puede mostrar masivamente los canonicals de todas las páginas paginadas.
✅ escala14.com supera esta regla: las páginas paginadas del blog (/campamento-base/pagina/2/ etc.) tienen canonicals self-referentials. Cada página paginada es tratada como una URL independiente.
Esta regla aborda un problema estructural frecuente: en muchos CMS, la URL base de una sección (/campamento-base/) y la primera página de paginación (/campamento-base/pagina/1/) muestran exactamente el mismo contenido. Son dos URLs distintas con contenido idéntico, lo que crea contenido duplicado.
La solución habitual es hacer que /pagina/1/ redirija (301) a la URL base, eliminando una de las dos URLs. Alternativamente, si /pagina/1/ existe, debe tener un canonical que apunte a la URL base (sin /pagina/1/).
Un caso relacionado es cuando la URL con parámetro de primera página (?pagina=1, ?page=1) muestra el mismo contenido que la URL limpia. Cualquiera de estas variantes de la primera página debe consolidarse en una única URL canónica.
# Configuraciones problemáticas
https://tudominio.com/blog/ → muestra los primeros 10 artículos
https://tudominio.com/blog/pagina/1/ → muestra los mismos 10 artículos → DUPLICADO
# Solución: redirección 301
https://tudominio.com/blog/pagina/1/ → 301 → https://tudominio.com/blog/
# O canonical desde la variante hacia la URL base
# En /blog/pagina/1/:
<link rel="canonical" href="https://tudominio.com/blog/" />Cómo detectarlo: accede manualmente a la URL base de una sección con paginación y a la primera página con número explícito. Si el contenido es idéntico, tienes un duplicado que resolver. Screaming Frog con la función de detección de duplicados (Hash / Near Duplicates) puede detectar este patrón a escala.
✅ escala14.com supera esta regla: la URL base /campamento-base/ no tiene una URL de primera página duplicada. La paginación empieza desde la página 2 con URL explícita.
Los sistemas de paginación pueden generar una gran variedad de formatos de URL para la misma información de página. Si no se normalizan correctamente, todas esas variantes pueden ser rastreadas e interpretadas como URLs distintas, generando contenido duplicado y fragmentando el presupuesto de crawl.
Los formatos de paginación que pueden coexistir sin normalización:
https://tudominio.com/blog/?pagina=2
https://tudominio.com/blog/?page=2
https://tudominio.com/blog/pagina/2/
https://tudominio.com/blog/page/2
https://tudominio.com/blog/page/2/Si alguna de estas variantes produce el mismo contenido, Google puede rastrear todas ellas e interpretarlas como versiones diferentes de la misma información. La forma correcta de normalizar es:
?page= si usas el formato de directorio /page/2/).# robots.txt: bloquea el parámetro alternativo de paginación
User-agent: *
Disallow: /*?pagina=
Disallow: /*?page=Cómo detectarlo: rastreo con Screaming Frog buscando URLs con parámetros de paginación (?page=, ?pagina=, etc.) y comparando con las URLs de directorio equivalentes. Google Search Console → Informe de cobertura puede mostrar URLs paginadas duplicadas si las ha rastreado.
✅ escala14.com supera esta regla: la paginación del blog usa exclusivamente el formato de directorio (/campamento-base/pagina/2/). No hay parámetros de paginación alternativos.
Cuando una auditoría de crawlability detecta varios problemas simultáneamente, el orden de ataque debe guiarse por la combinación de impacto en el posicionamiento y urgencia de la corrección:
| Prioridad | Regla | Impacto | Esfuerzo de corrección |
|---|---|---|---|
| Crítica | R1: URLs con noindex en sitemap | Gasto de crawl + señal contradictoria | Bajo — limpiar el sitemap |
| Crítica | R2: URLs bloqueadas por robots.txt en sitemap | Rastreo bloqueado + mapa inconsistente | Bajo — alinear sitemap y robots.txt |
| Crítica | R8: X-Robots-Tag noindex en páginas importantes | Desindexación silenciosa | Medio — revisar configuración de servidor |
| Crítica | R12: bucles canónicos | Google ignora ambos canonicals | Medio — identificar y romper el bucle |
| Crítica | R14: canonical cross-domain no intencionado | Pérdida de autoridad hacia dominio externo | Bajo — corregir el canonical |
| Alta | R3: URLs redirigidas en sitemap | Crawl budget duplicado sin beneficio | Bajo — actualizar el sitemap |
| Alta | R4: URLs con canonical externo en sitemap | Señal contradictoria de indexabilidad | Bajo — limpiar el sitemap |
| Alta | R7: meta robots noindex en páginas que deben indexarse | Desindexación de páginas importantes | Bajo — corregir la etiqueta |
| Alta | R9: señales de indexabilidad contradictorias | Google resuelve con la señal más restrictiva | Medio — auditar y alinear señales |
| Alta | R11: cadenas canónicas | Crawl budget extra + consolidación lenta | Medio — corregir todos los eslabones |
| Alta | R17: duplicado página 1 vs. URL base | Contenido duplicado activo | Bajo — añadir redirección o canonical |
| Media | R6: páginas huérfanas sin enlace interno | Páginas con poco crawl budget | Medio — añadir enlaces internos relevantes |
| Media | R5: sitemaps secundarios inaccesibles | Sección del sitio sin mapear | Bajo — restaurar o eliminar el sitemap |
| Media | R13: canonicals relativos en lugar de absolutos | Resolución ambigua en contextos externos | Bajo — cambiar a URLs absolutas |
| Media | R15: noindex con canonical self-referential | Señal redundante que genera ruido | Bajo — eliminar el canonical |
| Media | R16: canonical a página 1 en páginas paginadas | Páginas paginadas ignoradas | Bajo — cambiar a canonical self-referencial |
| Baja | R10: links internos importantes con nofollow | Reducción de flujo de autoridad | Medio — revisar plantilla y navegación |
| Baja | R18: parámetros de paginación no normalizados | Variantes de URL duplicadas | Medio — normalizar con robots.txt o redirects |
Consejo práctico de priorización: los problemas de canonical cross-domain y bucles canónicos son los que requieren atención más inmediata porque sus efectos son irreversibles mientras estén activos: están transfiriendo autoridad hacia fuera del sitio o bloqueando completamente el procesamiento de las URLs afectadas. Los problemas de paginación y páginas huérfanas, aunque importantes, tienen efectos más graduales y pueden abordarse en una segunda ronda de correcciones.
Nuestro resultado en escala14.com: las 18 reglas de crawlability se superan sin fallos. La arquitectura de Astro estático con generación automática de sitemap y canonicals elimina gran parte de los problemas frecuentes en CMS dinámicos, donde estos errores se acumulan silenciosamente con cada actualización de contenido o de plantilla.
Usa esta lista como referencia en cada auditoría de crawlability. El estado indica el resultado sobre escala14.com como referencia real:
Conflictos en el sitemap (1–5)
noindexSeñales de indexabilidad (6–10)
rel="nofollow"Cadenas y conflictos canónicos (11–15)
Problemas de paginación (16–18)
Resultado de escala14.com: 18 superadas ✅ · 0 advertencias ⚠️ · 0 fallos ❌ → Score: 100/A
La crawlability es la capacidad de Googlebot de llegar físicamente a una URL y visitarla. La indexabilidad es la capacidad de esa URL de ser incluida en el índice de Google una vez rastreada. Una página puede ser perfectamente rastreable (no hay nada que impida la visita) pero no indexable (tiene un noindex o un canonical que apunta a otra URL). El diagnóstico correcto requiere distinguir en qué etapa está el problema: si Google ni siquiera visita la página, es un problema de crawlability; si la visita pero no la indexa, es un problema de indexabilidad.
Google no publica una fórmula exacta para el crawl budget, pero sí hay factores conocidos que lo influyen: la popularidad del sitio (cuanto más backlinks y tráfico, más crawl budget), el tiempo de respuesta del servidor (servidores lentos reducen la frecuencia de rastreo) y el tamaño del sitio (sitios con millones de URLs tienen menor proporción de rastreo por URL). Para sitios pequeños y medianos (menos de 10.000 URLs), el crawl budget raramente es una limitación real. Se convierte en problema cuando hay muchas URLs duplicadas o de baja calidad que consumen el presupuesto disponible antes de llegar a las páginas importantes.
Google descarta ambas señales canónicas y decide por sí mismo cuál URL considera la canónica del par. Esta decisión puede ser diferente a la que tú deseas, y el resultado suele ser impredecible: Google puede indexar la URL que tú no querías, puede indexar ninguna o puede indexar ambas como URLs separadas. La detección y corrección de bucles canónicos es prioritaria precisamente porque su efecto es que Google toma el control de una decisión que debería ser tuya.
rel=next y rel=prev para la paginación?No. Google deprecó el soporte de rel=next/prev en 2019. Ya no los procesa como señales de paginación. La recomendación actual de Google es que cada página paginada tenga un canonical self-referencial (que apunte a sí misma) y que los links de paginación sean links normales sin atributos especiales. Lo importante es que el contenido de cada página paginada (los artículos o productos de esa página) sea accesible mediante links internos normales que Googlebot pueda seguir.
Técnicamente sí, pero con mucha dificultad. El sitemap garantiza que Google descubra la URL, pero la ausencia de enlaces internos tiene dos efectos negativos: el crawl budget asignado a esa página es bajo (porque no recibe señal de importancia a través de links), y la autoridad de página es muy baja (porque no recibe PageRank interno). El resultado es que aunque Google la rastree por el sitemap, la posicionará muy por detrás de páginas equivalentes que sí tienen una estructura interna de links que las refuerza.
La respuesta corta es: no es necesario, pero tampoco es perjudicial si el sitemap está bien configurado. Las páginas paginadas (página 2, 3, 4…) normalmente no tienen valor de posicionamiento propio — su valor está en los artículos o productos que muestran, no en la página de lista en sí. Google las descubrirá siguiendo los links de paginación desde la primera página, sin necesidad de que estén en el sitemap. Si las incluyes, asegúrate de que tienen canonical self-referencial (regla 16) y que no tienen noindex (lo que crearía la contradicción de la regla 1).
La señal más directa es una caída inesperada en el tráfico orgánico de páginas concretas sin cambios aparentes en el contenido o en los rankings de competidores. Un rastreo con Screaming Frog que muestre URLs canónicas con dominio diferente al del sitio es la forma más sistemática de detectarlo. También puedes revisarlo en Google Search Console: si ves URLs de tu sitio con estado “URL canónica elegida por Google distinta a la del usuario”, es posible que haya un canonical externo influyendo en la decisión de Google.
Para una auditoría básica son suficientes dos herramientas: Screaming Frog SEO Spider (o la versión gratuita limitada a 500 URLs) para el rastreo técnico local, y Google Search Console para la perspectiva de Google sobre tu sitio. Para auditorías más avanzadas o sitios con decenas de miles de URLs, herramientas como SEMrush, Ahrefs Site Audit o Sitebulb ofrecen informes más detallados y visualizaciones del gráfico de crawl que facilitan la detección de problemas en arquitecturas complejas.
La crawlability no es el aspecto más visible del SEO, pero sí es la base sobre la que descansa todo lo demás. Un sitio con contenido excelente, backlinks de calidad y una experiencia de usuario impecable puede perder posiciones sistemáticamente si el mapa que le entrega a Google está lleno de contradicciones: páginas que el sitemap dice que existen pero los canonicals desautorizan, señales de indexabilidad que se contradicen entre sí, páginas paginadas que Google interpreta como duplicados de la primera página.
Las 18 reglas de esta guía cubren los cuatro vectores donde esas contradicciones aparecen con más frecuencia: los conflictos en el sitemap, las señales de indexabilidad inconsistentes, las cadenas y bucles canónicos, y los problemas de paginación. La mayoría de las correcciones son cambios de configuración directos — lo difícil no es solucionarlos sino detectarlos, porque muchos de estos errores son invisibles en la navegación cotidiana y solo se revelan cuando buscas explícitamente las señales contradictorias.
Si quieres que analicemos la rastreabilidad de tu sitio y te entreguemos un informe con los problemas priorizados y el plan de corrección, cuéntanos qué necesitas. Sin compromiso.
Solicitar auditoría SEO gratuita → Ver servicios SEO → SEO técnico: robots.txt, sitemap y 404 (13 reglas) → URLs canónicas e indexación: la base técnica del SEO → Links en SEO: 19 reglas para auditar →
Aprende a auditar las 13 reglas de SEO técnico más importantes: robots.txt, sitemap.xml, estructura de URLs, páginas 404, soft 404s y códigos de error. Guía con checklist accionable.
Canonical tags, directrices noindex, títulos únicos y cómo resolver conflictos canónicos: la guía técnica completa para que los motores de búsqueda rastreen e indexen tu web correctamente.
Audita las 10 reglas de internacionalización SEO: atributo lang correcto, validación de hreflang, return links, conflictos y mismatches. Guía técnica con ejemplos de código y herramientas.
/ Volver al campamento
Más de 20 artículos publicados sobre SEO, diseño web y marketing digital, con datos reales y reglas auditables.