Guías/Solucionador de problemas de indexación

Páginas paginadas no indexadas: estrategias modernas de paginación para Google

Google declaró obsoletas las etiquetas rel=prev/next y tu contenido paginado ha caído del índice. Aprende estrategias modernas de pagination que funcionen con el comportamiento de indexación actual de Google.

Actualizado: 1 abr 2026

La pagination está por todas partes en la web. Los archivos de blog, las páginas de categoría de ecommerce, los listados de resultados de búsqueda, los índices de hilos de foros, los archivos de noticias y las galerías de imágenes usan pagination para dividir grandes conjuntos de contenido en páginas manejables. Durante años, el enfoque estándar fue implementar etiquetas rel=prev y rel=next para indicarle a Google que un conjunto de páginas formaba una serie paginada. Google entendía entonces la relación y consolidaba las señales de indexación de forma apropiada.

En marzo de 2019, Google confirmó que llevaba años sin usar rel=prev/next como señal de indexación. Este anuncio pilló desprevenida a la industria SEO porque muchos sitios habían construido toda su estrategia de pagination en torno a estas etiquetas. El impacto práctico fue inmediato: sin rel=prev/next, Google trata cada página paginada como una página independiente y autónoma en lugar de como parte de una serie conectada.

Este cambio significa que la página 2 de tu archivo de blog se evalúa por Google enteramente por sus propios méritos. Si la página 2 muestra una lista de extractos de entradas de blog sin contenido introductorio único, sin un encabezado único y sin contexto que explique de qué trata la página, Google ve una página pobre con fragmentos de contenido reciclados. No es de extrañar que Google decida con frecuencia no indexar estas páginas.

Las consecuencias se extienden más allá de las propias páginas paginadas. El contenido que aparece solo en páginas de pagination más profundas se vuelve más difícil de descubrir para Google. Si un producto o entrada de blog no está destacado en la página 1 de ningún listado y no está enlazado desde ningún otro lugar, puede convertirse efectivamente en huérfano y Google nunca lo rastreará. Esto convierte a la pagination no solo en un problema de páginas de listado, sino en un problema de descubrimiento de contenido para todo tu sitio.

Esta guía cubre estrategias modernas de pagination que funcionan con el comportamiento de indexación actual de Google, aborda los retos específicos del infinite scroll y los patrones Load More, y proporciona arreglos concretos para recuperar el contenido que se perdió cuando rel=prev/next dejó de funcionar.

IndexBolt consigue que Google rastree tus URL en menos de 24 horas — sin envíos manuales, sin esperar semanas.

Qué cambió cuando Google declaró obsoleto rel=prev/next

Para entender el estado actual de la indexación de pagination, ayuda saber qué se suponía que hacía rel=prev/next y qué hace Google realmente ahora.

Rel=prev/next era un conjunto de elementos HTML link que le decían a Google que una serie de páginas estaban conectadas como una secuencia paginada. La intención era que Google consolidara las páginas y entendiera que la página 1, la página 2, la página 3, y así sucesivamente, formaban un conjunto continuo. En teoría, Google trataría la serie como una sola entidad lógica, consolidando el link equity y potencialmente mostrando solo la primera página en los resultados de búsqueda mientras entendía que el contenido continuaba a través de las páginas posteriores.

Cuando Google reveló que no había usado estas señales durante años, la implicación estaba clara: Google se había basado en otras señales para entender la pagination. Estas señales incluyen patrones de URL (Google puede detectar patrones comunes de pagination como ?page=2 o /page/2/), estructuras de enlaces internos (los enlaces secuenciales entre páginas sugieren pagination) y análisis de contenido (las páginas con plantillas similares y diferentes subconjuntos de contenido sugieren una lista paginada).

El cambio práctico en el comportamiento es que Google ahora evalúa cada página paginada independientemente. La página 1 de tu categoría con un párrafo introductorio único, fuertes enlaces internos y 20 productos destacados puede ser indexada. La página 2, que muestra los siguientes 20 productos sin contenido único, se evalúa como una página independiente y puede no ser indexada porque no ofrece suficiente valor único por sí sola.

