Soft 404-fouten: wat ze zijn en hoe je ze oplost

Kort antwoord: Een soft 404 is een pagina die bezoekers “niet gevonden” toont (of vrijwel niets), maar met de successtatus 200 antwoordt in plaats van met 404. Google behandelt zulke pagina’s als fouten: wijst de inhoud van een 2xx-antwoord op een fout, dan meldt Search Console een soft 404. De oplossing is dat de server de status stuurt die bij de waarheid past: 404 of 410 voor pagina’s die weg zijn, een 301 naar een gelijkwaardige pagina voor pagina’s die zijn verhuisd, en echte inhoud voor pagina’s die er hoort te zijn.

Wat is een soft 404?

Elk antwoord van een webserver begint met een statuscode, en die komt vóór alle inhoud. 200 betekent “oké, hier is de pagina”. 404 betekent “hier is niets”. Een soft 404 is een tegenstrijdigheid tussen die twee: de pagina op het scherm zegt “niet gevonden” of “0 resultaten” of toont niets wat het lezen waard is, maar de status is 200.

Google beschrijft dit geval in de documentatie over HTTP-statuscodes en netwerkfouten. Bij een 2xx-antwoord houdt Google rekening met de inhoud. Wijst die inhoud op een fout, bijvoorbeeld een lege pagina of een foutmelding, dan toont Search Console een soft 404-fout. Bij een echte 4xx-status gebruikt Google de inhoud van de URL helemaal niet.

In een terminal zie je het verschil. Op een site met dit probleem geeft een verzoek naar een adres dat niet bestaat dit resultaat (het adres is een voorbeeld):

$ curl -s -o /dev/null -w "%{http_code}\n" https://jouw-site.example/pagina-bestaat-niet
200

Het juiste antwoord is 404. Een bezoeker ziet in beide gevallen dezelfde vriendelijke tekst “Pagina niet gevonden”. Alleen de status verschilt, en de status is het eerste wat een crawler leest.

Het woord “soft” betekent niet “mild”. Het betekent dat de server zegt dat alles in orde is, terwijl de pagina zegt dat dat niet zo is.

Waarom is een soft 404 een probleem?

Dit is wat gedocumenteerd is en wat niet.

Gedocumenteerd:

• Search Console toont zo’n URL als soft 404-fout, dus Google zelf ziet er een probleem in.
• Bij een echte 404 of 410 gebruikt Google de inhoud van de URL niet. Bij een 200 laat je het aan Google over om aan de hand van de inhoud te raden of de pagina een fout is.

Niet gedocumenteerd: een direct effect op rankings. Google noemt de fout in zijn rapport. Het zegt niet dat een soft 404 andere pagina’s van je site omlaag haalt, en we vonden geen bron die dat bewijst. Wees dus op je hoede bij beweringen als “soft 404’s maken je SEO kapot”.

Onze inschatting, en niet meer dan dat: een pagina zonder waarde hoort niet als resultaat aangeboden te worden, en de oplossing kost weinig. Er is ook een praktische kant die niets met Google te maken heeft: linkcheckers en uptimemonitors lezen statuscodes. Als elk adres met 200 antwoordt, kunnen ze je niet vertellen dat een link kapot is, en bezoekers die een oude link volgen, horen nooit dat de pagina weg is.

Wat veroorzaakt een soft 404?

Soft 404’s ontstaan meestal door patronen als deze:

• Een single-page-app die elk pad met hetzelfde omhulsel beantwoordt. De server stuurt de app, met status 200, voor elk adres. Pas nadat het JavaScript is uitgevoerd, staat er “niet gevonden” op het scherm. De status was op dat moment al bepaald, en die is 200. Google verwerkt zulke pagina’s in stappen (crawlen, renderen, indexeren), en een pagina met status 200 komt in de wachtrij voor rendering. Googles JavaScript-basics leggen het model uit. Crawlers die scripts misschien helemaal niet uitvoeren, vormen een apart onderwerp.
• Een mooie foutpagina met status 200. Een CMS, een framework of een proxyregel toont een vormgegeven sjabloon “niet gevonden”, maar vergeet de status in te stellen.
• Lege lijstpagina’s. Een categorie-, tag- of interne zoekpagina zonder items antwoordt nog steeds met 200 en toont “0 resultaten” of een leeg kader.
• Uitverkochte of uit het assortiment gehaalde producten. De pagina blijft bestaan met weinig meer dan “niet beschikbaar”. Een pagina die nog een echte beschrijving en een opmerking over de beschikbaarheid heeft, is iets anders dan een kaal bericht.
• Alles omleiden naar de homepage. Een verwijderde pagina die bezoekers naar de startpagina stuurt, eindigt in een 200 met niet-verwante inhoud. De homepage is zelden het equivalent van de pagina die weg is.

Een andere oorzaak is de dunne pagina: een sjabloon met bijna geen inhoud, zoals een plaatshouder of een half afgebouwd onderdeel. Inhoud die op een foutmelding of een lege pagina lijkt, kan worden gemarkeerd, ook als niemand er een foutpagina van wilde maken.

