La paginación se discute como si fuera un problema de indexación. Casi nunca lo es. El problema real es de descubrimiento: si tienes 4.000 productos repartidos en 167 páginas y la única forma de llegar al producto 3.800 es que Googlebot recorra 166 páginas en fila, ese producto no existe.
Esa es la pregunta que ordena todas las decisiones de este artículo. No “¿debe indexarse la página 7?”, sino “¿cómo llega un rastreador a los productos que están en la página 7?”.
Y hay una segunda capa que se ha vuelto seria este año: los rastreadores de IA no ejecutan JavaScript ni hacen clic en botones. Un catálogo que Google acaba descubriendo por insistencia puede ser invisible entero para ellos.
Aquí está el proceso completo: qué dice literalmente la documentación de Google (que contradice un par de recomendaciones muy repetidas), cómo decidir cuántos productos van por página, qué hacer con el canonical, por qué el noindex en paginadas profundas es una trampa, y cómo se junta todo esto con los filtros sin que explote el número de URLs.
Este artículo es la continuación natural de facetas y filtros: por qué el canonical no es la solución. Allí está la teoría del canonical, el robots.txt y el presupuesto de rastreo; aquí no la repito.
1. Cómo entiende Google la paginación hoy
El modelo mental correcto cabe en una frase: cada página de la serie es un documento independiente. No hay ninguna señal que le diga a Google “esto es un conjunto”. La página 2 se rastrea, se evalúa y se indexa (o no) por su cuenta.
Ese modelo cambió el 21 de marzo de 2019, cuando Google anunció que ya no usaba rel="next" y rel="prev". El detalle que lo hizo memorable es que llevaba años sin usarlos, y nadie en Google se había acordado de decirlo. Lo habían recomendado desde 2011.
La documentación actual de ecommerce lo recoge sin drama: Google ya no usa esas etiquetas, “aunque otros buscadores todavía pueden usarlas”.
Ese “otros buscadores” tiene nombre. Frédéric Dubut, de Bing, aclaró que Bing sí los utiliza como pistas para descubrir páginas y entender la estructura del sitio, aunque no para agrupar páginas ni para posicionarlas. O sea: si ya los tienes puestos, déjalos, que no molestan y a Bing le sirven. Si estás construyendo algo nuevo, no gastes ni una hora de desarrollo en ellos y pon ese esfuerzo en el enlazado.
2. Las cinco reglas oficiales
Esto es lo que dice la documentación de paginación y carga incremental de Google, resumido y sin adornos. Merece la pena tenerlo delante porque tres de las cinco se incumplen constantemente.
| Regla | Qué dice Google |
|---|---|
| URL única por página | Cada página necesita su propia URL, por ejemplo con un parámetro ?page=n |
| Nada de fragmentos | No uses identificadores de fragmento (#) para el número de página: Google los ignora |
Enlaces <a href> secuenciales | Enlaza cada página con la siguiente usando etiquetas <a href> rastreables |
| Canonical propio en cada página | No uses la primera página como canónica de toda la serie: cada página lleva su propia URL canónica |
| Los bots no pulsan botones | ”Los rastreadores de Google no hacen clic en botones” |
La cuarta es la que más dinero cuesta y la trato aparte en el bloque siguiente.
Sobre la primera hay un matiz de arquitectura que conviene decidir pronto: ?page=2 y /pagina-2/ funcionan igual de bien para Google. La ruta limpia tiene la ventaja de que separa la paginación del espacio de parámetros, con lo que puedes bloquear parámetros en robots.txt sin arrastrar la paginación por delante. Si tu web ya vive en parámetros, no merece la pena migrar solo por esto.
3. El canonical a la página 1: el error caro
Es la práctica más extendida y la que más inventario esconde.
La instrucción de Google es literal: no uses la primera página de una secuencia paginada como página canónica; dale a cada página su propia URL canónica. La página 2 canonicaliza a la página 2.
Lo que pasa cuando canonicalizas todo a la página 1: le estás diciendo a Google que las páginas 2 a 167 son versiones alternativas de la 1. Google deja de considerarlas resultados válidos, reduce su rastreo por considerarlas redundantes, y los productos que solo están enlazados desde ellas se quedan sin ruta de descubrimiento. No es que la página 5 no posicione, que daba igual: es que los cuarenta productos de la página 5 dejan de recibir enlaces internos que Google siga con interés.
En un catálogo grande el síntoma es inconfundible: fichas de producto en estado “descubierta, actualmente sin indexar” durante meses, concentradas en las categorías con más páginas. Si te suena, aquí está qué significa ese estado.
Dicho esto, una honestidad que casi ninguna guía se permite: que la página 2 sea autocanónica no significa que la vayas a ver indexada. Google evalúa cada página y muchas paginadas acaban sin indexar por poco valor. Eso está bien y no es un fallo. El canonical autorreferencial no está ahí para que la página 2 posicione, está para que Google la trate como una página legítima y siga sus enlaces con normalidad.
4. Títulos y metadatos: lo que Google dice de verdad
Aquí va la corrección que contradice a la mayoría de guías en español, incluidos los dos briefs que circulan sobre este tema.
Se repite que hay que poner títulos únicos en cada paginada, del tipo “Zapatillas de running mujer - Página 2”, para evitar duplicados. La documentación de Google dice lo contrario: las páginas de una secuencia paginada no necesitan seguir la recomendación de títulos y descripciones únicos, y puedes usar los mismos títulos y descripciones en todas.
Así que no, no tienes un problema de duplicados por repetir el title en la serie. Google sabe lo que es una paginación.
¿Significa que da igual? No del todo, y aquí ya opino con criterio propio, no citando a Google:
Añadir el número de página al title sigue siendo útil, pero por motivos que no son de posicionamiento. Te permite distinguir las paginadas en los informes de Search Console y en los rastreos, y evita que en la SERP aparezca un resultado idéntico al de la categoría cuando Google decide mostrar una paginada. Cuesta cinco minutos de plantilla y ahorra confusión en el análisis.
Lo que no hay que hacer es escribir contenido diferente en cada página. Ni textos introductorios distintos, ni bloques de “guía de compra” variados por página. Eso multiplica el trabajo de contenido por 167 y no aporta nada.
Y el texto introductorio de la categoría, solo en la página 1. Repetir 800 palabras idénticas en las 167 páginas de la serie es la definición de contenido inflado sin motivo. En la página 1 tiene sentido porque es la que compite por la consulta; en la 47 sobra. Sobre qué poner en ese texto y dónde, está el enfoque en el fin del texto SEO en el footer.
5. El noindex en páginas profundas es una trampa
La recomendación de “pon noindex, follow a partir de la página 5 para ahorrar presupuesto de rastreo” aparece en muchas guías. Tiene dos problemas y ninguno es menor.
No ahorra rastreo. La guía de presupuesto de rastreo de Google es explícita: no uses noindex para eso, porque Google seguirá pidiendo la página y la descartará al ver la etiqueta. El coste de rastreo se paga igual.
Y el follow caduca. John Mueller lo explicó en diciembre de 2017: cuando Google ve un noindex durante mucho tiempo, acaba tratando la página como si tuviera noindex, nofollow. Su frase fue que a largo plazo “noindex, follow es esencialmente lo mismo que noindex, nofollow”, porque una vez que la página sale del índice ya no puede seguir sus enlaces.
Júntalo con lo del bloque 3 y tienes el escenario completo: pones noindex, follow en la página 5 en adelante pensando que Google seguirá rastreando los enlaces a productos, y meses después esos enlaces han dejado de contar. Los productos que solo viven ahí se quedan aislados.
Entonces, ¿nunca? Casi nunca. El único caso donde lo consideraría es una serie con cientos de páginas donde los productos ya tienen otras rutas sólidas de descubrimiento: sitemaps completos, enlazado desde fichas relacionadas y subcategorías bien repartidas. Y aun así, antes de llegar ahí hay dos soluciones mejores: subir el número de productos por página y partir la categoría en subcategorías reales.
Si el problema es que tienes 167 páginas en una categoría, el problema no es la paginación. Es que esa categoría necesita hijos.
6. Paginación, “cargar más” e infinite scroll
La frase de la documentación de Google no deja lugar a interpretación: los rastreadores de Google no hacen clic en botones.
Con eso ya está resuelta la discusión de fondo, pero conviene ver los tres patrones con sus consecuencias.
| Patrón | Qué ve el usuario | Qué ve el bot | Riesgo |
|---|---|---|---|
| Paginación clásica con enlaces | Números de página | Todas las URLs de la serie | Ninguno si los enlaces son <a href> |
| Botón “cargar más” sin URL | Listado que crece | Solo el primer bloque de productos | Alto: el resto del catálogo no existe |
| Scroll infinito sin URL | Listado que crece al bajar | Solo el primer bloque | Alto, y además fatiga de scroll |
| Scroll infinito con estados de URL | Listado que crece, URL que cambia | Depende de si esas URLs se sirven completas | Medio: hay que verificarlo |
La solución que funciona es la de siempre, y no es “elegir entre UX y SEO”: mejora progresiva. El servidor sirve una paginación clásica con enlaces reales, y el JavaScript la mejora en el navegador cargando el siguiente bloque al pulsar o al bajar, actualizando la URL con la API de historial. El usuario ve un listado continuo. El bot ve una serie de páginas enlazadas.
La comprobación que decide si tu implementación es válida es una sola: desactiva JavaScript y navega. Si sin JavaScript no puedes llegar a la página 2, tu paginación no existe para nada que no sea un navegador moderno.
Y la segunda comprobación, que se salta casi todo el mundo: pide directamente ?page=7 en una ventana nueva. Tiene que devolver un 200 con los productos de la página 7 en el HTML de respuesta, no un 200 con un listado vacío que se rellena después. Si tu implementación solo funciona cuando se llega navegando desde la 6, no funciona.
Un apunte sobre el origen de esta recomendación, porque los briefs la atribuyen a la documentación actual: la guía canónica de scroll infinito compatible con búsqueda es una entrada del blog de Google de 2014. La documentación de ecommerce actual no entra en ese detalle, solo dice que estos patrones se implementan con JavaScript y remite a las prácticas de SEO para JavaScript. La recomendación sigue siendo buena, pero conviene saber que su fuente tiene doce años.
7. Cuántos productos por página
Esta es la decisión que más efecto tiene y la que casi nunca se toma con datos. Normalmente el número lo puso el tema de la plantilla y ahí se quedó.
La aritmética es simple y vale la pena hacerla con tus números:
| Productos por página | Páginas para 4.000 productos | Profundidad de la última página |
|---|---|---|
| 12 | 334 | Inalcanzable en la práctica |
| 24 | 167 | Muy profunda |
| 48 | 84 | Manejable con enlaces numerados |
| 96 | 42 | Cómoda |
| 200 | 20 | Cómoda, si el rendimiento aguanta |
Subir de 24 a 96 productos por página divide entre cuatro el número de URLs de la serie, acorta la distancia a los productos del final y reduce el rastreo dedicado a la propia paginación. Es el cambio de mayor impacto y menor coste de todo el artículo.
El límite lo pone el rendimiento, no el SEO. Cada producto añade su imagen, su marcado y su HTML, así que a partir de cierto número el LCP se resiente y el peso de la página se dispara. Los criterios que uso para decidir:
Mide antes de subir. Prueba 48, 96 y 200 en un entorno de pruebas y mira LCP e INP en cada caso, con datos de laboratorio y con la conexión limitada. Si el LCP se te va por encima de dos segundos y medio, has pasado el punto. Tienes el detalle en qué es el LCP y cómo mejorarlo.
Carga diferida en las imágenes de debajo del pliegue. Es lo que permite subir el número de productos sin pagarlo en rendimiento. Sin ella, 96 productos por página es inviable.
Vigila el tamaño del HTML. Googlebot rastrea los primeros 2 MB de un archivo de tipo admitido y descarta el resto. Con listados muy largos y marcado por producto se llega antes de lo que parece.
No cambies el número a la ligera si ya estás indexado. Pasar de 24 a 96 reordena toda la serie: la antigua página 4 ya no existe y su contenido está ahora en la página 1. Es una migración pequeña, con sus redirecciones y su periodo de reasentamiento. Merece la pena hacerla, pero avisando y con las páginas fuera de rango devolviendo 404.
8. La serie es inestable, y eso cambia el planteamiento
Un punto que no he visto tratado en ninguna guía y que explica bastante del comportamiento de Google con las paginadas.
En un ecommerce real, el contenido de la página 5 cambia cada día. Entra stock, se agota un producto, alguien cambia el orden por defecto a “novedades” y toda la serie se desplaza. La URL /zapatillas/page/5/ no identifica un contenido, identifica una posición en una lista que se mueve.
Consecuencias prácticas:
No esperes que las paginadas se indexen de forma estable. Google ve una página cuyo contenido cambia por completo entre rastreos y actúa en consecuencia. Eso no es un fallo tuyo.
No las metas en el sitemap. El sitemap es para URLs canónicas estables que quieres indexar. La paginación es infraestructura de rastreo, no destino. Lo que sí debe estar completo en el sitemap son las fichas de producto, que es la vía de descubrimiento que no depende de la posición en la lista.
No pongas enlaces internos a paginadas concretas. Enlazar desde un artículo a “la página 3 de zapatillas” es enlazar a un contenido que dentro de un mes será otro.
Y aquí está el argumento fuerte: si tus productos dependen para su descubrimiento de una lista que se reordena sola, no tienes una arquitectura, tienes una casualidad. Los productos necesitan rutas estables: subcategorías bien granuladas, enlaces desde fichas relacionadas, y sitemaps completos y actualizados. La paginación es la red de seguridad, no el camino principal.
9. La página “ver todo”
La idea de tener una URL con el catálogo completo de la categoría y canonicalizar la serie hacia ella viene de una recomendación de Google de 2011. Conviene saber que esa recomendación ya no aparece en la documentación actual de paginación de ecommerce, que habla solo de dar URL propia y canonical propio a cada página.
Mi criterio para decidir, que es de rendimiento y de negocio más que de SEO:
Compensa cuando la categoría entera cabe cómodamente en una página: por debajo de unos 150 productos, con carga diferida en las imágenes y sin que el LCP se resienta. Ahí concentras señales en una sola URL, el usuario ve todo el catálogo y te ahorras la serie.
No compensa cuando hay que servir 800 productos en un HTML de varios megas para que Google tenga que descartarlo por tamaño y el usuario espere seis segundos. En ese caso, ver todo es peor que paginar.
Y si la montas, que sea coherente: la serie paginada canonicaliza hacia el “ver todo”, la de “ver todo” es autocanónica, y no se mezcla con rel=next/prev, que no aportan nada y en Bing mandan una señal contradictoria.
10. Paginación y filtros: una sola política de listados
Aquí se juntan los dos problemas y es donde se generan los millones de URLs.
/zapatillas/?color=rojo&talla=42&orden=precio&page=3 es una URL. Y existen todas sus hermanas. Multiplica las combinaciones de filtros por el número de páginas de cada una y tienes el número real de URLs que tu web puede generar.
La regla que resuelve el 90 % de los casos: la paginación solo existe sobre estados que ya son indexables.
| Estado | ¿Puede tener paginación rastreable? |
|---|---|
| Categoría o subcategoría | Sí |
| Faceta curada con demanda propia y URL limpia | Sí |
| Filtro secundario en parámetros | No: el estado ya está bloqueado, su paginación también |
| Combinación de dos o más filtros | No |
| Ordenación y vista | No: no debería generar URL rastreable |
| Búsqueda interna | No |
Dicho de otro modo: si un estado no merece estar en el índice, su página 3 tampoco. Y si bloqueas los parámetros de filtro en robots.txt, la paginación de esos estados se bloquea sola, que es otra razón para tener la paginación en la ruta y los filtros en parámetros.
El criterio para decidir qué facetas merecen ser indexables (volumen, tipo de SERP e inventario) está desarrollado en el post de facetas, con la matriz completa.
Un caso frontera que da problemas: la ordenación. ?orden=precio-asc&page=2 es contenido idéntico al de otra página de la serie por defecto, solo que reordenado, y genera series enteras paralelas. Se resuelve con fragmento (#orden=precio) o bloqueando el parámetro. Nunca dejándolo rastreable.
11. El enlazado dentro de la serie
Con los enlaces <a href> no basta: importa a cuáles enlazas.
Solo “siguiente” es insuficiente. Si desde cada página solo enlazas a la siguiente, la página 84 está a 84 saltos de la categoría. Google rastrea en amplitud y las páginas muy profundas reciben mucho menos.
El patrón que funciona es el de números con saltos: primera, anterior, un rango de números alrededor de la actual, algún salto intermedio y última. Con eso, cualquier página de una serie de 84 queda a dos o tres saltos de la primera.
Enlaza a la última página. Es un enlace barato que reduce muchísimo la profundidad de la cola de la serie y que además le dice a Google el tamaño real del listado.
Enlaza de vuelta a la página 1 desde todas las de la serie. La documentación de Google lo menciona como opción para subrayar la importancia de la primera página, y de paso mantiene el reparto de enlaces hacia arriba.
Y no uses nofollow en los enlaces de paginación. Es una idea que aparece de vez en cuando para “no diluir autoridad” y el efecto real es dificultar el descubrimiento de tu propio catálogo. Sobre por qué el nofollow no funciona como reparto de autoridad, está explicado en el post de facetas.
La forma más rápida de auditar esto es mirar la profundidad de clic en un rastreo: si tus fichas de producto aparecen a cinco o más saltos de la home de forma sistemática, el enlazado de la serie es la causa más probable. Para el enfoque general está interlinking: cómo optimizar los enlaces internos.
12. Los estados límite que rompen la serie
Cinco casos que generan miles de URLs malas y que casi nadie prueba.
Página fuera de rango. /zapatillas/page/300/ en una categoría con 84 páginas. Tiene que devolver 404, no un 200 con un listado vacío. La guía de navegación facetada de Google lo dice para las combinaciones de filtros sin resultados y aplica igual aquí: un 200 vacío es un soft 404, y multiplicado por todas las categorías es un patrón de baja calidad extendido por el dominio.
Página 1 duplicada. /zapatillas/ y /zapatillas/page/1/ sirviendo lo mismo. Elige una (la limpia) y redirige la otra con un 301. Es de los duplicados más comunes y de los más fáciles de arreglar.
Categoría vacía. Cero productos en stock. Decide qué hace tu plantilla: mantenerla con productos relacionados si la categoría va a repoblarse, o devolver un 404 si desapareció del catálogo.
Parámetros añadidos a la paginación. ?page=2&utm_source=newsletter no debería ser rastreable. Se resuelve bloqueando los parámetros de campaña.
Cambio del número de productos por página. Si permites ?por_pagina=48 como parámetro rastreable, acabas de duplicar toda tu serie. Ese parámetro va bloqueado o en fragmento.
13. Datos estructurados en páginas paginadas
Aquí hay que deshacer una expectativa que circula en los briefs de este tema.
No existe hoy un rich result de carrusel para páginas de categoría de ecommerce. El marcado de carrusel con ItemList que documenta Google está admitido para listas de cursos, películas, recetas y restaurantes. No para listados de productos. Si alguien te vende CollectionPage con ItemList de productos como vía a un carrusel en la SERP, no va a pasar.
Lo cual no significa que el marcado no sirva. Lo que tiene sentido poner en una página de listado:
BreadcrumbList, que sí genera resultado enriquecido y ayuda a entender la jerarquía.CollectionPageconItemListapuntando por URL a las fichas de producto. No da rich result, pero describe la página de forma legible para máquinas, y ahí es donde importa cada vez más (bloque siguiente).- El marcado de producto completo, en la ficha, que es donde Google lo espera y donde genera los resultados enriquecidos de verdad.
Dos reglas de coherencia que sí son de Google: la información marcada debe corresponderse con la visible en la página, y todos los elementos de una lista deben ser del mismo tipo. Aplicado a la paginación significa que la página 3 marca los productos de la página 3, con sus posiciones correspondientes, y no el catálogo entero. Marcar 4.000 productos en cada paginada es exactamente lo que la política de coherencia prohíbe.
14. Paginación y motores de IA
El ángulo que casi ninguna guía está cubriendo y que en un catálogo grande decide si existes en las respuestas generativas.
El estudio de Vercel y MERJ mostró que los grandes rastreadores de IA no ejecutan JavaScript: GPTBot, ClaudeBot y PerplexityBot se quedan con el HTML de respuesta. Descargan los archivos JavaScript y no los ejecutan.
Aplicado a la paginación:
Un “cargar más” deja tu catálogo reducido al primer bloque. Google, con su servicio de renderizado, puede acabar viendo más. Ellos no. Si tienes 4.000 productos y sirves 24 en el HTML inicial, para un motor generativo tu catálogo tiene 24 productos.
El scroll infinito sin URLs es todavía peor, porque ni siquiera hay un enlace que seguir.
Y las series muy largas los agotan antes. En ese mismo estudio, más de un tercio de las peticiones de ChatGPT y de Claude terminaban en 404, frente al 8,22 % de Googlebot. Su gestión de espacios de URL es más rudimentaria, así que una serie de 300 páginas con parámetros de por medio es un mal sitio para gastar su presupuesto.
Lo que se deduce, y es coherente con todo lo anterior: HTML plano con enlaces reales, series cortas (más productos por página), y sitemaps completos de fichas de producto. Nada exótico. Si tu paginación funciona con JavaScript desactivado, funciona para ellos. Sobre el mecanismo completo, está en por qué ChatGPT no ve tu web en React.
15. Paginación en blogs, etiquetas y archivos
Todo lo anterior está escrito para catálogos, pero el problema es idéntico en un blog con 400 artículos, y ahí se descuida más.
Las diferencias que importan:
El contenido es estable. Un artículo publicado no cambia de página tan fácilmente como un producto cambia de posición. Solo se desplaza al publicar contenido nuevo, así que la serie es bastante más estable que en ecommerce.
El descubrimiento es más frágil. Un blog no suele tener un feed de productos ni sitemaps generados con la misma disciplina, así que la paginación del archivo es, muchas veces, la única ruta hacia los artículos antiguos.
Las páginas de etiquetas suelen sobrar. Un blog con 400 artículos y 300 etiquetas genera cientos de listados casi vacíos, cada uno con su propia paginación. Ahí el trabajo no es paginar mejor, es reducir el número de listados. El criterio de poda está en cómo mejorar tu SEO eliminando contenido.
Lo que aplicaría en un blog: archivos con bastantes entradas por página, enlaces numerados, canonical autorreferencial, sin noindex en la serie, sitemap completo de artículos, y un enlazado editorial decente entre posts para que ningún artículo dependa de estar en la página 12 del archivo.
16. Cómo auditar la paginación de tu web
Siete comprobaciones, por orden, y ninguna lleva más de diez minutos.
1. Desactiva JavaScript y navega a la página 2. Si no puedes, tienes un problema grave y el resto de comprobaciones sobran hasta arreglarlo.
2. Pide una página profunda directamente. Abre ?page=7 en una ventana limpia y mira el código fuente (no el inspector, el código fuente). Los productos tienen que estar ahí.
3. Comprueba los canonicals de la serie. En un rastreo, filtra las URLs de paginación y mira la columna de canonical. Todas deben apuntar a sí mismas.
4. Mide la profundidad de clic de tus productos. Si la mayoría está a cinco saltos o más, revisa el enlazado de la serie y el número de productos por página.
5. Pide una página fuera de rango. page/9999/ tiene que devolver 404.
6. Cuenta el tamaño real de tus series. Cuántas páginas tiene cada categoría y cuántos productos hay en la cola. Las categorías con más de 30 o 40 páginas son candidatas a subcategorizar o a subir productos por página.
7. Mira los logs. Es la prueba definitiva: qué proporción del rastreo de Googlebot se va en URLs de paginación y hasta qué página profunda llega de verdad.
# Qué páginas de la serie pide Googlebot y con qué frecuencia
grep -i "googlebot" access.log | awk '{print $7}' | grep -E "page[=/-]" | sort | uniq -c | sort -rn | head -40
Si Googlebot no pasa de la página 3 en ninguna categoría, ya sabes hasta dónde llega tu catálogo. El proceso completo de análisis está en análisis de logs: qué hace Googlebot de verdad en tu servidor.
17. Checklist
Base técnica
- Cada página de la serie tiene URL propia y estable
- Ningún número de página va en un fragmento (
#) - Los controles de paginación son enlaces
<a href>, no botones ni JavaScript - La serie es navegable con JavaScript desactivado
- Una petición directa a una página profunda devuelve 200 con los productos en el HTML
- Cada página lleva canonical autorreferencial
- Ninguna paginada canonicaliza a la página 1
- Sin
noindexen la serie salvo caso justificado y documentado -
/categoria/y/categoria/page/1/no coexisten: una redirige a la otra
Estructura de la serie
- Número de productos por página revisado con datos de rendimiento
- Ninguna categoría con una serie desproporcionadamente larga sin subcategorizar
- Enlaces a primera, última y a un rango de números, no solo a la siguiente
- Ninguna ficha de producto a más de cuatro saltos de la home
- Sin
nofollowen los enlaces de paginación
Estados límite
- Página fuera de rango devuelve 404
- Categoría vacía con tratamiento decidido
- Parámetros de campaña no rastreables sobre URLs paginadas
- Parámetro de productos por página bloqueado o en fragmento
- Ordenaciones sin serie paginada rastreable propia
Filtros
- Solo los estados indexables tienen paginación rastreable
- Los filtros bloqueados arrastran su paginación al bloqueo
- Paginación en la ruta y filtros en parámetros, si es posible
Contenido y marcado
- Texto introductorio de categoría solo en la página 1
- Title con número de página, por claridad de análisis
-
BreadcrumbListen todas las páginas de la serie - Los productos marcados en cada página son los visibles en esa página
- Paginadas fuera del sitemap; fichas de producto completas dentro
Descubrimiento alternativo
- Sitemap de productos completo y actualizado
- Enlaces entre fichas relacionadas
- Feed de Merchant Center al día, si aplica
18. Preguntas frecuentes
¿Hay que seguir usando rel=“next” y rel=“prev”?
Google dejó de usarlos y lo anunció el 21 de marzo de 2019, aunque llevaba años sin usarlos. Bing sí los utiliza como pista para descubrir páginas y entender la estructura, según indicó Frédéric Dubut. Si los tienes puestos, déjalos. Si estás desarrollando desde cero, no inviertas tiempo en ellos.
¿Cada página paginada debe llevar canonical a sí misma?
Sí. La documentación de Google dice expresamente que no uses la primera página como canónica de la secuencia y que cada página tenga su propia URL canónica. Otra cosa es que Google decida no indexar las páginas profundas, lo cual es normal y no indica un error.
¿Necesito títulos y meta descripciones únicos en cada página de la serie?
No. Google indica que las páginas de una secuencia paginada no necesitan seguir esa recomendación y que puedes usar los mismos títulos y descripciones en todas. Añadir el número de página sigue siendo útil para distinguirlas en tus informes, pero no es un requisito ni evita ninguna penalización.
¿Debo poner noindex en las páginas profundas para ahorrar crawl budget?
No es buena idea. Google seguirá pidiendo esas páginas igualmente, así que no ahorras rastreo, y a largo plazo un noindex acaba comportándose como noindex, nofollow, con lo que los productos enlazados solo desde ahí pierden su ruta de descubrimiento. Antes de eso, sube el número de productos por página o divide la categoría.
¿Cuántos productos debo mostrar por página?
Los máximos que el rendimiento aguante. Pasar de 24 a 96 divide entre cuatro el tamaño de la serie y acorta la distancia a los productos del final. El límite lo marcan el LCP y el peso del HTML, así que mídelo en pruebas con carga diferida de imágenes antes de decidir.
¿El scroll infinito es malo para el SEO?
Lo es cuando no hay URLs detrás, porque los rastreadores de Google no hacen clic en botones ni hacen scroll. Funciona bien si por debajo hay una paginación clásica servida desde el servidor y el JavaScript solo mejora la experiencia. La prueba es navegar con JavaScript desactivado.
¿Las páginas paginadas van en el sitemap?
No es necesario y yo no las pondría: el sitemap es para URLs canónicas estables que quieres indexar, y el contenido de una paginada cambia con cada movimiento del catálogo. Lo que sí debe estar completo es el sitemap de fichas de producto, que es la ruta de descubrimiento que no depende de la posición en la lista.
¿Sirve una página “ver todo”?
Solo si la categoría entera cabe sin destrozar el rendimiento, digamos por debajo de unas 150 referencias. La recomendación de Google de 2011 ya no aparece en la documentación actual de paginación, así que hoy es una decisión de rendimiento y de negocio, no una buena práctica por defecto.
¿Puedo combinar filtros con paginación?
Solo sobre estados que ya sean indexables por sí mismos: categorías, subcategorías y facetas curadas con demanda propia. Si un filtro está bloqueado al rastreo, su paginación se bloquea con él. Permitir paginación sobre combinaciones de filtros es la vía más rápida a un espacio de URLs de seis cifras.
¿Sirve el marcado de ItemList para conseguir un carrusel en la SERP?
No en páginas de categoría de ecommerce. El carrusel con ItemList que documenta Google está admitido para cursos, películas, recetas y restaurantes, no para listados de productos. El marcado sigue siendo útil para describir la página de forma legible por máquinas, pero no esperes un resultado enriquecido por ahí.
¿Afecta la paginación a que ChatGPT o Perplexity encuentren mis productos?
Bastante. Esos rastreadores no ejecutan JavaScript, así que un “cargar más” les deja el catálogo reducido al primer bloque de productos. Si tu paginación funciona con JavaScript desactivado y las series son cortas, para ellos funciona.
19. Qué hacer con todo esto
Tres comprobaciones que puedes hacer hoy mismo y que te dicen si tienes un problema y de qué tamaño.
Desactiva JavaScript y trata de llegar a la página 2 de tu categoría más grande. Mira el canonical de esa página 2. Y cuenta cuántas páginas tiene esa categoría.
Con esas tres respuestas ya sabes por dónde empezar. Si la paginación no funciona sin JavaScript, eso es lo primero y lo único hasta que esté resuelto. Si funciona pero canonicaliza a la página 1, ahí tienes inventario escondido. Y si la serie pasa de 40 páginas, el trabajo no es de etiquetas: es de subir productos por página y de partir la categoría en subcategorías con demanda propia.
Cuándo compensa pedir ayuda
Puedes hacerlo tú si tienes una tienda de tamaño medio, control sobre la plantilla y pocas categorías con series largas.
Busca ayuda cuando el catálogo tenga decenas de miles de referencias, cuando la paginación y los filtros compartan plantilla y estén generando combinaciones sin control, cuando el listado lo pinte un servicio externo de búsqueda y filtrado que no controlas, o cuando lleves meses viendo fichas de producto atascadas en “descubierta, actualmente sin indexar”. Ese último síntoma es paginación o enlazado interno en la inmensa mayoría de los casos.
En Consultoría SEO Sevilla revisamos esto dentro de la auditoría de arquitectura e indexación, que es donde se decide cómo se descubre tu catálogo, y en la auditoría SEO para ecommerce cuando hay que mirar también fichas, feeds y filtros. Si prefieres empezar por el diagnóstico técnico completo, está la auditoría SEO técnica, y todas las opciones en la página de auditorías SEO.
Si tienes productos que no consigues que se indexen y sospechas que el problema está en cómo se llega a ellos, escríbenos y lo miramos.
