Pagination SEO Dopo rel=next/prev: L'Honest Playbook

Cercate “pagination SEO” e la prima pagina è un museo. Le guide aggiornate solo tre mesi fa vi camminano ancora attraverso rel="next" e rel="prev" — markup che Google ha ammesso nel marzo 2019 di non aver usato come segnale di indicizzazione “da molti anni.” Il primo risultato organico per la query è la stessa documentazione di Google, sopra siede un AI Overview, e il consiglio sottostante ancora si muove cautamente su un tag che è morto più a lungo di molti dei siti che lo leggono. Ciò che nessuno risponde è la domanda che la persona che cerca effettivamente ha: senza il scorciatoia markup, cosa faccio effettivamente con la pagina 2 attraverso la pagina 40?

Questa guida risponde a quella domanda nel modo onesto: la paginazione ha smesso di essere un problema di markup e è diventata un problema di architettura. Scegliete deliberatamente uno di tre pattern — serie paginata, scroll infinito, visualizza-tutto — e lo implementate in modo che i crawler possano raggiungere ogni elemento senza annegare negli URL quasi-duplicati, e poi fate la parte che ogni altra guida salta: verificate nella Search Console che l’indicizzazione sia effettivamente migliorata. Questo è uno spoke del nostro pilastro agentic SEO, e si appoggia sulla stessa find → fix → verify disciplina come la guida sorella su l’audit tecnico SEO repo-first — la paginazione è solo lo strato di quell’audit dove il folklore è invecchiato peggio.

Il tag che tutti ancora raccomandano è morto nel 2019

La storia è importante perché spiega perché il consiglio là fuori è così confuso. Per anni, rel="next"/rel="prev" era la risposta ufficiale: annotate la serie, e Google avrebbe trattato l’insieme paginato come una sequenza approssimativa, consolidando i segnali verso la prima pagina. Poi nel marzo 2019, l’account di Google Search Central ha annunciato — retroattivamente — che l’annotazione non era stata utilizzata nell’indicizzazione per anni. Non “stiamo deprecandola.” Era già sparita, e nessuno al di fuori di Google se ne era accorto, perché il web ha continuato a funzionare.

Quell’evento non-evento porta la vera lezione. La paginazione non ha mai funzionato a causa del markup; ha funzionato quando l’architettura sottostante era corretta — URL unici, link reali, canonical sensati — e si è rotta quando non lo era, tag o no. Il ritiro non ha cambiato ciò che Google ricompensa. Ha rimosso la comoda illusione che un elemento <link> nell’head potesse coprire un’architettura che intrappolava i crawler o allagava l’indice con varianti sottili. Non c’è scorciatoia per reinstallare. C’è solo l’architettura.

Google ha ritirato rel=next/prev anni prima di dirlo a chiunque, e i ranking non si sono mossi. Il markup non stava mai portando il peso. L’architettura lo stava — e lo sta ancora.

Cosa Google effettivamente chiede ora

La documentazione sulla paginazione attuale di Google — la pagina che supera ogni blog SEO su questa query — è breve e inequivocabile, e la maggior parte contraddice il folklore che è sopravvissuto al 2019. Ogni pagina in una serie è trattata come una pagina separata, fine storia. Da quel fatto, le regole seguono: ogni pagina ha bisogno del suo URL crawlabile, le pagine dovrebbero collegarsi l’una all’altra sequenzialmente in modo che un crawler possa camminare la serie, e — la regola che la maggior parte dei siti ottiene al contrario — pagina 2 e oltre non dovrebbe canonicalize a pagina 1. Google esplicitamente lo sconsiglia, perché un canonical che punta a pagina 1 dice al crawler che le pagine più profonde sono duplicati, e gli elementi elencati solo su quelle pagine possono tranquillamente perdere il loro percorso di crawl.

Notate la forma dei fallimenti nella colonna di sinistra: ogni uno di essi tenta di farscomparire la paginazione — nascondere le pagine profonde, comprimerle nella pagina 1, bloccarle. La guidance documentata va dall’altra parte: rendere la serie leggibile. URL reali, link reali, un indirizzo onesto per pagina. Noioso, e corretto.

