Een URL die een HTTP-foutcode oplevert, wijst niet altijd op hetzelfde probleem. De oorzaak, de impact op de indexering en de aanpak verschillen sterk tussen een verkeerd geformuleerd verzoek (400), een verwijderde pagina (404) en een overbelaste server (503). Door de verschillen tussen deze codes in kaart te brengen, kun je herstelwerk prioriteren en de schade aan de vindbaarheid beperken.
HTTP-foutcodes: verschil in impact tussen de 4xx- en 5xx-families
Het eerste cijfer van de statuscode geeft aan aan welke kant het probleem zit. De 4xx- en 5xx-families hebben een heel verschillende impact op het crawlen van een website door Google-robots.
| Code | Familie | Oorzaak van het probleem | Gevolg voor de indexering |
|---|---|---|---|
| 400 | 4xx (client) | Verkeerd geformuleerde URL, niet-gecodeerde tekens, ontbrekende parameter | Pagina wordt behandeld als niet-bestaand en na enkele pogingen uit de index verwijderd |
| 403 | 4xx (client) | Toegang geweigerd door de server (machtigingen, .htaccess) | Pagina wordt niet geïndexeerd zolang de toegang geblokkeerd blijft |
| 404 | 4xx (client) | Pagina verwijderd, URL gewijzigd zonder omleiding, kapotte link | Pagina wordt geleidelijk uit de index verwijderd |
| 500 | 5xx (server) | Interne fout: defect script, beschadigde configuratie | De crawl van de hele website wordt vertraagd |
| 502 | 5xx (server) | Ongeldig antwoord ontvangen door de proxy of gateway | Hetzelfde als bij 500: de crawl wordt vertraagd |
| 503 | 5xx (server) | Server niet beschikbaar (onderhoud, overbelasting) | De crawl wordt opgeschort; geïndexeerde pagina’s kunnen worden verwijderd als de fout aanhoudt |
Onthoud vooral dit: een aanhoudende 5xx-fout kan ertoe leiden dat al geïndexeerde pagina’s worden verwijderd. Een afzonderlijke 404 heeft daarentegen geen merkbare gevolgen voor de rest van de website.
Google geeft aan dat 5xx- en 429-antwoorden zijn crawlers tijdelijk afremmen. Als het probleem aanhoudt, breidt de impact zich uit naar andere URL’s op dezelfde host. In een uitgebreide gids lees je hoe je een ongeldige server-URL corrigeert door de verschillende codefamilies nauwkeurig van elkaar te onderscheiden.
Fout in robots.txt: het geval dat het crawlen van een hele website blokkeert
Concurrenten besteden zelden aandacht aan dit scenario, hoewel het de grootste schade kan veroorzaken. Een 5xx-antwoord op het robots.txt-bestand schort het crawlen van de hele host op. Google probeert dit bestand op te halen voordat elke crawlsessie begint. Krijgt het een serverfout, dan crawlt het liever niets dan het risico te lopen verboden pagina’s te bezoeken.
De diagnose begint dus bij dit bestand. De toegankelijkheid ervan controleren kost maar een paar seconden met een rechtstreeks verzoek in de browser (uwdomein.com/robots.txt). Als de pagina een 200-code met leesbare inhoud teruggeeft, ligt het probleem ergens anders.
Wanneer de proxy de werkelijke oorzaak verbergt
Een 502- of 504-fout op robots.txt kan worden veroorzaakt door een tussenliggende partij (reverse proxy, CDN) en niet door de applicatieserver. Om de bron vast te stellen, moet je de communicatie tussen de proxy en de upstreamserver onderzoeken. De proxylogs (Nginx, Varnish, Cloudflare) laten zien of het verzoek de oorspronkelijke server heeft bereikt of onderweg is verlopen.
Een proxy-time-out verwarren met een storing in de applicatie leidt tot onnodige aanpassingen aan de code, terwijl het probleem in de netwerkconfiguratie zit.
Ongeldige URL’s opsporen: methoden en tools combineren
Eén tool is niet voldoende. Elke bron biedt een ander perspectief op de detectie. Door ze te combineren, voorkom je blinde vlekken.
- Het rapport ‘Crawlstatistieken’ in Google Search Console toont hoe vaak Googlebot fouten tegenkomt, om welk type het gaat (5xx, 404, DNS-time-out) en hoe dit in de loop van de tijd verandert. Dit is het perspectief van de zoekmachine.
- De serverlogs (access.log, error.log) geven de ruwe details: IP-adres van de client, opgevraagde URL, teruggestuurde code en exact tijdstip. Zo kun je foutpieken opsporen die verband houden met een implementatie of overbelasting.
- Een crawler zoals Screaming Frog of Sitebulb doorloopt de website via interne links en meldt elke URL die een afwijkende code teruggeeft. De tool detecteert ook kapotte links in de interne linkstructuur, die niet zichtbaar zijn in Search Console.
Search Console combineren met serverlogs is de betrouwbaarste methode. Search Console meldt welke URL’s Google niet kon bereiken; de logs laten zien waarom en wanneer de server de fout heeft teruggegeven.
DNS-fout of time-out: valse positieven onderscheiden
Een DNS-probleem betekent niet dat de server uit de lucht is. De DNS-server kan tijdelijk onbereikbaar zijn terwijl de website normaal werkt. Google meldt deze gevallen in Search Console onder ‘DNS-fout’. Controleer de DNS-resolutie met een tool zoals dig of nslookup voordat je iets aan de applicatiekant wijzigt, zodat je deze mogelijkheid kunt uitsluiten.
Serverfouten oplossen: prioriteren op basis van code en duur
Niet elke fout vereist dezelfde urgentie. Een tijdelijke 503 met een Retry-After-header is minder ernstig dan een permanente 500 op een pagina met veel organisch verkeer.
Gepland onderhoud en de Retry-After-header
De HTTP-standaard staat toe dat een server een 503-antwoord geeft met een Retry-After-header om robots te laten weten wanneer ze terug moeten komen. Zonder deze header behandelt Google de 503 als een gewone storing en vertraagt het de crawl, zonder te weten wanneer het opnieuw moet proberen. Door deze header toe te voegen tijdens gepland onderhoud, beperk je de gevolgen voor de indexering.
301-omleidingen voor terugkerende 404-fouten
Een verwijderde pagina die inkomende links ontving, verliest al haar SEO-waarde als ze een 404 blijft geven. Met een 301-omleiding naar de meest relevante pagina wordt het grootste deel van de waarde overgedragen. Alle 404’s naar de homepage omleiden werkt daarentegen averechts: Google negeert zulke algemene omleidingen uiteindelijk.
Maak je keuze op basis van twee gegevens: het aantal inkomende links naar de URL met de fout (via Search Console of Ahrefs) en het verkeersvolume dat de pagina vóór verwijdering genereerde. URL’s zonder links en zonder verkeer kunnen zonder gevolgen een 404 blijven geven.
De belangrijkste conclusie: aanhoudende 5xx-fouten beïnvloeden het crawlen van de hele website, terwijl 4xx-fouten beperkt blijven tot de betreffende pagina. De toegankelijkheid van robots.txt controleren en de Search Console-rapporten vergelijken met de serverlogs zijn de twee controles die je bij elk incident als eerste moet uitvoeren.
