Technische SEO-checklist: 30 controles met een werkblad

Waarom een checklist gebruiken?

Een controlelijst helpt om onderzoek herhaalbaar over te dragen. De waarde zit niet in het aantal vinkjes, maar in de onderbouwing: welke pagina is getest, onder welke omstandigheden en tegen welk gewenst gedrag? Een volgende collega moet kunnen begrijpen waarom iets openstaat of juist bewust ongemoeid blijft.

Gebruik deze dertig punten als startset. Voeg projectspecifieke controles toe voor bijvoorbeeld een checkout, meerdere talen of bijzondere koppelingen. Schrap niet stilzwijgend wat je niet kon onderzoeken. Wie een volledige onderzoeksmethode zoekt, kan de technische auditgids gebruiken. Hieronder staan de afzonderlijke controlepunten, geen bewijs dat jouw website ze al doorstaat.

Eerst de uitkomst, daarna de prioriteit

Noteer een status voordat je een deadline kiest. Bepaal bij een afwijking wie wordt geraakt, hoeveel belangrijke pagina's betrokken zijn en hoe zeker de oorzaak is. Een kritieke gebruikers- of beveiligingsfout kan voorrang krijgen boven een SEO-waarschuwing. Er bestaat geen vaste tabel die per categorie rankingherstel binnen een aantal weken voorspelt.

Vijf mogelijke uitkomsten van een controlepunt

Status	Wanneer gebruiken?	Vervolg
Niet getest	Toegang, tijd of gegevens ontbreken.	Ontbrekende informatie en eigenaar benoemen.
In orde binnen de test	De vastgelegde test voldoet aan het afgesproken gedrag.	Bewijs en testomstandigheden bewaren.
Afwijking	Werkelijk gedrag wijkt af van wat nodig is.	Gevolgen beoordelen en een herstelvoorstel maken.
Niet van toepassing	De functie bestaat niet binnen deze scope.	Een concrete reden vastleggen.
Bewuste uitzondering	Een verantwoordelijke accepteert het afwijkende gedrag.	Besluit, reden en heroverweegmoment bewaren.

1. Crawling en indexering

• 01. Bedoelde pagina's. Vergelijk CMS-inventaris, sitemap en bereikbare URL's. Benoem welke openbare pagina's in zoekresultaten thuishoren en welke uitzonderingen bewust bestaan.
• 02. Instructies. Controleer statuscode, robots.txt, meta robots en X-Robots-Tag apart. Vergelijk het gevonden gedrag met het bedoelde beleid per omgeving.
• 03. Google-waarneming. Bekijk waar beschikbaar indexatiegegevens en de inspectie van concrete URL's. Noteer datum en beperkingen; behandel een overzichtsteller niet als volledige inventaris.

De robots.txt-uitleg en noindex-richtlijn hebben verschillende doelen. Een crawlblokkade kan verhinderen dat Google noindex leest. Gebruik bij ontbrekende Google-data “niet getest”, niet een geschatte indexatiestatus. Ook het indexeringsrapport vraagt beoordeling per reden; niet iedere uitgesloten URL is verkeerd.

2. Snelheid en performance

• 04. Veldmetingen. Leg beschikbare LCP, INP en CLS vast, inclusief apparaat, periode en dekking. Laat ontbrekende metingen zichtbaar openstaan.
• 05. Herhaalbare labtest. Test relevante templates onder vastgelegde omstandigheden. Bewaar niet alleen de score, maar ook het waargenomen knelpunt.
• 06. Gerichte optimalisatie. Onderzoek beeldformaat, laadprioriteit, code en caching waar de meting aanleiding geeft. Hertest ook functionaliteit en toestemming na de ingreep.

Volgens Web.dev zijn de goede grenzen LCP ≤ 2,5 seconden, INP ≤ 200 milliseconden en CLS ≤ 0,1 op het 75e percentiel van veldmetingen. Een Lighthouse-score is geen vervanging voor deze gegevens. Laat een hoofdbeeld niet onnodig wachten op lazy loading. Kies compressie op zichtbare kwaliteit en werkelijk bestandsgrootteverschil, niet op een algemeen beloofd besparingspercentage.

