Hoppa till innehåll 
HTTP-statuskoder styra hur crawlers gör förfrågningar, laddar innehåll och om sidor överhuvudtaget hamnar i sökningen. Jag visar hur svar som 200, 301, 404 eller 503 påverkar crawlingen, crawlbudgeten och hostingen och var typiska bromsklossar finns.
Centrala punkter
- Budget för genomsökning hänger direkt på korrekta statussvar.
- 2xx/3xx möjliggöra indexering, blockera 4xx/5xx.
- Vidarebefordran Använd endast utan kedjor och öglor.
- Servertider och drifttid skapar förtroende för sökrobotar.
- Övervakning med loggar, GSC och crawlers.
Varför statuskoder styr crawlingen
Crawlers kontrollerar först Statuskod, först därefter följer rendering och utvärdering av innehållet. Jag prioriterar därför korrektheten i svaret före titeltaggar eller interna länkar. En 200 OK laddar innehållet omedelbart, medan 4xx och 5xx kostar tid, budget och förtroende. Om felen hopar sig minskar boten hämtningarna och fördröjer registreringen av nytt innehåll. Detta leder till tysta SEO-förluster, som kan undvikas med tydliga regler för Server-svar undvika.
2xx: Den direkta vägen till indexet
200 OK är för crawlers en Grönt ljus. Jag levererar 200 endast till äkta sidor med fullständigt innehåll och förhindrar Soft-404:or, som visserligen skickar 200, men inte erbjuder något mervärde. Tunna innehåll, saknade H1 eller nästan identiska texter är varningssignaler för sådana felkonfigurationer. Den som rensar upp här sparar crawlbudget och stärker den tematiska relevansen. Dessutom optimerar jag snippets och interna länkar så att crawlers och användare med en uppmaning nå rätt mål.
3xx: Vidarebefordringar utan förlust
301 flyttar innehåll permanent och överför signaler till den nya URL:en, medan 302 står för en tillfällig lösning. Jag använder 301 när innehållet verkligen har flyttats och jag tar bort kedjor och loopar, eftersom varje extra hopp kostar tid och pengar. Kontrollera interna länkar, eftersom en intern 301-kedja är en självskapad trafikstockning. För flyttar planerar jag konsekventa regler så att allt pekar i en rak linje mot mål-URL:en. Varför detta är så viktigt visar jag på Omdirigeringskedjor, som mätbart påverkar laddningstiden och crawlingen.
4xx: Tydliga signaler för borttaget innehåll
En 404 meddelar tydligt: Denna Resurs finns inte. Jag låter 404 stå kvar för sidor som verkligen har tagits bort och undviker soft-404 genom att aldrig skicka 200 vid felsidor. 410 signalerar ännu tydligare att en sida har tagits bort permanent; för gamla URL:er utan passande alternativ använder jag detta specifikt. Interna länkar till 404 slösar bort budget, därför korrigerar jag dem snabbt eller omdirigerar dem till det bästa tematiska alternativet. På så sätt håller jag kvar crawlers på de sidor som är äkta. Värde leverera.
5xx: Serverfel bromsar bots och användare
5xx betyder: Servern kunde inte behandla förfrågan. betjäna. Vid upprepade fall klassificerar crawlers webbplatsen som opålitlig och besöker den mindre ofta. För underhåll använder jag 503 med „Retry-After“ så att bots vet när det är lämpligt att försöka igen. Om en 503 kvarstår utvärderar jag loggarna och åtgärdar flaskhalsar i CPU, RAM, databas eller hastighetsbegränsningar. För WordPress samlar jag praktiska tips i denna guide om 503-fel, så att underhållsfönstren förblir kontrollerade och korta.
Caching, 304 och ETags: Spara pengar utan risker
304 Not Modified sparar Bandbredd, eftersom klienten får fortsätta använda sin kopia. Jag ställer in ETag eller Last-Modified korrekt så att crawlers kan använda If-Modified-Since korrekt. På så sätt minskar antalet hämtningar av oförändrade CSS, JavaScript och bilder. Om logiken inte stämmer laddar boten onödigt många filer eller missar uppdateringar. Därför testar jag varianter, kontrollerar svarhuvuden och håller 304-svaren konsekventa över alla Tillgångar.
Crawl-budget: Så håller jag den hög
Crawlbudgeten beror på tre faktorer: kodkvalitet, Prestanda och intern struktur. Jag minskar tidskrävande faktorer som vidarebefordringskedjor, dubbelt innehåll och långsam TTFB. Jag leder interna länkar till få, tydliga sökvägar så att bots snabbare kan identifiera prioriteringar. Jag korrigerar felaktiga eller övergivna sidor snabbt innan de drar på budgeten. Detta inkluderar även statuskoder för paginering, kanoniska adresser och hreflang, som utan felsignaler måste springa.
Hostingfaktorer som påverkar statuskoder
Bra hårdvara, ren serverkonfiguration och kapacitetsanpassad Caching förhindra 5xx-toppar. Jag ser till att det finns tillräckligt med PHP-arbetare, databasparametrar, Keep-Alive och HTTP/2 eller HTTP/3. Även hastighetsbegränsningar för bots bör vara rimligt inställda så att riktiga användare inte blockeras. Vid höga belastningstoppar hjälper edge-cacher och regler för statiska tillgångar. Här visar jag varför statuskoder och hostingprestanda hänger ihop: HTTP-status och serverkraft.
Övervakning: Använd loggar, GSC och crawlers på rätt sätt
Jag börjar med serverloggar eftersom de är äkta Förfrågningar och antecknar varje svar. Därefter kontrollerar jag Search Console för täckningsfel, sitemaps och renderingsstatus. En desktop- och mobilcrawl med en SEO-crawler upptäcker omdirigeringar, 4xx och 5xx i ett svep. För djupgående analyser korrelerar jag fel med tidpunkter för releaser eller trafiktoppar. Det visar om en rollout, ett plugin eller ett CDN-regelverk är orsaken till Svar på frågor har förändrats.
Snabböversikt: Statuskoder och åtgärder
Följande tabell ordnar typiska svar efter lämpliga åtgärder och lyfter fram viktiga punkter. Jag använder den som en kompass för snabba beslut i vardagen.
| Statuskod | Crawler-reaktion | Åtgärd | Information om webbhotell |
|---|---|---|---|
| 200 OK | Innehåll hämtas och utvärderas | Leverera äkta innehåll, undvik Soft-404 | Håll TTFB låg, cache varm |
| 301 Flyttad permanent | Signaler till mål-URL | Ta bort kedjor, uppdatera interna länkar | Håll omskrivningsreglerna tydliga |
| 302 Hittat | Tillfällig, källan behåller signaler | Använd endast under kort tid | Kontrollera regelbundet |
| 304 Ej modifierad | Använd cache, ingen nedladdning | Ställ in ETag/Last-Modified korrekt | Leverera tillgångar via CDN |
| 404 Hittades inte | URL tas bort från indexet | Korrigera interna länkar, undvik Soft-404 | Håll felsidan smal |
| 410 Borta | Snabbare borttagning | Använd för permanent borttaget innehåll | Vidarebefordran endast vid verkligt alternativ |
| 500 Internt fel | Bot minskar antalet besök | Kontrollera loggar, åtgärda orsaken | Öka resurser och gränser |
| 503 Tjänsten är inte tillgänglig | Underhållsläge accepterat | „Ställ in “Retry-After" och håll tiden kort | Planera underhållsfönster |
Felhantering: Vad jag kontrollerar först
Jag börjar med Omfattning: Berör felet alla användare, bara bots eller bara mobila enheter? Därefter kontrollerar jag om den senaste ändringen gjordes på servern, i applikationen eller i CDN. Om felet bara uppstår under belastning ökar jag resurserna på kort sikt och söker efter flaskhalsar i spårningarna. Vid återkommande 5xx-fel ställer jag in varningar på loggmönster och statusändpunkter. På så sätt löser jag akuta problem snabbt och förhindrar att de påverkar Budget för genomsökning sänka ytterligare.
Tekniska kontroller före lanseringar
Innan varje lansering testar jag kritiska vägar med ett Iscensättning-Crawla och jämför statuskoder med live-varianten. Jag har en lista med viktiga URL:er: startsida, kategori, produkt, filter, sökning, sitemap, API. Därefter kontrollerar jag rubriker som Cache-Control, Vary, omdirigeringsregler och kanoniska adresser. För funktionsflaggor sätter jag tydliga villkor så att de inte oavsiktligt genererar 302 eller 404. Först när statuskoder, laddningstider och renderingsresultat verkar stabila ger jag klartecken. Release gratis.
robots.txt, webbplatskartor och sekundära URL:er
Jag kontrollerar först om robotar.txt stabilt med 200 svar. 5xx eller 403 på robots.txt gör crawlarna osäkra och bromsar crawlingen. Ett 404 på robots.txt betraktas visserligen som „ingen begränsning“, men är ett dåligt tecken för webbplatser med crawlproblem. För Webbplatskartor Jag accepterar endast 200 och håller filerna små, rena gzippade och med korrekta lastmod-fält. 3xx till webbplatskartan är tekniskt tillåtna, men jag undviker dem till förmån för ett direkt 200-svar. För Feeds, AMP- eller API-Resurser ser jag till att de inte returnerar 404 eller 5xx när HTML-sidan levererar 200 – annars avbryts renderingen eller utvärderingen av strukturerade data på ett inkonsekvent sätt.
Canonical, Hreflang och paginering endast på 200
Signaler som rel=kanonisk, hreflang eller paginering fungerar bara om mål- och referens-URL:er laddas med 200 slutgiltigt. Jag undviker kanoniska länkar på 3xx, 404 eller noindex-URL:er, eftersom det förvirrar sökroboten. För hreflang kontrollerar jag bakåtreferens och att varje variant slutligen slutar på 200. Pagerade listor (page=2,3,…) måste leverera stabilt 200; jag förhindrar att tomma sidor utlöser Soft-404 genom att erbjuda tydligt innehåll och interna vidarebefordringar vid saknade resultat, men ändå skicka rätt status.
429 och använda hastighetsbegränsningar på rätt sätt
429 För många förfrågningar är mitt verktyg för finjusterad strypning när enskilda bots är för aggressiva. Jag sätter Försök igen efter med en rimlig tidsangivelse så att sökrobotar kan fördela sina förfrågningar. 429 ersätter inte 503-underhåll och bör aldrig påverka legitima användare. I WAF eller CDN differentierar jag efter användaragent, IP och sökvägar så att medieobjekt fortsätter att levereras med 200/304 medan HTML kortvarigt begränsas. Viktigt: 429 får inte bli permanent – annars bedömer botten webbplatsen som svåråtkomlig och sänker budgeten.
401/403/451: avsiktligt blockerad – men konsekvent
401 Jag använder det för inloggningsskyddade områden, 403 för otillåten åtkomst. Jag ser till att dessa svar inte av misstag gäller Googlebot, till exempel genom strikta botfilter. Vid geografiska blockeringar eller juridiska krav använder jag 451 och dokumentera orsakerna internt. Jag avstår från 200-svar med interstitials („åtkomst nekad“) – sådana sidor fungerar som mjuka 404-fel. Om det finns alternativ länkar jag tydligt till tillgängligt innehåll och låter den blockerade URL:en skicka rätt 4xx-status.
Paritet mellan svaren: mobil, stationär och dynamisk visning
Jag ser till att mobila och stationära botar har samma Statuskoder se. Dynamiska uppspelningar (A/B-tester, funktionsflaggor, geoinnehåll) får inte utlösa 302/403 för enskilda användaragenter. Jag använder Varierande-Använd rubriker sparsamt och medvetet (t.ex. Accept-Language) för att undvika onödiga cache-splits, och se till att varje sökväg för alla varianter konsekvent slutar på 200/304. Paritetsbrott leder till indexeringsproblem om boten ser en 404 medan användarna får 200 – sådana fall eliminerar jag med tydliga regler och tester per variant.
HEAD, OPTIONS och API-slutpunkter
Många sökrobotar skickar HEAD-Förfrågningar för att kontrollera tillgänglighet och storlek. Min server svarar på dessa med samma logik som på GET – bara utan body. Jag undviker 405 på HEAD om GET levererar 200. OPTIONER och CORS-Preflights hanterar jag så att tillgångar från tredjepartskällor kan laddas på ett korrekt sätt. För API-slutpunkter, När det gäller API:er som levererar data vid rendering, ser jag till att 200/304 är stabila och att 4xx är tydliga vid verkliga fel. Om API:er sporadiskt levererar 5xx markerar jag detta separat i loggarna, eftersom det kan förklara renderingsfel under huven, även om HTML-sidan skickar 200.
CDN-regler, Stale-strategier och 5xx-skydd
I CDN cachar jag 200, 301 och statiska 404 kontrollerat – men jag förhindrar att 503 eller admin-sidor hamnar i cachen. Med stale-om-fel kan jag överbrygga kortvariga 5xx utan att bots ser fel. Jag sätter Kontroll av surrogat för Edge-signaler och håller TTL:er för HTML kortare än för tillgångar. Jag konfigurerar ETags klustersäker (antingen samma överallt eller inaktiverat) så att 304 fungerar tillförlitligt och inte förfaller på grund av avvikande hashvärden. Viktigt: Vidarebefordringar (301/302) bör inte cachelagras i CDN för alltid, annars kvarstår gamla sökvägar som kedjor.
E-handelsfall: Slutsålda produkter, varianter, filter
Om produkter tillfälligt inte är tillgängliga förblir produktsidan på 200 med tydlig märkning och meningsfulla interna vidareförfaranden (kategori, alternativ). För produkter som tas bort permanent väljer jag mellan 301 till den bästa ersättnings-URL:en (endast vid verklig motsvarighet) och 410, om det inte finns något lämpligt alternativ. Jag undviker massomdirigeringar till startsidan, eftersom de fungerar som Soft-404s. För Filter- och parameter-URL:er Jag använder tydliga regler: Endast indexrelevanta kombinationer på 200, allt annat via 301 till den kanoniska URL:en eller med noindex – men aldrig 200 för tomma eller nästan identiska sidor som triggar Soft-404-detektorn.
Separera noindex, robotar och statuskoder på ett tydligt sätt
inget index är ett innehållssignal, statuskoden är ett transportsignal. Jag undviker blandformer som förvirrar crawlers: ingen 301 på en noindex-sida, ingen 200 med „begränsad åtkomst“-platshållare om resursen inte finns. Antingen är en sida indexerbar (200 + index) eller så är den borttagen (404/410) eller tillfälligt otillgänglig (503 med Retry-After). robots.txt blockerar endast crawling – inte indexering av redan kända URL:er. Därför använder jag för verkligen borttaget innehåll 404/410 istället för robotbarriärer.
Nyckeltal och tröskelvärden som jag observerar
- 5xx-frekvens: permanent betydligt under 0,1%. Undersök spikar omedelbart.
- 4xx-frekvens: beroende på webbplatstyp under 1–2%. Interna 4xx bör gå mot 0%.
- 3xx-andel: så låg som möjligt; Omdirigera kedjor till 0.
- 304-andel för tillgångar: hög är bra – indikator på fungerande caching.
- TTFB för HTML: stabilt lågt; avvikelser korrelerar jag med 5xx/429.
- Sitemap-Hälsa: 200, giltig lastmod, inga döda länkar.
- Paritet Mobil vs. stationär: samma statuskoder och slutliga URL:er.
Jag kopplar dessa mätvärden till distributioner, trafiktoppar och infrastrukturhändelser. På så sätt kan jag identifiera mönster som påverkar Budget för genomsökning påverka långt innan rankningarna reagerar.
Gränsfall: 1xx, 405, 410 vs. 404
1xx-Svaren är praktiskt taget irrelevanta för SEO; jag ser bara till att servern och CDN uppgraderas korrekt (t.ex. HTTP/2/3). 405 Metod tillåten uppstår när HEAD/POST är blockerade, även om GET 200 levererar – detta är ofarligt, men bör konfigureras konsekvent. Vid valet 404 mot 410 Jag använder 410 för avsiktligt borttaget innehåll med permanent karaktär och 404 för okända eller felaktigt länkade sökvägar. Det är viktigt att Samstämmighet, så att sökrobotar kan lära sig av återkommande mönster.
Rollback-strategier och driftsäkerhet
Jag planerar releaser så att jag snabbt kan gå tillbaka vid felaktiga statuskoder: Blå/Grön-Distributioner, finfördelade funktionsflaggor och reversibla omskrivningsregler. För underhåll använder jag Underhållssidor, som levererar 503 medan bakgrundsjobb körs. På infrastrukturnivå har jag hälsokontroller, automatiska omstarter och hastighetsbegränsningar som fångar upp attacker utan att lamslå legitim crawling. Varje åtgärd syftar till att, 200/304 maximera och hålla 4xx/5xx kontrollerade, korta och begripliga vid störningar.
Sammanfattning: Rena signaler, snabbare genomsökning
Jag ser till att alla Statuskod har ett tydligt budskap: 2xx för innehåll, 3xx utan kedjor, 4xx för borttagna sidor och 5xx endast i verkliga undantagsfall. Caching med 304 avlastar servern, medan konsekventa 200-svar ger botten förtroende. För att detta ska fungera kombinerar jag logganalyser, GSC-data och återkommande genomsökningar. På värdsidan håller jag svarstiderna låga, sätter rimliga gränser och planerar underhållet noggrant. På så sätt ökar kvaliteten, indexerbarheten och synligheten – och det Budget för genomsökning flödar dit där det ger mest nytta.
