Paginación y scroll infinito para SEO: guía práctica | Ighenatt

Una cuadrícula de productos puede parecer impecable para quien compra y, al mismo tiempo, ocultar casi todo su contenido a un rastreador. Se muestran los primeros 24 artículos, un botón solicita el siguiente lote y la URL no cambia. A primera vista no hay ningún fallo. Sin embargo, quizá no exista un enlace rastreable hacia el resto del catálogo, la página dos no tenga una dirección duradera y compartir la URL después de diez minutos de navegación devuelva a otra persona al principio.

El modelo más seguro es sencillo: asigna una URL persistente a cada bloque de resultados, conecta la serie mediante enlaces HTML normales y añade un canonical autorreferente a cada página útil. La paginación expone este modelo de forma directa. Un botón de cargar más o el scroll infinito pueden mejorar la experiencia visual, pero no deben convertirse en la única puerta de acceso al contenido.

Google indica que, por lo general, rastrea las URLs que encuentra en el atributo href de los elementos <a> y que no pulsa botones para cargar más contenido (Google, enlaces rastreables). Puedes construir una interfaz dinámica, pero el descubrimiento sigue necesitando enlaces.

Tres interfaces para tres formas de navegar

Los tres patrones dividen un conjunto grande de resultados en bloques más pequeños, aunque ofrecen controles distintos.

La paginación muestra un bloque cada vez y permite saltar a otros mediante enlaces explícitos. La posición queda clara: el usuario puede reconocer la página cuatro, copiar su URL y regresar más tarde. Encaja bien en búsquedas, catálogos y tareas de comparación donde interesa saber cuánto se ha avanzado.

El botón de cargar más mantiene una única lista visual. La persona decide cuándo añadir el bloque siguiente. Evita transiciones completas sin quitarle el control sobre el momento de ampliar los resultados. El error técnico habitual consiste en convertir ese botón en el único mecanismo para acceder a lo que falta.

El scroll infinito solicita contenido cuando el área visible se acerca al final de la lista. Puede funcionar en una experiencia de exploración donde la continuidad pesa más que una posición exacta. También puede alejar el pie de página sin límite, hacer crecer demasiado el documento y dejar a quien navega con teclado o tecnología de asistencia sin una señal clara de que han aparecido nuevos elementos.

Para SEO, son patrones de presentación, no tres sistemas de indexación. La documentación de Google trata la carga secuencial y el scroll infinito como interfaces que deben apoyarse en URLs distintas para cada bloque (Google, paginación y carga incremental). La base para el rastreador continúa siendo una serie enlazada.

Qué patrón elegir

La paginación encaja cuando los límites, la navegación directa y una ubicación visible ayudan a completar la tarea. Cargar más funciona si la continuidad aporta valor, pero conviene que el usuario decida cuándo crece la lista. El scroll infinito solo compensa en experiencias donde la exploración ininterrumpida justifica el coste adicional de estado, historial y accesibilidad.

Ninguno de los tres patrones concede por sí mismo una ventaja de ranking. La decisión parte del comportamiento de navegación. La implementación técnica, en cambio, debe conservar el descubrimiento, las direcciones estables y unas señales de indexación coherentes.

Diseña las URLs antes que la animación

Divide primero el conjunto completo en bloques deterministas. Con un mismo orden, cada elemento debería caer de forma predecible en un bloque. Después asigna una URL que el servidor o la capa de renderizado pueda abrir sin depender de interacciones anteriores.

Los parámetros de consulta son una opción habitual:

/tienda/?page=1
/tienda/?page=2
/tienda/?page=3

También sirven segmentos de ruta:

/tienda/pagina/1/
/tienda/pagina/2/
/tienda/pagina/3/

La consistencia importa más que el formato. Una petición directa a la tercera página debe devolver sus resultados, sus metadatos y los enlaces para avanzar o retroceder. No debería renderizar primero la página uno y esperar a que el historial del navegador reconstruya el estado pedido.

