Crawlfouten oplossen op basis van oorzaak en gevolgen

Een crawlfout is een probleem waardoor een crawler een aangevraagde bron niet goed kan ophalen of verwerken. Denk aan een serverstoring, een onbereikbare host, een redirectlus of een onbedoelde foutstatus. Niet iedere niet-geïndexeerde URL is een crawlfout: bewuste uitsluitingen en dubbele versies vragen een andere beoordeling.

Werk van oorzaak naar gevolg. Controleer eerst of belangrijke openbare pagina's bereikbaar zijn, daarna of statuscodes en instructies kloppen. Prioriteer op de functie van de getroffen pagina's en de omvang van de storing, niet uitsluitend op het aantal meldingen in een rapport.

Maak van een melding een controleerbare vraag

Noteer de exacte URL, het tijdstip of de rapportperiode, de bron van de melding en het verwachte gedrag. “SEO geeft fouten” is niet onderzoekbaar. “De dienstpagina hoort 200 terug te geven, maar retourneert sinds de verhuizing 404” is dat wel.

Vergelijk een rapportmelding met de actuele serverrespons. Search Console kan een eerdere toestand tonen; een browser kan door caching juist een oudere succesvolle versie laten zien. De gids over Search Console gebruiken helpt die waarnemingen uit elkaar houden. Bewaar ook een voorbeeld van een pagina die wel werkt, zodat u verschillen in sjabloon, host of route kunt vergelijken.

Onderscheid serverproblemen van paginafouten

Een 5xx-status wijst op een probleem aan de serverkant. Een 404 betekent dat de gevraagde bron niet gevonden is. Een 403 kan wijzen op een toegangsbeperking. DNS- of verbindingsproblemen kunnen voorkomen dat er überhaupt een HTTP-respons ontstaat.

Google beschrijft de gevolgen in HTTP-statuscodes, netwerk- en DNS-fouten. Gebruik die uitleg om uw beheerder gerichte vragen te stellen. Een tijdelijke capaciteitsstoring vraagt bijvoorbeeld een andere oplossing dan een foutieve slug. Verander niet alvast alle pagina-inhoud als de server de bestaande pagina's simpelweg niet kan afleveren.

Een fictieve triage van een foutenlijst

Een fictieve praktijk ziet 80 gemelde adressen. Het overzicht bestaat uit twee actuele dienstpagina's met een serverfout, achttien oude verwijderde artikelen en zestig parameter-URL's die bewust geen aparte publicatie zijn. Er is geen echte audit uitgevoerd.

De praktijk behandelt eerst de twee dienstpagina's: bezoekers kunnen hun belangrijkste vraag daar niet afronden. Vervolgens controleert zij of de achttien artikelen terecht verdwenen zijn en of er relevante vervangers bestaan. Ten slotte onderzoekt zij waarom de parameter-URL's nog intern worden gegenereerd.

Het aantal zestig bepaalt dus niet automatisch de hoogste prioriteit. De gebruikersfunctie, de gewenste indexeerbaarheid en de oorzaak wegen zwaarder dan de grootste groep in een export.

Herstel 404’s alleen wanneer dat inhoudelijk klopt

Een verwijderde pagina zonder vervanger mag 404 of 410 teruggeven. Maak haar niet kunstmatig succesvol om een rapport groener te maken. Een echte foutpagina kan navigatie en een zoekmogelijkheid bieden, zolang de status eerlijk blijft.

Bij een verhuisde pagina gebruikt u een passende redirect. Werk daarna ook de oude interne links bij. Een externe verwijzing naar een niet-bestaand, verkeerd gespeld adres vraagt soms een eigen regel, maar bouw geen onbeheersbare verzameling uitzonderingen voor willekeurige botpaden. Controleer of het oude adres werkelijk betekenis of gebruik had voordat u onderhoud toevoegt.

Onderzoek soft 404’s en lege sjablonen

Een soft 404 kan ontstaan wanneer een pagina een succesvolle status geeft maar inhoudelijk een foutmelding, leeg resultaat of vrijwel geen bruikbare inhoud toont. Google kan zo'n pagina als fout behandelen. Een voorbeeld is een productroute die “niet gevonden” zegt terwijl de server 200 teruggeeft.

Controleer of de inhoud tijdelijk ontbreekt door een laadfout of definitief verdwenen is. Herstel in het eerste geval de aflevering; gebruik in het tweede geval een passende status of vervanger. Kopieer niet wat algemene tekst op de pagina om haar langer te maken. Het probleem is de onduidelijke bestemming, niet een verplicht minimumaantal woorden.

Controleer blokkades, scripts en beschermlagen

Een crawler kan door robotsregels, een firewall of een onbedoelde beveiligingsuitdaging worden tegengehouden. Ga zorgvuldig na welke laag de beperking veroorzaakt. Een gewone bezoeker die ingelogd is, bewijst niet dat de openbare pagina zonder sessie bereikbaar is.

Bekijk robots.txt en het gedrag zonder cookies. Controleer daarnaast noodzakelijke scripts en afbeeldingen als de inhoud via rendering ontstaat. Google's gids voor JavaScript-SEO-problemen beschrijft relevante aandachtspunten. Zet beveiliging niet algemeen uit om een melding te laten verdwijnen. Vraag om een gerichte oplossing die de bedoelde openbare inhoud beschikbaar maakt.

Bewijs het herstel op meerdere niveaus

Controleer eerst de oorspronkelijke fout: reageert dezelfde URL nu zoals bedoeld? Controleer daarna de volledige gebruikersroute en enkele vergelijkbare pagina's. Een wijziging aan één sjabloon kan elders nieuwe fouten veroorzaken. Bij een redirect bekijkt u ook de eindbestemming en mogelijke ketens.

Noteer de herstelactie en datum. Verwacht niet dat alle rapporten direct bijwerken. Een actuele live controle kan correct zijn terwijl de indexeringsrapportage nog een eerdere toestand bevat. Maak dat onderscheid in uw controle na publicatie expliciet. “Serverrespons hersteld” is preciezer dan “SEO opgelost”, omdat indexering en prestaties nog apart moeten worden beoordeeld.

Houd een klein register van terugkerende oorzaken

Bewaar per probleem een voorbeeldadres, oorzaak, getroffen paginatype, oplossing, verantwoordelijke en preventieve controle. U hoeft geen volledige bezoekerslogs te kopiëren om een routefout te documenteren. Vermijd klantgegevens en geheime parameters in gedeelde notities.

Zo'n register maakt patronen zichtbaar: fouten na iedere import, verwijderde producten die als lege pagina blijven staan of een ontwikkelinstelling die telkens terugkeert. Plan vervolgens een controle op de oorzaak in plaats van dezelfde lijst maandelijks handmatig schoon te maken. Het doel is een betrouwbare website voor gebruikers en crawlers, niet een dashboard zonder enige uitgesloten URL.

Leg bij een terugkerende fout ook het moment in het beheerproces vast: direct na publiceren, pas na cacheverversing of alleen bij een bepaalde import. Dat helpt een technisch verantwoordelijke de oorzaak reproduceren. Noteer feitelijke omstandigheden, geen geheime sleutels of persoonlijke sessiegegevens. Een herhaalbaar voorbeeld is vaak bruikbaarder dan een grote ongesorteerde export met meldingen.

Bronnen en verder lezen

Google Search Central beschrijft HTTP-, netwerk- en DNS-fouten en het oplossen van JavaScript-SEO-problemen. De fictieve triage is een prioriteitsoefening, geen claim over gemeten impact.