3. On-page techniek

• 07. Begrijpelijke structuur. Controleer een duidelijke hoofdtitel en logisch geneste secties. Gebruik koppen om de inhoud begrijpelijk te maken, niet om een zoekwoordquotum te vullen.
• 08. Passende metadata. Vergelijk title, description en deelgegevens met de inhoud van deze pagina. Controleer op lege velden, oude beloften en verwisselde afbeeldingen.
• 09. Betekenisvolle media. Controleer alt-tekst, gereserveerde beeldruimte en leesbare uitleg bij complexe beelden. Een decoratieve afbeelding kan een lege alt-tekst hebben.

De W3C-uitleg over koppen en beslisboom voor afbeeldingen helpen bij de inhoudelijke beoordeling. Google geeft afzonderlijke richtlijnen voor titellinks en snippets. Lengtes zijn geen vaste toelatingseis; de zoekweergave kan worden ingekort of anders samengesteld.

4. URL-structuur en redirects

• 10. Variantscope. Inventariseer parameters, taalversies en andere alternatieven. Onderzoek welke inhoud gelijk, vergelijkbaar of werkelijk anders is voordat je voorkeuren wijzigt.
• 11. Eindbestemming. Controleer belangrijke interne links, eventuele tussenstappen en de laatste HTTP-respons. Herstel een loop; beoordeel een verdwenen pagina op een relevante vervanger.
• 12. Consistente voorkeur. Vergelijk canonicals, interne links en sitemap met het bedoelde URL-beleid. Leg noodzakelijke verplaatsingen vast in een mapping.

Canonicalisatie en redirects zijn geen reden om alle varianten naar dezelfde basispagina te sturen. Paginering of een waardevolle filterselectie kan andere inhoud bevatten. Een verwijderde URL zonder passende vervanger mag een echte 404 geven. Deze checklist wijzigt geen bestaande URL's of indexatie-instellingen.

5. Structured data

• 13. Type en doel. Controleer of de gebruikte markup bij de werkelijke pagina hoort en welk doel ermee wordt beoogd.
• 14. Feitelijke overeenstemming. Vergelijk namen, auteurs, datums, afbeeldingen en eventuele aanbodgegevens met zichtbare, controleerbare informatie.
• 15. Validatie en onderhoud. Test syntax en relevante velden; leg vast wie gegevens bijwerkt en controleert na een templatewijziging.

De algemene structured-data-regels vragen meer dan foutloze syntax. Extra markup is geen automatisch zichtbaarheidsvoordeel. Google heeft FAQ-rich results beëindigd; beloof geen dropdowns of vaste CTR-stijging bij het toevoegen van vragen. Een auteurscontrole mag niet uit een algemene databasewijziging worden afgeleid.

6. Verbinding en beheer

• 16. HTTPS-route. Controleer certificaat, bedoelde bestemming en bronnen die de pagina laadt. Leg een waarschuwing vast met concrete URL en tijdstip.
• 17. Verantwoordelijkheid. Bevestig wie updates, toegangsbeheer en herstel uitvoert. Deel geen vertrouwelijke gegevens in openbare auditvoorbeelden.
• 18. Veilige wijziging. Laat ingrijpende header- of serveraanpassingen vooraf beoordelen en hertest de betrokken functies. Bewaar een herstelmogelijkheid.

De uitleg over mixed content helpt onveilige deelbronnen vinden. Een goed certificaat of een hoge headerscore bewijst geen volledige veiligheid. Kopieer geen brede HSTS- of CSP-instelling zonder gevolgen voor subdomeinen, scripts en embeds te kennen. Deze controlelijst is geen volledige beveiligingsaudit.

7. Mobiele inhoud en bediening

