Technische SEO in 2027 kies wat echt verschil maakt

Toch krijgen die werkzaamheden in een technische audit soms ongeveer hetzelfde gewicht. Alles heeft een kleurtje, alles moet opgelost en ergens onderaan wacht de belofte van een perfect gezonde website. We zouden liever weten welke problemen je vindbaarheid werkelijk beperken.

Richting 2027 verdienen vooral bereikbaarheid, rendering, interne links, goede URL-keuzes en betrouwbare productinformatie je aandacht. PageSpeed blijft relevant, maar een perfecte testscore is zelden een overtuigend doel op zichzelf. En sommige vertrouwde werkzaamheden kun je inmiddels gewoon van je lijst halen.

Geef technische SEO geen punten voor aanwezigheid

Een canonical, een snelle server en Product structured data doen verschillende dingen. Ze verdienen dus ook een verschillende beoordeling.

Met een canonical geef je aan welke versie van vergelijkbare pagina’s je voorkeur heeft. Een bereikbare server maakt crawling mogelijk. Product structured data kan je geschikt maken voor bepaalde zoekresultaten. En Core Web Vitals worden daadwerkelijk door Googles ranking systems gebruikt.

Dat onderscheid voorkomt een hoop verkeerde verwachtingen. Een blokkade weghalen kan cruciaal zijn, zonder dat je daarmee een extra ranking bonus verdient. Andersom kan een erkend ranking signal zo weinig extra werk rechtvaardigen dat andere verbeteringen voorrang krijgen. Google publiceert geen universeel percentage waarmee we de SEO-waarde van al deze ingrepen kunnen uitrekenen.

Onze vraag bij een technische aanbeveling is daarom simpel: welke belangrijke pagina’s hebben hier last van, wat gaat er concreet mis en hoe gaan we controleren dat de aanpassing werkt?

Verbeter de ervaring en laat die 100 los

Laten we met de populaire beginnen. PageSpeed is lekker tastbaar. Je voert een URL in, krijgt een getal terug en kunt na een aanpassing laten zien dat het getal hoger is. We begrijpen de aantrekkingskracht. Alleen vertelt dat getal niet hoeveel extra bezoekers je uit Google gaat krijgen.

Google zegt in zijn huidige page experience-documentatie twee relevante dingen. Core Web Vitals worden gebruikt voor ranking. Tegelijk kan een perfecte score nastreven, puur voor SEO, een slechte besteding van je tijd zijn. Relevante content kan bovendien goed ranken met een minder goede page experience.

Daarmee is “PageSpeed doet er niet toe” te stellig. “Die laatste scorepunten krijgen vaak te veel aandacht” vinden we een stuk beter verdedigbaar. Hoe groot het ranking effect voor jouw site is, kun je niet uit een Lighthouse-score afleiden.

Kijk naar field data voordat je een sprint inplant

In PageSpeed Insights staan verschillende soorten metingen. De bekende Performance-score komt uit een Lighthouse-test onder gesimuleerde omstandigheden. De field data komen uit het Chrome UX Report, gebaseerd op echte gebruikerservaringen over de afgelopen 28 dagen. Beide zijn nuttig, maar ze beantwoorden een andere vraag.

Gebruik field data om te beoordelen waar bezoekers daadwerkelijk tegenaan lopen. Gebruik lab data om oorzaken te onderzoeken en oplossingen te testen. Controleer daarbij of de field data over de ingevoerde URL gaan of over de hele origin. Bij te weinig metingen kan PageSpeed Insights terugvallen op dat bredere niveau. Ontbrekende field data betekenen niet automatisch dat alles goed gaat; eigen real user monitoring kan dan helpen.

Voor een goede beoordeling liggen de grenzen bij LCP op maximaal 2,5 seconden, INP op maximaal 200 milliseconden en CLS op maximaal 0,1. De beoordeling gebruikt het 75e percentiel. Die grenzen zijn meetcriteria voor de gebruikerservaring, geen belofte van een rankingsprong zodra je groen wordt.

De field data helpen om het gebruikersprobleem te beoordelen. De lab data helpen om het technisch te onderzoeken. Eigen schema van MarketingCollega, gebaseerd op Google PageSpeed Insights-documentatie.