Hoe vind je soft 404-fouten?

Je hebt drie manieren, en ze vullen elkaar aan.

1. Search Console. Open het rapport “Pagina-indexering” in Search Console en zoek de reden “Soft 404”. Daar staan de URL’s die Google zelf in dit vak heeft gezet. De URL-inspectie laat zien wat Google van één adres krijgt.
2. Een terminal. Vraag een adres op dat niet kan bestaan en lees de status (commando hieronder).
3. De browser. Open de ontwikkelaarstools, ga naar het tabblad Netwerk, laad een verzonnen adres en kijk naar de status van het eerste verzoek. De pagina zelf vertelt je niets, want die ziet er bij elke status hetzelfde uit.

Voor de controle in de terminal volgt de optie -L omleidingen, zodat je ook ziet waar een adres uitkomt:

curl -s -L -o /dev/null -w "%{http_code} %{url_effective}\n" https://jouw-site.example/pagina-bestaat-niet

Je wilt 404 zien. Krijg je 200 https://example.com/, dan stuurt de server onbekende adressen door naar de homepage. Gebruik GET zoals hier en niet curl -I, omdat sommige servers een HEAD-verzoek anders beantwoorden.

Test van buitenaf: vraag het openbare adres op, niet de applicatie rechtstreeks. Een CDN, een cache of een firewall voor de applicatie kan het antwoord veranderen.

Zo test SEOgrinder op een soft 404

De gratis scan in SEOgrinder vraagt je site om een adres dat hij zelf verzint, met een willekeurige naam die niet kan bestaan. Is het antwoord 200, dan meldt hij een bevinding. Een omleiding van dat adres naar je homepage telt als dezelfde bevinding, omdat ook die in 200 eindigt. Het resultaat staat in het tabblad “Pagina bij Google”, in de kaart “Indexering”, als regel: “Onbekende adressen geven correct 404 terug” of “Onbekende adressen geven 200 in plaats van 404”. De bevinding komt in de takenlijst met het advies een echte 404 of 410 terug te geven.

Twee eerlijke grenzen. Ten eerste vraagt deze test hoe je server omgaat met adressen die niet bestaan. Hij zegt niet welke van je echte URL’s Google als soft 404 heeft aangemerkt. Voor losse URL’s staat het oordeel in Search Console. Bij een lokale installatie die met Search Console is verbonden, leest SEOgrinder ook de opgeslagen indexstatus van de gecontroleerde pagina en meldt het als Google die als soft 404 aanmerkt. Ten tweede kan de test niet zeggen of een dunne pagina van jou er voor Google leeg uitziet. De websitedoorloop markeert wel dunne pagina’s en kapotte interne links, en daar begint het probleem vaak.

Welke statuscode is juist? De beslistabel

Het juiste antwoord hangt af van wat er over de pagina waar is. Pas de status aan de waarheid aan, niet andersom.

Google ziet 301 en 308 als een sterk signaal dat het omleidingsdoel verwerkt moet worden, en 302 en 307 als een zwak signaal. Standaard volgt Google maximaal tien omleidingsstappen en negeert het de inhoud van de URL die doorverwijst. Leid dus één keer om, rechtstreeks naar het eindadres.

Zo los je een soft 404 op in nginx, Node en single-page-apps

nginx

Deze configuratie toont een vormgegeven foutpagina en behoudt de status 404. De regel error_page 404 /404.html; laat de oorspronkelijke status ongemoeid, tenzij je =200 toevoegt. Voeg dat dus niet toe.

server {
    root /var/www/voorbeeld;
    error_page 404 /404.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location = /404.html {
        internal;
    }

    # bewust verwijderd
    location /oude-actie/ {
        return 410;
    }

    # verhuisd
    location = /oude-pagina {
        return 301 https://example.com/nieuwe-pagina;
    }
}

Node

Bij routes met gegevens moet de code eerst het record opzoeken en pas daarna de status bepalen. Dit voorbeeld gebruikt alleen de eigen modules van Node:

import http from 'node:http';

const producten = new Map([['blauwe-mok', 'Blauwe mok']]); // vervanger voor je database

http.createServer((req, res) => {
  const { pathname } = new URL(req.url, 'http://localhost');
  const treffer = /^\/producten\/([a-z0-9-]+)$/.exec(pathname);
  const naam = treffer && producten.get(treffer[1]);
  res.writeHead(naam ? 200 : 404, { 'content-type': 'text/html; charset=utf-8' });
  res.end(naam ? `<h1>${naam}</h1>` : '<h1>Pagina niet gevonden</h1>');
}).listen(3000);

De foutpagina mag vriendelijk zijn en een eigen ontwerp hebben, en de status blijft toch 404. De meeste frameworks hebben er een “niet gevonden”-functie of -hook voor. Zoek die op die de status instelt en niet alleen een sjabloon toont.

Single-page-apps

De server moet weten welke paden echt bestaan. De gangbare sluiproute, “stuur index.html voor alles”, is precies wat het probleem veroorzaakt. In nginx kun je de echte routes opsommen en de rest met 404 beantwoorden:

location = / {
    try_files /index.html =404;
}