Google recomienda URLs únicas para cada bloque y desaconseja usar fragmentos como #page=2, ya que los fragmentos no suelen determinar qué contenido debe cargarse (Google, paginación y carga incremental). Usa un parámetro o una ruta que llegue al servidor.

El orden estable forma parte del contrato. Si los productos cambian de bloque de manera aleatoria en cada petición, usuarios y rastreadores encontrarán duplicados mientras otros artículos desaparecen del recorrido. Define un criterio principal y otro de desempate. El inventario de una tienda seguirá cambiando, pero no hace falta sumar volatilidad evitable.

Los filtros requieren otra política de indexación. Una categoría paginada y miles de combinaciones facetadas no son el mismo problema. Decide qué filtros merecen páginas de destino rastreables y cuáles deben permanecer como estados de uso interno. La guía sobre navegación facetada para SEO en ecommerce desarrolla esa decisión sobre el espacio de URLs.

En una tienda, este contrato también tiene que encajar con las plantillas de categoría, el descubrimiento de producto y los cambios de existencias. La guía de SEO técnico para ecommerce sitúa la paginación dentro de esa arquitectura más amplia.

Ofrece enlaces que funcionen sin JavaScript

Un rastreador debe llegar al bloque siguiente desde el HTML que recibe. Basta con una navegación corriente:

<nav aria-label="Páginas de resultados">
  <a href="/tienda/?page=1">1</a>
  <a href="/tienda/?page=2" aria-current="page">2</a>
  <a href="/tienda/?page=3">3</a>
  <a href="/tienda/?page=3">Siguiente</a>
</nav>

Google considera rastreable un enlace cuando es un elemento <a> cuyo href resuelve a una URL. Una función JavaScript sobre un span, un div con aspecto de botón o un anchor sin href no ofrecen una ruta equivalente (Google, enlaces rastreables).

No hace falta mostrar cientos de números. Enlaza la página actual con la anterior y la siguiente, y añade destinos cercanos o extremos cuando aporten utilidad. Si los enlaces permiten recorrer la serie, las páginas profundas dejan de depender únicamente de una respuesta JavaScript.

Conserva estos enlaces en el documento renderizado aunque JavaScript transforme la interfaz en un botón de cargar más o en scroll infinito. Pueden aparecer como un control compacto o como alternativa accesible. Lo que no conviene es retirar la única ruta de rastreo después de hidratar la página.

La documentación de JavaScript SEO de Google señala que el renderizado en servidor o el prerenderizado siguen siendo útiles: sirven el contenido antes a usuarios y rastreadores, y no todos los bots ejecutan JavaScript (Google, fundamentos de JavaScript SEO). Renderizar los elementos y la navegación en el HTML inicial también elimina bastante ambigüedad de las pruebas. Si esta capa falla, la guía de problemas de JavaScript SEO ofrece un proceso de diagnóstico más amplio.

Cada página útil lleva su propio canonical

La página dos no es un mero duplicado de la primera cuando muestra productos diferentes. Asigna a cada bloque útil un canonical autorreferente:

<!-- /tienda/?page=2 -->
<link rel="canonical" href="https://example.com/tienda/?page=2">

Google indica expresamente que no se debe usar la primera página de la serie como canonical de todas las demás. Cada bloque debe tener su propia URL canonical (Google, paginación y carga incremental). De este modo no estás declarando que varios conjuntos de resultados distintos son sustitutos de la página uno.

Una vista que reúne todos los resultados plantea un caso distinto. Si contiene los mismos elementos, rinde bien y es la versión preferida para búsqueda, puede convertirse en destino canonical. No crees esa URL solo para simplificar etiquetas. Una vista que agota el navegador, tarda demasiado o deja fuera productos no es un sustituto honesto.

