Paginació i scroll infinit SEO: guia pràctica | Ighenatt

Una graella de productes pot semblar impecable a una persona i ser gairebé invisible per a un rastrejador. Es mostren els primers 24 productes, un botó demana el bloc següent i el navegador conserva el mateix URL. A primera vista no falla res. Però potser la resta de productes no tenen cap camí rastrejable, la pàgina dos no existeix com a adreça permanent i compartir l’URL quan som a mig llistat torna a portar-nos al principi.

El model més segur és força senzill: cada pàgina de resultats ha de tenir una URL persistent, la seqüència s’ha de connectar amb enllaços HTML normals i cada pàgina útil ha de declarar una etiqueta canònica autoreferent. La paginació mostra aquest model directament. Un botó de carregar més o el scroll infinit poden millorar-ne l’experiència, però no haurien de ser l’única porta d’accés al contingut.

Aquesta diferència importa perquè Google explica que, en general, rastreja les URL que troba a l’atribut href dels elements <a> i que no prem botons per carregar més contingut (Google, enllaços rastrejables). La interfície pot ser dinàmica; el descobriment continua necessitant enllaços.

Paginació, carregar més i scroll infinit resolen necessitats diferents

Els tres patrons divideixen un conjunt extens de resultats en blocs més petits, però no ofereixen el mateix control.

La paginació presenta un bloc cada vegada i dona enllaços explícits a la resta. La ubicació és visible: una persona pot identificar la pàgina quatre, copiar-ne l’URL i tornar-hi més tard. És una opció natural per a tasques de comparació, resultats de cerca i catàlegs on convé percebre el progrés.

El botó de carregar més manté l’usuari en un sol llistat visual. És ell qui decideix quan vol afegir un altre bloc. Evita transicions entre pàgines sense eliminar el control sobre l’expansió de la llista. L’error tècnic habitual consisteix a convertir aquest botó en l’únic accés als resultats següents.

El scroll infinit carrega un bloc quan la finestra gràfica s’acosta al final del contingut actual. Pot encaixar en una navegació exploratòria, quan la continuïtat pesa més que una posició exacta. També pot allunyar el peu de pàgina indefinidament, fer créixer massa el document i deixar les persones que naveguen amb teclat o tecnologia assistiva sense saber que han aparegut nous elements.

Des del punt de vista SEO, són patrons de presentació, no tres sistemes d’indexació. La documentació de Google tracta la càrrega seqüencial i el scroll infinit com a interfícies que han d’estar sostingudes per URL diferents per a cada bloc (Google, paginació i càrrega incremental). La base visible per al rastrejador continua sent una sèrie enllaçada.

Una matriu per triar la interfície

Tria paginació si els límits, la navegació directa i una ubicació evident ajuden l’usuari. Tria carregar més si la continuïtat és útil, però vols que la persona decideixi quan creix el llistat. Reserva el scroll infinit per als casos on l’exploració ininterrompuda sigui prou important per assumir el cost de gestionar estat i accessibilitat.

Cap patró aporta per si sol un avantatge de rànquing. La decisió ha de respondre a la manera de navegar, mentre la implementació conserva el descobriment, les adreces estables i els senyals d’indexació.

Defineix el model d’URLs abans de programar la interacció

Comença dividint el conjunt complet de resultats en blocs deterministes. Amb un ordre estable, cada element ha d’aparèixer en un bloc previsible. Després assigna-hi una URL que el servidor o la capa de renderització pugui obrir sense dependre de cap interacció anterior.

Els paràmetres de consulta són una opció habitual:

/ca/botiga/?page=1
/ca/botiga/?page=2
/ca/botiga/?page=3

També poden funcionar els segments de ruta:

/ca/botiga/pagina/1/
/ca/botiga/pagina/2/
/ca/botiga/pagina/3/

La coherència és més important que l’opció escollida. Una petició directa a la pàgina tres ha de retornar els seus resultats, les metadades correctes i els enllaços per recórrer la seqüència. No hauria de mostrar primer la pàgina u i esperar que l’historial del client reconstrueixi l’estat demanat.

