Een technische SEO-controle heeft twee verschillende doelen: vaststellen of zoekmachines de juiste pagina kunnen verwerken en onderzoeken of bezoekers die pagina goed kunnen gebruiken. Begin bij de eerste vraag. Afbeeldingen verkleinen heeft weinig zin als de belangrijkste dienstenpagina nog een noindex-instructie uit de testomgeving bevat.
Volgens de technische vereisten van Google Search moet Googlebot toegang hebben, moet de pagina een werkende HTTP 200-respons geven en moet er indexeerbare inhoud zijn. Ook dan is opname in de index niet gegarandeerd. Deze checklist helpt problemen aantonen en herstellen; zij voorspelt geen zoekpositie.
Maak een controlelijst van pagina’s, niet alleen van scores
Neem de homepage, een dienstenpagina, een artikel, een contactpagina en ieder afwijkend paginatype op. Voeg oude URL’s toe die bij een redesign veranderen. Noteer per URL het bedoelde gedrag: publiceren, doorverwijzen, privé houden of verwijderen. Dat voorkomt dat iemand een bewuste uitsluiting als fout “oplost”.
Leg bij iedere bevinding de URL, datum, omgeving, apparaat, gebruikte tool en waarneming vast. Schrijf bijvoorbeeld: “De publieke dienstenpagina geeft 200, maar bevat een noindex-header.” Dat is controleerbaarder dan “SEO staat niet goed”. Bewaar ook het bewijs vóór de aanpassing. Zonder nulmeting kun je achteraf moeilijk onderscheiden wat werkelijk veranderd is.
1. Controleer wat een bezoeker en crawler ontvangen
- Bereikbaarheid: opent de pagina zonder account, ongewenste beveiligingschallenge of serverfout? Test niet alleen terwijl je als beheerder ingelogd bent.
- Status: geeft een bestaande openbare pagina 200? Geeft een ontbrekende pagina werkelijk een foutstatus, in plaats van een lege pagina met 200?
- Inhoud: zijn hoofdtekst, koppen en links aanwezig in de uiteindelijke pagina? Een zichtbare foto van tekst is geen vervanging voor leesbare artikeltekst.
- Mobiel: zijn dezelfde belangrijke uitleg en vervolgstappen bereikbaar zonder verborgen desktoponderdelen nodig te hebben?
Gebruik voor je eigen geverifieerde website ook URL-inspectie in Search Console. Vergelijk de bekende indexversie met een live test; die beantwoorden niet dezelfde vraag. Een live bereikbare pagina kan nog een oudere versie in de index hebben. Controleer bij verschillen ook je hosting, beveiligingslaag en cache.
Tarieven
Wat kost het?
Het begint bij . Wat jij betaalt hangt af van je situatie.
2. Houd robots.txt, noindex en canonical uit elkaar
robots.txt stuurt crawling. noindex stuurt indexering. Blokkeer je het ophalen van een pagina, dan kan Google de noindex-instructie op die pagina niet lezen. Zet noindex in een ondersteunde metatag of HTTP-header, niet in robots.txt. Dit onderscheid staat in Googles uitleg over noindex. Vertrouw voor vertrouwelijke informatie niet op zoekmachine-instructies: daarvoor is toegangsbeveiliging nodig.
Een canonical geeft aan welke versie van vergelijkbare inhoud je verkiest. Controleer of deze naar de bedoelde publieke URL wijst, niet naar localhost, een testdomein of een algemene overzichtspagina. Canonicals zijn een signaal, geen bevel. Google beschrijft ook hoe redirects, interne links en sitemaps de voorkeurs-URL ondersteunen.
Test bij een verhuizing de oude URL rechtstreeks. De bezoeker hoort op de inhoudelijk passende nieuwe pagina te eindigen. Een reeks redirects of een algemene homepage als bestemming maakt een specifieke oude link minder bruikbaar. Houd daarvoor een expliciete oud-naar-nieuwlijst bij; verander niet onnodig alle artikeladressen.
3. Laat interne links en de sitemap dezelfde website beschrijven
Een dienstenpagina die nergens gelinkt wordt, is lastig te ontdekken voor bezoekers. Loop daarom vanaf de navigatie en inhoudelijke overzichten naar de detailpagina’s. Links moeten rechtstreeks naar het bedoelde doel leiden en een begrijpelijke omschrijving hebben. Het aantal links op zichzelf is geen kwaliteitsmaat.
Neem in de XML-sitemap de volledige voorkeurs-URL’s op die je wilt laten indexeren. Controleer of daar geen concepten, testpagina’s, foutpagina’s of doorverwijzingen tussen staan. Volgens Googles sitemapdocumentatie moet lastmod een echte belangrijke wijziging weerspiegelen. Iedere dag alle datums verversen terwijl de inhoud gelijk blijft, is dus geen bruikbare actualiteitsinformatie.
4. Lees Core Web Vitals als gebruikersmetingen
Core Web Vitals gaan over laden, interactie en visuele stabiliteit. De huidige grenswaarden op web.dev zijn:
| Meting | Waar gaat het over? | Goed |
|---|---|---|
| LCP | Wanneer de grootste zichtbare inhoud verschijnt | Maximaal 2,5 seconden |
| INP | Reactievermogen bij gebruikersinteracties | Maximaal 200 milliseconden |
| CLS | Onverwachte verschuivingen van de lay-out | Maximaal 0,1 |
Beoordeel deze waarden op het 75e percentiel, afzonderlijk voor mobiel en desktop. Dat is niet het gemiddelde van drie tests op je eigen laptop. Noteer ontbrekende metingen als onbekend; maak er geen nul of automatisch groen vinkje van.
PageSpeed Insights combineert velddata en labdiagnose. De CrUX-velddata beslaan een voortschrijdende periode van 28 dagen. Bij te weinig gegevens over één URL kan de tool gegevens voor de hele origin tonen, of geen velddata. Lees dus steeds waarop de cijfers betrekking hebben. Lighthouse onderzoekt een gesimuleerde paginalading. Een betere Lighthouse-score is niet hetzelfde als bewezen betere INP bij echte bezoekers.
Liever even bellen?
Laat je terugbellen
Eén telefoontje is vaak sneller dan drie mailtjes. Je hoort binnen een werkdag van ons.
5. Zoek de oorzaak achter een slechte waarde
Werk niet met een vaste volgorde waarin LCP altijd belangrijker zou zijn dan een vastlopende knop. Onderzoek welke beperking gebruikers treft en op welke pagina’s. De volgende controles zijn hypotheses om te testen, geen set optimalisaties die je blind moet inschakelen.
- Een traag groot beeld: bepaal eerst welk element de LCP vormt. Onderzoek serverwachttijd, ontdekking van het bestand, download en weergave. Laat een belangrijk direct zichtbaar beeld niet pas door lazy loading ophalen. Pas resolutie en compressie aan op de werkelijke weergave. De LCP-aanpak van web.dev helpt die fasen apart onderzoeken.
- Een springende pagina: kijk welk element ruimte opeist nadat andere inhoud al staat. Reserveer ruimte voor afbeeldingen en embeds. Test ook het moment waarop een webfont of melding verschijnt; alleen een fontinstelling wijzigen bewijst niet dat het verschuiven weg is. De CLS-gids werkt zulke oorzaken uit.
- Een trage interactie: herhaal de betreffende handeling, zoals filteren of een formulierstap openen. Onderzoek lange taken en onnodig JavaScript rond die actie. De INP-documentatie maakt onderscheid tussen wachttijd, verwerking en het tonen van de volgende weergave.
Bij caching hoort een functionele controle. Open de pagina als nieuwe bezoeker en test het formulier. Een snellere respons is geen verbetering als een oude beveiligingswaarde, een verouderde prijs of gegevens van een andere gebruiker worden geserveerd. Test wijzigingen eerst in een afzonderlijke omgeving en leg vast hoe je ze terugdraait.
6. Sluit een bevinding pas na een herhaaltest
Gebruik een kort werkregister: probleem, bewijs, eigenaar, wijziging, herhaaltest en resterende onzekerheid. Voor een foutieve canonical kan de herhaaltest de HTML en de uiteindelijke doel-URL controleren. Voor een trage filterknop herhaal je dezelfde interactie. Bij veldmetingen wacht je daarnaast tot genoeg nieuwe gebruikersdata beschikbaar zijn.
Een hypothetisch voorbeeld: een hero-afbeelding werd pas na een scriptverzoek ontdekt. Na aanpassing is het beeld eerder in de netwerktrace zichtbaar en daalt de lab-LCP bij vergelijkbare testinstellingen. Dat ondersteunt de technische verbetering. Het bewijst nog geen extra aanvragen of hogere Google-positie. Noteer zulke uitkomsten afzonderlijk.
Als deze basis klopt maar de pagina de verkeerde vraag beantwoordt, is verdere technische tuning niet de enige volgende stap. Controleer dan de zoekintentie en indeling van de inhoud. Bij websites en platforms horen techniek, uitleg en een werkende gebruikersroute bij dezelfde oplevering.