La paginación SEO es la práctica de estructurar secuencias de varias páginas —categorías, archivos de blog, listados de resultados— para que los buscadores puedan rastrear toda la serie y llegar al contenido que hay debajo. A diferencia de una única página larga, la paginación reparte los elementos en URLs distintas, lo que convierte los caminos de rastreo en el factor que decide si tu catálogo profundo llega a indexarse.
Aquí está lo que casi todas las guías siguen contando mal. Google anunció en marzo de 2019 que había dejado de usar rel="next" y rel="prev" como señales de indexación, y confirmó que llevaba varios años sin utilizarlos. Siete años después, hay artículos publicados este mismo año recomendando implementarlos.
La documentación de ecommerce de Google sugiere entre 24 y 48 elementos por página como rango razonable, y Google Search Central afirma sin rodeos que sus rastreadores «no pulsan botones y generalmente no ejecutan funciones de JavaScript que requieran acciones del usuario». Esa segunda frase es la que silenciosamente le cuesta a muchas webs su catálogo entero.
Esto importa más que antes porque la paginación es hoy el camino de rastreo principal hacia buena parte de cualquier catálogo. Si un producto solo aparece en la página 7 de una categoría y la página 7 es inalcanzable, ese producto no está compitiendo. No es que posicione mal: no está en el índice.
En mi experiencia auditando ecommerce y medios grandes, los problemas de paginación casi nunca aparecen como errores. Nada en Search Console te avisa de que «los enlaces a tu página 2 son JavaScript». La web parece sana hasta que alguien nota que el inventario profundo ha dejado de generar impresiones.
Qué exige realmente la paginación SEO en 2026
Si quitas el folclore acumulado, los requisitos son pocos. La guía de Google se reduce a dos cosas: dar a cada página de la secuencia una URL única y enlazarlas entre sí con etiquetas <a href> estándar.
Ese es todo el contrato. Un patrón como /categoria/?page=2 o /categoria/page/2/ es perfectamente válido. Lo que no vale es una URL que nunca cambia, una que solo cambia después del hash (#page=2) o un control de «siguiente» que es un <button> con un manejador de clic en lugar de un enlace.
Todo lo demás —canonical, sitemaps, titles— es secundario frente a si un rastreador puede recorrer la cadena desde la página 1 hasta el final. Si no puede, ninguna optimización de etiquetas rescatará las páginas de debajo.
Tres detalles de implementación sí pesan. Cada página necesita canonical autorreferencial. Cada página necesita un title único, normalmente añadiendo el número de página para que Google no vea cuarenta titles idénticos. Y los enlaces de paginación tienen que estar en el HTML renderizado en servidor, no aparecer tras la hidratación.
El problema de rel=“next” y rel=“prev”
Durante casi una década, rel="next" y rel="prev" en el <head> fueron la respuesta de manual a la paginación. El anuncio de Google de marzo de 2019 diciendo que los había descartado como señal de indexación —y que llevaba años sin usarlos— cayó como un jarro de agua fría, precisamente porque muchísimas webs los habían implementado con cuidado.
El daño posterior ha sido indirecto pero real. Cuando saltó la noticia, una oleada de webs entró a «arreglar» su paginación y la empeoró, arrancando estructuras de enlazado que funcionaban junto con las etiquetas obsoletas. El análisis de Ahrefs sobre la deprecación documentó webs haciéndose daño a sí mismas durante esa limpieza.
Dos conclusiones prácticas. Si estás construyendo paginación hoy, no implementes estas etiquetas: estás escribiendo código que Google descarta al llegar. Si tu web ya las tiene, déjalas. Son inertes, no dañinas, y Bing ha dicho que las sigue usando como pista. No hay ninguna recuperación de posiciones esperándote detrás de quitarlas.
Un error relacionado que merece nombre propio: me encuentro con frecuencia rel="next" colocado en el <body> en lugar del <head>, aparentemente por analogía con el rel="nofollow" de los enlaces. Eso nunca fue marcado válido. Es una señal fiable de que la paginación se implementó desde un post a medio recordar en vez de desde la documentación.
El error de canonical que desindexa tus propias páginas
Este es el fallo de paginación más caro que circula, y todavía se recomienda con nombre y apellidos en guías publicadas este año: poner el canonical de todas las páginas paginadas apuntando a la página 1.
La lógica suena razonable —las páginas 2 a 40 son casi duplicados de la 1, así que hay que consolidar—. La lógica es errónea por partida doble.
Primero, no son duplicados. La página 2 contiene un conjunto de productos o artículos completamente distinto al de la página 1. Decirle a Google que son lo mismo es afirmar algo falso sobre tu propia web.
Segundo, y peor: un canonical que apunta a otra URL indica que esta no debe indexarse. Google pasa entonces a tratarla como objetivo de rastreo de baja prioridad. Y todos los enlaces de esa página —incluido el único enlace interno a los cuarenta productos que lista— heredan esa despriorización. No has consolidado señales de posicionamiento. Has cortado la cuerda hacia tu propio inventario.
La implementación correcta es canonical autorreferencial en cada página de la serie. El canonical de la página 2 apunta a la página 2. Cada página es indexable de forma independiente y los enlaces que contiene siguen vivos como caminos de rastreo. Esto conecta directamente con el crawl budget: una paginación sana es cómo el presupuesto de rastreo llega a la profundidad, y una rota es cómo esa profundidad se queda sin nada.
El mismo razonamiento descarta poner noindex general en las páginas paginadas. Una página con noindex se sigue rastreando, y Google acaba tratando las páginas con noindex prolongado como si tuvieran nofollow, así que los enlaces dejan de transmitir por completo. Si de verdad quieres las páginas 2 y siguientes fuera del índice, sigues necesitando que sus enlaces sean rastreables, y eso convierte al noindex en la herramienta equivocada.
Paginación con JavaScript: por qué el rastreador nunca ve la página 2
Este es el fallo que más me encuentro en stacks modernos y el que más sorprende a los clientes.
Una página de listado en React, Vue o Next.js pinta veinte elementos. El usuario pulsa «Siguiente». JavaScript pide los veinte siguientes y los intercambia en el DOM. La URL o no cambia, o cambia solo mediante un hash. No hay documento nuevo, no hay URL nueva, no hay nada que un rastreador pueda solicitar.
La postura de Google no admite interpretación: los rastreadores no pulsan botones y no ejecutan JavaScript que requiera interacción del usuario. Googlebot renderiza JavaScript, pero renderizar no es interactuar. Carga la página en su estado inicial y lee lo que hay. La página 2 solo existe como consecuencia de una acción que nadie realiza.
El resultado es una categoría con 800 productos donde exactamente 20 son descubribles. Si esos 780 productos no tienen otro enlace interno —y en la mayoría de webs no lo tienen— se convierten en páginas huérfanas por accidente.
Y ahora esto pincha más que antes, porque la población de rastreadores ha cambiado. Googlebot al menos renderiza JavaScript. La mayoría de rastreadores de IA no lo hacen: piden el HTML en crudo y lo parsean. Todo lo que tu framework hidrata sencillamente no forma parte del documento que ellos ven, lo que coloca la paginación solo-JS de lleno en el problema del acceso de los rastreadores de IA.
La solución no pasa por abandonar tu framework. Pasa por que cada estado paginado tenga una URL real, que el control de «siguiente» sea un <a href> que apunte a ella y que pedir esa URL directamente devuelva el contenido correcto desde el servidor. La mejora en cliente por encima de eso está bien. El cuadro completo está en la guía de JavaScript SEO.
Paginación, cargar más, scroll infinito o ver todo
Cuatro patrones, con consecuencias SEO muy distintas. La decisión suele tomarla un diseñador, lo cual está bien siempre que alguien especifique la capa de rastreo que va debajo.
| Patrón | Rastreable por defecto | Cuándo tiene sentido |
|---|---|---|
| Paginación clásica | Sí, si los enlaces son <a href> | Opción por defecto en catálogos, archivos y listados grandes |
| Botón «cargar más» | No, necesita paginación de respaldo | Buena UX en móvil; exige URLs reales detrás del botón |
| Scroll infinito | No, necesita una estructura paginada en la sombra | Feeds y navegación de descubrimiento, nunca como camino de rastreo principal |
| Página «ver todo» | Sí | Solo conjuntos pequeños; rompe Core Web Vitals pasados unos cientos de elementos |
La regla para «cargar más» y scroll infinito es la misma y viene directamente de Google: construye debajo una serie paginada. URLs reales, enlaces reales, renderizado en servidor, actualizando la URL con la History API según el usuario baja. El usuario tiene la experiencia fluida; los rastreadores tienen documentos discretos.
Una página «ver todo» es genuinamente útil en una categoría de 60 productos y genuinamente destructiva en una de 6.000, donde se convierte en un documento de varios megas que suspende todos los umbrales de Core Web Vitals que te importan. El rango de 24 a 48 elementos por página de Google es un valor por defecto sensato cuando hay dudas.
Auditoría de paginación SEO en siete pasos
Esta es la secuencia que ejecuto en toda auditoría de web grande. Lleva menos de una hora y encuentra problemas que ninguna herramienta automática reporta.
- Desactiva JavaScript y carga una página de categoría profunda. Si los controles de paginación desaparecen, o «Siguiente» no hace nada, has encontrado el problema en el primer paso. Todo lo demás es secundario hasta que esto pase.
- Navega a la página 2 y lee la barra de direcciones. Tiene que cambiar a una URL distinta y solicitable. Un fragmento con hash no cuenta.
- Pide esa URL de la página 2 directamente en una sesión nueva. Debe devolver el contenido correcto y un estado 200 sin necesidad de venir desde la página 1.
- Mira el código fuente de la página 2 y comprueba el canonical. Debe apuntar a la página 2. Si apunta a la 1, has encontrado el fallo de desindexación descrito arriba.
- Busca
noindexen las páginas 2 y siguientes. Después revisa elrobots.txtpor si hay un disallow sobre tu parámetro de paginación: es un resto sorprendentemente común de alguna limpieza de navegación facetada. - Cuenta los clics desde la home hasta la última página de tu categoría más grande. Si una categoría llega a 40 páginas y solo muestra enlaces a las páginas 1–3 más «siguiente», la última queda a 37 clics de profundidad. Eso es inalcanzable en la práctica por muy correctas que sean tus etiquetas.
- Confirma que cada página paginada tiene un title único. Añadir el número de página es suficiente.
El paso 6 es el que todo el mundo se salta, y a menudo es la restricción real. Un marcado impecable en una página enterrada a 37 niveles no cambia nada. Ampliar el control de paginación para mostrar primera, última y un rango de páginas numeradas reduce esa profundidad drásticamente: la misma lógica estructural que gobierna el enlazado interno en el resto de la web.
Cómo verificar que Google rastrea de verdad las páginas profundas
Pasar la auditoría significa que la implementación es correcta. No demuestra que Google esté actuando en consecuencia. La verificación es donde casi todo el trabajo de paginación se detiene demasiado pronto, y es parte central de cualquier proyecto serio de SEO técnico.
Empieza por la herramienta de inspección de URLs de Search Console sobre una URL paginada profunda concreta: la página 8, no la 2. Comprueba si está indexada y lee el campo de «página de referencia»: te dice qué URL usó Google para descubrirla. Si el descubrimiento vino solo del sitemap y nunca de un enlace interno, tu camino de rastreo está roto aunque la página esté indexada.
Después revisa el informe de indexación de páginas buscando el patrón. Ver URLs paginadas en bloque bajo «Rastreada: actualmente sin indexar» es normal y suele estar bien. Las mismas URLs bajo «Detectada: actualmente sin indexar» son la señal de alarma: Google sabe que existen y ha decidido que no merecen la pena, lo que apunta a una restricción de crawl budget o de calidad del sitio más que a un fallo de paginación. La distinción merece entenderse bien, y la desarrollé en la guía de rastreada pero sin indexar.
El análisis de logs lo zanja de forma definitiva. Filtra los logs del servidor por los accesos de Googlebot contra tu patrón de paginación y representa la distribución por profundidad de página. En una web sana la curva desciende de forma gradual. En una rota cae en picado después de la página 2 o 3, lo que te dice exactamente dónde se detienen los rastreadores y cuánto catálogo queda al otro lado de esa línea.
Aplicar bien las mejores prácticas de paginación SEO es trabajo poco vistoso: URLs únicas, enlaces reales, canonical autorreferencial y una pasada de verificación que demuestre que ha aterrizado. Pero es la diferencia entre un catálogo que Google ha visto y uno que no, y ninguna cantidad de contenido o link building compensa páginas que nunca llegaron a rastrearse. Si quieres revisar esto a fondo en tu web, para eso está una auditoría SEO.
Preguntas frecuentes
¿La paginación es mala para el SEO?
No, la paginación es neutra y normalmente es mejor que las alternativas. Dividir una categoría de 400 productos en páginas es la forma de mantenerlas rápidas y rastreables sin cargarlo todo de golpe. La paginación solo se convierte en un problema SEO cuando la implementación rompe los caminos de rastreo: enlaces solo por JavaScript, canonical apuntando a la página 1 o noindex en las páginas profundas. Arregla la implementación y la paginación no te cuesta nada.
¿El canonical de las páginas paginadas debe apuntar a la página 1?
No, y es el error de paginación más caro que me encuentro en auditorías. Cada página paginada debe llevar un canonical autorreferencial que apunte a sí misma. Poner el canonical de las páginas 2, 3 y 4 hacia la página 1 le dice a Google que son duplicados que no debe indexar, y de paso devalúa todos los caminos de enlace que pasan por ellas, incluida la única ruta hacia los productos que aparecen en la página 7.
¿Google sigue usando rel=next y rel=prev?
No. Google anunció en marzo de 2019 que había dejado de usar rel=next y rel=prev como señal de indexación, y confirmó que llevaba años sin utilizarlos. Implementarlos en una web nueva en 2026 es tiempo de desarrollo tirado. No hacen daño directo si ya están puestos, así que no hay urgencia por quitarlos, pero nunca deberían formar parte de un desarrollo nuevo.
¿El scroll infinito es malo para el SEO?
El scroll infinito es malo para el SEO cuando es la única forma de llegar al contenido. Los rastreadores de Google no hacen scroll ni pulsan botones, así que todo lo que se carga con un evento de scroll o de clic es invisible para ellos. La solución no es renunciar al scroll infinito, sino construir debajo una serie paginada: URLs reales, enlaces reales, renderizados en servidor. El usuario tiene el scroll y el rastreador tiene las páginas.
¿Hay que incluir las páginas paginadas en el sitemap XML?
En general no. El sitemap es para las URLs de destino que quieres posicionar: productos, artículos y páginas de categoría. Las páginas paginadas son caminos de rastreo, no destinos, y meterlas en el sitemap lo diluye sin mejorar el descubrimiento. La excepción es una web muy grande donde las páginas profundas realmente no se están alcanzando: ahí incluirlas de forma temporal puede ayudar mientras arreglas el enlazado interno.