El canonical es una señal, no una orden garantizada. Google evalúa su declaración junto con redirecciones, inclusión en sitemap y otras señales, y recomienda utilizar URLs absolutas coherentes (Google, consolidación de URLs duplicadas). Alinea los enlaces internos, la política del sitemap y las etiquetas canonical en vez de pedirle a una sola etiqueta que resuelva una arquitectura contradictoria.

rel="next" y rel="prev" tampoco arreglan el problema. Según su documentación de paginación, Google ya no los utiliza como señales de una serie paginada. Puedes mantener esas relaciones por otro consumidor o por una convención interna, pero Google sigue necesitando URLs coherentes y enlaces rastreables.

Cómo añadir un botón de cargar más sin esconder contenido

El patrón robusto empieza con una paginación que funciona. JavaScript intercepta la navegación, solicita el bloque siguiente y añade sus elementos. Debajo permanece un enlace hacia una URL real.

<a class="load-more" href="/tienda/?page=3">Cargar más productos</a>

Con JavaScript disponible, el controlador pide la tercera página, añade solo sus resultados, cambia el próximo destino y anuncia la actualización. Sin JavaScript, el enlace navega de la forma habitual. Googlebot también puede seguirlo sin tener que activar un botón.

Evita solicitudes repetidas mientras haya una carga en curso. Ante un error de red, no borres el enlace y permite reintentar. Cuando termine la serie, retira o desactiva el control con una explicación precisa. Un botón silencioso que no hace nada perjudica al usuario y complica el diagnóstico automatizado.

También hay que decidir qué debe ocurrir al pulsar Atrás. Si cargar varios bloques cambia un estado de navegación relevante, regístralo en la URL. Si no lo hace, al volver desde la ficha de un producto al menos deberían restaurarse la lista ampliada y una posición útil. No existe una solución universal, pero perder diez minutos de recorrido es claramente un fallo.

Scroll infinito con historial real

El scroll infinito puede reutilizar las mismas URLs. Observa un elemento centinela cerca del final, solicita el bloque siguiente, añádelo y conserva el límite entre bloques en el DOM. La API Intersection Observer detecta cuándo ese elemento cruza el área visible sin consultar continuamente la disposición desde el hilo principal.

Cuando un bloque se convierta en la sección visible principal, actualiza el navegador con su URL real. La History API proporciona pushState() y replaceState() para añadir o reemplazar entradas del historial sin recargar la página (MDN, uso de History API). La URL debe pertenecer al mismo origen. Utiliza las mismas rutas que ya responden correctamente a una petición directa.

No llames a pushState() ante cada pequeño desplazamiento. Llenarías el botón Atrás de pasos inútiles. Una política razonable consiste en reemplazar la entrada mientras el usuario permanece dentro de un bloque y añadir otra solo al cruzar un límite significativo. Pruébala en navegadores reales, porque la restauración automática y el enrutador de la aplicación pueden interferir.

Gestiona popstate para que Atrás y Adelante restauren el bloque representado por la URL. Si sus resultados ya no están en memoria, recupéralos o renderízalos. Si siguen presentes, restaura la posición o el foco sin repetir todas las peticiones. Abrir esa URL en una pestaña nueva debe funcionar igualmente; la History API no sustituye al enrutamiento del servidor.

El disparador de carga necesita límites. Precargar poco antes de llegar al final reduce la espera; solicitar muchas pantallas por adelantado gasta datos y dificulta recuperarse de errores. Respeta las preferencias de ahorro de datos y de movimiento reducido cuando la interfaz use animaciones. Facilita un acceso al pie de página o detén la carga automática tras un límite razonable y ofrece una continuación explícita.

La accesibilidad no se añade al final

Añadir contenido cambia la experiencia de lectura aunque el foco no se mueva. Una persona que mira la pantalla ve nuevas tarjetas. Quien utiliza un lector de pantalla puede no recibir ninguna indicación de que ha cambiado el número de resultados.

