Elke keer dat je paginering zo instelt dat alles terugverwijst naar de eerste pagina, kan het zijn dat AI-systemen je tweede pagina nooit zien. De meeste site-eigenaren stellen dit in zonder te beseffen dat generatieve zoekmachines paginering totaal anders aanpakken dan gewone zoekmachines. De tweede pagina van je productlijst, de tiende pagina van je blogarchief, de derde pagina van je casestudy's: voor ChatGPT of Perplexity bestaan ze misschien helemaal niet.
Dit is belangrijk, omdat paginering twee dingen raakt die AI-zichtbaarheid bepalen: vindbaarheid voor crawlers en de opbouw van je content. Een slecht opgezet pagineringssysteem betekent dat AI hele delen van je assortiment, je artikelen of je autoriteitscontent nooit ziet. Stelt een AI-gebruiker een vraag die je artikel op pagina tien perfect beantwoordt, dan vindt het systeem het nooit, omdat het niet verder kwam dan pagina één.
Wat paginering eigenlijk is (en waarom het uitmaakt voor AI)
De basis
Paginering is het systeem dat een grote verzameling content opdeelt in kleinere, genummerde pagina's. Een productcategorie met 500 items, verdeeld over 50 pagina's van 10 items. Een blogarchief met 20 berichten per pagina. Elke genummerde pagina is een aparte URL: pagina 1 is /products, pagina 2 is /products?page=2, pagina 3 is /products?page=3.
Waarom AI het anders ziet
Voor gewone zoekmachines is paginering al lang opgelost. De crawler van Google volgt links van pagina één naar pagina twee naar pagina drie. Hij herkent het patroon en indexeert elke pagina apart. Voor AI-systemen wordt paginering een zichtbaarheidsprobleem. Verwijst de canonical van elke pagina in je pagineringsstructuur terug naar pagina één, dan ziet AI alleen pagina één. Je content op pagina twee tot tien is feitelijk verborgen.
Hoe AI-systemen gepagineerde content anders crawlen
ChatGPT crawlt helemaal niet
ChatGPT crawlt niet in realtime. Het is getraind op momentopnamen die in de loop van de tijd zijn verzameld. Is de training klaar, dan surft ChatGPT niet meer op het huidige web.
Perplexity en realtime-AI gebruiken gewone zoekmachines
Perplexity, Claude en platforms die beweren realtime toegang te hebben, crawlen niet zoals Googlebot. Ze herformuleren de vragen van gebruikers en sturen ze naar Google en Bing. Daarna halen ze de top 5 tot 10 resultaten op. Scoort je pagina één voor een zoekopdracht maar je pagina vijf niet, dan ziet Perplexity pagina vijf nooit.
Het probleem met de canonical-tag
Veel sites laten de canonical van elke gepagineerde pagina terugverwijzen naar pagina één. Dat vertelt AI-systemen dat alle 50 pagina's als één pagina moeten worden behandeld. Google voegt alles samen in één indexvermelding. AI-systemen volgen Google en zien alleen pagina één. De unieke content op pagina twee tot 50 wordt onzichtbaar.
Waarom oneindig scrollen een groter AI-probleem is
Hoe oneindig scrollen AI-zichtbaarheid breekt
Bij oneindig scrollen wordt nieuwe content geladen terwijl gebruikers naar beneden scrollen. Voor mensen voelt dat naadloos. Voor AI-crawlers is het een zwarte doos. De meeste AI-crawlers voeren geen JavaScript uit. De crawler van ChatGPT ziet alleen de eerste HTML die werd geladen toen de pagina voor het eerst werd opgebouwd. Content die dynamisch laadt als mensen scrollen? Die heeft de crawler nooit gezien.
De crawlers van OpenAI, de bots van Perplexity en de systemen van Claude hebben allemaal deze beperking. Ze halen de HTML op maar wachten niet tot JavaScript is uitgevoerd. Bestaat de hele tweede helft van je producten alleen in JavaScript, dan zien AI-systemen die nooit.
De hybride aanpak
Bouw traditionele gepagineerde URL's, zodat elke pagina als aparte, statische URL bestaat. Leg daarna JavaScript eroverheen voor de gebruikerservaring. Terwijl iemand scrolt, past de browser de URL aan. De AI-crawler kan elke pagina nog steeds apart bereiken, omdat de URL's bestaan en te crawlen zijn.
Het verschil tussen de identiteit van een pagina en de overeenkomst tussen pagina's
Waarom rel="next" en rel="prev" niet meer uitmaken
Oudere adviezen raadden rel="next"- en rel="prev"-tags aan om reeksen pagina's aan te geven. Google bevestigde in 2019 dat het deze tags niet meer gebruikt voor indexering of ranking. De BERT-technologie van Google werd slim genoeg om paginering automatisch te herkennen. Voor AI-systemen doen deze tags er helemaal niet toe.
Hoe AI beslist of pagina's duplicaten zijn
AI-systemen moeten bepalen of een pagina een eigen indexvermelding verdient of moet worden samengevoegd met een andere pagina. Toont pagina één producten 1 tot 10 en pagina twee producten 11 tot 20, dan zijn het verschillende pagina's. Ze hebben unieke content. Ze beantwoorden andere vragen.
Maar kopieer je dezelfde metatitel en dezelfde inleidende tekst en verander je alleen de producten, dan kan AI ze zien als dunne duplicaten. Het kan besluiten dat pagina twee niets toevoegt. Of, als elke pagina een canonical naar pagina één heeft, indexeert AI alleen pagina één.
Hoe je paginering opbouwt zodat AI je content kan vinden
Regel één: onafhankelijk indexeren
Elke gepagineerde pagina moet een eigen URL hebben en onafhankelijk te indexeren zijn. Laat de canonical van pagina twee niet naar pagina één verwijzen. Laat elke pagina op zichzelf staan.
Regel twee: zichtbaar verschil
Verschilt pagina twee van pagina één, maak dat verschil dan zichtbaar in de HTML. Toont pagina twee producten 11 tot 20, maak dat duidelijk. Gebruik unieke metatitels en beschrijvingen voor elke pagina. Voeg schema markup toe die crawlers vertelt op welke pagina ze zijn en welke content erop staat.
Voor wie oneindig scrollen gebruikt
Houd traditionele paginerings-URL's beschikbaar voor crawlers. Leg oneindig scrollen eroverheen voor gebruikers. Terwijl iemand scrolt, gebruik je pushState van JavaScript om de URL aan te passen zonder de hele pagina te laden.
Technische opzet
Maak XML-sitemaps met alle gepagineerde pagina's. Gebruik voor productsites Product-schema en ItemList-schema. Gebruik voor blogs unieke metatitels en beschrijvingen op elke pagina. "Alle artikelen over SEO en content" en "Alle artikelen over technische SEO-audits" vertellen AI dat het verschillende verzamelingen zijn en niet dezelfde pagina die zich herhaalt.
Wanneer pagineren, oneindig scrollen of "meer laden"
Elke aanpak heeft andere afwegingen voor AI-zichtbaarheid en gebruikerservaring. De keuze hangt af van of je voorrang geeft aan vindbaarheid in zoekmachines of aan betrokkenheid van gebruikers. Voor de meeste sites werkt een hybride aanpak het best: bouw te crawlen paginerings-URL's en verbeter de ervaring met JavaScript.
| Aanpak | Hoe het werkt | AI-zichtbaarheid | Gebruikerservaring | Het best voor |
|---|---|---|---|---|
| Paginering | Aparte URL's voor elke pagina (/page=1, /page=2, enzovoort) | Het sterkst. Elke pagina is onafhankelijk te crawlen en te indexeren. | Je moet op "volgende" klikken om meer content te zien. | Zichtbaarheid in zoekmachines. Categorieën in webwinkels, blogarchieven en alle grote verzamelingen content. |
| Oneindig scrollen | Content laadt dynamisch terwijl gebruikers scrollen. Geen nieuwe URL's. | Het zwakst. De meeste AI-crawlers voeren geen JavaScript uit. Content na de eerste lading is onzichtbaar. | Het best. Naadloze ervaring, geen klikken nodig. | Betrokkenheid van gebruikers en tijd op de pagina. Niet aan te raden voor content die voor SEO cruciaal is. |
| Knoppen voor meer laden | Gebruikers klikken op een knop om de volgende reeks te laden. Met JavaScript, maar met aparte handelingen. | Gemiddeld. Kan goed werken als je het combineert met URL-wijzigingen via pushState. | Een goede tussenweg. Duidelijke handeling, maar minder naadloos dan oneindig scrollen. | Hybride aanpak. Betrokkenheid met enige vindbaarheid. |
| Hybride (paginering + JS) | Te crawlen paginerings-URL's bestaan. JavaScript verbetert de ervaring met oneindig scrollen erbovenop. | Het sterkst. URL's zijn te crawlen, maar gebruikers krijgen een naadloze ervaring. | Het beste van twee werelden. Naadloos scrollen voor mensen, gestructureerde pagina's voor crawlers. | Aan te raden voor de meeste sites. Geeft je AI-zichtbaarheid zonder in te leveren op gebruiksgemak. |
| Paginering met rel="next"/rel="prev" | Traditionele tags die reeksen pagina's aangeven. | Zwak voor AI. Google negeert deze tags sinds 2019. Andere zoekmachines gebruiken ze mogelijk nog. | Hetzelfde als gewone paginering. | Verouderde aanpak. Niet meer aan te raden. |
| Optie alles tonen | Eén pagina toont alle content zonder paginering. | Het sterkst als het goed is uitgevoerd. Alle content op één URL. | Slecht. De pagina laadt te traag. Overweldigend voor gebruikers. | Alleen voor kleine verzamelingen content (minder dan 50 items). Niet praktisch voor grote assortimenten. |
Paginering en AI-optimalisatie per pagina
Zie elke pagina als aparte bron voor citaten
Zie paginering niet als noodzakelijk kwaad, maar als kans om te optimaliseren. Elke gepagineerde pagina kan een deel van de zoekintentie bedienen. Pagina één richt zich op breed ontdekken. Pagina twee op nicheproducten. Pagina drie op specifieke functies.
Elke pagina wordt een eigen bron die geciteerd kan worden. Stelt een AI-gebruiker een vraag over een specifieke groep producten, dan kan AI de exacte pagina citeren waar die informatie staat.
Optimaliseer elke pagina afzonderlijk
Gebruik unieke metatitels en beschrijvingen die de specifieke content van die pagina weergeven. Voeg een H1 toe die lezers vertelt waar ze naar kijken. "Computermonitoren: 4K en hoger" vertelt AI dat deze pagina specifiek over monitoren met hoge resolutie gaat, niet over alle monitoren in de categorie.
Canonical-tags en paginering
De fout van te veel canonicals
Veel site-eigenaren laten de canonical-tag van elke gepagineerde pagina naar pagina één verwijzen. Dat vertelt AI-systemen alle 50 pagina's als één pagina te behandelen. Deze aanpak werkt averechts voor AI-zichtbaarheid. Verwijst elke pagina met een canonical naar pagina één, dan indexeren AI-systemen alleen pagina één.
De betere aanpak
Gebruik canonicals die naar de pagina zelf verwijzen. De canonical van pagina twee wijst naar pagina twee. De canonical van pagina vijf wijst naar pagina vijf. Dat vertelt zoekmachines "deze pagina is de gezaghebbende versie van zichzelf", en niet "behandel mij als pagina één".
Wanneer je samenvoegt
Heb je URL-varianten met parameters die dubbele paginering veroorzaken (page=1 tegenover page=2 tegenover page=2&sort=date), voeg die dan samen onder één canonical. Maar laat een hele reeks pagineringspagina's niet inklappen tot pagina één.
Veelgestelde vragen
[wemasy-accordion type="primary" wemasy-accordion title="Gebruikt Google rel=\"next\" en rel=\"prev\" nog voor paginering?"]<p>Google bevestigde in 2019 dat het deze tags niet meer gebruikt voor indexering of ranking. Andere zoekmachines zoals Bing vinden ze nog wel nuttig. Voor AI-zichtbaarheid doen deze tags er niet toe.</p>
[/wemasy-accordion]
Straft Google me af als ik alle pagina's een canonical naar pagina één geef?
Google straft je niet af. Maar je verliest indexering per pagina. Heeft pagina vijf unieke content, dan wil je dat die apart wordt geïndexeerd voor specifieke zoekopdrachten. Te veel canonicals schaadt de zichtbaarheid in alle soorten zoekmachines. Met de websitebouwer van WEMASY stel je dit rechtstreeks in op je website.
Moet ik oneindig scrollen of paginering gebruiken?
Voor zichtbaarheid in zoekmachines is gewone paginering sterker. Voor gebruikerservaring werkt oneindig scrollen goed. De beste aanpak is hybride: houd paginerings-URL's te crawlen en gebruik JavaScript om de ervaring te verbeteren.
Hoeveel items moet ik per pagina tonen?
Er is geen magisch getal. Productcategorieën tonen vaak 12 tot 50 items per pagina. Blogarchieven tonen 10 tot 20 berichten per pagina. Zoek een balans tussen laadsnelheid en te veel pagineringspagina's. Voor AI telt dat elke pagina onafhankelijk te crawlen is en aparte content heeft.
Moet ik gepagineerde pagina's indienen bij Google Search Console?
Neem alle gepagineerde pagina's op in je XML-sitemap. Google ontdekt ze via crawlen, maar de sitemap helpt ervoor te zorgen dat niets wordt gemist. Voor AI-zichtbaarheid wil je dat elke gepagineerde pagina te crawlen is.
Maakt paginasnelheid uit voor gepagineerde pagina's?
Ja. Trage gepagineerde pagina's laden traag voor zowel bezoekers als crawlers. Duurt het laden van pagina twee 8 seconden, dan kunnen crawlers time-outen. Optimaliseer de paginasnelheid van elke gepagineerde pagina, vooral van de eerste pagina's die crawlers bezoeken.