Esta evaluación independiente significa que las páginas paginadas más allá de la página 1 rara vez se indexan a menos que tengan alguna propuesta de valor única. Los elementos listados en la página 2 son diferentes a los de la página 1, pero la plantilla, la navegación, la meta información y la estructura general son idénticas. Desde la perspectiva de Google, la página 2 es una variación pobre de la página 1.

La pérdida de la consolidación de rel=prev/next también significa que el link equity ya no se consolida a través de las páginas paginadas. Antes, un backlink que apuntara a la página 3 de tu categoría podía haber beneficiado a toda la serie paginada. Ahora, ese link equity se queda solo en la página 3. Si la página 3 no está indexada, el link equity se desperdicia efectivamente.

La recomendación actual de Google para la pagination es asegurar que las páginas individuales importantes de contenido (productos, artículos, posts) sean directamente enlazables desde tu sitemap y desde otras páginas de tu sitio, en lugar de depender de la pagination como única vía de descubrimiento. La pagination es ahora principalmente una característica de experiencia de usuario en lugar de una característica SEO.

Página de categoría paginada mostrando la URL con parámetro de página
Cada URL paginada se evalúa ahora independientemente por Google sin consolidación de serie

Infinite scroll: el problema del contenido invisible

El infinite scroll sustituye la pagination tradicional por un patrón en el que el nuevo contenido se carga automáticamente conforme el usuario hace scroll hacia abajo. Los usuarios experimentan un feed fluido y sin fin. Desde la perspectiva del SEO, el infinite scroll es uno de los patrones de pagination más problemáticos porque el rastreador de Google no hace scroll.

Cuando Googlebot carga una página con infinite scroll, procesa el HTML inicial y cualquier contenido renderizado por JavaScript que aparezca en la carga inicial. No dispara eventos de scroll, lo que significa que cualquier contenido que se cargue cuando el usuario hace scroll más allá de cierto umbral es completamente invisible para Google. Si tu página de categoría muestra 20 productos en la carga inicial con infinite scroll para los 200 productos restantes, Google solo ve 20 productos.

Esto tiene consecuencias graves para el descubrimiento de contenido. Los productos o posts que solo aparecen vía infinite scroll no tienen ninguna ruta de rastreo desde la página de categoría. Si no están enlazados desde otras páginas o incluidos en el sitemap, Google puede no descubrirlos nunca. Incluso si están en el sitemap, la propia página de categoría no proporciona el enlace interno a estos elementos, debilitando su importancia percibida.

La solución recomendada es implementar infinite scroll junto con URLs paginadas tradicionales. Este enfoque híbrido proporciona la experiencia de usuario fluida del infinite scroll mientras le da a Google páginas paginadas rastreables con URLs reales. La implementación funciona así: crea URLs paginadas tradicionales (/category/page/2/, /category/page/3/) que muestren los mismos conjuntos de contenido que cada segmento de infinite scroll. Cuando un usuario hace scroll y se carga nuevo contenido, usa la History API para actualizar la URL del navegador a la URL paginada correspondiente. Si el usuario refresca o comparte la URL, ve la versión paginada con el contenido al que había hecho scroll.

Google recomienda específicamente este enfoque de pushState para infinite scroll. Las URLs paginadas sirven como puntos de anclaje que Google puede rastrear, mientras que el infinite scroll proporciona la experiencia de usuario que tus visitantes esperan. Sin las URLs paginadas subyacentes, el infinite scroll oculta a Google todo el contenido más allá del primer conjunto visible.

Un enfoque alternativo para conjuntos de contenido más pequeños es cargar todo el contenido en una sola página sin ningún tipo de pagination o carga basada en scroll. Si tu categoría tiene 50 productos o menos, renderizarlos todos en una sola página elimina el problema de la pagination por completo. Este enfoque no es viable para categorías con cientos o miles de elementos debido a las restricciones de rendimiento, pero funciona bien para colecciones más pequeñas.

