Videre til indhold 
HTTP-statuskoder styre, hvordan crawlere anmoder om indhold, indlæser indhold, og om sider overhovedet kommer med i søgningen. Jeg viser, hvordan svar som 200, 301, 404 eller 503 får crawling, crawl-budget og hosting til at fungere sammen, og hvor de typiske hindringer ligger.
Centrale punkter
- Kravl budget afhænger direkte af korrekte statusresponser.
- 2xx/3xx muliggør indeksering, blokerer 4xx/5xx.
- Videresendelse Brug kun uden kæder og løkker.
- Server-tider og oppetid skaber tillid til crawlere.
- Overvågning med logs, GSC og crawlere.
Hvorfor statuskoder styrer crawling
Crawlere kontrollerer først Statuskode, først derefter følger rendering og vurdering af indholdet. Jeg prioriterer derfor korrektheden af svaret før title-tags eller interne links. En 200 OK indlæser indhold med det samme, mens 4xx og 5xx koster tid, budget og tillid. Hvis fejlene hober sig op, reducerer botten antallet af opkald og forsinker optagelsen af nyt indhold. Dette resulterer i stille SEO-tab, som kan undgås med klare regler for Server-svar undgås.
2xx: Den direkte vej til indekset
200 OK er for crawlere en Grønt lys. Jeg leverer kun 200 til ægte sider med komplet indhold og forhindrer soft-404'ere, der sender 200, men ikke tilbyder nogen merværdi. Tyndt indhold, manglende H1 eller næsten identiske tekster er advarselstegn på sådanne fejlkonfigurationer. Hvis du rydder op her, sparer du crawl-budget og styrker den tematiske relevans. Derudover optimerer jeg snippets og interne henvisninger, så crawlere og brugere med en opfordring nå de rigtige mål.
3xx: Videresendelser uden tab
301 flytter indhold permanent og overfører signaler til den nye URL, 302 står for en midlertidig løsning. Jeg bruger 301, når indholdet virkelig er flyttet, og jeg fjerner kæder og sløjfer, fordi hvert ekstra hop spilder tid og budget. Tjek interne links, for en intern 301-kæde er en hjemmelavet trafikprop. Ved flytninger planlægger jeg konsistente regler, så alt peger i en ren linje mod mål-URL'en. Hvorfor det er så vigtigt, viser jeg på Omdirigeringskæder, som har en målbar indvirkning på indlæsningstiden og crawling.
4xx: Tydelige signaler for fjernet indhold
En 404 giver et klart budskab: Denne Ressource findes ikke. Jeg lader 404 stå for sider, der virkelig er fjernet, og undgår soft-404'ere ved aldrig at sende 200 på fejlsider. 410 signalerer endnu tydeligere, at en side er blevet fjernet permanent; for gamle URL'er uden passende alternativer bruger jeg det målrettet. Interne links til 404 spilder budget, derfor retter jeg dem hurtigt eller omdirigerer målrettet til det bedste tematiske alternativ. På den måde holder jeg crawlere på de sider, der er ægte. Værdi levere.
5xx: Serverfejl bremser bots og brugere
5xx betyder: Serveren kunne ikke behandle anmodningen. betjene. Ved hyppige forekomster klassificerer crawlere webstedet som upålideligt og besøger det sjældnere. Til vedligeholdelse indstiller jeg 503 med „Retry-After“, så bots ved, hvornår det er meningsfuldt at forsøge igen. Hvis en 503 varer ved, evaluerer jeg logfiler og afhjælper flaskehalse i CPU, RAM, database eller hastighedsbegrænsninger. Til WordPress samler jeg praktiske tip i denne vejledning til 503-fejl, så vedligeholdelsesvinduerne forbliver kontrollerede og korte.
Caching, 304 og ETags: Spar penge uden risici
304 Not Modified sparer Båndbredde, fordi klienten må fortsætte med at bruge sin kopi. Jeg indstiller ETag eller Last-Modified korrekt, så crawlere kan bruge If-Modified-Since korrekt. Dette reducerer antallet af hentninger af uændrede CSS, JavaScript og billeder. Hvis logikken ikke er korrekt, indlæser botten unødigt mange filer eller går glip af opdateringer. Derfor tester jeg varianter, kontrollerer responsheadere og holder 304-svarene konsistente på tværs af alle Aktiver.
Crawl-budget: Sådan holder jeg det højt
Crawl-budget afhænger af tre faktorer: kodekvalitet, Ydelse og intern struktur. Jeg reducerer tidskrævende elementer som videresendelseskæder, dobbeltindhold og langsom TTFB. Interne links fører jeg til få, klare stier, så bots hurtigere kan genkende prioriteter. Fejlbehæftede eller forældede sider retter jeg hurtigt, inden de trækker på budgettet. Dette omfatter også statuskoder for paginering, canonicals og hreflang, som uden fejlsignaler skal løbe.
Hostingfaktorer, der påvirker statuskoder
God hardware, ren serverkonfiguration og kapacitetsmæssig Caching forhindrer 5xx-spidsbelastninger. Jeg sørger for, at der er tilstrækkeligt med PHP-workere, databaseparametre, Keep-Alive og HTTP/2 eller HTTP/3. Også hastighedsbegrænsninger for bots bør indstilles fornuftigt, så ægte brugere ikke blokeres. Ved høje spidsbelastninger hjælper edge-caches og regler for statiske aktiver. Hvorfor statuskoder og hostingydelse hænger sammen, viser jeg her: HTTP-status og serverkraft.
Overvågning: Brug af logfiler, GSC og crawlere korrekt
Jeg starter med serverlogfiler, fordi de er ægte Forespørgsler og noterer hvert svar. Derefter tjekker jeg Search Console for dækningsfejl, sitemaps og renderstatus. En desktop- og en mobil-crawl med en SEO-crawler afslører omdirigeringer, 4xx og 5xx i én gennemgang. For at få en dybdegående analyse korrelerer jeg fejl med tidspunkter for udgivelser eller trafikspidser. Det viser, om en rollout, et plugin eller et CDN-regelsæt er årsagen til Svar på spørgsmål har ændret sig.
Hurtig oversigt: Status koder og foranstaltninger
Den følgende tabel sorterer typiske svar efter de passende trin og fremhæver hosting-punkter. Jeg bruger den som kompas til hurtige beslutninger i hverdagen.
| Statuskode | Crawler-reaktion | Handling | Hosting-bemærkning |
|---|---|---|---|
| 200 OK | Indholdet hentes og vurderes | Lever ægte indhold, undgå soft-404 | Hold TTFB lavt, cache varm |
| 301 Flyttet permanent | Signaler til mål-URL | Fjern kæder, opdater interne links | Hold omskrivningsreglerne klare |
| 302 Fundet | Midlertidig, kilden bevarer signaler | Kun til kortvarig brug | Kontroller regelmæssigt |
| 304 Ikke ændret | Brug cache, ingen download | Indstil ETag/Last-Modified korrekt | Levering af aktiver via CDN |
| 404 Ikke fundet | URL fjernes fra indekset | Korriger interne links, undgå soft-404 | Hold fejlside slank |
| 410 Væk | Hurtigere fjernelse | Anvendes til permanent fjernet indhold | Videresendelse kun ved reel alternativ |
| 500 Intern fejl | Bot reducerer besøg | Kontroller logfiler, fjern årsagen | Øg ressourcer og grænser |
| 503 Tjenesten er ikke tilgængelig | Vedligeholdelsesmodus accepteret | „Indstil “Retry-After", hold varigheden kort | Planlæg vedligeholdelsesvindue |
Fejlhåndtering: Hvad jeg tjekker først
Jeg begynder med Omfang: Berører fejlen alle brugere, kun bots eller kun mobilenheder? Derefter kontrollerer jeg, om den seneste ændring fandt sted på serveren, i applikationen eller i CDN. Hvis fejlen kun opstår under belastning, øger jeg ressourcerne på kort sigt og søger efter flaskehalse i sporene. Ved tilbagevendende 5xx indstiller jeg alarmer på logmønstre og statusendepunkter. På den måde løser jeg akutte problemer hurtigt og forhindrer, at de Kravl budget yderligere reducere.
Tekniske kontroller før udgivelser
Før hver udrulning tester jeg kritiske stier med en Iscenesættelse-Crawl og sammenlign statuskoder med live-varianten. Jeg har en liste over vigtige URL'er klar: Startside, kategori, produkt, filter, søgning, sitemap, API. Derefter tjekker jeg headere som Cache-Control, Vary, Redirect-regler og Canonicals. For feature-flags sætter jeg klare betingelser, så de ikke utilsigtet genererer 302 eller 404. Først når statuskoder, indlæsningstider og renderingsresultater virker stabile, giver jeg Udgivelse Gratis.
robots.txt, sitemaps og sekundære URL'er
Jeg tjekker først, om robots.txt stabil med 200 svar. 5xx eller 403 på robots.txt forvirrer crawlere og bremser crawlingen. En 404 på robots.txt betragtes som „ingen begrænsning“, men er et dårligt signal for websteder med crawlproblemer. For Sitemaps Jeg accepterer kun 200 og holder filerne små, rene, gzippede og med korrekte lastmod-felter. 3xx til sitemap er teknisk tilladt, men jeg undgår dem til fordel for et direkte 200-svar. For Feeds, AMP- eller API-Ressourcer sørger jeg for, at de ikke returnerer 404 eller 5xx, når HTML-siden leverer 200 – ellers afbrydes gengivelsen eller evalueringen af strukturerede data inkonsekvent.
Canonical, Hreflang og paginering kun på 200
Signaler som rel=canonical, hreflang eller paginering har kun effekt, hvis mål- og reference-URL'er indlæses med 200 final. Jeg undgår canonicals på 3xx, 404 eller noindex-URL'er, fordi det forvirrer crawleren. For hreflang tjekker jeg tilbagehenvisning og at hver variant ender på 200. Paginated lister (side=2,3,…) skal levere 200 stabilt; jeg forhindrer, at tomme sider udløser Soft-404, ved at tilbyde klart indhold og interne viderehenvisninger, når der mangler resultater, men alligevel sende den korrekte status.
429 og Rate Limits korrekt brug
429 For mange anmodninger er mit værktøj til finjustering, når enkelte bots er for aggressive. Jeg sætter Gentag efter med en rimelig tidsangivelse, så crawlere kan sprede deres forespørgsler. 429 er ikke en erstatning for 503-vedligeholdelse og bør aldrig ramme legitime brugere. I WAF eller CDN differentierer jeg efter brugeragent, IP og stier, så medieaktiver fortsat leverer 200/304, mens HTML kortvarigt begrænses. Vigtigt: 429 må ikke blive permanent – ellers vurderer botten, at webstedet er svært tilgængeligt og sænker budgettet.
401/403/451: bevidst blokeret – men konsekvent
401 bruger jeg til login-beskyttede områder, 403 for ulovlig adgang. Jeg sørger for, at disse svar ikke ved en fejl gælder for Googlebot, f.eks. ved hjælp af strenge botfiltre. Ved geografiske spærringer eller juridiske krav bruger jeg 451 og dokumenterer årsagerne internt. Jeg undgår 200-svar med interstitials („Adgang nægtet“) – sådanne sider virker som soft-404'ere. Hvor der findes alternativer, linker jeg tydeligt til tilgængeligt indhold og lader den blokerede URL sende den korrekte 4xx-status.
Paritet i svarene: Mobil, desktop og dynamisk afspilning
Jeg sikrer, at mobil- og desktop-bot bruger de samme Statuskoder se. Dynamiske afspilninger (A/B-tests, feature-flags, geo-indhold) må ikke udløse 302/403 for enkelte brugeragenter. Jeg bruger Varierer-Brug headers sparsomt og bevidst (f.eks. Accept-Language) for at undgå unødvendige cache-splits, og sørg for, at alle stier for alle varianter konsekvent ender på 200/304. Paritetsbrud fører til indekseringsproblemer, hvis botten ser en 404, mens brugerne får 200 – sådanne tilfælde fjerner jeg med klare regler og tests for hver variant.
HEAD, OPTIONS og API-endepunkter
Mange crawlere sender HEAD-Anmodninger om at kontrollere tilgængelighed og størrelse. Min server svarer på disse med samme logik som på GET – bare uden body. Jeg undgår 405 på HEAD, hvis GET leverer 200. OPTIONER og CORS-Preflights behandler jeg på en sådan måde, at aktiver fra tredjepartskilder kan indlæses korrekt. For API-slutpunkter, der leverer data ved rendering, holder jeg øje med stabile 200/304 og klare 4xx ved reelle fejl. Hvis API'er sporadisk leverer 5xx, markerer jeg det separat i logfilerne, da det kan forklare renderingsfejl under overfladen, selvom HTML-siden sender 200.
CDN-regler, stale-strategier og 5xx-afskærmning
I CDN cacher jeg 200, 301 og statiske 404 kontrolleret – men jeg forhindrer, at 503 eller admin-sider i cachen. Med stale-if-fejl kan jeg omgå kortvarige 5xx-fejl uden at bots ser fejlen. Jeg indstiller Surrogatkontrol for Edge-signaler og holder TTL'er for HTML kortere end for aktiver. Jeg konfigurerer ETags klyngesikker (enten det samme overalt eller deaktiveret), så 304 fungerer pålideligt og ikke forfalder på grund af afvigende hashes. Vigtigt: Videresendelser (301/302) bør ikke caches i CDN i al evighed, ellers forbliver gamle stier som kæder.
E-handelssager: Udsolgt, varianter, filtre
Hvis produkter midlertidigt ikke er tilgængelige, forbliver produktsiden på 200 med tydelig mærkning og meningsfulde interne viderehenvisninger (kategori, alternativer). Ved permanent fjernede produkter vælger jeg mellem 301 til den bedste erstatnings-URL (kun ved ægte overensstemmelse) og 410, hvis der ikke findes et passende alternativ. Jeg undgår masseomdirigeringer til startsiden, da de fungerer som soft-404'ere. For Filter- og parameter-URL'er Jeg bruger klare regler: Kun indeksrelevante kombinationer på 200, alt andet via 301 til den kanoniske URL eller med noindex – men aldrig 200 for tomme eller næsten identiske sider, der udløser Soft-404-detektoren.
Adskil noindex, robots og statuskoder tydeligt
noindex er et indholdssignal, statuskoden er et transportsignal. Jeg undgår blandede former, der forvirrer crawlere: ingen 301 på en noindex-side, ingen 200 med „adgangsbegrænset“ placeholder, hvis ressourcen ikke eksisterer. Enten er en side indekserbar (200 + indeks), eller også er den fjernet (404/410) eller midlertidigt utilgængelig (503 med Retry-After). robots.txt blokerer kun crawling – ikke indeksering af allerede kendte URL'er. Derfor sætter jeg for virkelig fjernet indhold 404/410 i stedet for robotspærringer.
Nøgletal og tærskelværdier, som jeg overvåger
- 5xx-rate: Permanent betydeligt under 0,1%. Undersøg straks spidser.
- 4xx-rate: afhængigt af webstedstype under 1–2%. Interne 4xx bør gå mod 0%.
- 3xx-andel: så lav som muligt; Omdirigeringskæder til 0.
- 304-andel For aktiver: høj er godt – indikator for velfungerende caching.
- TTFB for HTML: stabilt lavt; jeg korrelerer afvigelser med 5xx/429.
- Sitemap-Sundhed: 200, gyldig lastmod, ingen døde links.
- Paritet Mobil vs. desktop: samme statuskoder og endelige URL'er.
Jeg knytter disse målinger til implementeringer, trafikspidser og infrastrukturbegivenheder. På den måde kan jeg genkende mønstre, der Kravl budget påvirke længe før rangeringerne reagerer.
Edge-cases: 1xx, 405, 410 vs. 404
1xx-Svar er praktisk talt irrelevante for SEO; jeg sørger blot for, at serveren og CDN opgraderes korrekt (f.eks. HTTP/2/3). 405 Metode ikke tilladt opstår, når HEAD/POST er blokeret, selvom GET leverer 200 – dette er harmløst, men bør konfigureres konsekvent. Ved valg af 404 mod 410 bruger jeg 410 til bevidst fjernet indhold med permanent karakter, 404 til ukendte eller utilsigtet linkede stier. Det er vigtigt at Konsistens, så crawlere kan lære af tilbagevendende mønstre.
Rollback-strategier og fejlsikkerhed
Jeg planlægger udgivelser, så jeg hurtigt kan vende tilbage, hvis der opstår fejl i statuskoderne: Blå/grøn-Implementeringer, finmaskede feature-flags og reversible omskrivningsregler. Til vedligeholdelse bruger jeg Vedligeholdelsessider, der leverer 503, mens baggrundsopgaver kører. På infrastrukturniveau har jeg sundhedstjek, automatiske genstarter og hastighedsbegrænsninger, der opfanger angreb uden at lamme legitim crawling. Hver foranstaltning har til formål at, 200/304 at maksimere og holde 4xx/5xx kontrolleret, kort og forståeligt i tilfælde af fejl.
Resumé: Rene signaler, hurtigere crawling
Jeg sørger for, at alle Statuskode bærer et klart budskab: 2xx for indhold, 3xx uden kæder, 4xx for fjernede sider og 5xx kun i helt særlige tilfælde. Caching med 304 aflaster serveren, mens konsistente 200-svar giver botten tillid. For at det skal fungere, kombinerer jeg loganalyser, GSC-data og tilbagevendende crawls. På host-siden holder jeg svartiderne lave, sætter fornuftige grænser og planlægger vedligeholdelsen omhyggeligt. På den måde øges kvaliteten, indekserbarheden og synligheden – og det Kravl budget flyder derhen, hvor det giver mest.
