Technische SEO
Technische SEO die crawlbaarheid en indexatie verbetert
Technische SEO voorkomt dat goede content onzichtbaar blijft doordat statuscodes, canonicals, rendering, snelheid of interne links elkaar tegenspreken.
- Indexatie: Alleen canonieke, waardevolle pagina’s horen in sitemap en interne linkstructuur.
- Rendering: Belangrijke tekst en metadata moeten ook voor crawlers betrouwbaar beschikbaar zijn.
- Bewijsbaar herstel: Een fix telt pas als toegepast wanneer een onveranderlijk leveringsmoment is vastgelegd.
Wat controleert een technische SEO-audit?
Een audit inventariseert niet alleen fouten, maar bepaalt welke fouten indexatie, gebruikerservaring of conversie daadwerkelijk beïnvloeden. Een lijst met honderden waarschuwingen zonder prioriteit is geen plan.
- Statuscodes, soft 404’s en redirectketens
- Canonical- en hreflangsignalen
- Robots-directives en sitemapkwaliteit
- JavaScript-rendering en zichtbare HTML
- Interne links, orphan pages en crawl-diepte
- Core Web Vitals en mobiele bruikbaarheid
Van foutmelding naar prioriteit
We beoordelen bereik, ernst, commerciële waarde en uitvoeringsrisico. Een homepagecanonical op iedere dienstenpagina krijgt voorrang boven een ontbrekende alt-tekst op een decoratieve afbeelding.
- P0: blokkeert indexatie of veroorzaakt grootschalige verkeerde signalen
- P1: beperkt belangrijke pagina’s of meetbaarheid
- P2: verbetert kwaliteit maar blokkeert groei niet direct
Technische SEO stopt niet na de release
Nieuwe templates, plugins en content kunnen oude fouten terugbrengen. Daarom horen contracttests, monitoring en Search Console-controles bij de oplossing.
- Regressietest voor titles en canonicals
- Automatische sitemapcontrole
- 404- en redirectmonitoring
- Melding bij plotselinge indexatiedaling
Een technische SEO-fix begint met een toetsbaar eindpunt
Een opdracht als ‘los de canonicalproblemen op’ is te breed om zorgvuldig uit te voeren of te controleren. Een bruikbaar werkitem benoemt welke URL's of templates zijn getroffen, welk signaal nu verkeerd staat en welke toestand na publicatie wordt verwacht. Daarbij horen bijvoorbeeld de gewenste HTTP-status, canonical, robots-directive, interne link en zichtbare hoofdinhoud. Ook leggen we vast wie publiceert en in welke omgeving de controle plaatsvindt. Daardoor kan een ontwikkelaar gericht werken en kan iemand anders onafhankelijk vaststellen of de live uitkomst overeenkomt met de opdracht, zonder alleen op een gesloten ticket te vertrouwen.
Bij wijzigingen met een groot bereik hoort bovendien een herstelroute. Een aanpassing aan routing, redirects, robotsregels, structured data of een gedeeld template kan veel pagina's tegelijk beïnvloeden. Vooraf bepalen we daarom welke controle vóór de release nodig is, welke signalen na publicatie worden bekeken en wanneer terugdraaien verstandiger is dan doorpatchen. Het doel is niet om technische verandering onmogelijk te maken, maar om risico herkenbaar en herstelbaar te houden. Zo wordt technische SEO onderdeel van normaal releasebeheer en blijft duidelijk welke verbetering live staat, welke nog getest wordt en welke afhankelijk is van een andere partij.
- Exacte URL-set of template waarop de wijziging van toepassing is
- Verwachte statuscode, canonical, robots-signaal en hoofdinhoud
- Controle vóór en na publicatie door een aangewezen eigenaar
- Herstelroute voor wijzigingen met breed bereik
- Regressietest om herhaling in een volgende release te signaleren
Controleer wat de server levert voordat JavaScript draait
Een pagina kan er in een browser goed uitzien terwijl de oorspronkelijke serverrespons een tegenstrijdig signaal geeft. Een niet-bestaande URL kan bijvoorbeeld visueel een foutmelding tonen, maar technisch met status 200 en indexeerbare inhoud antwoorden. Ook kunnen title, canonical of hoofdtekst pas na JavaScript verschijnen, waardoor crawlers afhankelijk worden van een extra renderstap. Daarom vergelijken we voor belangrijke routes de ruwe HTTP-respons en bron-HTML met de uiteindelijke gerenderde pagina. We controleren of de inhoud, status, canonical en indexatie-instructie vanaf het eerste antwoord passen bij de functie van de URL.
Voor onbekende URL's is een echte 404-status passend; een permanent verhuisde pagina hoort via de server naar één gekozen bestemming te verwijzen. Een private omgeving wordt met authenticatie afgeschermd in plaats van alleen via robots.txt verborgen. Voor publieke pagina's die niet in de index horen, moet een leesbaar noindex-signaal beschikbaar blijven. Ook de sitemap moet uitsluitend canonieke, indexeerbare URL's bevatten die werkelijk met een succesvolle status antwoorden. Deze controles garanderen geen indexatie, maar voorkomen dat de site zelf onnodig conflicterende aanwijzingen geeft aan Google en andere systemen die webpagina's ophalen.
- Ruwe respons en gerenderde DOM afzonderlijk beoordelen
- Echte 404 voor onbekende URL's en serverredirects voor verhuizingen
- Private inhoud beveiligen; crawlblokkades niet als toegangscontrole gebruiken
- Alleen canonieke en indexeerbare URL's in de XML-sitemap
Dit bewijs hoort bij een technische release
Een releasebewijs maakt de technische toestand op het controlemoment herleidbaar. Per onderzochte URL kunnen statuscode, uiteindelijke redirectlocatie, canonical, robots-directive, title en aanwezigheid van hoofdinhoud worden vastgelegd. Bij een sitemapcontrole voegen we het aantal unieke canonieke URL's en eventuele uitgesloten private routes toe. Voor rendering vergelijken we relevante velden uit de bron-HTML met de browseruitkomst. Het verslag noemt ook het build- of deploymentkenmerk wanneer dat beschikbaar is, zodat een latere afwijking niet per ongeluk aan de verkeerde versie wordt gekoppeld. Een screenshot alleen is daarvoor meestal onvoldoende.
Dit materiaal bewijst dat de afgesproken technische toestand live en controleerbaar was; het bewijst nog niet dat Google de verandering al heeft verwerkt of dat posities stijgen. Crawlactiviteit, indexatiestatus, zoekverkeer en conversies hebben hun eigen bronnen en tijdsvensters. Die worden later apart beoordeeld met een complete vergelijkingsperiode. Wanneer Search Console een vertraging toont of een crawl nog niet heeft plaatsgevonden, wordt dat als open meetpunt vermeld. Zo ontstaat geen geforceerd succesverhaal, maar een duidelijke keten van probleem, wijziging, releasecontrole en pas daarna een onderbouwde beoordeling van mogelijke effecten.
- URL, HTTP-status, redirectdoel en canonical
- Robots-signaal, title en hoofdinhoud in de bronrespons
- Sitemap- en interne-linkcontrole
- Deploymentkenmerk, controletijd en eventuele rollback
- Latere crawl- en indexatiemeting als afzonderlijke bewijslaag
Veelgestelde vragen
Wat is technische SEO?
Technische SEO verbetert de crawlbaarheid, indexeerbaarheid, rendering, interne structuur en prestaties van een website.
Is een sitemap genoeg om geïndexeerd te worden?
Nee. Een sitemap helpt URL’s ontdekken, maar pagina’s moeten ook bereikbaar, indexeerbaar, waardevol en voorzien van consistente canonical- en robots-signalen zijn.
Kan Google JavaScript-websites indexeren?
Google kan veel JavaScript renderen, maar rendering kost extra stappen en niet iedere crawler doet dit hetzelfde. Belangrijke content en metadata vooraf renderen verkleint het risico.
Kunnen technische SEO-wijzigingen mijn website beschadigen?
Dat risico bestaat vooral bij wijzigingen aan routing, redirects, templates, canonicals, robotsregels en structured data die veel URL's tegelijk raken. Daarom werken we met een afgebakende URL-set, vooraf beschreven acceptatiecriteria, een controle na publicatie en waar nodig een rollbackroute. De omvang en het risico bepalen of een wijziging direct kan worden uitgevoerd of eerst expliciete technische goedkeuring nodig heeft.
Wat is het verschil tussen een echte 404 en een soft 404?
Een echte 404 laat via de HTTP-status weten dat de gevraagde bron niet bestaat. Bij een soft 404 antwoordt de server bijvoorbeeld met status 200, terwijl de pagina feitelijk leeg, irrelevant of een foutmelding is. Dat geeft crawlers een tegenstrijdig signaal. We beoordelen daarom niet alleen wat een bezoeker ziet, maar ook welke status en inhoud de server daadwerkelijk terugstuurt.
Is robots.txt genoeg om een private pagina uit zoekmachines te houden?
Nee. Robots.txt stuurt crawling, maar is geen toegangsbeveiliging en garandeert niet dat een bekende URL uit een index verdwijnt. Gevoelige inhoud hoort achter authenticatie. Een openbare pagina die niet geïndexeerd mag worden, heeft een correct noindex-signaal nodig dat de crawler kan ophalen. Welke maatregel passend is, hangt dus af van de reden waarom de pagina niet openbaar vindbaar mag zijn.
Wanneer is een technische SEO-audit afgerond?
De analyse is afgerond wanneer bevindingen zijn afgebakend, geprioriteerd en voorzien van een eigenaar en acceptatiecriterium. De uitvoering is pas afgerond wanneer de gekozen wijziging live staat en opnieuw is gecontroleerd. Een auditrapport en een geïmplementeerde oplossing zijn daarmee twee verschillende opleveringen. Eventuele effecten op crawling, indexatie of prestaties worden daarna in een passende meetperiode gevolgd.
Primaire bronnen
Door SEOJuice-redactie, Linktool B.V.. Laatst inhoudelijk bijgewerkt: .
Laat je technische basis controleren