U verwijdert een productpagina, u verandert de structuur van uw URL’s, of u migreert naar een nieuw CMS. Enkele weken later toont Google Search Console tientallen 404-fouten. De klassieke reflex is om ze allemaal naar de homepage te redirecten. Dit is een valse goede idee die andere problemen creëert.
Soft 404 en klassieke 404: de onderscheid dat uw SEO-strategie verandert
Een klassieke 404-fout retourneert een HTTP-code 404 (of 410) naar de browser en Googlebot. De server zegt duidelijk: deze pagina bestaat niet meer. Google begrijpt het signaal, verwijdert de URL geleidelijk uit zijn crawlschema en gaat verder.
De echte val zit ergens anders. Een soft 404 retourneert een code 200 OK terwijl de pagina leeg is of een foutmelding weergeeft. Vanuit het perspectief van Google lijkt deze URL te bestaan. De bot blijft deze dus bij elk bezoek bekijken, wat onnodig crawlbudget verbruikt.
Op een site met enkele tientallen pagina’s is het verschil verwaarloosbaar. Op een e-commercecatalogus of een redactionele site met duizenden URL’s vertragen de verzamelde soft 404’s de verkenning van de pagina’s die er echt toe doen. Voordat u begint met corrigeren, is de prioriteit om te weten hoe een 404-fout op Google te corrigeren door deze twee gevallen te onderscheiden.
Sites die zijn gebouwd met JavaScript-frameworks (React, Vue, Angular) zijn bijzonder kwetsbaar. Wanneer een route niet bestaat, toont de applicatie een “pagina niet gevonden” bericht aan de clientzijde, maar de server retourneert een code 200. Google behandelt dit gedrag als een soft 404, en de pagina blijft in de crawlwachtrij.
Sorteren van uw 404-fouten voordat u ze corrigeert: prioriteringsmethode
Niet alle 404-fouten verdienen dezelfde behandeling. Een URL die nooit externe links heeft ontvangen, nooit verkeer heeft gegenereerd en die overeenkomt met verouderde inhoud kan 404 blijven zonder enige SEO-schade. Google bevestigt dit: legitieme 404’s maken deel uit van de normale werking van het web.
Heeft u het rapport “Pagina’s” van Google Search Console al bekeken zonder te weten waar te beginnen? Hier is hoe u uw 404’s op prioriteit kunt rangschikken:
- De URL’s die nog steeds externe backlinks ontvangen: zij dragen autoriteit over. Zonder redirect verdwijnt dit SEO-kapitaal. Identificeer ze door de gegevens van Search Console te combineren met een crawltool.
- De URL’s die organisch verkeer genereerden voordat ze werden verwijderd: een 301-redirect naar de meest relevante pagina qua inhoud kan een deel van dit verkeer terugwinnen.
- De URL’s die voortkomen uit typfouten, bots of onjuiste URL-parameters: laat ze in 404. Het redirecten van deze URL’s zou onnodige redirects creëren die uw serverconfiguratie verzwaren.
Prioriteer de 404’s die backlinks of historische verkeer hebben. De rest kan wachten, of nooit worden behandeld.
301-redirects en code 410: de juiste HTTP-respons kiezen
De 301-redirect is de standaard reflex. Het werkt goed wanneer er een equivalente pagina op de site bestaat. Heeft u een categorie hernoemd of twee artikelen samengevoegd? De 301 draagt het grootste deel van de autoriteit van de links over naar de nieuwe URL.
Wanneer de 301-redirect problemen veroorzaakt
Een oude productpagina naar de homepage redirecten helpt niemand. De gebruiker komt op een pagina die niets met zijn zoekopdracht te maken heeft, en Google behandelt deze redirect uiteindelijk als een soft 404. Een 301-redirect moet naar inhoud die thematisch dichtbij is verwijzen, niet naar een generieke pagina.
De code 410 om een permanente verwijdering aan te geven
De HTTP-code 410 (Gone) geeft Google aan dat de pagina opzettelijk is verwijderd en niet terug zal komen. Google de-indexeert deze URL’s sneller dan met een eenvoudige 404. Gebruik de 410 voor definitief verwijderde productpagina’s, juridisch problematische inhoud, of test-URL’s die nooit geïndexeerd hadden moeten worden.
De 410 versnelt de de-indexering in vergelijking met de klassieke 404. Op een site met een groot volume aan verwijderde pagina’s maakt dit snel vrij crawlbudget.
Aangepaste 404-pagina: een fout omzetten in nuttige navigatie
Zelfs met rigoureus redirectwerk zullen bezoekers op niet-bestaande pagina’s terechtkomen. Een link gedeeld op een forum, een URL die uit het hoofd verkeerd is getypt: de nul 404 bestaat niet.
Een aangepaste 404-pagina lost het technische probleem niet op, maar beperkt het verlies van gebruikers. Om nuttig te zijn, moet deze aanbieden:
- Een onmiddellijk zichtbare interne zoekbalk, zonder te hoeven scrollen.
- Links naar de belangrijkste categorieën of de meest bekeken inhoud van de site.
- Een duidelijke boodschap die bevestigt dat de pagina niet bestaat, zonder technische jargon.
Het technische punt dat u niet mag missen: uw aangepaste 404-pagina moet een echte HTTP-code 404 retourneren. Als uw server of CMS een code 200 retourneert voor deze pagina, creëert u precies het soft 404-probleem dat hierboven is beschreven. Test de responscode met de URL-inspectietool in Search Console.
404-fouten op een JavaScript-site: controleer de server-side rendering
Single Page Applications (SPA) beheren de navigatie aan de clientzijde. Wanneer een bezoeker toegang krijgt tot een route die niet bestaat, toont het framework een “fout” component zonder dat de server ingrijpt. De HTTP-code blijft 200.
Om ervoor te zorgen dat Googlebot de situatie correct interpreteert, moet de 404-respons van de server komen. Twee benaderingen werken: server-side rendering (SSR) die de pagina genereert met de juiste HTTP-code voordat deze naar de browser wordt gestuurd, of statische pre-rendering die HTML-bestanden met de juiste headers produceert.
Een “pagina niet gevonden” bericht weergegeven door JavaScript met een code 200 wordt door Google behandeld als een soft 404. Controleer de werkelijke statuscode in het Netwerk-tabblad van de ontwikkeltools van uw browser, of rechtstreeks via Search Console.
Op een klassieke site onder WordPress of een vergelijkbaar CMS doet dit probleem zich doorgaans niet voor: de server beheert van nature de 404-code. De waakzaamheid betreft vooral decoupled architecturen (headless CMS + JavaScript frontend).