Google Search Console mostrando URLs paginadas en el índice
Solo las URLs paginadas con contenido renderizado en servidor aparecen en el índice de Google

Olvídate del trabajo manual — IndexBolt envía tus URL directamente a la cola de rastreo de Google. Empieza con 100 créditos gratis.

100 créditos gratis. Sin tarjeta de crédito.

Botones Load More: mejores que infinite scroll, aún problemáticos

Los botones Load More son un punto intermedio entre la pagination tradicional y el infinite scroll. El usuario ve un conjunto inicial de contenido y hace clic en un botón para cargar contenido adicional en la misma página. Desde la perspectiva de la experiencia de usuario, Load More suele preferirse a la pagination tradicional porque mantiene al usuario en la misma página y conserva la posición del scroll.

Sin embargo, los botones Load More tienen el mismo problema SEO fundamental que el infinite scroll: Google no hace clic en botones. El contenido cargado por un botón Load More se dispara por un evento de clic, y el renderer de Google no simula interacciones de clic. El contenido detrás del botón Load More es invisible para Google a menos que se tomen medidas específicas.

La solución refleja la solución de infinite scroll: implementa URLs paginadas tradicionales junto con la funcionalidad Load More. Cada segmento Load More debería corresponder a una URL paginada rastreable. Incluye enlaces a estas URLs paginadas en algún lugar del HTML (pueden ocultarse del diseño visual usando CSS) para que Google pueda descubrirlas y rastrearlas. Algunas implementaciones colocan los enlaces paginados en una etiqueta noscript para que estén disponibles para los rastreadores que no ejecutan JavaScript mientras el botón Load More aparece para los navegadores con JavaScript habilitado.

Otro enfoque es renderizar el contenido de Load More en la respuesta HTML inicial pero ocultarlo visualmente con CSS. Cuando el usuario hace clic en Load More, JavaScript revela el contenido oculto en lugar de obtenerlo del servidor. Este enfoque asegura que Google vea todo el contenido en el HTML inicial sin necesidad de interactuar con ningún botón. Sin embargo, esto solo funciona para cantidades moderadas de contenido oculto (cargar 200 productos en HTML oculto aumenta significativamente el peso de la página y el tiempo de carga).

Un tercer enfoque es implementar Load More con URLs paginadas que cargan progresivamente. La página inicial se carga con el primer conjunto de contenido y un botón Load More. Hacer clic en el botón usa AJAX para obtener y mostrar el siguiente conjunto de contenido y actualiza simultáneamente la URL a la siguiente página paginada (/page/2/). Cada URL paginada renderiza su conjunto de contenido específico en el lado del servidor, por lo que Google puede rastrear /page/2/ directamente y ver ese contenido sin necesidad de hacer clic en ningún botón. El botón Load More es una mejora progresiva para los usuarios, mientras que la estructura subyacente de URLs paginadas es la base rastreable para Google.

Estrategia de etiquetas canonical para series paginadas

Las etiquetas canonical en las páginas paginadas son uno de los temas más debatidos en SEO técnico. La cuestión es si la página 2, la página 3 y las páginas posteriores deberían tener etiquetas canonical apuntando a la página 1 o si cada página debería tener una canonical autorreferencial.

Apuntar todas las páginas paginadas a la página 1 como canónica le dice a Google que la página 1 es la versión definitiva y que las demás páginas son secundarias. Este enfoque es apropiado cuando no quieres ni necesitas que las páginas más profundas se indexen y cuando todos los elementos individuales son descubribles a través de otros medios (sitemap, enlaces directos). El beneficio es la simplicidad: Google indexa solo la página 1, y no te preocupas por problemas de thin content en las páginas más profundas. El riesgo es que los elementos que solo aparecen en páginas más profundas pueden perder las señales de enlazado interno del listado paginado.