Google recomana explícitament una URL única per a cada bloc i desaconsella fragments com #page=2, perquè en general no utilitza els fragments per decidir quin contingut s’ha de carregar (Google, paginació i càrrega incremental). Fes servir un paràmetre o una ruta que arribi al servidor.

L’ordenació estable forma part d’aquest model. Si els productes salten aleatòriament entre blocs a cada petició, rastrejadors i usuaris trobaran duplicats mentre altres elements desapareixen de la sèrie recorreguda. Defineix l’ordre principal i un segon criteri determinista per als empats. L’inventari d’un catàleg viu continuarà canviant, però el sistema no hi ha d’afegir volatilitat evitable.

Els filtres necessiten una política d’indexació pròpia. Una categoria paginada i milers de combinacions facetades no són el mateix problema. Cal decidir quins estats filtrats mereixen pàgines de destinació rastrejables i quins han de quedar com a combinacions per a l’usuari. La guia de navegació facetada per al SEO de comerç electrònic tracta aquesta decisió sobre l’espai d’URL.

En comerç electrònic, el contracte d’URLs també ha d’encaixar amb les plantilles de categoria, el descobriment de productes i els canvis d’estoc. La guia de SEO tècnic per a ecommerce situa la paginació dins d’aquesta arquitectura més àmplia.

Mostra enllaços que funcionin sense gestors de clic

El rastrejador ha de poder arribar al bloc següent a partir de l’HTML que rep. Un control de navegació convencional ja ho resol:

<nav aria-label="Pàgines de resultats">
  <a href="/ca/botiga/?page=1">1</a>
  <a href="/ca/botiga/?page=2" aria-current="page">2</a>
  <a href="/ca/botiga/?page=3">3</a>
  <a href="/ca/botiga/?page=3">Següent</a>
</nav>

Google considera rastrejable un enllaç quan és un element <a> amb un href que resol un URL. Una funció JavaScript aplicada a un span, un div amb aparença de botó o un enllaç sense href no ofereixen un camí de descobriment equivalent (Google, enllaços rastrejables).

No cal mostrar centenars de números alhora. Enllaça el bloc actual amb l’anterior i el següent, i afegeix enllaços propers o als extrems quan siguin útils. El que compta és poder recórrer la seqüència seguint enllaços i evitar que els blocs profunds només existeixin dins d’una resposta JavaScript.

Conserva aquests enllaços al document renderitzat encara que JavaScript els transformi en un botó de carregar més o en scroll infinit. Es poden presentar com un control compacte o una alternativa accessible, però la hidratació no ha d’eliminar l’únic camí de rastreig.

La documentació de SEO JavaScript de Google assenyala que la renderització al servidor o prèvia continua sent útil perquè posa el contingut abans a disposició dels usuaris i dels rastrejadors, i no tots els bots executen JavaScript (Google, conceptes bàsics de SEO JavaScript). A més, si els elements i la navegació ja són a l’HTML inicial, les proves resulten molt menys ambigües.

Cada pàgina útil necessita un canonical propi

La pàgina dos no és una simple còpia de la primera si mostra elements diferents. Dona a cada bloc útil un canonical autoreferent:

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

La documentació de Google indica que no s’ha d’utilitzar la primera pàgina com a canònica per a tots els components d’una seqüència. Cadascun ha de tenir el seu URL canònic (Google, paginació i càrrega incremental). Així no es comunica al cercador que conjunts de resultats diferents són substituts de la primera pàgina.

Una pàgina que ho mostra tot és un cas diferent. Si conté de debò els mateixos elements, ofereix un bon rendiment i és la versió preferida per a cerca, pot ser un destí canònic. No creïs aquest endpoint només per simplificar etiquetes: una pàgina que esgota el temps de resposta, col·lapsa el navegador o omet elements no és un substitut honest.

L’etiqueta canònica és un senyal, no una ordre garantida. Google avalua aquestes declaracions juntament amb redireccions, inclusió al mapa del web i altres senyals, i recomana utilitzar URL absolutes coherents (Google, directrius sobre URL canòniques). Els enllaços interns, la política del mapa del web i les etiquetes canòniques han d’explicar la mateixa història. Una sola etiqueta no arreglarà una arquitectura contradictòria.