• 19. Inhoud behouden. Vergelijk de belangrijke tekst, links en metadata op mobiel en desktop. Onderzoek of noodzakelijke inhoud pas na een gebruikersactie wordt opgehaald.
• 20. Handelingen uitvoeren. Test menu, formulier en primaire vervolgstap met aanraking én toetsenbord. Controleer zichtbare focus en begrijpelijke foutmeldingen.
• 21. Ruimte en vergroten. Test smalle schermen en grotere tekst. Controleer of vaste balken niets bedekken en brede tabellen afzonderlijk bedienbaar blijven.

Mobile-first indexing betekent niet dat iedere pixel op mobiel gelijk moet zijn aan desktop. Een andere indeling of toegankelijke uitklapsectie kan passend zijn. Het doel is beschikbare inhoud en bruikbare bediening, niet een ongemotiveerd vast percentage schermruimte voor alle soorten banners.

8. Taal- en regioversies

• 22. Alternatieven bepalen. Breng in kaart welke pagina's equivalente versies voor andere talen of landen zijn. Markeer dit als niet van toepassing wanneer zulke alternatieven ontbreken.
• 23. Verwijzingen toetsen. Controleer codes, volledige URL's en wederkerigheid. Vergelijk de relatie met de gebruikte canonicals.
• 24. Beheer afspreken. Controleer wat gebeurt wanneer een vertaling wordt toegevoegd, verwijderd of verplaatst. Benoem de eigenaar van die wijziging.

Hreflang helpt alternatieve taal- of regiopagina's aanduiden. Het verwijdert geen duplicaten. HTML, headers en sitemap zijn gelijkwaardige methoden; meer dan één methode is niet verboden, maar maakt consistent beheer lastiger. Beoordeel een eventuele x-default op de werkelijke terugvalroute.

9. JavaScript en rendering

• 25. HTML vergelijken. Vergelijk serverantwoord en gerenderde pagina op hoofdinhoud, links en metadata. Noteer wat daadwerkelijk verschilt.
• 26. Bronnen en fouten. Controleer of benodigde bestanden bereikbaar zijn en of een herhaalbare fout inhoud of interactie verhindert.
• 27. Na het laden testen. Doorloop navigatie en belangrijke handelingen ook na initialisatie. Controleer opnieuw na een gerichte framework- of templatewijziging.

Googles JavaScript-documentatie is het uitgangspunt, niet een algemene afwijzing van React of Next.js. Server-rendering en statische generatie kunnen nuttig zijn, maar de daadwerkelijke output moet kloppen. Een onderdrukte waarschuwing is geen bewezen reparatie en een nieuw framework is niet automatisch nodig.

10. AI-toegang en meetgrenzen

• 28. Doel per instelling. Leg vast welk product of gebruik een crawler- of producttoken regelt. Behandel zoekopname, training en andere verwerking niet als één instelling.
• 29. Werkelijk beleid. Vergelijk de ingestelde toegang en beschikbare Search Console-keuzes met wat de eigenaar wil. Controleer actuele leveranciersdocumentatie vóór een wijziging.
• 30. Uitkomst apart meten. Bewaar concrete waarnemingen met datum en platform. Een toegankelijke pagina is nog geen citatie, aanbeveling of nieuwe aanvraag.

Een concreet voorbeeld: Google-Extended is een producttoken voor bepaalde Gemini-toepassingen en heeft geen invloed op opname of ranking in Google Search. Gebruik het dus niet als universele aan-uitknop voor alle AI-zoekweergaven.

Voor Google's generatieve zoekfuncties gelden de actuele Search-richtlijnen, inclusief de toepasselijke deelname-instelling in Search Console. Speciale AI-schema's zijn niet nodig; llms.txt helpt of schaadt Google Search niet. Andere systemen kunnen andere keuzes hebben. De AI SEO-gids behandelt die platformafweging uitgebreider.

Welke hulpmiddelen passen bij de checklist?

Gebruik een browser voor echte handelingen, een crawler voor herhaalbare patronen, Search Console voor beschikbare Google-waarnemingen en prestatietools voor specifieke metingen. Voeg CMS- en releaseloggegevens toe om de bedoelde toestand te begrijpen. Een losse crawl kent niet automatisch alle verweesde pagina's, en de site:-zoekoperator geeft geen volledige indexatietelling.

