Paginación

TL;DR — La paginación consiste en dividir una lista larga — productos, publicaciones de blog, resultados de búsqueda — en páginas numeradas como página 1, 2, 3. Cada página necesita su propia URL, y quieres que los motores de búsqueda puedan rastrearlas todas para que puedan encontrar el contenido enlazado desde las páginas más profundas. Los grandes errores son decirle a Google que esas páginas más profundas no importan (canonicalizándolas todas a la página 1 o aplicándoles noindex).

Qué es la paginación

Cuando tienes más elementos de los que caben en una página — por ejemplo, 500 productos en una categoría, o años de publicaciones de blog en un archivo — los divides en una serie de páginas. La página 1 muestra el primer lote, la página 2 el siguiente, y así sucesivamente. Cada página vive en su propia dirección (una URL), normalmente algo como ?page=2 o /page/2/.

Eso es la paginación. La has usado mil veces sin pensar en ello.

Por qué es importante para el SEO

Las páginas en sí casi nunca posicionan para nada ni reciben tráfico directo. Su verdadero trabajo es ser una ruta que los motores de búsqueda siguen para llegar a los productos o publicaciones listados en ellas. Si un bot no puede llegar a la página 3, no puede encontrar las cosas que solo están enlazadas desde la página 3.

Así que todo el juego es simple: deja que los motores de búsqueda rastreen cada página de la secuencia. La mayoría de los problemas de paginación vienen de bloquear accidentalmente esa ruta.

Las tres formas de mostrar contenido paginado

1. Páginas numeradas (paginación tradicional). Página 1, 2, 3, cada una con su propia URL. Esta es la opción segura y amigable para el SEO.
2. Un botón “Cargar más”. Una página, y al hacer clic en el botón se carga el siguiente lote. Está bien si el botón está construido con enlaces reales — es un problema si es un botón solo de JavaScript que los bots no pueden hacer clic.
3. Scroll infinito. El contenido se sigue cargando mientras haces scroll. Genial para los usuarios, pero los bots no hacen scroll, así que sin enlaces reales a páginas numeradas en algún lugar, el contenido más abajo puede que nunca se encuentre.

Los errores a evitar

• No apuntes la etiqueta canónica de cada página a la página 1. Eso le dice a Google que las páginas 2, 3, 4 son solo duplicados de la página 1 y que no deberían indexarse — lo que puede ocultar el contenido que hay en ellas.
• No añadas noindex a la página 2 y siguientes. Parece ordenado, pero puede hacer que Google deje de rastrear esas páginas con el tiempo, y entonces pierde la ruta hacia todo lo que enlazan.
• No bloquees la paginación en robots.txt ni añadas nofollow a los enlaces de las páginas. Ambos cortan la ruta de rastreo.

El dato histórico que vale la pena conocer

Solía haber un código especial — rel="prev" y rel="next" — que le decía a Google cómo se conectaban las páginas paginadas. Google dejó de usarlo en 2019. No entres en pánico y lo elimines, sin embargo: Bing todavía lo usa y los navegadores lo usan para cargar la siguiente página más rápido, así que vale la pena mantenerlo.

¿Quieres la versión completa — autocanónicas, el problema de la cadena de rastreo con noindex, y la extraña historia de cómo se descubrió la desaprobación de Google — cambia a la pestaña Avanzado.

TL;DR — Trata cada URL paginada como una página independiente: canónica autorreferencial, rastreable, indexable, con enlaces reales <a href>. Los errores clásicos — canonicalizar las páginas 2+ a la página 1, aplicarles noindex, nofollow a sus enlaces, bloquearlas en robots.txt — todos rompen la cadena de rastreo hacia el contenido al que esas páginas enlazan. Google dejó de usar rel=prev/next silenciosamente antes de anunciarlo en marzo de 2019; Bing todavía lo usa, así que deja el marcado en su lugar. El presupuesto de rastreo solo importa a muy gran escala, y las páginas paginadas generan casi nada de tráfico directo (un caso de estudio: ~0,3 % de los clics orgánicos) — su valor es como rutas de rastreo.

Cada página paginada se sostiene por sí misma

