Een praktische case study over de Google spam update van 2026, pSEO risico’s, boilerplate content, structured data en wat wij concreet veranderden om schaalbare content menselijker te maken.

Op 5 mei 2026 crawlden we onze eigen site opnieuw: 1.316 pagina’s, 1.270 URLs in de sitemap, 100% sitemapdekking en een score van 94/100 in onze interne SEO crawler. Op papier was dat netjes. Toch zat de interessantste les niet in de score. De crawler vond precies de dingen waar Google sinds de spam updates scherper op lijkt te letten: ontbrekende static params, weinig unieke tekst op toolpagina’s, te veel template-overlap en pagina’s die technisch bestaan maar redactioneel nog niet sterk genoeg zijn.
Deze post is geen generieke lijst met SEO tips. Dit is een verslag van wat wij zelf veranderden op een Next.js site met ruim 1.300 gecrawlde URLs, inclusief pSEO pagina’s, blogposts, tools, vergelijkingstabellen en landingspagina’s. De context is belangrijk: Google’s spam policies richten zich expliciet op scaled content abuse. Niet op AI op zichzelf. Niet op pSEO op zichzelf. Wel op content die op schaal is gemaakt om te ranken zonder voldoende eigen waarde. Dat verschil bepaalt of je pSEO een asset is of een risico.
"Google beoordeelt AI-content niet automatisch als spam. De spamvraag is of content op schaal is gemaakt om zoekresultaten te manipuleren en weinig waarde toevoegt."
— Samenvatting van Google Search Central spam policies, geraadpleegd in mei 2026
Google schrijft in zijn spam policies dat scaled content abuse gaat om content die op grote schaal wordt gemaakt met als primair doel zoekresultaten te manipuleren. De productiemethode maakt minder uit dan de intentie en kwaliteit. AI kan onderdeel zijn van een goed redactieproces, maar een generator die honderd bijna-identieke pagina’s uitspuugt met alleen een plaatsnaam of toolnaam vervangen, valt precies in het risicogebied.
Voor bedrijven met programmatic SEO is dat ongemakkelijk, want pSEO werkt juist met herhaalbare structuren. Een vergelijkingpagina, locatiepagina of templatepagina heeft nu eenmaal vaste onderdelen. De vraag is niet of een template mag bestaan. De vraag is of de pagina bovenop die template genoeg originele, nuttige context toevoegt. Een pagina over software laten maken in Haarlem moet niet dezelfde tekst zijn als software laten maken in Breda met de plaatsnaam vervangen. Er moet een reden zijn waarom die pagina apart bestaat.
De scherpste technische finding was geen tekstprobleem. Onze crawler meldde dat het dynamische Next.js segment `[locale]` geen `generateStaticParams` had op layout-niveau. Daardoor konden tientallen locale-routes on-demand renderen in plaats van volledig pre-rendered HTML te leveren. Voor gewone gebruikers lijkt dat vaak prima. Voor crawlers, AI-indexers en snelle snapshot-tools is het minder robuust.
De fix was klein maar belangrijk: `generateStaticParams()` toevoegen aan `src/app/[locale]/layout.tsx` met de ondersteunde locales (`nl` en `en`). Daarmee dekken we alle descendant routes af, van `/blog` tot `/calculator` en `/tech-stack`. Dit is precies het soort SEO-probleem dat traditionele audits vaak missen. De pagina geeft een 200, de title staat goed, de sitemap klopt, maar de renderingstrategie ondermijnt de kwaliteit van wat crawlers ontvangen.
Voor klanten met Next.js, App Router en internationale routes controleren we dit inmiddels standaard. Als je pSEO of content hubs bouwt, wil je niet afhankelijk zijn van request-time rendering tenzij daar een bewuste reden voor is. Pre-rendering geeft crawlers sneller, stabieler en vollediger HTML. Dat is niet alleen SEO. Het is ook betrouwbaarheid.
De crawler vond vier pagina’s waar boilerplate te dominant was, waaronder de blog index en een Engelstalige alternatievenhub. De top gedeelde frases kwamen uit terugkerende blokken: klantprojecten, blog updates, navigatieachtige tekst en gedeelde secties die op veel pagina’s terugkomen. Geen ramp, maar wel een signaal. Wanneer de eerste alinea’s van een pagina vooral uit herbruikbare blokken bestaan, lijkt de pagina minder eigen.
Onze aanpak was niet om elk gedeeld component te verwijderen. Dat zou UX verslechteren. We hebben juist unieke intro’s en antwoordsecties boven of binnen de belangrijkste content geplaatst. Toolpagina’s kregen concrete uitleg over hoe het gereedschap werkt, wanneer je het gebruikt en waar de grenzen liggen. De vergelijkingmatrix kreeg extra secties over categorieën, scoring en updatefrequentie. De calculator kreeg een uitleg over prijsopbouw en nauwkeurigheid.
Dat is de belangrijkste pSEO-les: boilerplate is niet verboden, maar het mag de pagina niet dragen. De template moet de structuur leveren. De unieke content moet het antwoord leveren. Als je dat omdraait, maak je een schaalbaar spamrisico.
Drie routes misten JSON-LD: tech-stack, vacatures en de vergelijkingmatrix. Dat klinkt klein naast 1.300 pagina’s, maar het patroon is belangrijk. Structured data vertelt zoekmachines wat de primaire entiteit van de pagina is. Een toolpagina is niet zomaar een webpagina. Een vacaturepagina heeft een ander doel dan een blogpost. Een matrix is een interactieve utility met eigen context.
We voegden `WebPage` schema toe via dezelfde schema factory die de rest van de site gebruikt. Niet omdat JSON-LD op zichzelf rankings garandeert, maar omdat het consistentie geeft. Wanneer je een grote site bouwt, moet metadata niet per pagina geïmproviseerd worden. Het moet uit dezelfde bron komen als canonicals, hreflang en sitemaplogica. Anders krijg je langzaam drift: de ene pagina heeft correcte schema, de andere niet; de ene gebruikt de juiste locale URL, de andere wijst naar de verkeerde variant.
Voor maatwerk softwareprojecten is dit precies waar technische SEO en engineering elkaar raken. Het probleem is zelden dat iemand geen meta description kan schrijven. Het probleem is dat de software geen betrouwbaar systeem heeft om SEO-signalen consistent te produceren. Daar bouwen wij tooling voor.
Een goede audit is niet alleen een takenlijst. Het is ook een filter. Dezelfde crawl rapporteerde honderden titles die iets boven 60 tekens zaten en honderden meta descriptions die iets boven 160 tekens zaten. Dat is nuttige informatie, maar geen reden om massaal goede titels kapot te knippen. De audit hint zei zelf dat veel gevallen borderline waren. We hebben daarom alleen extreme gevallen aangepast, niet alles.
Hetzelfde geldt voor freshness. Sommige oudere blogposts zijn meer dan een jaar niet aangepast. Je kunt dan overal `updatedAt` naar vandaag zetten en de audit groen maken. Dat hebben we niet gedaan. Google waarschuwt al jaren tegen misleidende freshness-signalen. Een datum aanpassen zonder echte revisie is geen kwaliteitsverbetering. Het is cosmetiek. Voor 2026 is dat precies het soort gedrag dat je niet wilt automatiseren.
De discipline zit in niet alles fixen. Je wilt technische fouten snel oplossen, contentdikte verbeteren waar de pagina echt te dun is, en redactionele updates plannen waar feiten verouderd zijn. Je wilt niet ieder SEO-signaal najagen alsof het een bug is. Dat maakt sites onnatuurlijker, niet beter.
Wij gebruiken nu vijf checks voordat een pSEO pagina indexeerbaar mag zijn. Eén: de pagina heeft een eigen zoekintentie die niet volledig overlapt met een andere pagina. Twee: de eerste 200 woorden bevatten specifieke context die niet uit de template komt. Drie: de pagina linkt naar verwante content op een manier die de lezer helpt, niet alleen PageRank verdeelt. Vier: schema, canonical en hreflang worden centraal gegenereerd. Vijf: de pagina heeft een eigenaar, datum en inhoudelijke reden om actueel te blijven.
Voor locatiepagina’s betekent dat lokale context. Voor vergelijkingen betekent dat echte trade-offs en criteria. Voor tools betekent dat uitleg over input, output en beperkingen. Voor templates betekent dat voorbeelden van gebruik en fouten die mensen in de praktijk maken. Het patroon is simpel: elke pagina moet iets oplossen dat een generieke hub niet oplost.
Als je al pSEO hebt, begin dan niet met herschrijven. Begin met meten. Crawl je site. Cluster pagina’s op template. Zoek duplicate body, title overlap, thin pages, menu-only inbound links, ontbrekende schema en statuscodes. Pas daarna beslis je welke templates redactioneel werk nodig hebben en welke technische fixes direct kunnen.
Een standaard SEO crawler is prima voor kleine sites. Bij pSEO, meertalige Next.js projecten of contentprogramma’s met honderden pagina’s loop je snel tegen grenzen aan. Je wilt bronbestanden aan URLs koppelen, routes detecteren uit de App Router, locale-prefixes controleren, sitemapdekking vergelijken met crawldata en schema validatie automatiseren. Dat is softwarewerk, geen handmatige checklist.
Bij MG Software bouwen we dit soort interne tools voor onszelf en voor klanten. Soms is dat een CLI die in CI draait. Soms een dashboard met trends per template. Soms een crawler die precies uitlegt welk bestand verantwoordelijk is voor een fout. Als je site omzet moet genereren, wil je deze signalen niet pas zien nadat rankings dalen. Je wilt ze zien voordat ze live gaan.
Heb je een grote contentsite, SaaS-platform of pSEO-programma dat belangrijk is voor leads? Dan is een technische SEO audit geen marketingklus maar een engineeringklus. Stuur ons je situatie. We kijken graag mee of je met bestaande tools voldoende hebt, of dat maatwerkcontrole nodig is.
De Google spam update van 2026 maakt pSEO niet dood. Het maakt slechte pSEO duurder. Pagina’s die alleen bestaan omdat een keyword in een database staat, worden kwetsbaarder. Pagina’s die vanuit een duidelijke zoekintentie, technische betrouwbaarheid en echte redactionele waarde zijn opgebouwd, blijven verdedigbaar.
Onze eigen audit liet zien dat de grootste winst vaak in de combinatie zit: renderingstrategie, structured data, interne links, unieke intro’s en redactionele discipline. Geen enkele fix is magisch. Samen maken ze het verschil tussen een schaalbare contentmachine en een schaalbaar spamrisico.

Jordan Munk
Co-founder

Leer de technische SEO-strategieen die webapplicaties vindbaar maken, van server-side rendering tot structured data en Core Web Vitals.

Wij testten OpenAI Codex Security naast Snyk en SonarQube. Het vond 11.000 kritieke bugs in beta, maar er zijn kanttekeningen. Lees onze analyse voor development teams.

JetBrains Air draait Codex, Claude, Gemini en Junie tegelijk in een IDE. Wij testten het naast Cursor en GitHub Copilot op echte projecten. Benchmarks, prijzen en ons eerlijk oordeel.

TypeScript is nu GitHub's #1 taal, voorbij Python en JavaScript. We analyseren de data, AI's rol in deze verschuiving en wat het betekent voor uw tech stack.


















Dezelfde technische expertise die u leest, zetten wij dagelijks in voor klanten.
Bespreek uw technische uitdaging