Usa un mensaje de estado como “Se han cargado 24 productos más” sin obligar a trasladar el foco. WCAG 2.2 explica que los mensajes de estado pueden exponerse a las tecnologías de asistencia mediante roles o propiedades sin recibir foco (W3C, mensajes de estado). Mantén el aviso breve y evita emitir varios por una sola carga.

No desplaces automáticamente el foco del teclado cuando el scroll infinito añada un bloque. Tras una acción explícita de cargar más, moverlo al primer resultado nuevo puede ayudar, pero también puede romper el contexto. Prueba el comportamiento con el control, la estructura y los lectores de pantalla compatibles. Como mínimo, conserva un orden lógico: WCAG exige que los componentes enfocables reciban el foco en una secuencia que preserve el significado y el uso (W3C, orden del foco).

Para una secuencia de artículos o tarjetas, el patrón WAI-ARIA feed define un contenedor con elementos article y describe expectativas de carga e interacción por teclado (W3C, rol feed). Úsalo solo si la interacción implementada respeta el patrón. Añadir role="feed" a una lista inaccesible no la repara.

Incluye una forma reconocible de saltarse la lista creciente. Un enlace hacia la paginación o el pie evita que alguien tenga que tabular por todas las tarjetas cargadas. Conserva los encabezados y las regiones identificadas al añadir bloques y no dupliques identificadores de elementos.

Fallos habituales y lo que delatan

El resto del catálogo solo existe tras un botón

El HTML inicial no enlaza a la segunda página y el botón llama a una API con un cursor opaco. Quien tiene JavaScript ve el catálogo; Googlebot no tiene por qué activar el control. Crea URLs duraderas y enlaces, y deja que el botón mejore la experiencia.

Todos los bloques canonicalizan hacia la primera página

Suele ocurrir cuando la plantilla ignora el parámetro de página al generar metadatos. Construye el canonical desde la URL resuelta y prueba la primera página, la segunda y la última. Que exista una etiqueta no significa que sea correcta.

#page=3 parece resolver el enrutamiento

Los fragmentos cambian la dirección sin solicitar una ruta al servidor, de ahí que resulten tentadores. Google desaconseja usarlos como URLs de bloques paginados. Emplea un parámetro o segmento y haz que la petición directa devuelva el contenido correspondiente.

El orden cambiante repite y pierde elementos

La paginación por offset sobre datos que cambian deprisa puede desplazar entradas entre peticiones. Usa un orden estable con desempate o una recuperación basada en cursor, pero conserva URLs duraderas y rastreables allí donde haga falta indexación. Un feed privado y personalizado quizá no deba aparecer en buscadores; no le añadas una arquitectura SEO que no necesita.

Los filtros multiplican la serie

Cada combinación de color, talla, orden y página acaba siendo rastreable. El espacio de URLs puede crecer mucho más de lo que justifica el catálogo. Define qué facetas tienen demanda, limita el enlazado interno y aplica una política consistente. Si el problema es el descubrimiento a escala, revisa la guía de optimización del crawl budget.

JavaScript cambia la URL, pero una petición directa falla

Durante la sesión todo parece correcto. Al refrescar la cuarta página aparece un 404 o vuelve la primera. Es un cambio cosmético de estado, no una dirección duradera. Crea un enrutamiento estático o de servidor para cada URL que escribas en el historial.

Los resultados nuevos llegan en silencio

La carga visual funciona, pero la tecnología de asistencia no recibe un aviso y quien usa teclado no llega al pie. Añade un mensaje de estado adecuado, preserva el orden del foco y ofrece una navegación explícita alrededor del feed.

Prueba el sistema como cuatro clientes distintos

Empieza por una petición HTTP directa. Solicita la segunda página sin cookies ni estado previo. Confirma que responde correctamente, muestra los elementos previstos, incluye un canonical autorreferente, aplica la política de indexación y ofrece enlaces rastreables. Repite la prueba con una página profunda y con la última.

