Technische SEO in 2026: de basis die echt telt

Technische SEO wordt vaak gepresenteerd als een lijst van tweehonderd punten. Dat maakt het onbruikbaar, want je weet niet meer wat eerst moet.

In de praktijk gaan sites niet stuk op punt 174. Ze gaan stuk op een handvol dingen: een pagina die is geblokkeerd terwijl hij alleen uit de index moest, een statuscode die het tegenovergestelde zegt van wat de pagina toont, of inhoud die pas in de browser wordt opgebouwd.

Wat er sinds 2025 bij is gekomen, is dat dezelfde basis nu twee soorten lezers dient. Google zegt het zelf in zijn richtlijn voor generatieve AI, gepubliceerd op 15 mei 2026 en daarna bijgewerkt: “all existing technical SEO best practices continue to be worthwhile”. Om in AI Overviews of AI Mode te kunnen verschijnen, moet een pagina geïndexeerd zijn en met een snippet kunnen worden weergegeven. Geen aparte techniek dus, maar wel dezelfde techniek op orde.

Dit artikel gaat langs de punten die er in mijn werk echt om blijken te gaan, met bij elk punt de documentatie waar het staat. Ik noem ook een paar dingen die volgens Google juist niet nodig zijn.

Elke laag bepaalt of de laag erboven nog iets uithaalt.

Crawlen en indexeren zijn twee verschillende dingen

Hier gaat het vaker mis dan bij al het andere in dit artikel bij elkaar.

robots.txt regelt of een crawler je pagina mag ophalen. Het regelt niet of die pagina in de zoekresultaten staat. Google zegt dat letterlijk: “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.”

Een geblokkeerde pagina kan dus in de resultaten staan. Google: “A page that’s disallowed in robots.txt can still be indexed if linked to from other sites.” Je ziet dan een zoekresultaat zonder beschrijving eronder.

Wil je een pagina echt uit de index, dan gebruik je noindex. En daar zit de val die ik het vaakst tegenkom, in Googles eigen woorden: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler. If the page is blocked by a robots.txt file or the crawler can’t access the page, the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it.”

Blokkeren en uitsluiten samen werkt dus niet. Het is het een of het ander. En noindex in robots.txt zetten werkt helemaal niet: “Specifying the noindex rule in the robots.txt file is not supported by Google.”

Nog iets dat vaak verkeerd gaat: crawlbudget. Google heeft daar een uitgebreide gids over, en die begint met een waarschuwing dat de meeste sites hem niet nodig hebben: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” De getallen die Google noemt, liggen bij een miljoen pagina’s die wekelijks veranderen, of tienduizend pagina’s die dagelijks veranderen. Google zet er zelf bij dat dat geen harde grenzen zijn: “These are not exact thresholds.” Zit je er ver onder, dan is crawlbudget jouw probleem niet. Bij een site met duizenden automatisch gemaakte pagina’s ligt dat anders.

Eén detail uit die gids is wel voor iedereen relevant, nu er meer bots langskomen dan ooit: “While each crawler has a different crawl demand, the crawl capacity limit is shared across all crawlers. This means that high demand from one crawler can reduce the capacity available for others.” Google zegt dat over zijn eigen crawlers. Wat de bots van AI-partijen met je server doen, hangt af van hoe die server het houdt.

Canonical is een sterk signaal, geen bevel

Een canonical tag vertelt Google welke versie van een pagina de echte is. Wat veel mensen niet weten, is dat het een aanwijzing is en geen instructie.

Google zet de signalen op een rij, in volgorde van kracht: een redirect is het sterkste signaal, een rel="canonical" daarna, en opname in de sitemap noemt Google zelf “a weak signal”. En dan: “none of them are required; your site will likely do just fine without specifying a canonical preference.”

De regels die Google er wel bij geeft, zijn concreet. Gebruik robots.txt niet voor canonicalisatie. Geef niet via twee verschillende methodes twee verschillende canonicals op voor dezelfde pagina. Zet een canonical ook op de canonieke pagina zelf. En gebruik geen noindex om te kiezen tussen twee eigen pagina’s, want daarmee gooi je de pagina helemaal uit de zoekresultaten.