rel="next" i rel="prev" tampoc ho solucionen. Segons la seva documentació de paginació, Google ja no els utilitza com a senyals de seqüència. Pots conservar-los per a un altre consumidor o una convenció interna, però Google continua necessitant enllaços rastrejables i URLs coherents per a cada bloc.

Afegeix carregar més sense amagar la seqüència

Un patró de carregar més robust parteix d’una paginació que ja funciona. JavaScript intercepta la petició de l’usuari, recupera el bloc següent i n’afegeix els elements. L’enllaç de base continua apuntant a un URL real.

Un control simplificat podria ser aquest:

<a class="load-more" href="/ca/botiga/?page=3">Carrega més productes</a>

Amb JavaScript, el gestor demana la pàgina tres, afegeix només els resultats previstos, actualitza el destí del control i anuncia el canvi. Sense JavaScript, l’enllaç navega amb normalitat. Googlebot també el pot seguir sense haver d’activar cap botó.

Evita peticions repetides mentre hi ha una càrrega en curs. Gestiona els errors de xarxa sense eliminar l’enllaç i permet tornar-ho a provar. Quan s’acaba la seqüència, retira o desactiva el control amb una explicació precisa. Un botó que deixa de respondre sense dir res perjudica l’experiència i costa de diagnosticar en proves automàtiques.

Decideix què ha de fer el botó Enrere. Si carregar diversos blocs canvia de manera significativa l’estat de navegació, registra’l a l’URL. Si no, com a mínim, tornar des de la fitxa d’un producte ha de restaurar la llista ampliada i una posició útil. No hi ha una única resposta vàlida, però perdre deu minuts de navegació és clarament un error.

El scroll infinit necessita historial real

El scroll infinit pot reutilitzar els mateixos punts d’accés. Observa un sentinella prop del final de la llista, demana el bloc següent, afegeix-lo i mantén els límits de cada bloc al DOM. L’API Intersection Observer pot detectar quan el sentinella entra a la finestra gràfica sense consultar contínuament la disposició al fil principal.

Quan un bloc es converteixi en la secció visible principal, actualitza el navegador amb el seu URL real. La History API ofereix pushState() i replaceState() per afegir o substituir entrades de l’historial de sessió sense una navegació completa (MDN, treballar amb la History API). L’URL passat a aquests mètodes ha de tenir el mateix origen; utilitza les rutes que ja funcionen en peticions directes.

No cridis pushState() per cada moviment mínim de scroll. Ompliries el botó Enrere de passos inútils. Una política raonable és substituir l’entrada actual mentre la persona continua dins del mateix bloc i afegir-ne una de nova només quan travessa un límit significatiu. Prova-ho en navegadors reals, perquè la restauració i els encaminadors de l’aplicació poden interferir entre si.

Gestiona popstate perquè Enrere i Endavant recuperin el bloc representat per l’URL. Si els resultats necessaris ja no són a memòria, torna’ls a demanar o renderitzar. Si encara hi són, restaura el focus o la posició sense repetir totes les peticions de xarxa. Obrir aquell mateix URL en una pestanya nova també ha de funcionar; la History API no substitueix l’encaminament del servidor.

El disparador de càrrega ha de tenir límits. Precarregar poc abans del final pot reduir l’espera, però anticipar moltes pantalles malbarata ample de banda i complica la recuperació d’errors. Respecta les preferències d’estalvi de dades i de moviment reduït si la interfície té animacions. Ofereix una ruta cap al peu de pàgina o atura la càrrega automàtica en un punt raonable i mostra un control explícit per continuar.

L’accessibilitat forma part de l’arquitectura

Afegir contingut canvia l’experiència de lectura i de focus, encara que el focus no es mogui. Una persona que mira la pantalla veu les targetes noves. Qui utilitza un lector de pantalla pot no rebre cap indicació que el recompte de resultats ha canviat.

Utilitza un missatge d’estat per anunciar, per exemple, «S’han carregat 24 productes més», sense obligar a moure-hi el focus. WCAG 2.2 explica que les tecnologies assistives poden rebre els missatges d’estat mitjançant rols o propietats sense que aquests missatges rebin el focus (W3C, missatges d’estat). Els avisos han de ser breus i no se n’han de disparar diversos per una sola càrrega.

