Technische SEO-fouten: tien controlepunten en een herstelplan

Kies het juiste startpunt

Heb je een acuut probleem met een belangrijke pagina? Begin bij blokkades en HTTP-statussen. Voor gepland onderhoud gebruik je de prioriteitenafweging. De voorbeeldopdracht laat zien welke informatie een developer nodig heeft.

1. Trage of instabiele pagina's

Een grote hoofdafbeelding, laat geladen lettertypen of veel JavaScript kunnen het gebruik bemoeilijken. Meet eerst wat er gebeurt. De Core Web Vitals beoordelen laden, reageren en stabiliteit met LCP, INP en CLS. De goede grenzen zijn respectievelijk 2,5 seconden, 200 milliseconden en 0,1, steeds inclusief de grenswaarde op het 75e percentiel van beschikbare velddata.

Een labtest helpt oorzaken vinden, maar is geen vervanging voor echte gebruikersgegevens. Vergelijk dezelfde pagina en testinstellingen, bewaar meerdere metingen en benoem ontbrekende data. Kies daarna een gerichte ingreep, zoals een passend beeldformaat, gereserveerde afbeeldingsruimte of minder onnodige code. Lazy-load geen hoofdbeeld dat direct nodig is. Een duurdere hostingvorm of CDN is niet automatisch de oplossing.

Vermijd algemene voorspellingen als “elke seconde kost zoveel procent omzet”. Die zeggen zonder passende onderzoekscontext niets over jouw website. Controleer daarnaast dat de wijziging formulieren, toestemming en andere noodzakelijke functies intact laat.

2. Een onjuiste HTTPS-inrichting

Controleer de geldigheid van het certificaat en of de bedoelde URL veilig bereikbaar is. Kijk ook welke bestanden de pagina gebruikt. De uitleg over mixed content beschrijft hoe onveilige bronnen binnen een HTTPS-pagina problemen kunnen veroorzaken. Een browserwaarschuwing is reden voor onderzoek, niet om de beveiliging uit te schakelen.

Leg vast welke URL of bron faalt, herstel de configuratie met de beheerder en test de gebruikersroute opnieuw. Voer een eventuele HTTP-naar-HTTPS-migratie uit met een gecontroleerde URL-mapping en passende redirects. Zet geen ingrijpende HSTS-instelling aan zonder te beoordelen welke hosts en herstelmogelijkheden worden geraakt.

3. Ontbrekende inhoud of onbruikbare bediening op mobiel

Een pagina kan binnen de schermbreedte passen en toch niet goed werken. Denk aan een contactbalk over een verzendknop of een menu dat niet met het toetsenbord bereikbaar is. Controleer meerdere schermmaten, grotere tekst, focus en echte handelingen, niet alleen een screenshot.

Google gebruikt de mobiele inhoud bij mobile-first indexing. Houd belangrijke informatie en links beschikbaar. Maak noodzakelijke hoofdinhoud niet afhankelijk van eerst klikken, swipen of typen om die op te halen. Een andere indeling of een uitklapsectie kan wel passend zijn wanneer de inhoud beschikbaar blijft.

4. Onbeoordeelde URL-varianten

Een trackingparameter, sortering of printweergave kan meerdere URL's voor vergelijkbare inhoud opleveren. Dat is niet automatisch een straf. Onderzoek welke varianten bestaan, waarom ze nodig zijn en welke pagina de beste voorkeursversie is. Een filterpagina met een eigen nuttige selectie vraagt een andere beoordeling dan een identieke kopie met alleen een campagneparameter.

Gebruik geen algemene opdracht om alle filters te noindexen of iedere taalversie naar de Nederlandse pagina te laten verwijzen. Canonicalisatie, crawlbeperking en indexatie zijn verschillende beslissingen. Maak per URL-groep een voorstel en controleer vóór uitvoering bestaande prestaties, links en functionele afhankelijkheden.

5. Een verkeerde bestemming of HTTP-status

Een interne link naar een verdwenen belangrijke pagina is een probleem voor de bezoeker. Maar een echt verwijderde pagina zonder passende vervanger mag een 404 of 410 teruggeven. Niet iedere 404 hoeft dus een redirect te krijgen. Een foutpagina met status 200 kan juist een soft-404-probleem opleveren.

De uitleg over HTTP-statuscodes onderscheidt ontbrekende inhoud van serverproblemen. Leg status, tijdstip en getroffen URL's vast. Controleer bij terugkerende serverfouten de oorzaak en niet alleen de foutmelding in een SEO-tool. Herstel verwijzingen naar bestaande eindbestemmingen; stuur verdwenen pagina's niet standaard naar de homepage.

6. Niet-passende alternatieve tekst