Werk je met een site die inhoud in de browser opbouwt, dan is er een extra regel: “The best way to do this is to specify the canonical URL in the HTML source code and make sure that JavaScript doesn’t change the canonical link element.”

Statuscodes moeten zeggen wat de pagina laat zien

Een crawler leest twee dingen: de statuscode en de inhoud. Als die elkaar tegenspreken, kiest Google de veilige kant.

Wat Google zelf per code doet:

Code	Wat Google ermee doet
`2xx`	Inhoud wordt beoordeeld voor indexering. Laat de pagina een fout zien, dan volgt een soft 404 in Search Console
`3xx`	Google volgt maximaal tien redirects achter elkaar
`4xx`	Wordt niet geïndexeerd, en een al geïndexeerde pagina wordt verwijderd
`5xx` en `429`	Google gaat langzamer crawlen. Geïndexeerde pagina's blijven eerst staan en verdwijnen daarna

Een soft 404 is een pagina die zegt dat er niets is, maar wel een 200 meestuurt. Google: “Custom 404 pages are created solely for users. Since these pages are useless from a search engine’s perspective, make sure the server returns a 404 HTTP status code to prevent having the pages indexed.”

Let op wat Google over 404 zegt in verhouding tot blokkeren: “Google won’t forget a URL that it knows about, but a 404 status code is a strong signal not to crawl that URL again. Blocked URLs, however, will stay part of your crawl queue much longer.” Een pagina die echt weg is, ruim je dus op met een 404 of 410, niet met robots.txt.

Snelheid: de drempels zijn niet veranderd

De drie Core Web Vitals en hun drempels staan er nog precies zo als vorig jaar:

LCP, hoe snel het grootste element in beeld staat: binnen 2,5 seconden.
INP, hoe snel de pagina reageert op een klik of tik: 200 milliseconden of minder.
CLS, hoeveel de pagina verschuift tijdens het laden: 0,1 of minder.

Die drempels gelden op het 75e percentiel van je bezoeken, apart gemeten voor mobiel en desktop. Driekwart van je bezoeken moet er dus onder blijven. In de officiële lifecycle-lijst staan alle drie op “Stable”. Ik heb geen aankondiging van een opvolger van INP kunnen vinden en ook geen wijziging in 2026; de pagina op web.dev waar de drempels staan, is voor het laatst bijgewerkt in oktober 2024.

Google formuleert het effect voorzichtiger dan de meeste SEO-teksten: “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” Dat is geen belofte van hogere posities. Wat je erover moet weten en waar je bij INP op moet letten, staat in mijn artikel over Core Web Vitals en INP.

Structured data: minder rich results, nog steeds nuttig

Hier is in 2026 wel iets veranderd, en het raakt veel Nederlandse sites.

FAQPage levert geen rich results meer op. Google meldde het op 8 mei 2026 in het overzicht met documentatiewijzigingen: “This feature will no longer appear in Google Search starting May 7, 2026.” De documentatiepagina zelf is in juni 2026 weggehaald; wat er nu over is, is die notitie in het wijzigingenoverzicht. HowTo was al eerder gesneuveld, in september 2023; daar is in 2026 niets nieuws over gebeurd, ook al lees je dat soms.

Moet je die markup nu weghalen? Google zegt van niet: “Structured data that’s not being used does not cause problems for Search, but also has no visible effects in Google Search.” Zelf laat ik FAQ-markup staan, omdat AI-systemen vraag-en-antwoordparen er correct uit overnemen. Verwacht er alleen geen sterretjes meer van.

En dan de misvatting die ik het vaakst moet uitleggen. Schema markup is niet nodig om in AI-antwoorden van Google te komen. Google: “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add. However, it’s a good idea to continue using it as part of your overall SEO strategy.” Welke types nog wel iets opleveren en hoe je ze inzet, staat in mijn artikel over schema markup en AI Overviews.

Wat AI-zoekmachines aan dezelfde basis hebben

