Pagination en SEO: canonical, noindex of load more?

Pagination en SEO: canonical, noindex of load more?

Google heeft rel="next" en rel="prev" al in 2019 officieel afgeschaft. Toch zien wij in 2026 nog wekelijks webshops die deze tags blind in hun head plaatsen. Ze doen niets. Erger: ze geven een vals gevoel van controle terwijl de echte paginerings-problemen onaangeroerd blijven.

Paginering is een van de meest verkeerd begrepen onderwerpen in technische SEO. De meeste adviezen op internet zijn verouderd of ronduit fout. Deze gids legt uit wat in 2026 wél werkt, met een concrete aanbeveling per situatie.

Waarom paginering überhaupt een SEO-probleem is

Een categoriepagina met 240 producten verdeel je niet over één URL. Je splitst ze in pagina's: ?p=1, ?p=2, ?p=3. Logisch voor de gebruiker. Een probleem voor crawlers.

Drie dingen gaan namelijk mis:

• Crawl budget verdamt. Google crawlt pagina 2 tot en met 12 van elke categorie. Bij 80 categorieën zijn dat honderden URL's met weinig unieke waarde.
• Duplicate content. Titels, meta descriptions en filterteksten zijn op elke paginavariant identiek. Alleen de productgrid verschilt.
• Link equity versnippert. Interne en externe links die naar pagina 3 wijzen, voeden niet de pagina die je wél wilt laten ranken: pagina 1.

Het doel is dus simpel. Je wilt dat Google de producten op de diepere pagina's ontdekt, maar niet dat die paginavarianten zelf gaan concurreren in de zoekresultaten.

rel next/prev is dood (echt waar)

Laten we hier geen misverstand over laten bestaan. Google gebruikt rel="next" en rel="prev" niet meer voor indexering. John Mueller bevestigde dit. Bing geeft aan de signalen nog "licht" mee te wegen, maar bouwt er geen strategie omheen.

Wat betekent dit praktisch?

• De tags schaden niet. Ze helpen alleen niet voor Google.
• Voor accessibility (schermlezers, browser-prefetch) hebben ze nog wel beperkte waarde.
• Bouw je SEO-strategie er nooit omheen.

Als een bureau je in 2026 nog vertelt dat rel="next"/"prev" je paginerings-probleem oplost, weet je genoeg. Wij komen dit nog tegen bij oude Magento-installaties waar de tags standaard meekwamen.

Optie 1: self-referencing canonical per pagina

De huidige aanbeveling van Google zelf. Elke paginavariant krijgt een canonical naar zichzelf.

<!-- op ?p=2 -->
<link rel="canonical" href="https://shop.nl/schoenen?p=2" />

De gedachte: elke pagina is uniek genoeg (andere producten) om als zelfstandige URL te bestaan. Google indexeert ze, maar geeft pagina 1 doorgaans voorrang omdat die de meeste interne links krijgt.

Wat je nooit moet doen: een canonical van pagina 2+ naar pagina 1 laten wijzen. Google ziet pagina 2 dan als duplicaat van pagina 1 en negeert vaak de canonical, omdat de inhoud aantoonbaar verschilt. Je verliest de garantie dat producten op pagina 2+ worden gevonden.

Optie 2: view-all met canonical

Heb je een categorie met 60 tot 120 producten? Dan is een "view-all"-pagina vaak de schoonste oplossing.

Je maakt één URL die alle producten toont. Elke paginavariant krijgt een canonical naar die view-all-pagina.

<!-- op ?p=2 -->
<link rel="canonical" href="https://shop.nl/schoenen?view=all" />

Google consolideert dan alle signalen op één sterke URL. Geen index bloat, geen versnippering.

Optie 3: load more / infinite scroll en crawlbaarheid

Hier gaat het in de praktijk het vaakst mis. Infinite scroll oogt modern, maar verbergt content voor crawlers als je het verkeerd bouwt.

Het probleem: Googlebot scrollt niet. Klikt niet op "laad meer". Als producten pas via JavaScript verschijnen na een gebruikersactie, ziet Google ze nooit.

De oplossing is altijd dezelfde regel: elke product moet bereikbaar zijn via een echte, crawlbare URL.

Doe het zo:

• Implementeer load more bovenop echte gepagineerde URL's (?p=2, ?p=3).
• Gebruik de History API zodat de URL meeverandert tijdens het scrollen.
• Zorg dat directe toegang tot ?p=3 server-side de juiste producten rendert (SSR).
• Plaats -links naar volgende pagina's in de HTML, ook als JavaScript ze "vervangt".