Este es el único cambio mental que arregla la mayoría de los problemas de paginación. Después de que Google dejara de usar rel=prev/next, John Mueller expresó la nueva realidad claramente: “For the most part, we just index the pages as we find them, so as we’ve recommended for a long time, it’s good to make sure that all pages can stand on their own.” (traducción) «En su mayor parte, simplemente indexamos las páginas tal como las encontramos, así que, como hemos recomendado durante mucho tiempo, es bueno asegurarse de que todas las páginas puedan sostenerse por sí mismas.»

«Sostenerse por sí misma» significa que cada página de la secuencia es una página normal e indexable con una URL principal autorreferencial — la de la página 2 apunta a la página 2 y la de la página 3 a la página 3. La guía actual de Google es explícita: dale a cada página su propia URL canónica; no uses la primera página como URL principal para todo el conjunto.

Una excepción a la práctica recomendada habitual: Google dice que las etiquetas <title> idénticas en una secuencia paginada están bien. Las páginas de un conjunto paginado “don’t need to follow” (traducción) «no necesitan seguir» la recomendación habitual de títulos únicos, así que no tienes que inventar sufijos como “Página 2 de 9” (aunque no hacen daño).

La historia de rel=prev/next — y por qué es la parte interesante

En 2011, Google introdujo rel="prev" y rel="next" — elementos <link> en el <head> que le decían a Google qué URLs formaban una secuencia paginada para que pudiera consolidar señales entre ellas. Durante la mayor parte de la década de 2010, añadirlos era una higiene estándar del SEO técnico.

Luego dejó de importar silenciosamente. La forma en que el mundo del SEO se enteró es la parte que la mayoría de los artículos omiten: Gary Illyes descubrió, durante una investigación interna, que Google ya había dejado de usar rel=prev/next silenciosamente — y no lo había estado usando durante algún tiempo. Lo escaló internamente, y el 21 de marzo de 2019 la cuenta @googlewmc lo hizo público:

El anuncio explicó, en español, que Google retiraba rel=prev/next tras reevaluar sus señales de indexación; recomendaba el contenido de una sola página cuando fuera posible, aunque aclaraba que el contenido dividido en varias partes también era válido para la Búsqueda de Google.

La razón: la indexación de Google se había vuelto lo suficientemente buena para reconocer secuencias paginadas a partir de encabezados, títulos y enlaces internos que la pista explícita era redundante. Cuando hablé sobre esto en SMX West a principios de 2020, lo que seguía volviendo a mi mente era lo completamente que tomó por sorpresa a la industria — todos habíamos estado haciendo un trabajo que, resultó, Google no había estado leyendo durante un tiempo.

¿Deberías eliminar rel=prev/next? No — y aquí es donde mucha gente sobrecorrige. Cubrí exactamente esto en mi artículo de Ahrefs, Cómo se rompe la paginación tras el cambio de Google en rel=prev/next. Mantenlo, porque:

• Bing todavía lo admite y lo recomienda. La guía de Bing no ha cambiado — un rel="next" y/o un rel="prev" por página, en el <head>. Eliminarlo para “clean up after Google” (traducción) «limpiar después de Google» solo puede perjudicar tu rendimiento en Bing.
• Los navegadores lo usan para precargar — pueden precargar la página siguiente para una experiencia más rápida.
• Es un estándar W3C y ayuda con la accesibilidad.

Entonces: Google lo ignora, todos los demás todavía se benefician. Dejarlo en su lugar es la decisión correcta.

Canónicos: autorreferencia, no página 1

El patrón antiguo, ahora perjudicial, era canonicalizar las páginas 2, 3, 4… de vuelta a la página 1. La intención era “evitar contenido duplicado”, pero el efecto es lo contrario de lo que quieres: le estás diciendo a Google que esas páginas más profundas son duplicados que no deberían indexarse, lo que huérfana el contenido enlazado solo desde ellas y rompe la ruta de rastreo a través de la secuencia.

Correcto: cada página es autocanónica. La única alternativa legítima es una página de vista completa — una sola URL que muestre todo el conjunto — con las páginas paginadas canonicalizando hacia esa. La guía anterior de Google se apoyaba mucho en la vista completa; la guía actual la suaviza a “una opción si la página carga lo suficientemente rápido”. Para la mayoría de los catálogos grandes, los canónicos autorreferenciales en cada página paginada es el valor predeterminado más simple y seguro.

¿Deberías usar noindex en la página 2+? Casi nunca — y aquí está la trampa