De richtlijn die Google in mei 2026 publiceerde, is voor dit onderwerp de enige bron die telt. Twee dingen staan daar hard in.

Ten eerste de eis: “To be eligible to be shown in generative AI features on Google Search, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements.”

Er staat op diezelfde pagina nog een tweede voorwaarde, en die wordt vaak overgeslagen: “In addition to the technical requirements for Search, a site must be included in Search generative AI features in Search Console to be eligible for display in generative AI features on Google Search.” Die instelling staat standaard aan, dus je hoeft er niets voor te doen. Wel is het het eerste dat ik nakijk als een site nergens in AI-antwoorden opduikt.

En dan nog een zin die ik graag citeer als iemand garanties vraagt: “Indexing and serving aren’t guaranteed.”

Ten tweede: wat volgens Google niet nodig is. Google zet het onder het kopje “Mythbusting generative AI search: what you don’t need to do”.

Over llms.txt: “You don’t need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn’t use them.” Google voegt toe dat het ook niet schaadt. Wat het bestand wel is en waarom ik het toch aanraad voor andere systemen, staat in mijn artikel over llms.txt.
Over content in stukjes hakken: “There’s no requirement to break your content into tiny pieces for AI to better understand it.”
Over apart schrijven voor AI: “You don’t need to write in a specific way just for generative AI search.”

Elders op die pagina, in het deel over meten, staat nog een zin die je bij elke toolkeuze mag aanhalen: “No third-party tool has access to our internal ranking or AI systems.”

Nog een hardnekkige fout: Google-Extended blokkeren haalt je niet uit AI Overviews. Google is daar expliciet over: “Google-Extended does not impact a site’s inclusion in Google Search nor is it used as a ranking signal in Google Search.” Dat token gaat over training van Gemini-modellen, niet over de AI-functies in Search. Wil je beperken wat er van je pagina’s in Search wordt gebruikt, dan zijn nosnippet, data-nosnippet, max-snippet en noindex de knoppen.

Voor de crawlers van de andere partijen geldt iets anders. OpenAI en Perplexity schrijven beide dat je hun zoekbot in robots.txt moet toestaan om in hun resultaten te kunnen verschijnen. En geen van beide zegt iets over het uitvoeren van JavaScript, wat de reden is dat ik server-side of statisch gerenderde HTML als uitgangspunt neem. Wat dat betekent als je site met een AI-bouwer is gemaakt, staat in mijn artikel over een website maken met AI. Hoe Perplexity je site leest, heb ik eerder uitgezocht.

Meertalig: twee fouten die bijna iedereen maakt

Heb je een Nederlandse en een Engelse versie, dan komt hreflang erbij: de verwijzing waarmee je per pagina aangeeft in welke taal hij staat en welke andere taalversies er zijn. Google noemt de veelgemaakte fouten zelf, onder het kopje “Common Mistakes”.

De eerste: ontbrekende terugverwijzingen. “If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored.”

De tweede zit in de codes. UK bestaat niet als regiocode; het moet GB zijn. Google: “If you use codes that are listed as reserved for something else, Google Search ignores that part of the annotation (for example, using EU, UN, or UK in hreflang annotations doesn’t have an effect on Google Search).”

Verder: URL’s moeten volledig zijn, inclusief https, elke versie moet ook naar zichzelf verwijzen, en een canonical moet naar een pagina in dezelfde taal wijzen. Heb je maar twee talen, dan wijst x-default naar de versie die je als standaard wilt tonen.

De volgorde waarin ik dit controleer

Bij een nieuwe site loop ik dit rijtje af. De volgorde is niet willekeurig: elk punt bepaalt of het volgende nog iets uithaalt.