Voor onze Shopify Plus en Magento 2 projecten bouwen wij infinite scroll standaard als progressive enhancement bovenop crawlbare paginering. De gebruiker krijgt soepel scrollen, Google krijgt platte URL's. Beide blij.

Optie 4: noindex op pagina 2+

Een veelgehoord advies: zet noindex, follow op alle paginavarianten vanaf pagina 2. Dan houd je alleen pagina 1 in de index.

Dit klinkt netjes, maar er zit een addertje onder.

Google behandelt een langdurige noindex op een URL na verloop van tijd als nofollow. De links op die pagina worden dan niet meer gevolgd. Producten die alleen op pagina 4 staan? Onvindbaar.

<!-- riskant op ?p=2 en dieper -->
<meta name="robots" content="noindex, follow" />

Daarom geldt: noindex op paginering werkt alleen als je producten óók via een andere route crawlbaar zijn. Bijvoorbeeld via een complete XML-sitemap met alle product-URL's, of via interne links vanaf andere pagina's.

Heb je die alternatieve route niet? Dan snijd je jezelf in de vingers. Producten verdwijnen uit de index zonder dat je het doorhebt.

Concrete aanbeveling per situatie

Geen one-size-fits-all. Maar wel een helder beslismodel.

Onze standaardkeuze voor de meeste webshops in 2026:

1. Self-referencing canonical op elke paginavariant. Simpel, robuust, Google-conform.
2. Complete XML-sitemap met alle product-URL's als vangnet voor crawlbaarheid.
3. Load more met History API bovenop die URL's voor de UX.
4. Optimaliseer pagina 1 voor de zoekterm. Daar gaat je interne linking heen.

Voeg je daar noindex aan toe? Alleen als Search Console aantoont dat index bloat je daadwerkelijk crawl budget kost. Niet preventief. Niet "voor de zekerheid".

Wat je moet meten

Beslis niet op gevoel. Meet.

• Search Console > Pagina's: hoeveel paginavarianten zitten er in de index? Hoeveel daarvan krijgen klikken?
• Crawl-statistieken: hoeveel van je crawl budget gaat naar ?p=-URL's?
• Log files: welke pagina's bezoekt Googlebot daadwerkelijk en hoe vaak?

Pas als de cijfers een probleem laten zien, grijp je in. Veel webshops "optimaliseren" paginering die helemaal geen probleem vormt en breken daarbij hun crawlbaarheid.

Twijfel je over je eigen paginerings-setup? Neem contact op en we kijken samen naar je crawl-statistieken en index. Geen verkooppraatje, wel een eerlijke diagnose.

Veelgestelde vragen

Moet ik rel next/prev nog gebruiken in 2026?

Niet voor Google. Die negeert de tags sinds 2019. Ze schaden niet en hebben beperkte waarde voor accessibility en browser-prefetch, maar bouw er nooit je SEO-strategie omheen. Verwijder ze als ze je in de waan houden dat je probleem is opgelost.

Mag ik een canonical van pagina 2 naar pagina 1 zetten?

Nee. Pagina 2 toont andere producten dan pagina 1 en is dus geen duplicaat. Google negeert zo'n canonical doorgaans en je verliest de garantie dat producten op diepere pagina's worden gevonden. Gebruik een self-referencing canonical of een view-all-canonical.

Is infinite scroll slecht voor SEO?

Niet inherent. Het wordt slecht als producten alleen via JavaScript laden zonder crawlbare URL's. Bouw infinite scroll altijd bovenop echte gepagineerde URL's met de History API. Dan ziet de gebruiker soepel scrollen en ziet Google platte, indexeerbare links.

Wat is beter: noindex op pagina 2+ of self-referencing canonical?

Voor de meeste webshops is self-referencing canonical veiliger. Noindex riskeert dat Google de links op die pagina's na verloop van tijd niet meer volgt, waardoor diepere producten onvindbaar worden. Gebruik noindex alleen met een complete XML-sitemap als vangnet en alleen bij aantoonbare index bloat.

Hoe weet ik of paginering mijn crawl budget kost?

Kijk in Search Console naar de crawl-statistieken en in je server log files. Zie je dat een groot deel van Googlebots bezoeken naar ?p=-URL's gaat die nauwelijks klikken opleveren, dan heb je een probleem. Zo niet, laat je setup met rust en optimaliseer iets dat wel rendeert.