La opción aparentemente ordenada es poner noindex en todo lo que esté más allá de la página 1 para que solo la página 1 aparezca en la búsqueda. El problema es lo que noindex hace al rastreo con el tiempo: Google eventualmente rastrea menos las páginas con noindex y puede dejar de seguir los enlaces en ellas. Si la página 3 tiene noindex y Google deja de rastrearla, Google pierde su camino hacia todo lo que solo está enlazado desde la página 3. Ese es el problema de la cadena de rastreo, y es por eso que el noindex en la paginación tiende a enterrar contenido silenciosamente.

La heurística de Mueller para saber si una página se puede indexar con noindex de forma segura es una comprobación útil: “Si alguien solo viera esta página desde mi sitio, ¿estarías bien?” Para una página genuinamente fina y sin valor, la respuesta podría ser sí, pero para una lista paginada que es la única ruta hacia docenas de productos, la respuesta casi siempre es no.

Donde el noindex sí suele ser apropiado: variantes de filtro y ordenación, que la gente confunde con la paginación. Una secuencia paginada real (?page=2) debería permanecer indexable. Una variante filtrada u ordenada (/shoes/?color=red&sort=price) suele ser un candidato a trampa de araña casi duplicado que legítimamente puedes querer poner con noindex o bloquear. Distinguir ambos casos es la clave: esto se superpone en gran medida con cómo manejas la navegación facetada, que es un tema propio.

Los otros asesinos de la ruta de rastreo

La misma regla de “no romper la ruta” descarta algunos patrones más:

• No marques con nofollow los enlaces de paginación. Cada página paginada es parte de tu grafo de enlaces internos; esa marca en los enlaces de navegación bloquea el flujo de PageRank y la señal de rastreo hacia las páginas más profundas.
• No bloquees la paginación en robots.txt. Eso impide que Google llegue a las páginas por completo, y por lo tanto a todo lo que está enlazado desde ellas.
• Usa enlaces reales <a href> para los controles de paginación. Google rastrea las URLs encontradas en los atributos href; un botón de “Cargar más” solo con JavaScript que dispara un onclick sin un enlace real es invisible para Googlebot. Google es explícito en que sus rastreadores “no ‘hacen clic’ en botones y generalmente no activan funciones de JavaScript que requieren acciones del usuario.”

Scroll infinito y “Cargar más”: hazlos rastreables

El scroll infinito está bien para los usuarios y es hostil para los rastreadores a menos que les des a los bots una alternativa. La solución es una contraparte paginada y rastreable: URLs reales ?page=n con enlaces <a href> (a menudo mostrados en un pie de página o en una alternativa <noscript>) que expongan el mismo contenido que el scroll carga dinámicamente. El mismo consejo para “Cargar más”: el botón puede impulsar la experiencia de usuario, pero debería haber una ruta real de enlace ancla hacia cada página de resultados detrás de él. Para catálogos muy grandes, apóyate en mapas de sitio XML (o un feed de Merchant Center) para complementar el descubrimiento, ya que no puedes contar con que el descubrimiento por enlaces llegue a todo.

Datos estructurados en contenido paginado

No hay un tipo de esquema especial para “una serie paginada”. Marca lo que realmente hay en cada página: el marcado Product pertenece a las páginas de producto individuales (no al contenedor de paginación), y el marcado Article en cada página de una serie de artículos de varias partes. No intentes expresar la relación anterior/siguiente a través de datos estructurados: no es para eso.

Presupuesto de rastreo y la comprobación de la realidad

La paginación crea muchas URLs, por eso se la culpa de los problemas de presupuesto de rastreo. La respuesta honesta: para la mayoría de los sitios no importa. El presupuesto de rastreo es una restricción real solo a gran escala: piensa en 1M+ páginas, o catálogos muy grandes que cambian rápidamente. Google tiene, según Mueller, “mucha experiencia tratando con la paginación” y aprende tus patrones de URL con el tiempo, por lo que generalmente maneja bien las secuencias paginadas sin configuración especial.

Y vale la pena mantenerlo en perspectiva: las páginas paginadas generan casi nada de tráfico orgánico directo. Un caso de estudio conocido encontró que las URLs de paginación representaban solo ~0,3 % de los clics orgánicos totales, sin impacto negativo en el SEO por tener muchas de ellas indexadas. Eso refuerza el enfoque de toda esta página: las páginas paginadas se ganan su lugar como rutas de rastreo hacia el contenido que exponen, no como páginas de clasificación por derecho propio. Así que el consejo práctico que sigo dando: no lo compliques en exceso. Haz que las páginas sean rastreables y autocanónicas, luego déjalas en paz y deja que Google lo resuelva.