Reageert een productfilter traag, springt de bestelknop weg of wachten bezoekers lang op het belangrijkste deel van de pagina? Dan is performance serieus werk waard. Ook als je geen ranking effect kunt aantonen. Hetzelfde geldt voor een server die onder belasting bezwijkt en crawling belemmert.

Maar zijn de belangrijkste templates prettig in gebruik, zijn de field data goed en zit de discussie vooral tussen 94 en 100? Dan zouden we eerst kijken welke andere SEO-kansen nog openstaan. Een goede developer kan prima uitleggen waarom een aanpassing nodig is zonder die zes punten als verdienmodel te gebruiken.

Test wat Google werkelijk te zien krijgt

“Er zit JavaScript in, dus dat is slecht voor SEO” is een nogal luie diagnose. Op 4 maart 2026 verwijderde Google verouderde tekst uit zijn documentatie: JavaScript gebruiken om content te laden maakt het niet automatisch moeilijker voor Google Search. Google rendert al jaren JavaScript.

Dat geeft je geen vrijbrief om alleen in je eigen browser te kijken. Een pagina kan voor jou compleet zijn, terwijl een API faalt bij Google, belangrijke resources worden geblokkeerd of de inhoud pas na een gebruikersactie verschijnt.

We zouden per belangrijk template de HTTP-response, oorspronkelijke HTML en rendered HTML vergelijken. Staat de productinformatie erin? Zijn de links echte links? Kloppen de robots-instructies en de canonical? Met URL Inspection en de Rich Results Test kun je bekijken wat Google tijdens de test ontvangt en rendert. De geïndexeerde versie en de live test vertellen daarbij niet hetzelfde: een succesvolle live test bewijst nog geen indexatie.

Een voorbeeld van wat een vergelijking tussen HTML en rendered HTML kan blootleggen. De URL’s zijn illustratief. Eigen schema van MarketingCollega, gebaseerd op Google Search Central.

Let juist op tegenstrijdigheden. Een canonical in de HTML die JavaScript vervolgens naar een andere URL verandert, is onnodig onduidelijk. En een oorspronkelijke noindex laten we niet staan in de hoop dat JavaScript die later wel verwijdert. Google waarschuwt voor die aanpak.

Server-side rendering kan een prima keuze zijn, onder meer voor snelheid en bots die geen JavaScript uitvoeren. Maar een complete rebuild voorstellen omdat “Google geen JavaScript kan lezen” zouden we in 2027 niet meer accepteren. Laat eerst zien welk relevant probleem je ermee oplost.

Controleer zware HTML als daar aanleiding voor is

Een concreet aandachtspunt uit 2026 is de gedocumenteerde fetch limit van Googlebot: 2 MB per bestand voor ondersteunde bestandstypen, met een aparte grens voor PDF’s. Google lichtte dit op 31 maart uitgebreid toe. Het gaat om ongecomprimeerde data; externe CSS en JavaScript worden afzonderlijk opgehaald en hebben hun eigen limiet.

Dit is dus geen maximum van 2 MB voor je complete pagina inclusief alle afbeeldingen. Wel kunnen enorme inline scripts, base64-afbeeldingen of andere HTML-bloat belangrijke informatie voorbij de afkapgrens duwen. Voor een gewone pagina is die grens ruim. Bij uitzonderlijk zware templates zouden we hem controleren. Dat is gerichte technische SEO, geen reden om overal op iedere kilobyte te gaan jagen.

Geef belangrijke pagina’s betere interne links

Interne links klinken minder spannend dan een nieuw framework. Toch vonden we hier een van de interessantste recente praktijkresultaten.

SearchPilot publiceerde op 30 september 2026 een gecontroleerde SEO-test bij een webshop. De merknaam op productpagina’s werd een link naar de bijbehorende merkpagina. Voor die merkpagina’s rapporteerde SearchPilot een geschatte stijging van 18% in organic traffic, met een 95% credible interval. Op de productpagina’s was het resultaat inconclusive.

Dat is één test op één website, gepubliceerd door de leverancier van het testplatform. De ruwe data zijn niet openbaar. We zouden er dus geen algemene groeibelofte van maken. Maar het is wel concreter bewijs voor een mogelijke verbetering dan de aanname dat nóg een technisch vinkje vast iets zal doen.