Las canonicals autorreferenciales en cada página paginada le dicen a Google que cada página es su propia entidad distinta. Este enfoque es apropiado cuando cada página paginada apunta a contenido diferente o cuando quieres que Google indexe todas las páginas de la serie. El beneficio es que cada página retiene su propio link equity y puede aparecer potencialmente en los resultados de búsqueda. El riesgo es que Google puede ver las páginas más profundas como thin content y decidir no indexarlas de todos modos.

La recomendación pragmática para la mayoría de los sitios es un enfoque híbrido. La página 1 obtiene una canonical autorreferencial y tu esfuerzo de optimización (contenido introductorio único, meta tags adecuados, elementos destacados). Las páginas 2 a 5 obtienen canonicals autorreferenciales pero se tratan como secundarias (menor prioridad de optimización, aceptando que algunas pueden no indexarse). Las páginas 6 en adelante obtienen etiquetas canonical apuntando a la página 1 porque el contenido tan profundo es poco probable que se indexe por sus propios méritos y el presupuesto de rastreo se gasta mejor en otra parte.

Independientemente de la estrategia canonical, asegúrate de que cada página de elemento individual (producto, post, artículo) esté incluida en tu sitemap XML con una URL directa. El sitemap proporciona una vía de descubrimiento independiente que no depende de la pagination. Incluso si Google nunca indexa la página 7 de tu categoría, los productos que aparecen en la página 7 aún pueden ser descubiertos e indexados a través del sitemap.

Impacto en el presupuesto de rastreo de la pagination profunda

La pagination profunda, donde un listado de contenido abarca docenas o cientos de páginas, es uno de los mayores drenajes de presupuesto de rastreo en sitios web con mucho contenido. Cada página paginada es una URL que Google puede intentar rastrear, evaluar y potencialmente indexar. Un sitio con 100 categorías, cada una con 20 páginas de pagination, genera 2.000 URLs de listado paginado además de las URLs reales de las páginas de contenido.

El programador de rastreo de Google debe decidir cómo asignar sus limitados recursos de rastreo entre todas estas URLs. Cuando las páginas de listado paginado superan en número a las páginas de contenido real, Google puede gastar la mayor parte de su presupuesto de rastreo en páginas de listado en lugar de en el contenido que realmente quieres indexar. Esto es particularmente problemático para sitios de ecommerce donde las páginas de producto son el contenido generador de ingresos, pero Google está gastando su tiempo rastreando y volviendo a rastrear la pagination de listados de categorías.

La señal diagnóstica de desperdicio de presupuesto de rastreo por pagination está en las estadísticas de rastreo de Google Search Console. Si ves un alto volumen de páginas rastreadas pero un bajo porcentaje de páginas indexadas, la sobrecarga de pagination puede ser la causa. Exporta las URLs que Google rastrea con más frecuencia y comprueba qué porcentaje son URLs de listado paginado frente a páginas reales de contenido.

Varias estrategias reducen el impacto en el presupuesto de rastreo de la pagination profunda. Primero, limita la profundidad de la pagination rastreable. Usa robots.txt para bloquear el rastreo de las páginas paginadas más allá de cierta profundidad (por ejemplo, bloquea /page/6/ y más profundas). Alternativamente, añade etiquetas noindex,follow a las páginas profundas para que Google no las indexe pero pueda seguir enlazando a elementos individuales. Segundo, reduce el número de elementos por página para reducir la profundidad total de pagination. Mostrar 50 elementos por página en lugar de 20 convierte una categoría de 20 páginas en una categoría de 8 páginas. Tercero, implementa una página View All para categorías donde el peso de la página lo permita, eliminando la pagination por completo.

Para la pagination dinámica que cambia con frecuencia (nuevos productos añadidos diariamente, elementos en tendencia reordenados), mantén tu sitemap como mecanismo principal de descubrimiento en lugar de depender de la pagination. El sitemap proporciona una lista completa de todas las URLs individuales de contenido que Google puede rastrear a su propio ritmo, independientemente de cómo aparezcan esas URLs en los listados paginados en un día determinado.