Noteer beperkingen en instellingen naast de uitkomst. Deze lijst schrijft geen betaald abonnement voor en claimt niet dat Pico Yellow iedere genoemde tool dagelijks gebruikt. Verdiep een onduidelijk punt via de bron of de gids over technische foutanalyse.

Kopieerbaar werkblad en ingevuld voorbeeld

Kopieer de velden uit onderstaande tabel naar je eigen document of ticketsysteem. Dit is het werkblad zelf; je hoeft geen contactformulier in te vullen voor een niet-beschikbare download. Vul één regel per relevante controle en URL-groep in. Bewaar herstelde afwijkingen voor latere regressietests.

Werkblad: controle, bewijs en vervolg

Veld	Wat vul je in?
Controle en scope	Nummer 01 t/m 30, betrokken URL's, template en omgeving.
Test	Datum, apparaat, hulpmiddel, instellingen en reproductiestappen.
Uitkomst	Een van de vijf statussen, met bewijs of reden waarom niet getest.
Besluit	Gewenst gedrag, gevolgen, prioriteit en verantwoordelijke.
Vervolg	Afgebakende wijziging of aanvullende informatie, acceptatie en hertestdatum.

Fictief ingevuld voorbeeld bij punt 20: in een testomgeving is de aanvraagknop wel aan te raken, maar niet met het toetsenbord bereikbaar. Status: afwijking. De tester bewaart de tabvolgorde en het betrokken template; de developer onderzoekt de oorzaak. Acceptatie: de knop is bereikbaar, heeft zichtbare focus en start de juiste aanvraagroute. Dit voorbeeld bevat geen echte klantgegevens of gemeten conversiestijging.

1. Kies. Bepaal welke controles en pagina's relevant zijn.
2. Leg vast. Bewaar test, bewijs en status.
3. Beslis. Spreek vervolg en eigenaar af.
4. Controleer opnieuw. Hertest na een wijziging en houd open punten zichtbaar.

Wil je de bevindingen laten onderzoeken of uitvoeren? Bekijk technische SEO bij Pico Yellow of plan een vrijblijvend adviesgesprek. We bespreken scope en taakverdeling; de offerte is op maat.

Veelgestelde vragen

Hoeveel controlepunten staan er in deze versie?

Dertig, verdeeld over tien categorieën. De lijst is een startset; voeg noodzakelijke projectcontroles toe en noteer wat niet van toepassing is.

Waar vind ik de template?

Het kopieerbare werkblad staat op deze pagina, met velden voor scope, test, uitkomst, besluit en vervolg. Er wordt geen afzonderlijke download of levering na een aanvraag beloofd.

Mag ik een punt zonder gegevens afvinken?

Nee. Gebruik niet getest en benoem wat ontbreekt. Een onbekende indexatiestatus of ontbrekende veldmeting is geen geslaagd controlepunt.

Moet ik alles tegelijk herstellen?

Nee. Beoordeel gevolgen en risico's en maak afgebakende opdrachten. Een bewuste uitzondering kan blijven bestaan wanneer de verantwoordelijke die onderbouwt.

Is een volledige checklist een garantie op hogere rankings?

Nee. De lijst controleert gekozen technische voorwaarden. Inhoudelijke relevantie, concurrentie en zakelijke uitkomsten vragen afzonderlijk onderzoek.

Moet elke AI-crawler worden toegestaan?

Nee. Bepaal eerst welk doel en product een instelling regelt. Leg het gewenste gebruik vast en controleer de actuele documentatie vóór je beleid aanpast.

Hoe vaak gebruik ik deze lijst?

Stem dat af op releases, incidenten en risico. Een belangrijke templatewijziging kan andere tests vereisen dan een kleine tekstcorrectie.

Wanneer is een afwijking gesloten?

Na een vastgelegde hertest op de juiste versie die aan de afgesproken acceptatie voldoet. Latere verwerking door zoekmachines en bedrijfsresultaten worden apart gevolgd.