No moguis automàticament el focus de teclat quan el scroll infinit afegeixi un bloc. Després d’una acció explícita de carregar més, moure’l al primer element nou pot ajudar algunes persones, però també pot fer-los perdre el context. Prova el comportament amb el control, l’estructura de resultats i els lectors de pantalla compatibles. Com a mínim, preserva un ordre de focus lògic. WCAG exigeix que els components enfocables rebin el focus en un ordre que conservi el significat i l’operabilitat (W3C, ordre del focus).

Per a un flux d’articles o targetes, el patró feed de WAI-ARIA defineix un contenidor amb fills article i descriu la interacció de teclat i les expectatives de càrrega (W3C, rol feed). Fes-lo servir només si la interacció implementada compleix el patró. Afegir role="feed" sense més no repara una llista inaccessible.

També cal una manera fàcil de saltar-se una llista que no para de créixer. Un enllaç de salt a la paginació o al peu evita que qui navega amb teclat hagi de travessar totes les targetes carregades. Conserva els encapçalaments i landmarks després d’afegir contingut, i no dupliquis identificadors d’elements entre blocs.

Errors habituals i què indiquen

La resta del catàleg només existeix darrere d’un botó

L’HTML inicial no conté cap enllaç a la pàgina dos i el botó crida una API amb un cursor opac. Els usuaris amb JavaScript ho veuen tot, però Googlebot no té cap motiu documentat per activar el control. Crea URLs permanents per als blocs i enllaça’ls; després deixa que el botó els millori.

Tots els blocs apunten amb canonical a la primera pàgina

Sovint passa perquè la plantilla ignora el paràmetre de pàgina quan construeix les metadades. Genera el canonical a partir de l’URL resolt i prova la primera pàgina, la segona i l’última. Que l’etiqueta existeixi no significa que sigui correcta.

#page=3 sembla resoldre l’encaminament

Els fragments permeten canviar l’adreça sense fer una petició al servidor, i per això tempten. Google desaconsella utilitzar-los com a URL dels blocs paginats. Fes servir un paràmetre o una ruta, i assegura’t que una petició directa retorna el bloc corresponent.

Un ordre canviant repeteix i perd elements

La paginació per desplaçament sobre dades que canvien ràpidament pot moure registres entre peticions. Utilitza un ordre estable amb un criteri de desempat o una recuperació basada en cursor, però continua exposant URL persistents i rastrejables per als blocs que s’hagin d’indexar. Un flux privat i personalitzat potser no necessita paginació indexable; no imposis controls SEO a contingut que no ha de sortir als cercadors.

Els filtres multipliquen la seqüència sense límit

Cada combinació de color, talla, ordre i pàgina es torna rastrejable. L’espai d’URL pot créixer molt més del que justifica el catàleg. Decideix quines facetes tenen valor de cerca, limita l’enllaçat intern i mantén la paginació coherent amb la política de navegació facetada. Consulta l’article sobre optimització del pressupost de rastreig quan el problema sigui el descobriment a escala i no un sol bloc.

JavaScript canvia l’URL, però les peticions directes fallen

La interfície sembla correcta durant una sessió. En refrescar la pàgina quatre, però, apareix un 404 o es torna a la primera. Això és una aparença d’estat creada al client, no un estat persistent. Cal afegir encaminament al servidor o estàtic per a cada adreça guardada a l’historial.

Els resultats nous arriben en silenci

La càrrega visual funciona, però la tecnologia assistiva no rep cap avís i qui navega amb teclat no pot arribar al peu. Afegeix un missatge d’estat adequat, conserva l’ordre de focus i ofereix navegació explícita al voltant del feed.

Prova el sistema com quatre clients diferents

Comença amb una petició HTTP directa. Demana la pàgina dos sense galetes ni estat de sessió previ. Confirma una resposta correcta, els elements previstos, un canonical autoreferent, la política d’indexació i enllaços rastrejables. Repeteix la prova amb una pàgina profunda i l’última.

