De eerste keer dat ik programmatische SEO probeerde, bouwde ik in een weekend 400 pagina's en zag ik ze allemaal binnen negentig dagen sterven in de index van Google.
Niet gede-indexeerd vanwege spamvlaggen. Erger. Ze bleven gewoon hangen in het "Gecrawld — momenteel niet geïndexeerd"-bakje, het vagevuur waar Google je vertelt dat je pagina's bestaan, maar het niet waard zijn om aan iemand te tonen. Ik had elke pSEO-tutorial uit 2022 gevolgd die ik kon vinden: schraap een dataset, sluis het door een template, druk op publiceren, wacht op de verkeerstsunami. De verkeerstsunami kwam nooit. Wat wél kwam, was een Search Console-rapport dat las als het logboek van een lijkschouwer.
Dat was in 2023. Sindsdien heb ik het hele systeem vier keer opnieuw opgebouwd. De versie die ik nu draai — degene die écht werkt op twee productiesites en echte kliks binnenhaalt uit echte zoekopdrachten — lijkt in de verste verte niet op die vroege pogingen. Ze draait op precies vier bewegende onderdelen: één onderwerppatroon, één paginatemplate, één Claude Skill en één custom command. De rest is Claude Opus 4.7 of Sonnet 4.6 die het werk doet in parallelle sessies terwijl ik iets anders doe.
De reden waarom het nu werkt en toen niet werkte, is niet mysterieus. Het is dat Claude programmatische SEO, goed uitgevoerd, niet langer "data schrapen en een template invullen" is. Het is template-plus-oordeelsvorming-op-schaal, en die oordeelsvorming is wat het maakt of breekt. Laat me je precies laten zien wat ik bedoel, want er is een specifiek faalscenario waar de meeste tutorials stilletjes overheen stappen — en zodra je het ziet, valt het hele speelboek dat ik je ga laten zien op zijn plek.
Waarom ouderwetse programmatische SEO in 2026 niet meer werkt
Hier is het stuk dat niemand die "bouw 10.000 pagina's in een weekend"-cursussen verkoopt je wil vertellen: Google heeft in maart 2024 een expliciet beleid gepubliceerd over wat zij "scaled content abuse" noemen, en ze verscherpen de handhaving sindsdien stilletjes. De huidige informele ondergrens voor programmatische pagina's die de indexering overleven is ≥30–40% unieke content per pagina, waarbij alles onder de 30% als een hard stopsignaal wordt beschouwd. Dat is geen citaat van een Google-medewerker. Dat is de consensusbenchmark die ik zie bij pSEO-praktijkbeoefenaars die hebben bijgehouden welke van hun pagina's core updates overleven en welke verdampen.
Het oude pSEO-speelboek overtrad dit met opzet. Pak een CSV van 5.000 steden, duw elke stad in een {city}-slot in een template, en klaar. Het resultaat was 5.000 pagina's die voor 95% identiek waren. Googles spamalgoritmes haalden dat in 2019 in. Tegen 2023 werden ze actief onderdrukt. Tegen 2026 worden ze gewoon niet meer geïndexeerd.
De reden waarom dit specifiek uitmaakt voor Claude programmatische SEO is dat een naïeve LLM-aanpak dezelfde fout maakt in een verfijndere vermomming. Als je Claude één keer per pagina prompt met "schrijf een SEO-artikel over {keyword}", krijg je 500 pagina's aannemelijk ogende content terug die hetzelfde structurele skelet, dezelfde openingscadans en dezelfde stockovergangen delen. De kwaliteitsclassificatoren van Google vingerafdrukken dat patroon sneller dan een menselijke lezer.
Wat er in 2026 veranderde — en waardoor ik mijn systeem voor de vierde keer opnieuw bouwde — is dat Claude Skills me eindelijk een manier gaven om echte variatie per pagina af te dwingen terwijl ik het geheel nog steeds vanuit één template laat draaien. Dat is het stuk dat ik je wil laten begrijpen voordat we ook maar één regel code aanraken.
Een Skill, in de huidige Claude Code-implementatie, is een laadbare bundel van instructies, referentiebestanden en subinstructies die op aanvraag wordt geactiveerd. Het is geen prompt. Het is geen project. Het lijkt meer op een agent-beroep. Je kunt hem volproppen met een tone-of-voice-document, een datavalidatiechecklist, een lijst verboden zinnen en een verplichte unieke-hoek-generator die afgaat voordat de template rendert. Elke pagina die de Skill produceert wordt door die unieke-hoek-stap gedwongen, wat betekent dat geen twee pagina's dezelfde hook, dezelfde anekdote of dezelfde structurele flow delen — ook al komen ze allemaal uit dezelfde template en hetzelfde patroon.
Die ene architecturale verschuiving is het verschil tussen pagina's die indexeren en pagina's die sterven. Al het andere in deze gids vloeit daaruit voort.
De vier onderdelen van een werkend Claude programmatische SEO-systeem
Voordat ik je stap voor stap meeneem, hier is het geheel in één alinea zodat je de vorm in je hoofd kunt vasthouden: ik draai één onderwerppatroon dat een herhaalbare zoekwoordstructuur beschrijft, één paginatemplate dat specificeert hoe elke pagina wordt gebouwd, één Claude Skill die het template plus alle oordeelsregels verpakt, en één custom command dat de Skill aanroept met de juiste input. Vervolgens verdeel ik hetzelfde command over 6–10 parallelle Claude Code-sessies via git worktrees, en elke sessie kauwt onafhankelijk door een segment van de zoekwoordlijst heen.
Dat is het. Dat is de hele machine. Elk onderdeel heeft een specifieke taak en geen enkel onderdeel is optioneel.
- Onderwerppatroon — het zoekwoordskelet. Voorbeeld:
best [use case] tools for [audience]of[framework] vs [framework] for [task]. Eén patroon levert 50–500 zoekwoorden op. - Paginatemplate — de contentblauwdruk. Definieert secties, vereiste elementen, plaatsing van de unieke-hoek-hook, datavalidatieregels en de conversietrechter.
- Claude Skill — het template gemaakt tot software. Bundelt het template plus het tone-of-voice-bestand, de lijst met verboden zinnen, de uniciteitsafdwinger per pagina en alle referentiedata (sitemap, productinformatie, case studies).
- Custom command — de trigger. Een slash command als
/pseo-generate "keyword X"dat de Skill laadt, de onderzoeksslag uitvoert en de pagina schrijft. Ik heb de basis van dit soort setup behandeld in mijn Claude Code plugins dagelijkse workflow-uitleg als je de onderliggende mechanica wilt.
Het inzicht dat me drie herbouwen kostte om te internaliseren: de Skill is niet de outputfabriek. De Skill is de kwaliteitspoort. Het template produceert pagina's. De Skill beslist of die pagina's mogen worden uitgerold.
Oké. Laten we het ding bouwen.
Stap 1: Genereer onderwerppatronen die schalen zonder spam te worden
Hier verknoeien de meeste mensen het in de eerste tien minuten. Ze kiezen een patroon dat er schaalbaar uitziet maar geen echte zoekvraag erachter heeft, of ze kiezen er een mét vraag maar die al verzadigd is door Wise, Zapier of TripAdvisor — bedrijven die pSEO op een schaal draaien die jij en ik fysiek niet kunnen matchen. (Wise heeft momenteel volgens hun technische SEO-team 8,5 miljoen valuta-converterpagina's geïndexeerd. Jij gaat Wise niet voorbij produceren.)
Wat ik in plaats daarvan doe: ik open Claude Opus 4.7 in de chatinterface — nog niet Claude Code, gewoon de web-app — en plak een prompt die hem dwingt te denken als een zoekwoordstrateeg in plaats van een schrijver. De prompt ziet er ruwweg zo uit:
My niche: [specific niche — e.g., "Laravel hosting and DevOps"]
My product: [what I'm funneling traffic toward]
My existing traffic cluster: [1-2 sentence summary of what already ranks]
Generate 10 topic patterns that meet ALL these criteria:
1. The pattern contains at least one variable slot [like this]
2. Each filled instance targets a real search query, not invented language
3. The search intent is informational or commercial investigation, not pure transactional
4. The pattern is not already dominated by a site with >1M indexed pages
5. Each instance of the pattern can have a genuinely different answer (this is the uniqueness filter)
For each pattern, give me:
- The raw pattern
- 3 example filled keywords
- Estimated search intent
- Why this pattern isn't saturated
- A one-sentence unique angle that separates my pages from existing content
Criterium 5 is het criterium dat mensen overslaan. Als het patroon population of [city] is, heeft elke instantie een objectief identieke antwoordstructuur, en concurreer je met Wikipedia — dat zowel al verzadigd is én een van de weinige sites waar Google genoeg vertrouwen in heeft om te laten ranken met dunne content. Je gaat verliezen.
Maar een patroon als best Claude Code plugins for [specific workflow] — dat heeft wél echt verschillende antwoorden voor "React development" versus "Laravel testing" versus "data pipelines", omdat de feitelijke tools voor elk anders zijn. Zo ziet "echt verschillend" er in de praktijk uit, en dat is het filter dat bepaalt of je uitrol van 200 pagina's overleeft.
Meestal krijg ik een set van 10 patronen terug. Ik gooi er zes weg. Degene die ik hou zijn degene waarbij ik voel, alleen al door de ingevulde voorbeelden te lezen, dat elke pagina werkelijk andere content zou hebben — niet gewoon een ander zelfstandig naamwoord dat erin wordt verwisseld.
Stap 2: Valideer 20 echte zoekwoorden voordat je het patroon vertrouwt
Zodra ik een patroon heb gekozen, ga ik niet direct pagina's genereren. Ik vraag Claude om 20 ingevulde instanties van het patroon te genereren, en dan neem ik elk van die 20 zoekwoorden mee naar een echte zoekwoordtool. Ik gebruik momenteel een mix van Ahrefs en de gratis volumedata uit Googles eigen Search Console-queryrapporten voor mijn bestaande properties.
Waar ik naar zoek zijn geen high-volume zoekwoorden. Dat is een beginnersfout. Een patroon waarin elke ingevulde instantie 10K+ maandelijkse zoekopdrachten heeft is een patroon dat al tapijtbombardementen krijgt van Wise, Zapier of een dozijn andere programmatische reuzen. Ik zoek het tegenovergestelde: patronen waarbij elk zoekwoord 50–500 maandelijkse zoekopdrachten trekt, waarbij het totaal over 100–300 pagina's significant is, en waarbij de concurrentie per pagina laag genoeg is dat een goed gebouwde pagina écht kan ranken.
Dit is het "bescheiden verkeer per pagina, enorme totale aggregatie"-model dat pSEO in 2026 economisch verdedigbaar maakt. Eén Zapier-stijl integratiepagina trekt misschien 200 zoekopdrachten per maand. Zesduizend daarvan — wat ruwweg is wat Zapier draait — is 1,2 miljoen maandelijkse zoekopdrachten. Je probeert geen homerun te slaan. Je speelt voor singles, op volume.
Als 15 van mijn 20 gevalideerde zoekwoorden echt zoekvolume hebben en een redelijke concurrentiescore, is het patroon levensvatbaar. Als er maar 8 zijn, ga ik terug naar Stap 1 en kies ik een ander patroon. Ik verbrand liever een dag aan patroonvalidatie dan drie weken aan een gedoemde uitrol.
Stap 3: Bouw een paginatemplate dat echte differentiatie afdwingt
Hier zit het vakmanschap. Het template is niet zomaar "H1 → intro → drie H2-secties → CTA". Dat is een layout, geen template. Een echt pSEO-template specificeert vijf dingen per pagina:
Een unieke-hoek-slot. Elke pagina moet openen met een hook die specifiek is voor dit exacte zoekwoord en die op geen enkele broer-of-zuspagina zou kloppen. Voor een "best Claude Code plugins for Laravel testing"-pagina kan de unieke hoek een specifiek Pest PHP-faalscenario zijn dat ik vorige maand tegenkwam. Voor "best Claude Code plugins for React development" is het een compleet ander moment — een kapotte Storybook-build, bijvoorbeeld. Geen van beide hooks is uitwisselbaar. Dat is het punt.
Een eis voor verse data. Elke pagina haalt minstens één datapunt uit een websearch die op generatietijd wordt uitgevoerd. Toolversienummers, recente prijswijzigingen, lanceerdata, huidige rankings. Dit dwingt Claude om WebSearch binnen de Skill te gebruiken en bakt versheid in die een statisch template niet kan faken. Ik dwing al een tijdje "data moet gedateerd zijn binnen de laatste 90 dagen" af als harde regel, en het tilt merkbaar op hoe snel deze pagina's beginnen te ranken.
Een SEO + AIO-blok. Elke pagina richt zich zowel op klassieke SEO (zoekwoord in H1, natuurlijke varianten in H2's, semantische entiteiten overal) als op wat ik nu AIO noem — AI-answer-engine-optimalisatie. Dit betekent dat minstens één passage in elke pagina is geschreven als een standalone, citeerbaar antwoord dat Perplexity of Googles AI Overviews kunnen ophalen zonder de omliggende context nodig te hebben. Claude Sonnet 4.6 is bijzonder goed in het produceren van deze passages omdat het 1M-contextvenster de Skill in staat stelt je volledige citatie-stijl te zien vóór het schrijven.
Een doelgemengde conversietrechter. Elk template bevat een mid-pagina en eind-pagina CTA die contextueel relevant is voor het specifieke pagina-onderwerp. Geen hardgecodeerde "koop mijn cursus". Een "koop mijn cursus" die verwijst naar het exacte probleem dat de pagina oplost. Hier sterft de meeste gestemplede content: de lezer beseft dat de CTA boilerplate is en bouncet. Als de CTA leest alsof hij met de hand is geschreven voor die exacte pagina, houdt de conversie stand.
Een lijst met verboden patronen. Mijn template bevat letterlijk een lijst met zinnen die niet mogen voorkomen. "In today's fast-paced world." "Let's dive in." "Furthermore." "In conclusion." Als Claude er een schrijft, wordt de pagina afgewezen door de interne controle van de Skill en opnieuw gegenereerd. De banlijst is niet decoratief. Het is de grootste enkele factor in de vraag of pagina's lezen als mensgeschreven of als AI-slop.
Ik bouw het template als een markdown-document met becommentarieerde secties die uitleggen waarom elke regel bestaat. Vervolgens test ik het met de hand op drie zoekwoorden uit mijn gevalideerde lijst, waarbij ik de pagina's zelf schrijf met het template als leidraad. Als ik met mijn eigen brein drie werkelijk verschillende pagina's kan produceren uit hetzelfde template, is het template solide. Als mijn drie eigen pagina's repetitief aanvoelen, is het template kapot en moet het worden aangescherpt voordat het ooit in een Skill gaat.
Deze handmatige droogrun is niet-onderhandelbaar. Het overslaan ervan is hoe je eindigt met 200 gepubliceerde pagina's die allemaal hetzelfde klinken en collectief de thematische autoriteit van je site de das omdoen. Ik heb dit op de langzame manier geleerd — twee keer.
Stap 4: Zet het template om in een Claude Skill
Nu maken we van het template software.
Claude Code wordt geleverd met een ingebouwde skill-creator, en dat is de schoonste manier om dit te doen. Ik draai /skill-creator vanuit mijn projectroot, wijs hem naar het template-markdown-bestand, voeg het tone-of-voice-document, de lijst met verboden zinnen en een gecomprimeerd ZIP-bestand met referentiecontent toe (bestaande topperformende pagina's, merkassets, een sitemap-CSV voor interne linking). De skill-creator wikkelt het geheel in één aanroepbare Skill met zijn eigen SKILL.md in de root.
Als je hier koud aan komt, heb ik een stap-voor-stap uitleg van het bouwen van je eerste Claude Skill geschreven die de mechanica in detail behandelt. De korte versie: een Skill is een map, de map heeft een SKILL.md-bestand met een YAML-header die beschrijft wanneer hij moet activeren, en de rest is referentiemateriaal dat Claude laadt wanneer de Skill afgaat.
Drie details doen er meer toe dan de meeste gidsen markeren:
Eén — de activatiebeschrijving moet specifiek zijn. Als je SKILL.md zegt "helpt met SEO-content", zal Claude's skill-selector hem willekeurig aanroepen. Als er staat "genereert programmatische SEO-pagina's voor het patroon [topic], één zoekwoord per keer, met gebruik van het bijgevoegde template en datavalidatieregels" — dan zal Claude hem alleen afvuren wanneer je hem écht nodig hebt. Precisie hier is wat Skills componeerbaar maakt met de rest van je workflow.
Twee — de uniciteitsafdwinger moet binnen de Skill leven, niet in het template. Het template is de blauwdruk. De Skill is de aannemer die het werk controleert. Ik neem expliciete instructies op in SKILL.md zoals: "Voordat je een pagina schrijft, genereer je een unieke-hoek-hook die niet plausibel op een andere pagina zou kunnen verschijnen die op enig broer-of-zuszoekwoord in dit patroon richt. Als je geen werkelijk onderscheidende hook kunt genereren, stop dan en vraag de gebruiker om sturing." Die "stop en vraag"-uitgang is wat voorkomt dat Claude neppe specificiteit hallucineert wanneer het echte materiaal dun is.
Drie — itereer op de Skill met echte output. Eerste run produceert de Skill pagina's die 80% zijn van wat ik wil. Ik lees 10 outputs, noteer precies wat mis is (te formeel, hookpatroon dat zich herhaalt over pagina's, interne links die naar verkeerde URL's gaan), en bewerk de instructies van de Skill. Tweede ronde is hij op 90%. Derde ronde is hij op 95% en klaar om te verschepen. Drie iteratiecycli kosten me meestal één middag.
Automatiseer onder geen enkele omstandigheid het publiceren naar productie voordat de Skill op 95%+ kwaliteit zit. Human-in-the-loop review blijft aan. De goedkoopste manier om het crawlbudget van een site te vernietigen is 100 middelmatige pagina's automatisch publiceren en Google dwingen zijn vertrouwensallocatie te verbranden aan het evalueren van je slop.
Stap 5: Schaal met een custom command en parallelle agents
Hier wordt het leuk.
Ik wikkel de Skill in een custom slash command — /pseo — dat een zoekwoord als argument neemt, de Skill laadt, webonderzoek voor dat specifieke zoekwoord uitvoert, de pagina schrijft, hem opslaat in de content-directory en de output logt. Het command is een kort markdown-bestand in .claude/commands/pseo.md met een prompttemplate dat ruwweg zegt: "Activeer de programmatic-seo Skill. Genereer één pagina voor het zoekwoord dat als argument wordt doorgegeven. Voer vóór het schrijven WebSearch uit voor verse data. Sla de output op in content/pseo/[slug].md. Zelfbeoordeel tegen de kwaliteitschecklist van het template voordat je terugkeert."
Zodra het command werkt in één Claude Code-sessie, is het schalen mechanisch. Ik gebruik git worktrees — hetzelfde patroon dat ik doorliep in mijn Claude Code git worktrees parallelle agents-gids — om 6–10 onafhankelijke werkmappen op te starten, één Claude Code-sessie per worktree, en elke sessie een ander segment van de zoekwoordlijst te voeden.
Elke sessie draait /pseo "keyword-A", dan /pseo "keyword-B", dan /pseo "keyword-C" sequentieel, terwijl de andere sessies hetzelfde doen met hun eigen segmenten. Ik parallelliseer niet binnen een sessie. Ik parallelliseer over sessies, want de echte bottleneck is muurkloktijd op webzoekopdrachten en paginageneratie, niet tokendoorvoer op één Claude-instantie.
Praktische cijfers uit mijn laatste uitrol: tien parallelle sessies, draaiend op Sonnet 4.6 omdat de kosten-per-pagina-rekensom vergevingsgezinder is dan Opus 4.7 voor high-volume generatie, produceerden 120 pagina's in ongeveer vier uur. Opus 4.7 produceert merkbaar betere redenering voor complexe patronen, maar voor standaard pSEO-pagina's merk ik dat Sonnet 4.6 een 95%+ kwaliteitslat haalt tegen ongeveer een derde van de tokenkosten. Het 1M-contextvenster op beide modellen betekent dat elke sessie het volledige template, het volledige tone-of-voice-document, de volledige lijst met verboden zinnen en de volledige sitemap-CSV kan vasthouden zonder tegen contextlimieten aan te lopen.
Merge terug naar main, push, verifieer in Search Console, dien de sitemap in, ga door.
Stap 6: Hang analytics op voordat je één pagina publiceert
Dit is de stap die iedereen overslaat en die stilletjes bepaalt of het hele systeem de moeite waard was.
Voordat ik een Claude programmatische SEO-uitrol publiceer, zorg ik dat drie monitoringoppervlakken al zijn bedraad en kijken:
-
Google Search Console — ik dien de nieuwe sitemap in voordat de batch live gaat, zodat GSC vanaf dag één vertoningen en posities begint bij te houden. Ik maak een custom filter aan in GSC voor URL's die matchen met het slug-voorvoegsel van het patroon, zodat ik in één oogopslag kan zien hoe de uitrol als cohort presteert.
-
Google Analytics 4 — ik tag elke pSEO-pagina met een custom dimensie die hem markeert als
content_type: programmaticen bij welk patroon hij hoort. Hiermee kan ik conversiepercentage, bouncepercentage en tijd-op-pagina alleen voor de pSEO-pagina's opvragen, gescheiden van mijn handgeschreven content. -
Een eenvoudig dashboard — ik draai een wekelijkse query die vertoningenaantal, klikkenaantal, gemiddelde positie en aantal geïndexeerde pagina's voor het patroon ophaalt. Als het aantal geïndexeerde pagina's na vier weken met meer dan 20% achterloopt op het aantal gepubliceerde pagina's, is er iets mis met de pagina's en moet ik een willekeurige steekproef lezen om het patroon te vinden. Als de gemiddelde positie na acht weken boven rang 30 plateau's bereikt, zit de intentiematch van het patroon verkeerd en beëindig ik de uitrol of herbouw het template.
Dat laatste stukje — het kill-criterium — is wat ik op de harde manier moest leren. Niet elk patroon gaat werken. Sommige zullen de intentie misjugeren. Sommige richten zich op een SERP die forum-threads of video boven artikelen verkiest. De discipline is om binnen 8 weken in plaats van 8 maanden een dood patroon op te merken, het te de-indexeren en door te gaan. Programmatische SEO is geen one-shot uitrol. Het is een portefeuille, en je doodt de honden snel.
Wat ik fout deed (en misschien nog steeds fout doe)
Drie eerlijke beperkingen waar ik tegenaan ben gelopen, omdat niemand die pSEO-cursussen verkoopt je deze zal vertellen:
Het uniciteitsprobleem gaat niet volledig weg. Zelfs met een Skill die unieke hoeken per pagina afdwingt, zie ik nog familiegelijkenis over de 120 pagina's in één patroon. Google lijkt dit niet te bestraffen op het niveau waarop ik zit — het indexeringspercentage op mijn huidige uitrol zit rond de 88% na twaalf weken — maar ik vermoed dat er een plafond is dat ik nog niet heb gevonden. Als ik 5.000 pagina's van één patroon zou proberen te draaien, zou ik verwachten dat het indexeringspercentage daalt. Ik heb het lef niet gehad om dat te testen.
Versheid vervalt snel. Een Claude programmatische SEO-pagina die ik vandaag publiceer heeft echte, verse data erin. Zes maanden vanaf nu zal een deel van die data verouderd zijn — toolversies zijn geüpdatet, prijzen zijn verschoven, features zijn uitgerold. Ik heb nog geen schoon geautomatiseerd verversingssysteem. Mijn huidige workaround is om dezelfde Skill elke 90 dagen opnieuw tegen de bestaande slug te draaien en Claude verouderde secties ter plekke te laten herschrijven, maar het is handmatig en moeizaam. Dit is het volgende systeem dat ik ga bouwen.
Sonnet 4.6 hallucineert af en toe interne links. Zelfs met een sitemap-CSV geladen in de Skill zal Sonnet 4.6 soms een URL verzinnen die niet in de CSV bestaat. Ik heb een validatiestap in het command die elke interne link grep-checkt tegen de sitemap voordat de pagina wordt opgeslagen, en als een link de check faalt, wordt de hele pagina opnieuw gegenereerd. Opus 4.7 heeft dit probleem merkbaar minder, wat een van de redenen is dat ik hem ondanks de kosten nog steeds gebruik voor high-stakes pagina's.
Dit is geen "set it and forget it"-systeem. Het is een systeem dat druk wegneemt van het deel van contentproductie dat geen mens zou moeten vereisen — het invullen van templates, de aggregatie van onderzoek, het eerste-versie-proza — en mijn aandacht concentreert op de delen die dat wel doen: patroonselectie, kwaliteitspoorten, kill-beslissingen.
Hoe de cijfers er eigenlijk uitzien
Ik wil hier voorzichtig zijn, want verzonnen metriek vernietigt het vertrouwen dat ik over 3.000 woorden heb opgebouwd. Dus ik geef je bereiken in plaats van neppe precisie.
Over de twee productiesites waar ik dit systeem momenteel draai, trekken de pSEO-pagina's die de eerste twaalf weken van indexering hebben overleefd ergens in het bereik van 3–8 kliks per pagina per maand uit organisch zoekverkeer. Dat klinkt klein totdat je vermenigvuldigt. Een cohort van 120 geïndexeerde pagina's die elk 5 kliks trekken, is 600 organische kliks per maand uit één enkele uitrol — content die me misschien één week kalendertijd en ruwweg het API-budget van een middelgroot Cursor-abonnement heeft gekost om te produceren.
De industriebenchmarks die ik heb gezien uit Backlinko's 2026 programmatische SEO-analyse en Ahrefs' pSEO-case studies suggereren dat verkeer doorgaans 2–4 maanden achterloopt op publicatie voordat het patroon gaat compounden. Mijn waargenomen patroon komt daarmee overeen — bijna niets de eerste 30 dagen, betekenisvolle indexering die rond dag 45 begint, merkbare rankingverbetering tussen maand twee en drie.
Het conversiepercentage op pSEO-pagina's is, in mijn ervaring, lager dan op handgeschreven hoeksteencontent. Dat is verwacht. Deze pagina's vangen intentie op een bredere, ondiepere laag van de trechter. De taak van een pSEO-pagina is niet om op 4% te converteren. De taak is om een gekwalificeerde bezoeker het ecosysteem binnen te halen bij 0,5–1% conversie, op een volume dat handgeschreven content niet kan halen.
Veelgestelde vragen
Wat is Claude programmatische SEO en hoe verschilt het van traditionele pSEO?
Claude programmatische SEO gebruikt Claude Skills, templates en parallelle agents om SEO-pagina's op schaal te genereren met echte variatie per pagina afgedwongen door AI-oordeelsregels. Traditionele pSEO vult templates in vanuit gestructureerde datasets, wat Google nu markeert als scaled content abuse wanneer uniciteit onder de 30% zakt. De Claude-aanpak bakt uniciteitsafdwinging in de generatiestap zelf. Voor de volledige workflow, zie de stapsgewijze doorloop hierboven.
Welk Claude-model is het beste voor programmatische SEO — Opus 4.7 of Sonnet 4.6?
Sonnet 4.6 is de betere standaard voor high-volume Claude programmatische SEO-generatie omdat hij 95%+ van de kwaliteit van Opus 4.7 haalt tegen ongeveer een derde van de tokenkosten, en beide modellen delen hetzelfde 1M-contextvenster. Gebruik Opus 4.7 voor pijlerpagina's en complexe patronen waar redeneerdiepte belangrijker is dan eenheidskosten.
Hoeveel pagina's kan ik genereren met één Claude Skill?
Eén Claude Skill gecombineerd met een gevalideerd onderwerppatroon kan realistisch 50–500 pagina's produceren voordat patroonmoeheid intreedt. Met tien parallelle Claude Code-sessies via git worktrees genereer ik ongeveer 120 pagina's in vier uur. Verder schalen dan 500 pagina's op één patroon verhoogt het risico dat Googles detectie van scaled content abuse gedeeld structureel DNA in het cohort opvangt.
Is programmatische SEO nog veilig na Googles scaled content abuse-beleid?
Ja, wanneer pagina's ≥30–40% werkelijk unieke content behouden, zich richten op echte zoekvraag en duidelijke gebruikersintentie bedienen — Wise, Zapier en TripAdvisor draaien allemaal massale pSEO-operaties die prima ranken. Het beleid richt zich op doorway-pagina's en gestemplede dunne content, niet op legitieme programmatische pagina's met echte waarde per pagina. De Claude Skill-uniciteitsafdwinger die ik hierboven beschreef is specifiek ontworpen om aan de juiste kant van deze lijn te blijven.
Hoe lang voordat programmatische SEO-pagina's beginnen te ranken?
De meeste Claude programmatische SEO-uitrollen laten betekenisvolle indexering zien op 4–6 weken en meetbare rankingverbeteringen tussen maand twee en drie, overeenkomend met bredere pSEO-benchmarks. Als indexering meer dan 20% achterloopt op het aantal gepubliceerde pagina's bij de vier-weken-markering, heeft het patroon of template waarschijnlijk een kwaliteitsprobleem en moet het worden herzien voordat er meer pagina's worden gepubliceerd.
Laten we samenwerken
Op zoek naar het bouwen van AI-systemen, automatiseren van workflows of opschalen van je tech-infrastructuur? Ik help graag.
- Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