Tre pattern, una scelta deliberata

Ogni superficie di elenco — archivio blog, pagina di categoria, risultati di ricerca, griglia di prodotti — è uno di tre pattern. L’errore non è scegliere quello sbagliato; è ereditarne uno da un tema o libreria di componenti e non controllare mai cosa fa ai crawler.

Serie paginata — il noioso default che funziona

Pagine numerate, URL unici, link sequenziali. Questo è il pattern intorno al quale la documentazione di Google è scritta, e quello da scegliere per default quando siete incerti. La barra di implementazione è bassa ma specifica: ?page=2 o /page/2 come URL reso realmente dal server, un canonical auto-referenziante su ogni pagina, link next/previous nell’HTML (non iniettati al click), e la pagina 1 che vive all’URL pulito — con ?page=1 canonicalized o reindirizzato ad esso in modo che la root non competa con il suo duplicato. I titoli dovrebbero disambiguare (“Pagina 3 di …”), che non costa nulla e ferma le pagine paginatte cannibalizzarsi l’una l’altra per il termine principale.

Scroll infinito — invisibile senza URL reali

Googlebot non scrolla, e non clicca “carica altri.” Il contenuto che esiste solo dopo che un evento di scroll si attiva è contenuto che non esiste, per quanto riguarda il crawling. La correzione documentata di Google è il caricamento paginato: quando l’utente scrolla, aggiornate l’URL con l’History API in modo che ogni segmento di contenuto abbia un indirizzo (?page=4), e rendete gli stessi indirizzi raggiungibili come link semplici per i client che non eseguono il vostro gestore di scroll — che include il crawler. Se il vostro scroll infinito non può essere camminato pagina-per-pagina con JavaScript disabilitato, tutto al di sotto della prima vista è decorazione. Su un sito che abbiamo controllato, un redesign di categoria ha scambiato le pagine numerate per un pulsante load-more; nient’altro è cambiato, e gli elementi più in profondità nel catalogo gradualmente sono caduti fuori dall’indice — non penalizzati, solo irraggiungibili.

Visualizza-tutto — fantastico finché non lo è

Una pagina, ogni elemento, nessuna serie da gestire. Per set piccoli questa è genuinamente la risposta più pulita: nessun rischio di duplicazione, nessun problema di profondità di crawl, un URL che accumula tutti i segnali. La modalità di fallimento è la fisica. Una pagina visualizza-tutto con duemila prodotti è lenta per gli utenti e pesante per il rendering, e Core Web Vitals lo dirà. La regola onesta: visualizza-tutto quando l’intero set rende velocemente abbastanza che sareste felici di atterrare su di esso da un risultato di ricerca voi stessi; una serie paginata nel momento in cui non lo fa. Se eseguite entrambi, scegliete uno come superficie canonicale e siate coerenti su quale uno i link interni puntano — eseguire due route parallele agli stessi elementi è come dare a Google un puzzle di duplicazione che risolverà senza consultarvi.

Le due modalità di fallimento: duplicati sottili e trappole di crawl

Ogni bug di paginazione che importa si traduce come uno di due problemi. Il primo è laduplicazione sottile: gli stessi elementi raggiungibili a molti indirizzi. Varianti ordinate (?page=2&sort=price), varianti filtrate, il duplicato ?page=1 della root, parametri di sessione che cavalcano su ogni link di pagina. Ogni variante è una pagina che Google deve recuperare, renderizzare e deduplicare — e quando sceglie canonical in scala, a volte sceglie il vostro male. La correzione è sottrazione: canonicalize le varianti di ordinamento e filtro all’ordine predefinito, mantenete i parametri fuori dai link di paginazione, e lasciate esattamente un indirizzo per pagina della serie.

Il secondo è la trappola di crawl: paginazione moltiplicata per navigazione sfaccettata. Venti filtri per cinquanta pagine per quattro ordini di ordinamento sono quattromila URL per una categoria — uno spazio in cui un crawler può vagare per settimane senza scoprire un singolo nuovo elemento. Questo è il pattern dietro la maggior parte dei cumuli di “Scoperto — attualmente non indicizzato” su siti grandi: non un giudizio di qualità, solo un crawler con pazienza finita che incontra uno spazio di URL senza fondo. Le pagine profonde della vostra serie onesta poi competono per l’attenzione di crawl con migliaia di permutazioni di rifiuti, e perdono.