Otra técnica es priorizar el presupuesto de rastreo hacia la página 1 de cada categoría fortaleciendo los enlaces internos a la página 1 y debilitando los enlaces a la pagination más profunda. La navegación de tu sitio enlaza a la página 1 de cada categoría. Los enlaces internos desde entradas de blog y otro contenido apuntan a la página 1. Las secciones de productos destacados o entradas destacadas en la página de inicio enlazan a la página 1. Estos fuertes enlaces internos le indican a Google que la página 1 es la URL de listado de mayor prioridad para cada categoría.

Guía paso a paso

1

Audita la implementación actual de pagination en tu sitio

Rastrea tu sitio e identifica todos los patrones de URL paginada. Los patrones comunes incluyen /page/2/, ?page=2, /p2 y ?start=20. Cuenta el número total de URLs de listado paginado frente a las URLs reales de páginas de contenido. Comprueba qué páginas paginadas están indexadas actualmente usando el operador "site:" con los patrones de URL paginada. Identifica qué categorías o secciones tienen la pagination más profunda. Documenta el comportamiento actual de las etiquetas canonical, las reglas de robots.txt y el estado noindex de las páginas paginadas. Esta auditoría base revela el alcance de tu problema de pagination y guía la priorización.

Informe de rastreo del sitio listando todos los patrones de URL paginada encontrados
Identifica cada patrón de pagination en tu sitio y cuenta el total de URLs paginadas
2

Verifica las rutas de descubrimiento de contenido más allá de la pagination

Asegúrate de que cada página individual de contenido (producto, artículo, post) sea descubrible a través de al menos una vía distinta a la pagination. Comprueba que todas las URLs de contenido estén en tu sitemap XML. Verifica que las páginas de contenido reciban enlaces internos desde otro contenido (secciones de productos relacionados, posts relacionados). Ejecuta un análisis de páginas huérfanas para encontrar páginas de contenido que solo son descubribles a través de pagination profunda y no tienen otros enlaces internos. Para el contenido huérfano, añade enlaces internos desde páginas relacionadas o secciones destacadas para crear vías de descubrimiento alternativas.

Análisis de páginas huérfanas mostrando contenido alcanzable solo a través de pagination profunda
Encuentra páginas que dependen únicamente de la pagination profunda para el descubrimiento y añade enlaces alternativos
3

Implementa URLs rastreables para infinite scroll o Load More

Si tu sitio usa infinite scroll o botones Load More, implementa URLs paginadas subyacentes que correspondan a cada segmento de contenido. Usa la History API para actualizar la URL del navegador conforme los usuarios hacen scroll o clic en Load More. Asegúrate de que cada URL paginada renderice su contenido en el servidor sin requerir interacción JavaScript. Prueba accediendo directamente a /page/2/ en un navegador y verificando que se muestre el conjunto correcto de contenido. Incluye estas URLs paginadas en tu HTML (como enlaces de pagination en el pie de página o en un bloque noscript) para que Google pueda descubrirlas sin ejecutar JavaScript.

Barra de URL del navegador actualizándose a una URL paginada mientras el usuario hace scroll vía History API
Usa la History API para actualizar la URL conforme los usuarios hacen scroll, creando endpoints de página rastreables
4

Configura las etiquetas canonical en las páginas paginadas

Implementa tu estrategia canonical elegida. Para la mayoría de los sitios, usa canonicals autorreferenciales en las páginas 1 a 5 y canonical apuntando a la página 1 para las páginas 6 en adelante. Verifica las etiquetas canonical viendo el código fuente de las páginas paginadas en diferentes profundidades. Asegúrate de que las URLs canónicas usen el protocolo correcto (HTTPS) y el formato de dominio (www o sin www, coincidiendo con tu formato de URL preferido). Si tu CMS genera etiquetas canonical automáticamente, verifica que las etiquetas automáticas sean correctas para las páginas paginadas, ya que algunas plataformas CMS autorreferencian incorrectamente todas las páginas paginadas independientemente de la profundidad.

5

Optimiza la página 1 de cada serie paginada

