Een soft 404 herkennen zonder pagina's te raden

Een gewone 404 meldt via de HTTP-status dat de pagina niet bestaat. Een soft 404 meldt via de status 200 dat alles goed is, terwijl de inhoud iets anders zegt: een lege productpagina, een zoekresultaat zonder items of een melding als 'product niet gevonden' in een gewoon sjabloon. Het probleem zit dus in de combinatie van twee signalen die elkaar tegenspreken.

Je moet daarom altijd twee dingen naast elkaar leggen: wat de server antwoordt en wat een bezoeker ziet. Alleen kijken naar het scherm mist het statusdeel, alleen naar de status mist de lege inhoud. Noteer beide per URL, dan hoef je nooit te raden.

Let op een grens: een pagina met weinig tekst is niet automatisch een soft 404. Een bewust korte pagina met een duidelijk doel valt hier niet onder. De test is of de inhoud nog iets bruikbaars biedt voor wie de URL opent.

Begin niet met willekeurige adressen, maar met URL's waarvan je al weet dat ze verdacht zijn. Zoals de Search Console-documentatie beschrijft op Aan de slag met Search Console, geeft het indexeringsoverzicht een beeld van pagina's die Google wel of niet kon indexeren en meldt het fouten en waarschuwingen. Gebruik dat overzicht als startlijst. De exacte rapportnaam en weergave kunnen wijzigen, controleer dus in je eigen Search Console wat je account toont.

1. Exporteer of kopieer de URL's met een melding over fouten of uitsluiting uit het indexeringsrapport.
2. Voeg uit je eigen systeem de verwijderde of uitverkochte producten toe, en de slugvarianten die je intern of in oude links nog tegenkomt.
3. Open elke URL en noteer de HTTP-status, bijvoorbeeld via de netwerktab van je browser of een headercontrole.
4. Noteer in een aparte kolom wat er zichtbaar is: volledige productinfo, lege shell, foutmelding of omleiding.

Een browsercontrole zegt iets over wat een bezoeker krijgt, niet over crawltoegang voor Google. Voor een uitspraak over Google gebruik je zo nodig de URL-inspectie in Search Console.

Bij sites die de inhoud met JavaScript opbouwen, kan de eerste HTML nagenoeg leeg zijn en de echte inhoud pas later verschijnen. Volgens de uitleg over de basis van JavaScript en zoekmachines verwerkt Google zulke pagina's in fasen: crawlen, renderen en indexeren, en pagina's met status 200 komen in aanmerking voor rendering. Een foutmelding die pas na het renderen verschijnt, kan dus samengaan met een 200-status. Of Google zo'n pagina ook als soft 404 behandelt, volgt niet uit deze bron en controleer je per URL in de URL-inspectie.

Vergelijk daarom twee versies van dezelfde URL: de ruwe HTML-respons en het resultaat nadat het script gelopen heeft. Staat in de ruwe HTML een leeg sjabloon en komt de melding 'niet beschikbaar' pas later, dan is dat een kandidaat voor een soft 404.

1. Bekijk de ruwe bron van de pagina en zoek naar echte productgegevens.
2. Bekijk daarna de gerenderde pagina en zoek naar foutmeldingen of een leeg overzicht.
3. Controleer of de statuscode in beide gevallen 200 is.

Gebruik voor de uitspraak over wat Google zag de URL-inspectie op een URL die Google al kent, niet alleen je eigen browser.

Gebruik deze matrix om per gevonden URL een eigen keuze te maken. Het is een beslishulp voor je eigen situatie, geen universele regel.

Verwijder een uitverkocht product dus niet automatisch. Behoudt de pagina waarde voor wie er via een link of zoekopdracht terechtkomt, dan blijft ze beter bestaan. Een 404 of 410 geeft geen gegarandeerd verschillend verwerkingstempo bij Google, kies er dus een op basis van wat klopt, niet op basis van verwachte snelheid.

Als meerdere URL's dezelfde of bijna dezelfde inhoud tonen, kun je Google een voorkeur doorgeven. De documentatie over het opgeven van een canonieke URL noemt een redirect als sterk signaal, een rel="canonical"-link ook als sterk signaal en opname in de sitemap als zwak signaal. Een canonical is dus een aanwijzing, geen bevel: Google kan een andere URL kiezen.

Wil je dat een bezoeker nooit op de verkeerde slug blijft staan, dan is een redirect logischer. Wil je beide adressen laten bestaan maar één voorkeur aangeven, dan past een canonical. Productvarianten, zoals maten of kleuren, vragen een eigen inhoudelijke keuze: zijn ze echt verschillende producten, dan hoort elk een eigen URL; zijn het gewoon opties van één product, dan kan consolidatie zinvol zijn.

De bron raadt ook af om robots.txt of noindex te gebruiken om een canonical te regelen. Robots.txt blokkeert crawlen, maar garandeert geen verwijdering uit de index. Wil je zien welke URL Google als canonical koos, lees dat dan uit de URL-inspectiedata van een geïndexeerde pagina, niet uit de live test.

Na een aanpassing controleer je opnieuw wat je eerder vastlegde. Verwacht geen vaste termijn of resultaat: het opnieuw verwerken door Google is onzeker. Je kunt wel zelf nagaan of de technische staat klopt.

Fictief voorbeeld. Een webwinkel heeft drie URL's op de lijst: (A) een definitief verdwenen product zonder vervanger dat nu een leeg sjabloon met status 200 toont, (B) een uitverkocht product met volledige beschrijving en een melding 'tijdelijk niet beschikbaar', (C) dezelfde productpagina bereikbaar via een slug met hoofdletter. Verwachte technische controles: bij A geeft de URL na aanpassing een echte foutstatus met nuttige navigatie; bij B blijft status 200 en wordt de uitverkocht-melding en een alternatief getoond; bij C gebeurt een redirect naar de gewone slug of staat een canonical naar die slug. Hoofdletters of URL-opbouw zijn op zichzelf geen bewezen rankingfactor, het gaat om het ontdubbelen.

1. Haal opnieuw de HTTP-status op voor A, B en C.
2. Open elk resultaat en vergelijk de zichtbare inhoud met je tabel.
3. Gebruik URL-inspectie voor de geïndexeerde versie en lees de door Google gekozen canonical.
4. Controleer later opnieuw in je indexeringsrapport of de meldingen voor deze URL's veranderd zijn, zonder een vaste termijn te verwachten.

Wil je daarnaast de publiek zichtbare signalen van je eigen website bekijken, dan kan dat via Marketing Scan. Een publieke scan meet wat zichtbaar is en bewijst geen volledige technische implementatie, en de controles in dit artikel voert onze scan niet allemaal uit.