404 in Search Console maar pagina werkt: wat nu?

Search Console toont wat Google heeft aangetroffen op het moment van de crawl, niet noodzakelijk wat je site nu doet. Google beschrijft het hulpmiddel als een manier om te begrijpen hoe Google je site crawlt, indexeert en toont, en raadt aan de gegevens bijvoorbeeld maandelijks of na wijzigingen te bekijken (Google over aan de slag met Search Console). Een melding kan dus een momentopname uit het verleden zijn.

Een 404 in een rapport kan drie dingen betekenen: de pagina was toen echt niet bereikbaar, de pagina is intussen hersteld, of Google kreeg een andere respons dan jij in je browser. Daarom is een historische melding niet automatisch een incident. Het wordt pas een probleem als de huidige situatie klopt met de melding.

Welke rapporten en schermnamen je precies ziet, kan wijzigen. Open het indexeringsrapport voor je property en kijk bij de details van de betrokken URL.

Veel 'werkende pagina's' blijken een andere URL te zijn dan de gemelde. Kopieer de URL letterlijk uit Search Console en vergelijk tekens voor tekens met wat je in je browser opent.

• Staat er een slash aan het einde, of juist niet?
• Gaat het om http of https, met of zonder www?
• Zit er een parameter in, zoals een tracking- of filterdeel?
• Gaat het om hoofdletters of kleine letters in het pad?
• Is de URL een oude variant, bijvoorbeeld van voor een herbouw?

Dit zijn controles op wat de server teruggeeft, geen rankingtrucs. Hoofdletters of slashes zijn op zichzelf geen bewezen rankingfactor, maar ze kunnen wel bepalen of een adres een pagina of een 404 oplevert. Google legt bovendien uit dat dezelfde inhoud via meerdere URL's bereikbaar kan zijn en dat je met redirects en rel="canonical" aangeeft welke versie de voorkeur heeft (Google over canonieke URL's). Een canonical is een signaal, geen opdracht.

Gebruik de URL-inspectie in Search Console voor de gemelde URL. Bekijk twee dingen apart:

1. De geïndexeerde versie: wanneer Google de URL voor het laatst crawlde en welke status toen werd gezien.
2. De live test: wat Google nu ophaalt.

Houd die twee gescheiden. De live test zegt iets over nu, de geïndexeerde gegevens over de laatste crawl. Wil je weten welke canonical Google heeft gekozen, lees dat dan in de geïndexeerde inspectiegegevens, niet in de live test.

Controleer daarnaast de HTTP-respons zelf. Een browser toont soms een nette pagina terwijl de server een 404-statuscode meestuurt (dat is een verkeerde statuscode bij een werkende pagina, dus niet hetzelfde als een soft 404, waarbij een foutpagina juist status 200 geeft). Kijk in de netwerktab van de ontwikkelaarstools naar de statuscode van het hoofdverzoek, niet naar wat je ziet. Let ook op redirectketens: eindigt de keten op een werkende pagina met status 200?

Belangrijk: een gewone browser respecteert robots.txt niet, Googlebot wel. Dat je pagina in de browser opent, bewijst dus niet dat Googlebot erbij kan. Robots.txt blokkeert crawlen, maar garandeert geen verwijdering of afwezigheid uit een zoekindex.

Bij sites die inhoud pas in de browser opbouwen, kan het verschil tussen browser en crawl groter zijn. Google legt uit dat het pagina's crawlt, rendert en indexeert, en dat een pagina in de wachtrij voor rendering enkele seconden of langer kan blijven staan (Google over JavaScript en zoeken). Pagina's met een 200-status worden voor rendering ingepland, tenzij een robots-metatag of header indexering verbiedt.

Voor jouw controle betekent dit: staat de echte inhoud al in de eerste HTML-respons, of verschijnt ze pas na JavaScript? Dit is een eigen controle-aanname, geen bronuitspraak: een app die voor geldige routes eerst een 404-status of foutscherm toont voordat de route is opgebouwd, kan Google mogelijk een andere toestand laten zien dan jij ziet. Vraag je ontwikkelaar of de server voor geldige routes meteen status 200 geeft. Zowel server-side als pre-rendering blijft volgens de bron nuttig, en niet alle bots voeren JavaScript uit.

Fictief voorbeeld, enkel invoer en verwachte controles: Search Console meldt een 404 voor een URL met een slash aan het einde, terwijl je in de browser dezelfde pagina zonder slash opent. Verwachte controles: haal beide varianten op en lees de statuscodes, kijk of er een redirect van de ene naar de andere variant is, inspecteer de gemelde URL in Search Console en vergelijk de geïndexeerde gegevens met de live test. Welk resultaat Google daarna toont en hoe snel, is onzeker. Noteer enkel wat je meet.

Behandel een 404-melding als een aanleiding tot onderzoek, niet als alarm. Een goede routine is kort:

• Noteer URL, datum van de melding en de huidige statuscode.
• Los enkel op wat nu echt fout is.
• Vraag na een herstel opnieuw inspectie aan en bekijk het rapport enkele weken later opnieuw, zonder dat je een vaste termijn mag verwachten.
• Verwijder een pagina niet louter omdat ze in een rapport staat. Heeft ze nog nuttige inhoud of interne links, bewaar ze dan of leid door naar een passende opvolger.

Wil je ook zien welke publieke signalen je site naar buiten toe geeft, bekijk dan je eigen website via Marketing Scan. Die scan meet zichtbare signalen en vervangt een controle in Search Console niet.