Dado que la página 1 es la página de pagination con más probabilidades de ser indexada, invierte en hacerla lo más fuerte posible. Añade contenido introductorio único (descripción de categoría, guía de compra, resumen del tema) que solo aparezca en la página 1. Asegúrate de que la página 1 tenga un title tag y una meta description únicos y optimizados para palabras clave. Destaca tus elementos más importantes en la página 1 mediante curación manual o ordenación algorítmica. Añade datos estructurados (schema ItemList) a la página 1 para ayudar a Google a entender el formato de listado. Refuerza los enlaces internos que apuntan a la página 1 desde la navegación, los breadcrumbs y las páginas de contenido.

6

Controla el presupuesto de rastreo gastado en pagination profunda

Implementa controles de presupuesto de rastreo para la pagination profunda. Añade etiquetas noindex,follow a las páginas paginadas más allá de la página 5 (o tu umbral elegido). Esto permite a Google seguir los enlaces en las páginas profundas para descubrir elementos individuales de contenido mientras evita que las propias páginas profundas consuman cuota de índice. Para pagination muy profunda (página 20+), considera añadir reglas disallow en robots.txt para evitar el rastreo por completo, confiando en tu sitemap para el descubrimiento de contenido más allá de esa profundidad. Monitoriza las estadísticas de rastreo en Search Console después de implementar los controles para verificar que el presupuesto de rastreo se desplace de las páginas de listado a las páginas de contenido.

7

Envía las páginas paginadas clave y el contenido individual para indexación

Después de implementar los arreglos de pagination, envía la página 1 de cada categoría o sección importante a través de la herramienta de Inspección de URLs de Google Search Console. Para las páginas de contenido individual que anteriormente solo eran descubribles a través de la pagination profunda, envíalas a través de IndexBolt para asegurarte de que Google las indexe independientemente de su posición de pagination. Monitoriza la indexación tanto de las páginas de listado como de las páginas de contenido individual durante las semanas siguientes. Si las páginas de contenido permanecen sin indexar a pesar de estar en el sitemap y tener enlaces internos directos, investiga si las propias páginas tienen problemas de calidad o técnicos más allá del contexto de pagination.

¿Terminaste los pasos manuales? Acelera el proceso.

IndexBolt envía tus URL directamente a Google — la mayoría se rastrea en menos de 24 horas.

Problemas habituales y cómo solucionarlos

Productos/posts en la página 2+ no se indexan aunque los elementos de la página 1 sí

Causa: Los elementos en la página 1 reciben fuertes señales de enlazado interno desde la página de categoría (que a su vez está bien enlazada desde la navegación). Los elementos en páginas más profundas reciben señales más débiles porque las páginas paginadas en las que aparecen tienen menos autoridad y se rastrean con menos frecuencia. Además, si las páginas paginadas más allá de la página 1 no están indexadas, Google descubre los elementos de esas páginas con menos frecuencia que los elementos de la página 1.

Solución: Asegúrate de que todas las URLs de páginas individuales de contenido estén en tu sitemap XML, proporcionando una vía de descubrimiento independiente de la pagination. Añade enlaces internos a elementos importantes desde contextos no paginados: secciones de productos relacionados, menciones en entradas de blog, elementos destacados de la página de inicio y widgets de cross-sell. Considera rotar los elementos destacados para que diferentes productos aparezcan en la página 1 con el tiempo. Usa IndexBolt para enviar URLs de elementos individuales atascados en páginas profundas y que no se indexan orgánicamente.

El sitio con infinite scroll solo tiene indexado el primer lote de elementos

Causa: Google no puede hacer scroll, por lo que solo los elementos renderizados en la carga inicial de la página son visibles para Google. Los elementos cargados por solicitudes JavaScript disparadas por scroll son invisibles. Sin URLs paginadas subyacentes, Google no tiene forma de acceder al contenido más allá del primer lote visible. Los elementos más allá de la primera carga de scroll efectivamente no existen desde la perspectiva de Google.