Después inspecciona el HTML renderizado sin JavaScript. Si el objetivo es una mejora progresiva, tanto el bloque como la navegación deben seguir funcionando. Si la aplicación exige JavaScript, la salida renderizada en servidor o prerenderizada debería exponer el contenido y los destinos que esperas que encuentre un rastreador.

Usa luego la interfaz con ratón, teclado e historial. Carga varios bloques, abre un elemento, pulsa Atrás, refresca y comparte la URL. La lista, la dirección y la posición deben concordar. Limita la red y fuerza un error de API. El usuario debe conservar una opción de reintento que funcione.

Por último, prueba con tecnología de asistencia. Comprueba el aviso del número de resultados, el orden del foco, las regiones identificadas, los enlaces de salto y el final de la serie. Las herramientas automáticas detectan roles inválidos e IDs duplicados, pero no pueden decidir si volver desde la ficha de un producto resulta coherente.

Convierte estas comprobaciones en controles previos a la publicación, no en una auditoría puntual:

• cada URL de bloque muestreada devuelve el tramo de resultados previsto;
• los canonicals son absolutos y autorreferentes;
• los enlaces renderizados conectan toda la serie;
• el fragmento no es la única representación del estado;
• una petición directa y una URL creada por el historial devuelven contenido equivalente;
• un error de carga mantiene una vía de reintento;
• Atrás y Adelante restauran un estado con sentido;
• los avisos de estado y el orden del foco pasan una revisión manual;
• el orden definido no omite ni duplica elementos de forma sistemática.

En equipos grandes, estas pruebas encajan en la observabilidad SEO técnica dentro de CI/CD. Los casos de prueba de las plantillas pueden detectar un canonical perdido antes de publicar; los rastreos programados cubrirán más tarde la secuencia completa.

Preguntas frecuentes

¿Es mejor la paginación que el scroll infinito para SEO?

La paginación es más fácil de rastrear porque expone URLs y enlaces estables de manera natural. El scroll infinito también funciona si se apoya en la misma secuencia paginada, actualiza URLs reales a medida que se avanza y no espera que Googlebot pulse o haga scroll. El patrón adecuado depende de la tarea de navegación, no de una ventaja de ranking.

¿Todas las páginas paginadas deben canonicalizar hacia la primera?

No. Google recomienda que cada bloque tenga su propia URL canonical. Canonicalizar la segunda página y las siguientes hacia la primera puede presentar conjuntos distintos como duplicados. Una vista completa solo puede ser canonical cuando contiene el mismo contenido y es la versión que se quiere indexar.

¿Google sigue utilizando rel=next y rel=prev para la paginación?

Google ya no usa rel="next" y rel="prev" como señales de paginación. Pueden conservar significado para otros consumidores, pero no sustituyen a los enlaces rastreables, las URLs únicas, unas etiquetas canonical coherentes ni el enlazado interno en Google Search.

¿Puede Google rastrear contenido situado tras un botón de cargar más?

No dependas de ello. Google documenta que su rastreador no pulsa botones para cargar contenido adicional. Mantén el botón si ayuda al usuario, pero ofrece enlaces normales a las URLs de todos los bloques en el HTML renderizado para que los rastreadores puedan descubrir la secuencia completa.

El contrato que debe quedar por escrito

Antes de desarrollar, documenta qué estados del listado tienen URLs persistentes, cómo llega un rastreador a ellas, cuáles son indexables, cómo se generan sus canonicals y qué deben restaurar Atrás, Adelante y una recarga. Añade al mismo contrato el comportamiento accesible y el estado del último bloque.

Con esas decisiones explícitas, paginación, cargar más y scroll infinito se convierten en interfaces distintas sobre una arquitectura que se puede probar. Sin ellas, una lista visualmente pulida puede esconder la mayor parte del contenido y perder la posición del usuario al mismo tiempo.