location ~ ^/(over-ons|contact|docs)/?$ {
    try_files /index.html =404;
}

location / {
    try_files $uri =404;
}

Bestanden als scripts en afbeeldingen vindt het laatste blok, en elk ander pad krijgt een 404. Is de routelijst lang of verandert ze vaak, genereer haar dan bij het bouwen uit je router. Het alternatief is om echte pagina’s op de server of vooraf te renderen, zodat elk adres een eigen HTML-bestand heeft en de server ervoor kan antwoorden. Google zelf noemt server-side rendering of pre-rendering een goed idee, omdat de pagina sneller wordt voor gebruikers en crawlers en omdat niet alle bots JavaScript uitvoeren. Voor apps waarin een statuscode instellen onmogelijk of onpraktisch is, noemen Googles JavaScript-basics nog twee wegen: met JavaScript doorsturen naar een adres dat 404 geeft (bijvoorbeeld /niet-gevonden), of op foutpagina’s met JavaScript <meta name="robots" content="noindex"> toevoegen.

Voer na elke wijziging de curl-controle opnieuw uit en test één echte pagina, één verhuisde pagina en één adres dat niet kan bestaan.

Veelgemaakte fouten

• Het ontwerp repareren in plaats van de status. Een mooie “niet gevonden”-pagina die 200 stuurt, blijft een soft 404.
• Alle ontbrekende pagina’s naar de homepage omleiden. Het verbergt het probleem voor je eigen tools en geeft bezoekers iets anders dan waar ze om vroegen. Leid om naar een gelijkwaardige pagina, of antwoord met 404.
• error_page 404 =200 /index.html; en vergelijkbare sluiproutes. Ze zetten de status voor elk onbekend adres op 200.
• Alleen in de browser testen. De browser ziet er bij elke status hetzelfde uit. Lees de status.
• De adressen in robots.txt blokkeren in plaats van de status te corrigeren. Een crawler die een pagina niet mag ophalen, ziet haar statuscode nooit.
• Dode adressen in de sitemap laten staan. Een sitemap hoort alleen pagina’s te noemen die bestaan en met 200 antwoorden.
• Verwachten dat het rapport meteen verdwijnt. De melding in Search Console verandert pas als Google de URL opnieuw ophaalt. Niemand kan beloven wanneer dat gebeurt.

Veelgestelde vragen

Schaadt een soft 404 mijn rankings?

Niet bewezen. Google meldt het als fout in Search Console, en dat is gedocumenteerd. Een directe rankingstraf voor de rest van je site staat in geen enkele bron die wij gebruikten. De verstandige lezing is: los het op omdat het een verkeerd antwoord is, niet vanwege een beloofde winst.

Is een soft 404 hetzelfde als een 404?

Nee. Een 404 is een eerlijk antwoord: de status zegt dat de pagina niet bestaat. Een soft 404 zegt 200 terwijl de inhoud het tegendeel zegt.

Moet ik 404 of 410 sturen?

Beide zijn 4xx-foutstatussen, en Google gebruikt bij beide de inhoud van de URL niet. 404 is het gebruikelijke antwoord voor “niet gevonden”. 410 betekent “verdwenen”, dus het past bij pagina’s die je bewust hebt verwijderd.

Mag ik een eigen 404-pagina maken?

Ja, en dat zou je ook moeten doen. Ontwerp haar zoals je wilt, voeg een link naar de homepage of een zoekfunctie toe, maar zorg dat de status 404 is.

Hoe controleer ik mijn hele website?

Voer de gratis scan uit om te testen hoe je server onbekende adressen beantwoordt, en kijk in het Search Console-rapport naar de URL’s die Google heeft gemarkeerd. Controleer nog één ding met de hand: pagina’s die niets dragen behalve een korte mededeling.

Mijn SPA staat bij een hoster waar ik niets aan de server kan instellen. Wat nu?

Dan bepaalt de hoster de status. Lees in zijn documentatie of onbekende paden een 404 kunnen geven, of vraag het de support. Helpt dat niet, dan noemt Google twee wegen voor een single-page-app waarin je geen statuscode kunt instellen: met JavaScript doorsturen naar een adres dat 404 geeft (bijvoorbeeld /niet-gevonden), of op foutpagina’s met JavaScript <meta name="robots" content="noindex"> toevoegen. Daarnaast kun je de pagina’s vooraf genereren, zodat elk echt adres een eigen bestand heeft. Voor al het andere bestaat dan geen bestand. Staat er bij de hoster geen regel die alle paden naar index.html stuurt, dan kan hij zelf met een 404 antwoorden; anders blijft het bij 200 en dus bij een soft 404.

Je volgende stap

Vraag met curl een adres op dat op je eigen site niet kan bestaan. Krijg je geen 404, los dat dan eerst op. Voer daarna de gratis scan uit met SEOgrinder, zoek de soft 404-regel in de kaart “Indexering” van het tabblad “Pagina bij Google” en klik na je wijziging op “Opnieuw controleren” om het nieuwe resultaat te zien. Meer over de rest van de basis lees je in de SEO-audit checklist.