Het gaat om het alt-attribuut, niet om een verplichte verzameling zoekwoorden. Gebruik de W3C-beslisboom voor alt-tekst: beschrijf betekenisvolle afbeeldingen passend bij de context; decoratie kan een lege alt-tekst krijgen. Bij een functionele afbeelding moet de handeling of bestemming duidelijk zijn.

Een complexe grafiek heeft doorgaans meer uitleg nodig dan één korte alt-tekst. Zet de relevante informatie ook in gewone tekst of een toegankelijke tabel. Een vaste limiet van 125 tekens is geen algemene W3C-eis. Controleer of een foto werkelijk iets toevoegt voordat je de alt-tekst optimaliseert.

7. Onnodig ingewikkelde of inconsistente URL's

Voor nieuwe URL's zijn leesbare woorden, consistente schrijfwijzen en een begrijpelijke opbouw nuttig. Google geeft daarvoor URL-richtlijnen. Parameters zijn niet per definitie onbruikbaar; vooral onnodige combinaties kunnen veel varianten creëren. Er bestaat geen verplichte ideale lengte van drie tot vijf woorden.

Hernoem bestaande werkende URL's niet alleen om ze korter of mooier te maken. Zo'n wijziging vraagt onderzoek, een mapping, redirects en nacontrole. De URL-structuurgids helpt die afweging maken. Dit artikel verandert geen bestaande URL's of indexatie-instellingen.

8. Een sitemap die niet aansluit op de bedoelde pagina's

Een sitemap is een hulpmiddel voor ontdekking, geen indexatiegarantie. Controleer of hij de bedoelde canonieke URL's bevat en niet onbedoeld verouderde, verwijzende of uitgesloten pagina's opsomt. Laat de selectie aansluiten op je publicatieproces. Gebruik werkelijke belangrijke wijzigingen voor lastmod, niet automatisch de datum van iedere build.

Volgens Googles sitemapdocumentatie is de bovengrens per bestand 50.000 URL's of 50 MB ongecomprimeerd. Enkele duizenden URL's verplichten dus niet tot opsplitsen. Opsplitsen kan wel nuttig zijn voor beheer en controle. Dien geen extra sitemaptypen in zonder passende inhoud en een duidelijk doel.

9. Tegenstrijdige crawl- en indexatie-instructies

Robots.txt beheert crawltoegang. Een disallow-regel garandeert niet dat de URL uit zoekresultaten verdwijnt. Voor noindex moet Google de instructie op de pagina of in de HTTP-header kunnen lezen. Een gelijktijdige crawlblokkade kan dat verhinderen.

Controleer daarom robots.txt, meta robots, X-Robots-Tag en eventuele toegangsbeperking apart. Verwijder niet blind alle blokkades: sommige horen bij privé- of beheerpagina's. Bewaar het bedoelde beleid per omgeving. Een afgeschermde preview hoeft niet openbaar te worden om een SEO-check te doorstaan.

10. Canonicals die de verkeerde voorkeur aangeven

Een canonical is een signaal bij dubbele of sterk vergelijkbare inhoud. Google kan een andere versie kiezen. Controleer of de opgegeven bestemming bestaat, inhoudelijk past en aansluit op interne links en sitemap. Het ontbreken van een canonical is niet automatisch een kritieke fout.

Een voorkeursversie kan naar zichzelf verwijzen; duplicaten verwijzen naar die voorkeursversie. Zet dus niet op iedere variant automatisch een self-canonical. Absolute URL's zijn aanbevolen; relatieve canonicals zijn niet per definitie onleesbaar. Onderzoek bij een onverwachte keuze eerst de betrokken varianten en andere signalen.

Aanvullend: markup die niet klopt met de pagina

Controleer structured data op syntax én feiten. Een auteursnaam, prijs, review of afbeelding moet passen bij wat bezoekers zien. De algemene structured-data-richtlijnen maken dat onderscheid expliciet. Een geslaagde Rich Results Test belooft geen speciale zoekweergave of hogere klikfrequentie.

Gebruik geen oude checklist waarin FAQ-dropdowns als gegarandeerde opbrengst staan. De FAQ-rich-resultfunctie is beëindigd. Laat nuttige vragen en antwoorden voor lezers staan, maar corrigeer de verkoopbelofte en beoordeel alleen markup die werkelijk bij de pagina past.

Aanvullend: redirects die niet bij de situatie passen

Een lus is een fout; een extra tussenstap vraagt beoordeling en kan vaak worden vereenvoudigd. Kies volgens Googles redirectuitleg een permanente of tijdelijke redirect passend bij de wijziging. Niet iedere verplaatsing vraagt dus dezelfde statuscode.

Werk belangrijke interne links bij naar de echte eindbestemming. Test bij een migratie de oude URL, iedere tussenstap en het uiteindelijke antwoord. Bewaar de mapping en controleer ook uitzonderingen. Ken niet aan iedere extra stap een verzonnen vast verliespercentage toe.