Ook het tegenvoorbeeld is nuttig. In maart 2026 beschreef SearchPilot een test met links naar dertig populaire bestemmingen. Het linkblok op andere listing pages leverde geen aantoonbare trafficverbetering op. Meer links toevoegen is kennelijk geen recept dat je overal hetzelfde kunt toepassen.

We kijken daarom naar gemiste logische verbindingen. Een product naar zijn merk. Een koopgids naar de bijbehorende categorie. Een dienstenpagina naar een relevante specialisatie. Vervolgens controleren we of die links als <a href> beschikbaar zijn en naar de juiste canonical URL verwijzen. Een klikbaar blok in je design is niet vanzelf een goed crawlbare link.

Houd producten achter de eerste pagina bereikbaar

Ook pagination blijft de moeite waard. Bij “laad meer” en infinite scroll moet Google de volgende producten kunnen bereiken zonder eerst op een knop te klikken. Gebruik bereikbare vervolg-URL’s en crawlbare links.

Die vervolgpagina’s krijgen ieder een eigen canonical. Alles naar pagina één laten wijzen is geen handige opruimactie: pagina twee bevat andere producten. Wat je wél kunt laten liggen, is werk aan rel="next" en rel="prev" uitsluitend voor Google. Google gebruikt die annotations niet meer. Ook unieke titles en meta descriptions voor iedere pagination-pagina zijn volgens de documentatie niet nodig.

Stuur filters en indexatie bewust aan

Een webshop kan vijfduizend producten hebben en toch honderdduizenden URL’s produceren. Combineer maat, kleur, sortering en beschikbaarheid en je krijgt al snel veel varianten van ongeveer hetzelfde aanbod.

Hier kan technische SEO veel zinvoller zijn dan een snellere animatie. Google waarschuwt in zijn actuele documentatie voor faceted navigation die enorme URL-ruimtes creëert. Dat kan servercapaciteit opslokken en de ontdekking van nuttige nieuwe pagina’s vertragen.

We zouden beginnen met de commerciële keuze. Welke combinaties verdienen een zelfstandige landing page? “Zwarte leren eetkamerstoelen” kan een zinvolle categorie zijn, als zoekvraag en assortiment dat dragen. Een willekeurige combinatie van sortering, prijsrange en voorraadstatus hoeft meestal geen eigen zoekresultaat te krijgen.

Daarna kies je het technische middel. Een canonical is bedoeld om signalen van dubbele of sterk vergelijkbare pagina’s te bundelen. Noindex is bedoeld om een pagina buiten de index te houden. Robots.txt stuurt crawling. Die drie zijn niet onderling uitwisselbaar.

Een belangrijke valkuil: zet je noindex op een URL en blokkeer je die tegelijk in robots.txt, dan kan Google die noindex niet lezen. Moet een bestaande indexvermelding verdwijnen, laat Google de verwijderinstructie dan kunnen ophalen. Wil je vooral voorkomen dat een eindeloze filterruimte wordt gecrawld, ontwerp daarvoor een afzonderlijk crawlbeleid. Een canonical alleen is geen betrouwbare crawlstop.

Controleer vervolgens of interne links, sitemaps en canonicals dezelfde voorkeurs-URL ondersteunen. Kijk in URL Inspection ook welke canonical Google daadwerkelijk heeft geselecteerd. Een technisch geldige tag is nog geen garantie dat Google jouw keuze volgt.

Maak van crawl budget geen standaard maandproject

Google richt zijn uitgebreide crawl budget-advies vooral op zeer grote sites, snel veranderende sites en sites met veel ontdekte maar nog niet gecrawlde URL’s. Worden jouw belangrijke nieuwe pagina’s vlot opgehaald en is je server gezond? Dan is er weinig aanleiding om crawl budget als zelfstandig optimalisatieproject te verkopen.

Bij twijfel bekijken we Crawl Stats en geverifieerde Googlebot-requests in server logs. Worden relevante URL’s gemist, of kijken we vooral naar een groot getal? Minder crawl requests zijn niet automatisch beter. En een pagina die al is gecrawld maar niet geïndexeerd, heeft niet per definitie een crawl budget-probleem.

Bescherm je vindbaarheid bij releases en migraties

