Ga naar de inhoud 
HTTP-statuscodes bepalen hoe crawlers verzoeken indienen, inhoud laden en of pagina's überhaupt in de zoekresultaten terechtkomen. Ik laat zien hoe antwoorden zoals 200, 301, 404 of 503 het crawlen, het crawlbudget en de hosting op elkaar afstemmen en waar typische remmen liggen.
Centrale punten
- Kruip budget hangt rechtstreeks af van correcte statusantwoorden.
- 2xx/3xx indexering mogelijk maken, 4xx/5xx blokkeren.
- Doorsturen Alleen gebruiken zonder kettingen en lussen.
- server tijden en uptime vormen het vertrouwen in crawlers.
- Controle met logs, GSC en crawlers.
Waarom statuscodes het crawlen regelen
Crawlers controleren eerst de Statuscode, pas daarna volgen rendering en beoordeling van de inhoud. Ik geef daarom voorrang aan de juistheid van het antwoord boven title-tags of interne links. Een 200 OK laadt inhoud onmiddellijk, terwijl 4xx en 5xx tijd, budget en vertrouwen kosten. Als fouten zich opstapelen, vermindert de bot het aantal opvragingen en vertraagt hij de opname van nieuwe inhoud. Dit leidt tot stille SEO-verliezen, die met duidelijke regels voor Serverresponsen vermijden.
2xx: De directe weg naar de index
De 200 OK is voor crawlers een Groen licht. Ik lever alleen 200 aan echte, inhoudelijk volledige pagina's en voorkom soft-404's, die wel 200 verzenden, maar geen meerwaarde bieden. Dunne inhoud, ontbrekende H1 of bijna identieke teksten zijn waarschuwingssignalen voor dergelijke verkeerde configuraties. Wie hier opruimt, bespaart crawlbudget en versterkt de thematische relevantie. Daarnaast optimaliseer ik snippets en interne verwijzingen, zodat crawlers en gebruikers met een oproep de juiste doelen bereiken.
3xx: Doorsturen zonder verlies
301 verplaatst inhoud permanent en stuurt signalen door naar de nieuwe URL, 302 staat voor een tijdelijke oplossing. Ik gebruik 301 wanneer inhoud echt is verplaatst en ik verwijder ketens en loops, omdat elke extra hop tijd en budget kost. Controleer interne links, want een interne 301-keten is een zelfgemaakte opstopping. Voor verhuizingen plan ik consistente regels, zodat alles in een nette lijn naar de doel-URL verwijst. Waarom dit zo belangrijk is, laat ik zien bij Redirect-ketens, die de laadtijd en crawling meetbaar belasten.
4xx: Duidelijke signalen voor verwijderde inhoud
Een 404 geeft duidelijk aan: Deze Bron bestaat niet. Ik laat 404 staan voor pagina's die echt verwijderd zijn en vermijd soft-404's door nooit 200 te verzenden bij foutpagina's. 410 geeft nog duidelijker aan dat een pagina permanent verwijderd is; voor oude URL's zonder geschikte alternatieven gebruik ik dit doelbewust. Interne links naar 404 verspillen budget, daarom corrigeer ik ze tijdig of leid ik ze gericht om naar het beste thematische alternatief. Zo houd ik crawlers op de pagina's die echt Waarde bezorgen.
5xx: Serverfouten vertragen bots en gebruikers
5xx betekent: De server kon het verzoek niet bedienen. Bij herhaalde gevallen classificeren crawlers de site als onbetrouwbaar en bezoeken ze deze minder vaak. Voor onderhoudswerkzaamheden stel ik 503 in met „Retry-After“, zodat bots weten wanneer het zinvol is om opnieuw te proberen. Als een 503 aanhoudt, evalueer ik de logbestanden en verhelp ik knelpunten bij de CPU, RAM, database of rate limits. Voor WordPress verzamel ik praktische tips in deze handleiding over 503-fouten, zodat onderhoudsperiodes beperkt blijven en onder controle blijven.
Caching, 304 en ETags: bespaar op uw budget zonder risico's
304 Not Modified bespaart Bandbreedte, omdat de client zijn kopie mag blijven gebruiken. Ik stel ETag of Last-Modified correct in, zodat crawlers If-Modified-Since correct kunnen gebruiken. Dit verkort het ophalen van ongewijzigde CSS, JavaScript en afbeeldingen. Als de logica niet klopt, laadt de bot onnodig veel bestanden of mist hij updates. Daarom test ik varianten, controleer ik response-headers en houd ik de 304-antwoorden consistent over alle Activa.
Crawlbudget: zo houd ik het hoog
Het crawlbudget hangt af van drie factoren: de kwaliteit van de code, Prestaties en interne structuur. Ik verminder tijdverspillers zoals doorstuurketens, dubbele inhoud en trage TTFB. Ik leid interne links naar een paar duidelijke paden, zodat bots sneller prioriteiten kunnen herkennen. Ik corrigeer foutieve of verweesde pagina's snel, voordat ze budget opslokken. Hiertoe behoren ook statuscodes voor paginering, canonicals en hreflang, die zonder foutsignalen moeten lopen.
Hostingfactoren die statuscodes beïnvloeden
Goede hardware, nette serverconfiguratie en capaciteit op maat Caching voorkomen 5xx-pieken. Ik let op voldoende PHP-workers, databaseparameters, Keep-Alive en HTTP/2 of HTTP/3. Ook rate limits voor bots moeten zinvol worden ingesteld, zodat echte gebruikers niet worden geblokkeerd. Bij hoge piekbelastingen helpen edge-caches en regels voor statische assets. Waarom statuscodes en hostingprestaties met elkaar verband houden, laat ik hier zien: HTTP-status en serververmogen.
Monitoring: logs, GSC en crawlers correct gebruiken
Ik begin met serverlogs, omdat ze echte Vragen en noteer elk antwoord. Daarna controleer ik de Search Console op dekkingsfouten, sitemaps en renderstatus. Een desktop- en mobiele crawl met een SEO-crawler detecteert omleidingen, 4xx en 5xx in één keer. Voor diepgaande analyses correleer ik fouten met tijdstippen van releases of verkeerspieken. Dit laat zien of een roll-out, een plug-in of een CDN-regelset de Antwoorden veranderd.
Sneloverzicht: statuscodes en maatregelen
De volgende tabel rangschikt typische antwoorden volgens de juiste stappen en benadrukt hostingpunten. Ik gebruik ze als kompas voor snelle beslissingen in het dagelijks leven.
| Statuscode | Crawler-reactie | Actie | Hosting-opmerking |
|---|---|---|---|
| 200 OK | De inhoud wordt opgehaald en geëvalueerd. | Echte inhoud leveren, Soft-404 vermijden | TTFB laag houden, cache warm |
| 301 Permanent verplaatst | Signalen naar doel-URL | Kettingen verwijderen, interne links bijwerken | Houd herschrijfregels duidelijk |
| 302 Gevonden | Tijdelijk, bron behoudt signalen | Alleen voor kortstondig gebruik | Regelmatig controleren |
| 304 Niet gewijzigd | Cache gebruiken, geen download | ETag/Last-Modified correct instellen | Assets leveren via CDN |
| 404 Niet gevonden | URL wordt uit de index verwijderd | Interne links corrigeren, soft-404 vermijden | Houd de foutpagina slank |
| 410 Weg | Snellere verwijdering | Gebruiken voor permanent verwijderde inhoud | Doorsturen alleen bij echt alternatief |
| 500 Interne fout | Bot vermindert bezoeken | Logs controleren, oorzaak verhelpen | Hulpbronnen en limieten verhogen |
| 503 Service niet beschikbaar | Onderhoudsmodus geaccepteerd | „Retry-After“ instellen, duur kort houden | Onderhoudsvensters plannen |
Foutbehandeling: wat ik eerst controleer
Ik begin met de Reikwijdte: Heeft de fout betrekking op alle gebruikers, alleen bots of alleen mobiele apparaten? Vervolgens controleer ik of de laatste wijziging op de server, in de applicatie of in het CDN heeft plaatsgevonden. Als de fout alleen onder belasting optreedt, verhoog ik tijdelijk de resources en zoek ik in traces naar knelpunten. Bij terugkerende 5xx stel ik waarschuwingen in op logpatronen en status-eindpunten. Zo los ik acute problemen snel op en voorkom ik dat ze het Kruip budget verder verlagen.
Technische controles vóór releases
Voor elke roll-out test ik kritieke paden met een Staging-Crawl en vergelijk statuscodes met de live-variant. Ik houd een lijst met belangrijke URL's bij: startpagina, categorie, product, filter, zoeken, sitemap, API. Daarna controleer ik headers zoals cache-control, vary, redirect-regels en canonicals. Voor feature-flags stel ik duidelijke voorwaarden, zodat ze niet onbedoeld 302 of 404 genereren. Pas als de statuscodes, laadtijden en renderresultaten stabiel lijken, geef ik de Vrijgave gratis.
robots.txt, sitemaps en secundaire URL's
Ik controleer eerst of robots.txt stabiel met 200 antwoorden. 5xx of 403 op robots.txt verontrusten crawlers en vertragen het crawlen. Een 404 op robots.txt geldt weliswaar als „geen beperking“, maar is een slecht signaal bij sites met crawlproblemen. Voor Sitemaps Ik accepteer alleen 200 en houd de bestanden klein, netjes gzipped en met correcte lastmod-velden. 3xx naar de sitemap is technisch toegestaan, maar ik vermijd dit ten gunste van een direct 200-antwoord. Voor Feeds, AMP- of API-Ik zorg ervoor dat bronnen geen 404 of 5xx retourneren als de HTML-pagina 200 retourneert, anders wordt het renderen of evalueren van gestructureerde gegevens inconsistent afgebroken.
Canonical, hreflang en paginering alleen op 200
Signalen zoals rel=canonical, hreflang of paginering hebben alleen effect als de doel- en referentie-URL's met 200 definitief worden geladen. Ik vermijd canonicals op 3xx, 404 of noindex-URL's, omdat dit de crawler in verwarring brengt. Voor hreflang controleer ik de terugverwijzing en dat elke variant uiteindelijk eindigt op 200. Gepagineerde lijsten (pagina=2,3,…) moeten stabiel 200 opleveren; ik voorkom dat lege pagina's Soft-404 veroorzaken door bij ontbrekende resultaten duidelijke inhoud en interne doorverwijzingen aan te bieden, maar toch de juiste status te verzenden.
429 en rate limits correct gebruiken
429 Te veel verzoeken is mijn tool voor fijngranulaire beperking wanneer individuele bots te agressief zijn. Ik stel Opnieuw proberen na met een zinvolle tijdsaanduiding, zodat crawlers hun opvragingen spreiden. 429 is geen vervanging voor 503-onderhoud en mag nooit legitieme gebruikers treffen. In de WAF of CDN maak ik onderscheid op basis van user-agent, IP en paden, zodat media-assets 200/304 blijven leveren, terwijl HTML kortstondig wordt afgeremd. Belangrijk: 429 mag niet permanent worden, anders beoordeelt de bot de site als moeilijk bereikbaar en verlaagt hij het budget.
401/403/451: opzettelijk geblokkeerd – maar consistent
401 Ik gebruik het voor gebieden die met een login beveiligd zijn., 403 voor verboden toegang. Ik zorg ervoor dat deze antwoorden niet per ongeluk van toepassing zijn op Googlebot, bijvoorbeeld door strenge botfilters. Bij geografische blokkades of wettelijke vereisten gebruik ik 451 en documenteer de redenen intern. Ik zie af van 200-antwoorden met interstitials („toegang geweigerd“) – dergelijke pagina's werken als soft-404's. Als er alternatieven zijn, link ik duidelijk naar toegankelijke inhoud en laat ik de geblokkeerde URL de juiste 4xx-status verzenden.
Pariteit van de antwoorden: mobiel, desktop en dynamische weergave
Ik zorg ervoor dat mobiele en desktopbots dezelfde Statuscodes zien. Dynamische weergaven (A/B-tests, feature flags, geo-content) mogen geen 302/403 voor individuele user agents activeren. Ik gebruik Variëren-Gebruik headers spaarzaam en bewust (bijv. Accept-Language) om onnodige cache-splitsingen te voorkomen en zorg ervoor dat elk pad voor alle varianten consistent eindigt op 200/304. Pariteitsbreuken leiden tot indexeringsproblemen wanneer de bot een 404 ziet, terwijl gebruikers 200 krijgen – dergelijke gevallen los ik op met duidelijke regels en tests per variant.
HEAD, OPTIONS en API-eindpunten
Veel crawlers sturen HEAD-verzoeken om de beschikbaarheid en grootte te controleren. Mijn server reageert hierop met dezelfde logica als op GET – alleen zonder body. Ik vermijd 405 op HEAD als GET 200 levert. OPTIONS en CORS-preflights behandel ik zodanig dat assets uit externe bronnen correct kunnen worden geladen. Voor API-eindpunten, die bij het renderen gegevens leveren, let ik op stabiele 200/304 en duidelijke 4xx bij echte fouten. Als API's sporadisch 5xx leveren, markeer ik dat apart in logs, omdat dit renderfouten onder de motorkap kan verklaren, ook al stuurt de HTML-pagina 200.
CDN-regels, stale-strategieën en 5xx-afscherming
In het CDN cache ik 200, 301 en statische 404 gecontroleerd – maar ik voorkom dat 503 of admin-pagina's in de cache terechtkomen. Met stale-if-error kan ik kortstondige 5xx omzeilen zonder dat bots fouten zien. Ik stel Surrogaatcontrole voor Edge-signalen en houd ik TTL's voor HTML korter dan voor assets. Ik configureer ETags clusterveilig (ofwel overal hetzelfde ofwel gedeactiveerd), zodat 304 betrouwbaar werkt en niet vervalt door afwijkende hashes. Belangrijk: doorverwijzingen (301/302) mogen niet voor onbepaalde tijd in het CDN worden gecachet, anders blijven oude paden als ketens behouden.
E-commercegevallen: uitverkocht, varianten, filters
Als producten tijdelijk niet beschikbaar zijn, blijft de productpagina op 200 met duidelijke markering en zinvolle interne doorverwijzingen (categorie, alternatieven). Bij permanent verwijderde producten kies ik tussen 301 naar de beste vervangende URL (alleen bij echte overeenkomst) en 410, als er geen geschikt alternatief is. Ik vermijd massale omleidingen naar de startpagina, omdat deze werken als soft-404's. Voor Filter- en parameter-URL's Ik hanteer duidelijke regels: alleen indexrelevante combinaties op 200, al het andere via 301 naar de canonieke URL of met noindex – maar nooit 200 voor lege of bijna identieke pagina's die de soft-404-detector activeren.
Noindex, robots en statuscodes netjes scheiden
noindex is een inhoudssignaal, de statuscode is een transportsignaal. Ik vermijd gemengde vormen die crawlers in verwarring brengen: geen 301 op een noindex-pagina, geen 200 met „beperkte toegang“-plaatshouder als de bron niet bestaat. Een pagina is ofwel indexeerbaar (200 + index), ofwel verwijderd (404/410) of tijdelijk niet beschikbaar (503 met Retry-After). robots.txt blokkeert alleen het crawlen – niet de indexering van reeds bekende URL's. Daarom stel ik voor echt verwijderde inhoud 404/410 in plaats van robotblokkades.
Kerncijfers en drempelwaarden die ik in de gaten houd
- 5xx-percentage: permanent duidelijk onder 0,1%. Pieken onmiddellijk onderzoeken.
- 4xx-percentage: afhankelijk van het type site onder 1–2%. Interne 4xx moeten naar 0% gaan.
- 3xx-aandeel: zo laag mogelijk; Kettingen omleiden op 0.
- 304-aandeel bij Assets: hoog is goed – indicator voor goed functionerende caching.
- TTFB voor HTML: stabiel laag; uitschieters correleer ik met 5xx/429.
- Sitemap-Gezondheid: 200, valide lastmod, geen dode links.
- Pariteit Mobiel versus desktop: dezelfde statuscodes en definitieve URL's.
Ik koppel deze statistieken aan implementaties, pieken in het verkeer en infrastructuurevenementen. Zo herken ik patronen die het Kruip budget beïnvloeden, lang voordat rankings reageren.
Edge-cases: 1xx, 405, 410 vs. 404
1xx-Antwoorden zijn praktisch irrelevant voor SEO; ik zorg er alleen voor dat de server en het CDN correct worden geüpgraded (bijv. HTTP/2/3). 405 Methode niet toegestaan verschijnt wanneer HEAD/POST geblokkeerd zijn, hoewel GET 200 levert – dit is onschadelijk, maar moet consistent worden geconfigureerd. Bij de keuze 404 versus 410 Ik gebruik 410 voor bewust verwijderde inhoud met een permanent karakter, 404 voor onbekende of per ongeluk gekoppelde paden. Belangrijk is de Consistentie, zodat crawlers kunnen leren van terugkerende patronen.
Rollback-strategieën en betrouwbaarheid
Ik plan releases zo dat ik snel terug kan bij foutieve statuscodes: Blauw/groen-Implementaties, fijnmazige feature flags en omkeerbare herschrijfregels. Voor onderhoud gebruik ik Onderhoudspagina's, die 503 leveren terwijl achtergrondtaken worden uitgevoerd. Op infrastructuurniveau houd ik health checks, automatische herstarts en rate limit-grenzen bij, die aanvallen onderscheppen zonder legitieme crawling te belemmeren. Elke maatregel is erop gericht om, 200/304 maximaliseren en 4xx/5xx in geval van storingen gecontroleerd, kort en begrijpelijk houden.
Samenvatting: duidelijke signalen, sneller crawlen
Ik zorg ervoor dat iedereen Statuscode een duidelijke boodschap bevat: 2xx voor inhoud, 3xx zonder kettingen, 4xx voor verwijderde pagina's en 5xx alleen in echte uitzonderingsgevallen. Caching met 304 ontlast servers, terwijl consistente 200-antwoorden de bot vertrouwen geven. Om dit te laten werken, combineer ik logboekanalyses, GSC-gegevens en terugkerende crawls. Aan de hostzijde houd ik de responstijden laag, stel ik zinvolle limieten in en plan ik onderhoud op een nette manier. Dit verhoogt de kwaliteit, indexeerbaarheid en zichtbaarheid – en dat Kruip budget vloeit naar waar het het meeste oplevert.