Prioriteit volgt uit bereik en gevolgen

Onderstaande indeling is een praktisch besliskader, geen meting van rankinggewichten. Bepaal het aantal getroffen belangrijke pagina's, het gebruikersprobleem, de zekerheid over de oorzaak en de risico's van herstel.

Een melding beoordelen vóór je een deadline kiest

Situatie	Eerste actie	Waarom?
Belangrijke openbare route valt uit	Incident bevestigen en beheerder betrekken.	Bezoekers kunnen hun taak niet afronden.
Template bevat een onbedoelde indexatie-instructie	Scope en bedoeld beleid vastleggen vóór herstel.	Eén wijziging kan veel pagina's raken.
Herhaalbare prestatie- of bedieningsfout	Oorzaak isoleren en een hertest afspreken.	Een algemene score noemt niet de juiste ingreep.
Waarschuwing zonder aangetoond nadeel	Context onderzoeken en eventueel bewust laten staan.	Veranderen heeft ook kosten en risico's.

Werkvoorbeeld: een canonicalfout herstellen

Fictief voorbeeld: in een testomgeving verwijst de canonical van meerdere verschillende diensten naar dezelfde homepage. Er zijn geen echte klantgegevens, gevonden aantallen of rankingresultaten ingevuld.

Van vermoeden naar gecontroleerde vrijgave

Stap	Wat leg je vast?
Reproduceren	Voorbeeld-URL's, bron-HTML, opgegeven canonical en verwacht doel.
Oorzaak toetsen	Is de homepage hardcoded in het template of komt het doel uit verkeerde CMS-data?
Herstel begrenzen	Alleen het betreffende template aanpassen; duplicaten en privépagina's niet automatisch wijzigen.
Accepteren	Per bedoelde openbare pagina één passende canonical; interne links en sitemap consistent.
Nacontrole	Juiste deployment controleren en Google's latere waarneming afzonderlijk volgen.

1. Bewijs. Maak het probleem herhaalbaar met een concrete URL.
2. Besluit. Leg doel, eigenaar en risico vast.
3. Test. Controleer de oplossing eerst in een passende preview.
4. Hertest. Verifieer de gepubliceerde versie en bewaak terugkeer.

Een release kan technisch geslaagd zijn terwijl Google de pagina nog niet opnieuw heeft verwerkt. Rapporteer die toestanden apart. Bekijk voor een bredere aanpak de technische auditwerkwijze of bespreek technische SEO-uitvoering. Een adviesgesprek helpt scope, toegang en verantwoordelijkheden afbakenen; een offerte blijft op maat.

Veelgestelde vragen

Hoe ontdek ik technische fouten?

Combineer concrete gebruikersmeldingen, een gerichte crawl, browsercontroles en beschikbare Search Console-gegevens. Bewaar URL, datum en reproductiestappen zodat iemand anders de bevinding kan toetsen.

Welke fout is altijd het belangrijkst?

Er is geen vaste rangorde voor iedere website. Een uitgevallen aanvraagroute of onbedoelde templateblokkade kan dringend zijn; een bewuste 404 hoeft geen herstel te vragen.

Moet iedere 404 worden geredirect?

Nee. Een werkelijk verdwenen pagina zonder relevante vervanger mag een 404 of 410 geven. Herstel wel interne links die bezoekers daar ten onrechte naartoe sturen.

Mag ik alle robotsblokkades verwijderen?

Nee. Controleer eerst welk beleid is bedoeld en of privé-inhoud wordt geraakt. Robots.txt, noindex en toegangsbeveiliging hebben verschillende functies.

Moet iedere pagina naar zichzelf canonicaliseren?

Nee. De voorkeursversie kan naar zichzelf wijzen; een duplicaat verwijst naar die voorkeursversie. Vergelijkbare en daadwerkelijk verschillende pagina's vragen een eigen beoordeling.

Hoe snel herstellen rankings?

Daarvoor bestaat geen vaste termijn. Een technische hertest, een nieuwe crawl en veranderingen in zoekresultaten zijn verschillende gebeurtenissen. Relevantie en andere factoren blijven meespelen.

Kan ik dit zelf repareren?

Een losse verkeerde link is vaak af te bakenen. Wijzigingen aan templates, beveiliging en indexatie vragen kennis van de gevolgen, een testomgeving en een herstelmogelijkheid.

Is een geslaagde schematest genoeg?

Nee. Een test controleert niet alle inhoudelijke juistheid en geeft geen weergavegarantie. Vergelijk de markup met de zichtbare pagina en de actuele regels voor het gebruikte type.

Hoe voorkom ik herhaling?

Voeg de gevonden fout toe aan passende regressietests en releasecontroles. Leg vast wie waarschuwingen beoordeelt, welke wijzigingen extra controle vragen en hoe herstel verloopt.