Als we ontwikkeltijd mogen verdelen, reserveren we graag een deel voor controles rond wijzigingen. Een thema-update die belangrijke interne links verwijdert, kan meer aandacht verdienen dan maanden aan kleine performanceverbeteringen.

Bij gewijzigde URL’s controleren we de mapping naar inhoudelijk passende nieuwe bestemmingen, de redirects en de uiteindelijke response. Interne links en canonicals moeten mee. Bij een domeinmigratie neem je ook relevante subdomeinen en www-varianten mee. Google verduidelijkte die laatste aanwijzing in juni 2026.

Dat betekent niet dat iedere 404 gerepareerd moet worden. Een definitief verwijderde pagina zonder passende vervanger mag een 404 of 410 teruggeven. Prioriteit krijgen onverwachte 404’s op belangrijke pagina’s en kapotte interne routes. Alles naar de homepage redirecten omdat het rapport dan mooier oogt, zouden we niet doen.

Ook buiten migraties is dit waardevol. Maak een kleine vaste controleset van belangrijke categorieën, producten en diensten. Controleer na een release dezelfde URL’s op statuscodes, indexeerbaarheid, canonical, content en links. Je hoeft daarvoor niet elke keer de complete site opnieuw binnenstebuiten te keren.

Geef internationale pagina’s een samenhangende inrichting

Werk je met Nederlandse, Belgische of Duitse versies, dan verdient hreflang aandacht wanneer de verkeerde versie in de zoekresultaten verschijnt. Zorg dat alternatieven naar elkaar en zichzelf verwijzen en inhoudelijk bij elkaar horen. Laat een Duitse vertaling niet automatisch naar de Nederlandse versie canonicaliseren.

Wat je meestal kunt overslaan, is hreflang op drie manieren tegelijk implementeren. Google behandelt HTML, HTTP-headers en sitemaps als gelijkwaardige methoden. Een goede implementatie is voldoende. De extra kopieën leveren vooral extra plekken op waar iets uit de pas kan gaan lopen.

Kies structured data met een concreet doel

“Er kan nog meer schema bij” is geen strategie. Welke ondersteunde zoekweergave wil je mogelijk maken, en klopt de informatie die je aanlevert?

Voor webshops blijven Product structured data en de aansluiting op Merchant Center interessant. Denk aan consistente prijzen, beschikbaarheid, varianten en verzend- en retourinformatie. In juli 2026 verduidelijkte Google onder meer de verwerking van productcategorieën en de geldigheidsperiode van sale prices. Dat zijn concrete onderhoudspunten als jouw shop zulke gegevens gebruikt.

Een relevante nuance bij JavaScript: Google adviseert voor shopping-toepassingen om Product structured data in de oorspronkelijke HTML op te nemen. Dynamisch gegenereerde markup kan Shopping-crawls minder frequent en minder betrouwbaar maken. Juist bij snel wisselende prijzen en voorraad is dat een betere reden om iets aan je implementatie te veranderen dan een algemene afkeer van JavaScript.

Wat inmiddels van de Google-checklist mag, is FAQPage-markup toevoegen om FAQ rich results te krijgen. Die functie wordt sinds 7 mei 2026 niet meer in Google Search getoond. In juni verdween ook de bijbehorende documentatie. Het gaat dus verder dan de oudere beperking tot bepaalde gezondheids- en overheidssites.

Goede FAQ-content kan natuurlijk nog steeds bezoekers helpen en relevante vragen beantwoorden. Alleen het beloofde extra zoekresultaat is verdwenen. We zouden bestaande correcte markup niet met spoed laten verwijderen, maar er ook geen ontwikkelbudget voor reserveren zonder een andere concrete toepassing.

Voor overige structured data geldt hetzelfde: kies een ondersteunde toepassing die bij de pagina past. Een geldig resultaat in de Rich Results Test geeft geen garantie op vertoning. En een optioneel veld aanvullen met onbetrouwbare informatie maakt je implementatie niet beter.

Besteed je AI-budget aan bereikbaarheid

Richting 2027 krijgt bijna ieder technisch advies wel een AI-variant. Toch is Google over een populair voorbeeld opvallend duidelijk.

In juni 2026 verduidelijkte Google dat llms.txt niet wordt gebruikt voor Google Search en de zichtbaarheid of rankings daar niet verbetert of verslechtert. Ook speciale AI-markup of een extra Markdown-versie is geen vereiste voor Googles generatieve zoekfuncties.