Una advertencia honesta: tener la configuración técnica correcta —enlaces rastreables, autocanónicas, sin noindex accidental— solo mantiene la puerta abierta. No garantiza que Google rastree, indexe o clasifique cualquier página paginada dada, y no garantiza tráfico ni una cita de IA tampoco. Lo que elimina son las razones arquitectónicas por las que el contenido en páginas más profundas se pasa por alto en primer lugar.

Este tema se sitúa junto al resto del grupo de estructura del sitio web — el enlazado interno, la navegación facetada, la estructura de URLs y las migas de pan moldean la misma cuestión de rutas de rastreo desde diferentes ángulos.

Resumen de IA

Una versión condensada de la versión avanzada:

• Paginación divide grandes conjuntos de contenido (páginas de categoría, archivos, resultados de búsqueda, series de artículos) en URLs numeradas secuencialmente. El valor SEO de cada página es como ruta de rastreo hacia el contenido al que enlaza — no como página de clasificación.
• Cada página paginada debería valerse por sí misma: indexable, rastreable, con una URL principal autorreferencial. Google: dale a cada página su propia URL principal — no apuntes las páginas 2+ hacia la página 1.
• rel=prev/next: Google dejó de usarlo silenciosamente antes de anunciar el retiro el 21 de marzo de 2019 (Gary Illyes lo encontró internamente). Bing todavía lo usa, los navegadores lo precargan, es un estándar W3C — así que no lo elimines.
• No pongas noindex en la página 2+ en casos normales: las páginas con noindex se rastrean menos y Google puede dejar de seguir sus enlaces, rompiendo la cadena de rastreo hacia el contenido enlazado solo desde esas páginas. La prueba de Mueller: “If someone only saw this page… would that be OK?” (traducción) «Si alguien solo viera esta página… ¿estaría bien?»
• Las variantes de filtro/orden ≠ paginación. El ?page=n verdadero sigue siendo indexable; las variantes filtradas (?color=red&sort=price) a menudo se noindexan/bloquean legítimamente.
• También evita: nofollow en enlaces de paginación, bloquearlos en robots.txt y botones de “Cargar más” solo con JavaScript. Usa enlaces <a href> reales; dale al scroll infinito un respaldo paginado rastreable.
• Datos estructurados: marca lo que hay en cada página (Product, Article); ningún tipo de esquema expresa una serie paginada.
• El presupuesto de rastreo importa solo a gran escala (~1M+ páginas). Las páginas paginadas generan ~0,3 % de los clics orgánicos en un caso de estudio. No lo compliques en exceso.
• Sin garantías: la configuración correcta elimina las razones arquitectónicas por las que las páginas más profundas se pasan por alto — no garantiza rastreo, indexación, clasificaciones, tráfico ni citas de IA.

Documentación oficial

Orientación de fuentes primarias de los motores de búsqueda.

Google

• Prácticas recomendadas de paginación para Google — orientación actual sobre la URL principal: dale a cada página su propia URL principal, los tres patrones de UX (paginación, cargar más, scroll infinito) y los requisitos de enlaces rastreables.
• Paginación con rel=“next” y rel=“prev” (2011) — la orientación original (ahora obsoleta), mantenida por contexto histórico.
• Vídeo sobre paginación con rel=“next” y rel=“prev” (2012) — el seguimiento de 2012.
• Consolidación de URL duplicadas — métodos de canonicalización (el tema adyacente del que depende el manejo de la paginación).

Bing / Microsoft

• Implementación del marcado para contenido paginado y secuencial — la guía aún vigente de Bing sobre rel=prev/next: un rel="next"/rel="prev" por página, en el <head>, combinable con la URL canónica.
• Bing Webmaster Guidelines.

Citas de la fuente

Declaraciones públicas de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — la retirada de rel=prev/next (21 de marzo de 2019)

• “Spring cleaning! As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search.” (traducción) «¡Limpieza de primavera! Al evaluar nuestras señales de indexación, decidimos retirar rel=prev/next. Los estudios muestran que a los usuarios les encanta el contenido de una sola página, apunta a eso cuando sea posible, pero el contenido en varias partes también está bien para la Búsqueda de Google.» — @googlewmc, 21 de marzo de 2019. Ver el tuit
• “Google no longer uses these tags, although these links may still be used by other search engines.” (traducción) «Google ya no utiliza estas etiquetas, aunque otros motores de búsqueda pueden seguir usando estos enlaces.» — Google Search Central, documentación sobre paginación. Ir a la cita