Solución: Implementa URLs paginadas junto al infinite scroll usando el enfoque pushState de la History API. Cada segmento de scroll debería corresponder a una URL paginada rastreable. Incluye enlaces de navegación paginada en el HTML para que Google los siga. Verifica que cada URL paginada renderice su conjunto de contenido en el servidor. Después de la implementación, envía las URLs paginadas a través de IndexBolt o Search Console para acelerar el descubrimiento de Google de la nueva estructura de URLs.

Todas las páginas paginadas muestran 'Duplicado, Google ha elegido otra canónica' en Search Console

Causa: Google está tratando las páginas paginadas como duplicados entre sí o de la página 1. Esto sucede cuando las páginas paginadas tienen title tags idénticos, meta descriptions idénticas, contenido introductorio idéntico, y solo difieren en qué elementos se listan. Google las ve como variaciones de la misma página en lugar de páginas distintas, y elige una (normalmente la página 1) como canónica.

Solución: Si quieres que las páginas paginadas se indexen independientemente, diferéncialas. Añade números de página a los title tags ("Zapatillas de running - Página 2 de 8"). Crea meta descriptions únicas para cada página paginada o elimina las meta descriptions de las páginas 2+ para dejar que Google las genere a partir del contenido. Muestra el contenido introductorio solo en la página 1. Si no necesitas que las páginas profundas se indexen, establece explícitamente etiquetas canonical en las páginas 2+ apuntando a la página 1 y acepta que solo se indexará la página 1.

El contenido del botón Load More desaparece del índice de Google con el tiempo

Causa: El contenido detrás de los botones Load More que anteriormente era accesible a través de vías alternativas (sitemap antiguo, enlaces directos) puede perder la indexación cuando Google reevalúa el sitio. Si el contenido de Load More no es accesible sin interacción JavaScript y las vías alternativas ya no se mantienen, Google no tiene forma actual de acceder al contenido y puede desindexar elementos previamente indexados que ya no puede verificar que existan.

Solución: Implementa URLs paginadas renderizadas en servidor que Google pueda rastrear directamente. Asegúrate de que estas URLs estén en tu sitemap y enlazadas desde el HTML de la página de listado. Verifica que al eliminar el JavaScript de la página todavía se permita el acceso a todo el contenido a través de URLs paginadas. Después de arreglarlo, envía las URLs de los elementos afectados a través de IndexBolt para restaurar la indexación del contenido previamente desindexado.

Consejos pro

Añade datos estructurados ItemList en la página 1 de las secciones paginadas.
Usa un recuento de elementos por página consistente en todas las categorías del sitio.
Sustituye la pagination de blog basada en fechas por páginas hub de tema que enlacen a los mejores posts.
Comprueba Search Console para ver las impresiones en páginas profundas — aplica noindex a aquellas con cero.
Evita la ordenación tipo "primero en stock" que desplaza los productos entre páginas entre rastreos.

La pagination no debería determinar si tu contenido se indexa. IndexBolt envía las URLs de las páginas individuales de contenido directamente a Google, saltándose por completo la vía de descubrimiento por pagination. Tanto si tus productos están en la página 1 como en la página 50, IndexBolt asegura que todos se indexen. Envía tu lista completa de URLs de contenido y deja que cada página llegue a Google independientemente de su posición de pagination.

100 créditos gratis. Sin tarjeta de crédito. Resultados en menos de 24 horas.

Preguntas frecuentes

¿Google sigue soportando rel=prev/next de alguna forma?+

No. Google confirmó en marzo de 2019 que llevaba varios años sin usar rel=prev/next como señal de ranking o indexación. Incluir estas etiquetas en tu HTML no causa daño, pero no proporciona ningún beneficio para Google. Otros motores de búsqueda (Bing) aún pueden usar estas etiquetas, así que mantenerlas no perjudica, pero no deberías confiar en ellas para la indexación en Google. Tu estrategia de pagination para Google debe basarse en etiquetas canonical, directivas noindex, inclusión en sitemap y calidad del contenido en lugar de en señales rel=prev/next.

¿Debería crear una página 'View All' en lugar de usar pagination?+