Komt er een 200 uit en staat de inhoud in de HTML? Zonder dat heeft de rest geen zin.
Wat staat er in robots.txt en waar staat noindex? Vaak vind ik hier het echte probleem, en het is meestal in vijf minuten op te lossen.
Kloppen de statuscodes met wat de pagina laat zien? Vooral de 404-pagina en verwijderde pagina’s.
Zijn de canonicals eenduidig? Eén methode, zelfverwijzend, geen tegenstrijdigheden.
Staat alles wat moet meedoen in sitemap.xml, en niets anders? Let op lastmod: die datum hoort alleen te veranderen als de pagina echt is gewijzigd, niet bij elke nieuwe build.
Kloppen de hreflang-verwijzingen heen en terug? Bij twee talen kost dat tien minuten.
Halen de Core Web Vitals de drempels op het 75e percentiel? In veldgegevens, niet in een labtest.
Staat er schema dat nog iets oplevert, en niets dat schade doet?
Pas dan: content en interne links. Zonder techniek wordt een goede tekst niet gelezen, en zonder goede tekst helpt perfecte techniek je niet aan klanten.

Loop je dit rijtje liever niet zelf af, dan is de vraag wat het kost om het uit te besteden. Wat je daarvoor in Nederland betaalt en waar je op moet letten, staat in mijn artikel over SEO uitbesteden.

Wat er daarna nog rest, is meten of het werkt. Voor AI-verkeer is dat sinds dit jaar anders geregeld dan voor gewoon zoekverkeer; dat heb ik uitgewerkt in mijn artikel over AI-verkeer meten in GA4.

Kort samengevat

Robots.txt regelt crawlen, noindex regelt indexeren. Samen gebruiken werkt niet, want een geblokkeerde pagina laat de noindex nooit zien.
Canonical is volgens Google een sterk signaal, geen instructie, en is niet verplicht.
Statuscodes moeten overeenkomen met de inhoud. Een foutpagina met een 200 wordt een soft 404.
De Core Web Vitals-drempels zijn onveranderd: LCP 2,5 seconden, INP 200 milliseconden, CLS 0,1, op het 75e percentiel.
FAQPage levert sinds 7 mei 2026 geen rich results meer op. HowTo al sinds september 2023. Weghalen hoeft niet.
Voor AI-functies van Google geldt geen aparte techniek: geïndexeerd zijn en met een snippet kunnen verschijnen. Llms.txt, content in stukjes hakken en extra schema zijn volgens Google niet nodig.
Google-Extended blokkeren haalt je niet uit AI Overviews. Dat token gaat over modeltraining.

Veelgestelde vragen

Wat is technische SEO eigenlijk?

Alles wat bepaalt of een zoekmachine of AI-systeem je pagina’s kan ophalen, lezen en begrijpen. Dus crawlen, indexeren, statuscodes, snelheid, structuur en markup. Het gaat niet over wat er op de pagina staat, maar over of het gelezen kan worden.

Moet ik crawlbudget optimaliseren?

Bijna zeker niet. Google zegt zelf dat je die gids niet hoeft te lezen als je pagina’s worden gecrawld op de dag dat je ze publiceert. De drempels die Google noemt, liggen bij tienduizend pagina’s met dagelijkse wijzigingen of een miljoen pagina’s met wekelijkse.

Kan ik een pagina uit Google halen met robots.txt?

Nee. Robots.txt houdt de crawler tegen, niet de indexering. Als andere sites naar die pagina linken, kan hij alsnog in de resultaten staan, zonder beschrijving. Gebruik noindex en zorg dat de pagina daarvoor wel toegankelijk is.

Heb ik schema markup nodig om in AI-antwoorden te komen?

Volgens Google niet: “Structured data isn’t required for generative AI search.” Google raadt het wel aan als onderdeel van je gewone SEO, omdat het je in aanmerking laat komen voor rich results.

Is llms.txt nodig?

Niet voor Google. Google Search gebruikt het bestand niet en zegt dat het niet helpt en niet schaadt. Voor andere systemen die het bestand wel uitlezen, kan het zin hebben. Zet er in elk geval geen verwachtingen op richting Google.

Bronnen

Alle bronnen zijn geraadpleegd op 22 september 2026.

Wil je weten hoe jouw site technisch staat?

In een gratis GEO-scan loop ik de punten uit dit artikel na op je eigen site. Je krijgt de bevindingen met de bron erbij, zodat je ze zelf kunt narekenen. Wil je het liever uitbesteden, dan zie je bij SEO en GEO wat er in welk pakket zit.