Formato nuevo
Paginación del sitio: cómo montarla sin dañar el SEO
La paginación parte una lista larga en páginas: catálogo, blog, resultados de búsqueda. Útil para lectores, pero sin reglas fácilmente obtienes páginas finas duplicadas en el índice.
Abajo: por qué hace falta, cómo montarla, ajustes SEO, el vínculo con filtros y la auditoría. Atributos exactos como rel prev/next ya no son universales — apóyate en tags canónicos y en si cada página es útil.
Por qué existe la paginación
La paginación acelera la carga, simplifica la navegación de listas grandes y da URLs estables para volver y enlazar. Hace falta donde la gente compara muchos ítems parecidos.
Las páginas numeradas son rastreables y disponibles sin JavaScript. Un botón «Mostrar más» puede complementarlas, pero no debe esconder el contenido solo detrás de JS.
Dónde aparece:
- catálogos de tienda online
- feeds de blog y noticias
- búsqueda on-site
- archivos y tags
Cómo montarla en un sitio
El servidor o el frontend devuelve un lote de ítems y navegación: números, siguiente/atrás. Haz URLs predecibles — `/catalog/page/2/` o `?page=2` — y consistentes en toda la sección.
Cada página existente necesita un código de estado correcto y enlaces a vecinos. Paginar más allá del final no debe devolver un 200 vacío como si hubiera contenido.
Práctica UX:
- la página actual se ve
- targets de toque grandes en móvil
- los filtros persisten entre páginas
- el sort no se resetea
- existe camino a la primera y a vecinos
Setup SEO
Title y H1 en páginas de paginación no deben ser clones sin sentido. Elige canonical según estrategia de catálogo y utilidad de listings profundos — no una plantilla «todo a la primera» a manta.
En el sitemap, incluye listings que deben indexar. Controla aparte filtros, sorts y duplicados de parámetros: a menudo duelen más que la numeración misma.
Errores habituales:
- miles de page=N casi vacías en el índice
- duplicados con/sin slash y parámetros distintos
- 200 en páginas inexistentes
- el mismo texto SEO encima de la lista en cada página
Paginación vs filtros y sorts
La paginación avanza por el mismo set. Filtros y sorts crean selecciones nuevas y fácilmente hinchan el índice a cientos de miles de URLs.
Decide de antemano: qué combinaciones indexar (landings fuertes), cuáles cerrar (noindex / robots / canonical). Si no, el SEO de paginación no te salva de una explosión de facets.
Separa en la política:
- page=N dentro de una categoría limpia
- filtro color + precio + marca
- sort por precio o novedad
- UTM y parámetros de utilidad
«Mostrar más» e infinite scroll
La numeración clásica es mejor para un catálogo cuando necesitas volver a un slice concreto. «Mostrar más» corta clics, pero las URLs del siguiente lote deben seguir disponibles para bots y personas.
Infinite scroll encaja en feeds de noticias, pero es peor cuando la gente necesita volver a una posición. Si usas JavaScript, ofrece salida renderizada en servidor y un camino sin script.
Revisa UX:
- se ve la página o posición actual
- los filtros persisten
- existe control por teclado
- tras Atrás del navegador, no se pierde el lugar en la lista
Contenido en páginas 2+
El copy SEO de categoría suele quedarse en la primera página. Copiarlo a la 2, 3 y siguientes no sirve y refuerza la sensación de duplicado.
En páginas profundas bastan una lista, navegación y un title claro («Página 2» / rango de productos — según plantilla de tienda). Lo que importa es un set único de fichas y enlaces correctos.
Buena práctica:
- set único de productos/posts por página
- no duplicar texto SEO largo
- enlaces internos a categorías clave desde la página 1
- no indexar una cola vacía
Indexar page=N (simplificado)
| Situación | Enfoque habitual |
|---|---|
| Muchos productos, listing útil | Indexar a propósito |
| Colas casi vacías | No indexar / fuera del sitemap |
| Landings fuertes de filtro | URLs aparte, no confundir con page |
| Solo sort | Suele no ir al índice |
Auditoría tras el lanzamiento
Crawl de la sección: códigos de estado, canonical, cadena de enlaces, ítems por página. Compara plantillas desktop y móvil.
En Webmaster/GSC vigila errores de índice y crawl. Cambiar filtros o la plantilla del catálogo puede crear miles de URLs — repite la auditoría tras releases.
Banderas rojas:
- páginas vacías con 200
- URLs distintas para el mismo set de resultados
- duplicados de parámetros
- contenido solo vía JavaScript
- explosión de page=N en el informe de índice
FAQ
¿Hace falta paginación en lugar de «mostrar más»?
Cualquiera de los dos enfoques vale. Infinite scroll es cómodo pero peor para compartir URLs profundas. El clásico `?page=2` es más fácil de controlar.
¿Deben indexarse page=2, 3…?
Si hay contenido o productos únicos y útiles — sí, a propósito. Si son casi copias vacías — noindex o canonicalize con criterio.
¿Ayuda rel=prev/next?
Google dejó hace tiempo de tratarlos como señal dura. Canonical, estructura y calidad pesan más.
¿Y los filtros y sorts?
No crees combos de filtro indexables que no necesitas — eso son facets, no paginación. Dales una política de parámetros aparte.
¿Cuántos productos por página?
Equilibra UX y peso de página: suelen ser docenas de fichas, no cientos de bloques pesados de golpe.
¿Siempre hay que canonicalizar a la página 1?
No siempre — depende de la unicidad del listing. No escondas fichas necesarias canonicalizando todo a page=1 a ciegas.
¿Una page=100 inexistente debe devolver 200?
Si la página no existe, devuelve 404 (o un «fin de lista» correcto), no un 200 vacío.
¿Todas las páginas van en el sitemap?
No es obligatorio. Incluye los listings que deben indexarse; una cola larga de page=N a menudo sobra.
¿page=N vacías inflando el índice?
Ordenamos canonical, facets y colas — sin 200 vacíos ni texto SEO clonado en cada página.
Hablar del proyecto