Després inspecciona l’HTML renderitzat amb JavaScript desactivat. Si l’objectiu és la millora progressiva, tant el bloc com la navegació han de continuar funcionant. Si l’aplicació requereix JavaScript, la sortida renderitzada al servidor o prèviament encara ha de mostrar el contingut i els destins d’enllaç que esperes que trobin els rastrejadors. La guia sobre problemes de SEO amb JavaScript ofereix un procés de diagnòstic més ampli.

A continuació, utilitza la interfície amb ratolí, teclat i l’historial del navegador. Carrega diversos blocs, obre un element, torna enrere, refresca i comparteix l’URL. Llista, adreça i posició han de coincidir. Limita la xarxa i força un error d’API: l’usuari ha de conservar una via funcional per tornar-ho a provar.

Finalment, prova tecnologies assistives. Revisa l’avís del recompte de resultats, l’ordre de focus, els landmarks, els enllaços de salt i l’estat de final de resultats. Les comprovacions automàtiques poden detectar rols invàlids o IDs duplicats, però no poden valorar si tornar des d’una fitxa de producte resulta coherent.

Aquestes proves han de formar part de les comprovacions de publicació, no quedar en una auditoria puntual:

• cada URL de bloc mostrejat retorna el tall de resultats previst;
• els canonicals són absoluts i autoreferents;
• els enllaços renderitzats connecten tota la seqüència;
• els fragments no són l’única representació de l’estat;
• una petició directa i l’URL creat des de l’historial retornen contingut equivalent;
• un error de càrrega deixa disponible un control per reintentar-ho;
• Enrere i Endavant restauren un estat útil;
• els missatges d’estat i l’ordre de focus superen una revisió manual;
• cap element queda omès o duplicat sistemàticament amb l’ordre definit.

En equips grans, aquestes comprovacions encaixen en l’observabilitat de SEO tècnic dins de CI/CD. Les dades de prova de la plantilla poden detectar una etiqueta canònica o un enllaç perdut abans de publicar; després, els rastrejos programats poden cobrir la seqüència sencera.

Preguntes freqüents

La paginació és millor que el scroll infinit per a SEO?

La paginació és més fàcil de fer rastrejable perquè mostra URL estables i enllaços des del principi. El scroll infinit també pot funcionar si es construeix sobre la mateixa seqüència paginada i rastrejable, actualitza URL reals a mesura que l’usuari avança i no depèn que Googlebot faci clic o scroll. La tria depèn de la tasca de navegació, no d’un avantatge de posicionament.

Totes les pàgines paginades han d’apuntar amb canonical a la primera?

No. Google recomana que cada pàgina de la seqüència tingui el seu propi URL canònic. Fer que la segona pàgina i les posteriors apuntin a la primera pot presentar conjunts de resultats diferents com si fossin duplicats. Una pàgina que ho mostri tot només pot ser canònica si conté realment el mateix contingut i és la versió que es vol indexar.

Google encara utilitza rel=next i rel=prev per a la paginació?

Google ja no utilitza rel="next" i rel="prev" com a senyals de paginació. Aquestes relacions poden continuar sent útils per a altres consumidors, però no substitueixen els enllaços rastrejables, les URL úniques de cada pàgina, unes etiquetes canòniques coherents ni l’enllaçat intern a Google Search.

Google pot rastrejar contingut ocult darrere d’un botó de carregar més?

No hi confiïs. Google documenta que el seu rastrejador no prem botons per carregar contingut addicional. Pots mantenir el botó per als usuaris, però has d’oferir en l’HTML renderitzat enllaços normals cap a totes les URL de la seqüència perquè els rastrejadors la puguin descobrir sencera.

La decisió que cal deixar escrita

Abans de començar el desenvolupament, documenta un contracte: quins estats dels resultats tenen URL persistent, com hi arriben els rastrejadors, quins s’han d’indexar, com es generen els canonicals i què han de restaurar Enrere, Endavant i el refresc. Afegeix al mateix contracte el comportament accessible i l’estat de l’últim bloc.

Quan aquestes decisions són explícites, paginació, carregar més i scroll infinit es converteixen en opcions d’interfície sobre una arquitectura que es pot provar. Si no ho són, un llistat molt polit pot ocultar bona part del contingut i fer perdre la posició a l’usuari al mateix temps.