La checklist di paginazione repo-first

Come con l’audit più ampio di tecnico, il modo più veloce per controllare la paginazione non è un esportazione di crawl — è leggere la sorgente. La logica di paginazione vive in una manciata di file: la route che accetta il parametro di pagina, la funzione di metadati che emette il canonical, il componente che renderizza i link di pagina. Un bug lì è un bug su ogni pagina che il template rende, e potete saperlo da una lettura di file. Il crawl rimane il fallback per i siti che non potete leggere, e il check che ciò che il codice intende è ciò che il server serve.

Verificare che l’indicizzazione sia effettivamente migliorata

Qui c’è la metà che nessuna guida di paginazione spedisce. I fix di paginazione sono insolitamente facili da dichiarare fatto — il codice merge, il canonical sembra giusto in view-source — e insolitamente difficili da controllare, perché il payoff è distributivo: gli elementi che erano irraggiungibili iniziano a guadagnare impressioni, settimane dopo, attraverso centinaia di query di long-tail che nessuno sta guardando. Se non vi impegnate per una metrica prima che il fix esca, non saprete mai se ha funzionato, e “fatto” starà per sempre non esaminato.

La disciplina è lo stesso contratto di prova che corre attraverso il nostro metodo closed-loop. Prima del fix: registrate il finding come un task, nominate la metrica che lo giudicherà — per la paginazione è quasi sempre impressioni sugli URL interessati, perché la raggiungibilità si presenta come essere mostrato affatto prima di presentarsi come click — e impostate un target. Spedite con un timestamp e il PR. Poi aspettate circa tre settimane: Google deve ricrawlare la serie, riscoprire gli elementi, e accumulare dati di query sufficienti da entrambi i lati del cambio affinché un confronto significhi qualcosa. Rileggete la metrica, filtrata agli URL di elemento di pagina profonda, e scrivete il verdetto: confermato, regredito, o inconcludente. I conteggi di indicizzazione di pagina nella Search Console danno una lettura di supporto — “Scoperto — attualmente non indicizzato” che drena è quello che un crawl trap sciolto sembra — ma le impressioni sulle pagine che avete liberato sono il numero che prova che gli elementi non sono solo indicizzati ma mostrati.

Eseguilo in questo modo e la paginazione smette di essere un dibattito di folklore e diventa una voce nella storia misurata del vostro sito: su questo sito, sciogliere la trappola di crawl sfaccettata confermato; il consolidamento ?page=1 ha letto inconcludente. Quali numeri possono portare quel tipo di peso — e quali sono vanità — è il soggetto della guida sorella su KPI SEO.

Paginazione in una pagina di risultati zero-click

Un motivo in più per preoccuparsi nel 2026: la query che questo articolo bersaglia — 260 ricerche al mese, difficoltà modesta — già porta un AI Overview, e così fa una quota crescente delle query di long-tail che gli elementi del vostro catalogo profondo rispondono. Le risposte AI sono assemblate da pagine che i motori potrebbero crawlare, indicizzare e classificare con sicurezza. Un elemento incatenato dietro un evento di scroll o orfano da un canonical-a-pagina-1 non è solo unranked — è incitabile, in ogni motore di risposta alla volta. Il lavoro unglamorous di crawl-path in questa checklist è la tassa di ingresso per il territorio coperto nella nostra guida per SEO zero-click: non potete essere citati da una pagina che nessun motore ha mai raggiunto.

Se volete che la metà di find corra contro la vostra proprietà, il report SEO gratuito collega la vostra Search Console e visualizza dove la raggiungibilità vi costa — le sezioni che guadagnano impressioni sulla pagina 1 di una serie e silenzio sotto. E se preferite che l’intero loop corra come un sistema — finding archiviati, correzioni spedite, verdetti di indicizzazione letti tre settimane dopo — prenotate una chiamata.