Voor opname als ondersteunende link in AI Overviews of AI Mode moet een pagina geïndexeerd zijn en in aanmerking komen voor weergave met een snippet. Bereikbare content, interne links en passende indexatie-instructies blijven daardoor heel concrete aandachtspunten.

Dat is een uitspraak over Google Search. We trekken hem niet automatisch door naar ieder ander AI-platform. Heeft een specifieke dienst een aantoonbare toepassing voor een bestand of koppeling, beoordeel die dan op die toepassing.

Maar als de belangrijkste informatie achter een kapotte API of te strenge botbeveiliging zit, beginnen we daar. Een nieuw tekstbestand in de root lost dat niet op.

Pas headings aan met een reden

Zelfs iets ogenschijnlijk kleins als een heading tag verdient meer afweging dan een vaste checklistregel. SearchPilot publiceerde op 13 november 2026 twee tests op dezelfde retailwebsite. Productnamen van H2 naar H4 veranderen gaf op merkpagina’s een geschatte trafficstijging van 14%. Dezelfde wijziging op andere product listing pages gaf juist een geschatte daling van 8,5%. Beide resultaten werden op het 95%-niveau gerapporteerd.

De verklaring die SearchPilot daarvoor geeft, is een hypothese over de rol van productnamen op de verschillende paginatypen. Het experiment bewijst dat mechanisme niet. Wel is het een goed argument om een winnende template-aanpassing niet klakkeloos overal door te voeren.

We zouden dus niet beweren dat headings niets doen. We zouden vragen welk inhoudelijk probleem een wijziging oplost en het effect per template beoordelen. Toegankelijke, begrijpelijke structuur blijft daarbij ook op zichzelf waardevol.

Laat je backlog op deze punten uitdunnen

Niet iedere oude aanbeveling is onzin. Vaak zit het verschil tussen verstandig onderhoud en overbodig werk in de aanleiding. Dit is hoe we de keuzes richting 2027 zouden maken.

Bij die cosmetische URL-wijzigingen hoort nog een recente aanleiding. Google verduidelijkte op 23 oktober 2026 waarom het hyphens boven underscores aanbeveelt. Prima uitgangspunt voor nieuwe URL’s. Het is geen aankondiging van een nieuwe ranking boost en voor ons geen zelfstandige reden om bestaande, goed werkende URL’s te migreren.

Ook bij sitemaps kun je precies zijn zonder eindeloos werk te creëren. Google negeert priority en changefreq. Een betrouwbare lastmod bij een wezenlijke wijziging kan wel worden gebruikt. Elke dag dezelfde datum vernieuwen zonder inhoudelijke aanpassing helpt de betrouwbaarheid daarvan niet.

Spreek vooraf af wanneer een verbetering geslaagd is

Een technische ingreep is pas overtuigend als je kunt laten zien wat ermee is opgelost. Wij zouden daarom vóór het werk de betrokken URL’s, het probleem en de controle vastleggen.

Na een rendering-fix moet de ontbrekende content aantoonbaar in de rendered HTML staan. Na een redirect-aanpassing moet de oude URL op de juiste eindbestemming uitkomen. Na een filteraanpassing wil je in de logs zien dat het beoogde crawlgedrag verandert. Bij performance vergelijk je dezelfde templates en omstandigheden, en geef je field data tijd om nieuwe bezoeken te bevatten.

Daarna volgt de zakelijke vraag. Krijgen de bedoelde pagina’s meer relevante vertoningen, klikken of conversies? Houd rekening met seizoen, andere wijzigingen en veranderingen in de zoekresultaten. Bij voldoende vergelijkbare pagina’s en verkeer kan een gecontroleerde SEO-test helpen. Een simpele voor-en-na-grafiek bewijst op zichzelf geen oorzakelijk verband.

We hebben dus weinig behoefte aan nóg een langere checklist voor 2027. Liever een kortere backlog met heldere keuzes. Laat zien welke pagina’s nu kansen missen, los dat gericht op en controleer het resultaat. Als er daarna nog tijd over is om van 94 naar 100 te gaan, mag dat groene bolletje alsnog zijn feestje krijgen.