Google — dale a cada página su propio canonical

• “Give each page its own canonical URL” — y no uses la primera página como canonical para todas las páginas paginadas. (traducción) «Dale a cada página su propia URL canónica» Ir a la cita
• Sobre el rastreo de la paginación con JavaScript: los rastreadores de Google “don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.” (traducción) «no “hacen clic” en los botones y, por lo general, no activan funciones de JavaScript que requieran acciones del usuario para actualizar el contenido de la página actual.» Ir a la cita

John Mueller, Google — las páginas deben sostenerse por sí mismas

• “For the most part, we just index the pages as we find them, so as we’ve recommended for a long time, it’s good to make sure that all pages can stand on their own.” (traducción) «En su mayor parte, simplemente indexamos las páginas tal como las encontramos, así que, como hemos recomendado durante mucho tiempo, es bueno asegurarse de que todas las páginas puedan sostenerse por sí mismas.» Cobertura
• Sobre la heurística para noindexar una página paginada: “If someone only saw this page from my site, would that be OK?” (traducción) «Si alguien solo viera esta página de mi sitio, ¿estaría bien?» Si es así, puedes aplicarle noindex — pero ese es un estándar alto para la mayoría del contenido paginado. Cobertura

Lista de verificación de SEO para paginación

Una pasada para confirmar que los motores de búsqueda pueden rastrear tus secuencias paginadas y el contenido que hay detrás de ellas:

• Cada página paginada tiene su propia URL única (p. ej. ?page=2) — sin identificadores de fragmento (#) que marquen números de página (Google ignora los fragmentos).
• Cada página lleva una canonical autorreferencial — no una canonical que apunte de vuelta a la página 1 (a menos que deliberadamente uses una página de vista completa).
• Las páginas 2+ son indexables (sin noindex general).
• Los controles de paginación son enlaces reales <a href>, no botones solo de JavaScript.
• Los enlaces de paginación se pueden seguir.
• Las URLs de paginación no están bloqueadas en robots.txt.
• rel="prev" / rel="next" se dejan en su lugar (para Bing, la precarga del navegador, la accesibilidad) — aunque Google los ignore.
• El desplazamiento infinito / “Cargar más” tiene un respaldo paginado rastreable con enlaces ancla reales.
• Los sitemaps XML complementan el descubrimiento para catálogos grandes (especialmente listados renderizados con JS).
• Las variantes de filtro/orden (p. ej. ?color=red&sort=price) se manejan por separado de la paginación real — usa noindex/bloquea estas si no añaden valor único.
• Los datos estructurados marcan lo que hay en cada página (Product, Article), no el contenedor de paginación.

Los modelos mentales

1. Las páginas paginadas son rutas de rastreo, no destinos. Su trabajo es exponer los productos/publicaciones enlazados desde ellas para que los bots (y el PageRank) puedan alcanzarlos. Una vez que interiorices esto, casi todas las reglas se siguen solas: no hagas nada que rompa la ruta. Un estudio de caso midió la paginación en ~0,3 % de los clics orgánicos — no posicionan, enrutan.

2. “¿Puede esta página sostenerse por sí sola?” El replanteamiento de Mueller tras la retirada de rel=prev/next. Trata cada URL paginada como una página normal, autocanónica e indexable, en lugar de un fragmento dependiente de un conjunto.

3. Los cuatro rompedores de la cadena de rastreo. Ten esto claro y la mayoría de los errores de paginación desaparecen:

• Canonicalizar las páginas 2+ → página 1 (dice “duplicado, no indexar”)
• noindex en las páginas 2+ (se rastrean menos → los enlaces dejan de seguirse)
• nofollow en los enlaces de paginación (bloquea el PageRank + la señal de rastreo)
• robots.txt con disallow (bloquea el acceso por completo)

4. “Google lo usa” ≠ “sigue siendo útil”. rel=prev/next es el ejemplo canónico: Google lo eliminó, pero Bing lo usa, los navegadores precargan con él, y es HTML válido. Decide qué mantener para todos los consumidores, no solo para Google.

5. Paginación vs. variantes facetadas. Una secuencia real (?page=2) permanece indexable. Las variantes de filtro/orden (?color=red&sort=price) suelen ser ruido casi duplicado que puedes marcar con noindex o bloquear. URLs de aspecto similar, manejo opuesto — clasifica antes de configurar.

¿Cómo debería un listado largo exponer más elementos?

Errores de paginación que cortan la ruta de rastreo

Canonicalizar cada página a la página uno

La página dos y las siguientes contienen elementos diferentes, así que la página uno no es su equivalente. Deja que las páginas de componentes se autocanonicalicen; usa redirecciones o consolidación canónica solo cuando las URLs sean genuinamente duplicadas.

Añadir noindex a la página dos y más allá

La directiva elimina esas URLs del índice y puede debilitar la ruta hacia los elementos enlazados solo desde páginas más profundas. Mantén la secuencia rastreable y mejora el listado en lugar de ocultar su continuación.

Construir desplazamiento infinito sin URLs persistentes

Un evento de desplazamiento o un botón no es una ruta de rastreo. Combina la experiencia con URLs de página únicas y cargables y anclas reales para que cada elemento siga siendo alcanzable sin interacción del usuario.

Fallos comunes de paginación

Los productos en páginas posteriores no se descubren

Síntoma: Los elementos visibles tras hacer clic o desplazarse nunca aparecen en un rastreo. Causa probable: El siguiente lote se carga solo mediante JavaScript y no tiene URL de ancla. Solución: Expón URLs paginadas persistentes, enlázalas con anclas normales y verifica que un rastreo que comienza en la página uno alcance las URLs de los elementos.

Google selecciona la página uno como canónica para toda la serie

Síntoma: La Inspección de URLs informa que la página uno es la URL principal de Google para páginas más profundas. Causa probable: Todas las páginas declaran la página uno como principal o muestran contenido casi idéntico. Solución: Usa URL principales autorreferenciales, conjuntos de elementos distintos, títulos estables cuando sea útil y enlaces internos consistentes a cada página de componente.

Los rastreadores se quedan en un bucle con números de página infinitos

Síntoma: Un rastreo descubre URLs vacías o repetidas mucho más allá de la última página real. Causa probable: El enlace “siguiente” se genera sin comprobar si existe otro lote. Solución: Deja de emitir el ancla “siguiente” en la página final y devuelve una respuesta de no encontrado real para números de página imposibles.

Referencia de señales de paginación

Ponte a prueba: Paginación

Cinco preguntas rápidas sobre el manejo de la paginación para SEO. Elige una respuesta para cada una y luego comprueba.

Recursos que valen tu tiempo

Mis escritos sobre paginación

• Cómo se rompe la paginación tras el cambio de Google en rel=prev/next y cómo corregirla — mi artículo principal sobre este tema: por qué mantener el marcado y los cuatro errores que rompen la paginación.
• Etiquetas de URL principal: guía sencilla para principiantes — la mecánica de las URL principales de la que depende el manejo de la paginación.
• Guía para principiantes de SEO técnico — dónde encaja la paginación en el panorama más amplio del rastreo e indexación.

Mis charlas

• Video: Patrick Stox on pagination, technical SEO & community (Search Engine Land, SMX West 2020) — mi opinión sobre cómo la silenciosa desaprobación de rel=prev/next por parte de Google tomó por sorpresa a la industria y por qué los SEOs sobreingenierizan la paginación.

De la industria

• Prácticas recomendadas de paginación para Google (Google Search Central) — la guía oficial actual.
• Implementación del marcado para contenido paginado y secuencial (blog para webmasters de Bing) — los requisitos actuales de rel=prev/next de Bing.
• Gary Illyes, quien descubrió que rel=prev/next ya no era compatible (Search Engine Roundtable) — la historia de cómo salió a la luz la desaprobación.
• Consejos de Google sobre paginación y series de páginas (Search Engine Roundtable) — la guía de Mueller sobre páginas independientes.
• Qué ocurre cuando el 67 % de las URL indexadas de un sitio son de paginación (GSQI / Glenn Gabe) — el estudio de caso donde la paginación generó solo ~0,3 % de los clics orgánicos sin impacto negativo.
• Explicación de la saga de rel=prev/next de 2019 (Embryo) — un recorrido claro de la desaprobación y sus consecuencias.

Registro de cambios