Una página View All que lista cada elemento en una sola página es la solución más simple para Google porque elimina la pagination por completo. Google ha declarado que generalmente prefiere las páginas View All cuando son técnicamente viables. Sin embargo, las páginas View All solo son prácticas para conjuntos de contenido más pequeños (menos de 100 elementos). Para categorías con cientos o miles de elementos, una página View All sería demasiado lenta para cargar, demasiado intensiva en recursos para renderizar y demasiado abrumadora para los usuarios. Para grandes conjuntos de contenido, usa el enfoque híbrido de pagination tradicional combinado con un sitemap XML completo.

¿Hasta qué profundidad debería permitir que Google rastree mi pagination?+

No hay una respuesta universal, pero una guía práctica es permitir la indexación de las primeras tres a cinco páginas y aplicar noindex (mientras se permite follow) a las páginas más profundas. El umbral exacto depende de la calidad de tus páginas paginadas y del presupuesto de rastreo de tu sitio. Si tu sitio tiene una fuerte autoridad y Google está rastreando agresivamente, puedes permitir una indexación más profunda. Si tu sitio tiene un presupuesto de rastreo limitado, restringe la indexación solo a la página 1 y confía en tu sitemap para el descubrimiento de contenido. La métrica clave es si las páginas paginadas más profundas realmente generan impresiones de búsqueda. Comprueba Search Console para ver si alguna URL de página 5+ está recibiendo impresiones. Si no, aplicarles noindex ahorra presupuesto de rastreo sin impacto en el tráfico.

Mi infinite scroll usa AJAX para cargar contenido. ¿Puede Google ver el contenido cargado por AJAX?+

Google puede renderizar contenido cargado por JavaScript, incluidas respuestas AJAX, pero solo si la carga del contenido se dispara por el render inicial de la página en lugar de por interacción del usuario (scroll, clic). El contenido AJAX que se carga automáticamente en la carga de la página es visible para Google. El contenido AJAX que se carga en respuesta a un evento de scroll no lo es, porque el renderer de Google no hace scroll. Si tu infinite scroll dispara solicitudes AJAX basadas en la posición de scroll, ese contenido es invisible para Google. Implementa URLs paginadas subyacentes con contenido renderizado en servidor como base, y superpón la experiencia de infinite scroll con AJAX encima para los usuarios.

¿Importa el orden de los elementos en la pagination para el SEO?+

El orden de los elementos importa principalmente porque los elementos en la página 1 reciben significativamente más atención de rastreo y valor de enlazado interno que los elementos en páginas más profundas. Google es más propenso a rastrear e indexar el contenido de la página 1 que el de la página 10. Si tienes elementos de alta prioridad que quieres que se indexen y sean visibles, asegúrate de que aparezcan en la página 1 mediante curación manual, fijado o algoritmos de ordenación que muestren los elementos importantes primero. Para ecommerce, ordenar por más vendidos, mejor valorados o más recientes a menudo muestra de forma natural los productos más relevantes en la página 1. Evita la ordenación aleatoria que cambia con cada carga de página, ya que Google puede tener dificultades para evaluar contenido de página inconsistente.

¿Debería añadir contenido único a cada página paginada para ayudarla a indexarse?+

Añadir contenido único a cada página paginada no es práctico ni necesario para la mayoría de los sitios. Concentra tu esfuerzo de optimización de contenido en la página 1, que es la más probable de indexarse y la más importante para el tráfico de búsqueda. Para las páginas 2 a 5, los title tags diferenciados con números de página son suficientes. Para las páginas más profundas, aplícales noindex y no te preocupes por el contenido único. Los elementos individuales listados en esas páginas deben tener cada uno su propio contenido único en sus propias URLs. La página de listado paginado es un mecanismo de navegación, no un destino de contenido. Invierte tu esfuerzo de creación de contenido en los elementos individuales en lugar de en las páginas de listado.

¿Listo para indexar tus URLs?

Empieza con 100 créditos gratis. Sin tarjeta de crédito.