HTTP státuszkódok: teljes útmutató

A HTTP státuszkód egy háromjegyű szám, amelyet a szerver minden kérésre visszaküld, és amely megmondja, mi történt: sikeres válasz (2xx), átirányítás (3xx), kliensoldali hiba (4xx) vagy szerverhiba (5xx). A kereső ebből dönti el, indexelje-e az oldalt, kövesse-e az átirányítást, vagy később próbálkozzon újra. A helyes kód a technikai SEO alapja.

Alapfogalmak

Amikor egy böngésző vagy egy keresőrobot lekér egy URL-t, a szerver válasza két részből áll. Az első a fejléc, amelyben a státuszkód és egyéb technikai információk utaznak, a második a törzs, vagyis maga az oldal. A felhasználó a törzset látja, a státuszkódot szinte soha. A kereső számára viszont a kód az első és legfontosabb jelzés: még mielőtt a tartalmat feldolgozná, a kódból tudja, hogy van-e értelme egyáltalán foglalkozni vele.

A státuszkódokat a HTTP szabvány határozza meg. Az első számjegy jelöli az osztályt, a további kettő a pontos esetet. Nem kell mindegyiket fejből tudni. A SEO gyakorlatban alig egy tucat kód fordul elő rendszeresen, és ezek viselkedését kell pontosan érteni.

A státuszkód-osztályok

Osztály	Jelentés	Példák	SEO-következmény röviden
1xx	Tájékoztató válasz, a kérés feldolgozása folyik	100 Continue	A SEO gyakorlatban nem játszik szerepet
2xx	Sikeres válasz	200 OK, 204 No Content	A 200-as oldal tartalma indexelhető
3xx	Átirányítás, a tartalom máshol van	301, 302, 304, 307, 308	A kereső követi, a kódtól függ, melyik URL marad az indexben
4xx	Kliensoldali hiba	404, 410, 403, 429	Az URL nem indexelhető, idővel kikerül
5xx	Szerveroldali hiba	500, 502, 503, 504	A kereső lassít, tartós hibánál az URL kikerül

A SEO-ban leggyakoribb kódok

200 OK. Az oldal létezik és kiszolgálható. Ez az egyetlen kód, amelynek tartalmát a kereső indexeli.
301 Moved Permanently és 308 Permanent Redirect. Végleges átirányítás. A kereső az új URL-t tekinti a jövőben a tartalom címének.
302 Found és 307 Temporary Redirect. Átmeneti átirányítás. A kereső általában megtartja az eredeti URL-t, bár hosszan fennálló átmeneti átirányításnál a Google idővel véglegesként kezelheti.
304 Not Modified. A tartalom nem változott az előző lekérés óta, a kliens használhatja a tárolt változatot. Feltételes kérésekre adott válasz.
404 Not Found. Az URL-en nincs tartalom.
410 Gone. A tartalom megszűnt, és nem tér vissza.
403 Forbidden. A szerver megtagadja a hozzáférést.
429 Too Many Requests. A kliens túl sok kérést küldött rövid idő alatt.
500, 502, 503, 504. Különböző szerveroldali hibák, a karbantartásnál használt 503-mal együtt.

Mi nem státuszkód?

A hibaüzenet szövege nem státuszkód. Egy „Az oldal nem található" felirat 200-as kóddal is kimehet, és ilyenkor a kereső sikeres választ kap. Ugyanígy a meta refresh vagy a JavaScript-alapú átirányítás sem 3xx kód: ezek a tartalomban történnek, nem a szerver válaszában. A kereső többnyire ezeket is követi, de a szerveroldali átirányítás a legegyértelműbb jelzés.

Miért a kód, és nem a tartalom?

Felmerülhet a kérdés, miért nem elég, ha a kereső egyszerűen elolvassa az oldalt. A válasz a mennyiség. Egy kereső naponta rengeteg URL-t kér le, és a státuszkód alapján olcsón el tudja dönteni, melyikkel kell tovább foglalkoznia. Egy 404 vagy egy 301 után nem kell tartalmat elemezni, renderelni, összehasonlítani. Ha a kód megbízható, a kereső az erőforrásait a valódi tartalomra fordíthatja. Ha nem az, minden oldalt alaposabban kell megvizsgálnia, és ez a webhelyen is lassabb feltérképezést eredményez.

Hogyan működik?

A kereső minden lekért URL-nél először a státuszkódot értékeli. A döntés innen elágazik. 200-as kódnál a tartalom feldolgozásra kerül, szükség esetén renderelés után, és a kereső eldönti, bekerüljön-e az indexbe. 3xx kódnál a kereső megnézi az átirányítás célját, és azt is lekéri. 4xx kódnál az URL-t nem indexeli, a már indexelt változatot idővel eltávolítja. 5xx kódnál átmeneti hibát feltételez, lassít, és később újra próbálkozik.

A 200-as válasz nem garancia

A 200-as kód azt jelenti, hogy az oldal indexelhető, de nem azt, hogy indexelésre is kerül. A kereső a tartalmat is megvizsgálja. Ha a 200-as oldal valójában hibaoldal vagy üres, soft 404-ként sorolja be. Ha noindex utasítás szerepel rajta, nem indexeli. Ha a canonical egy másik URL-re mutat, az is befolyásolja, melyik cím kerül be. A státuszkód tehát az első kapu, nem az egyetlen.

Az átirányítások működése

Átirányításnál a szerver a státuszkód mellett egy Location fejlécet is küld, amely megadja az új címet. A kereső ezt lekéri, és ha az is átirányít, továbbhalad. Több lépésből álló átirányítási lánc lassítja a feltérképezést és a felhasználót is, egy bizonyos lépésszám felett pedig a Googlebot abbahagyja a követést. Ha a lánc önmagába tér vissza, átirányítási hurok keletkezik, és a céloldal soha nem töltődik be. A végleges és az átmeneti átirányítás közötti különbség pedig abban áll, hogy melyik URL-t tekinti a kereső a tartalom elsődleges címének.

A 404 és a 410 viszonya

Mindkét kód azt jelzi, hogy az URL-en nincs tartalom. A 410 kifejezetten azt mondja, hogy a tartalom szándékosan és véglegesen szűnt meg. A Google a gyakorlatban mindkettőt hasonlóan kezeli, a 410 legfeljebb valamivel gyorsabban vezethet az URL eltávolításához. Ha biztosan tudod, hogy a tartalom nem tér vissza, a 410 a pontosabb jelzés, de a 404 sem hiba.

Kidolgozott példa: egy URL útja négy kóddal

Egy cikk eredetileg a /blog/regi-cim/ címen élt. Átnevezéskor a csapat 302-es átirányítást állított be az új címre, mert nem gondolt a különbségre. Később az új cím is módosult, és ide is került egy átirányítás, így két lépéses lánc keletkezett. Amikor a cikket végül megszüntették, az utolsó URL 200-as kóddal „a cikk nem érhető el" szöveget mutatott. A kereső szemszögéből a történet zavaros volt: átmeneti átirányítás, lánc, majd egy hibaoldal sikeres kóddal. A rendbetétel egyszerű lett: a régi címekről egyetlen 301 mutat egy releváns, élő cikkre, ahol pedig nincs ilyen, ott 410 áll.

A 304 és a feltételes kérések

A kereső egy már ismert URL-t gyakran feltételes kéréssel kér le: jelzi, mikor látta utoljára, vagy milyen azonosítója volt a tárolt változatnak. Ha a tartalom azóta nem változott, a szerver 304 Not Modified választ adhat tartalom nélkül. Ez mindkét félnek erőforrást takarít meg. A 304 helyes működéséhez a szervernek pontosan kell kezelnie a Last-Modified és az ETag fejléceket. Ha ezek hibásak, például a szerver minden kérésnél új módosítási időt küld, a feltételes kérés nem hozza meg a megtakarítást.

Fő módszerek

A státuszkódok helyes kezelése nem egyetlen beállítás, hanem egy sor szabály, amelyet a webhely egész életén át be kell tartani. A módszerek lényege, hogy minden helyzetnek legyen előre eldöntött, helyes válasza, és a rendszer ezt következetesen adja vissza.

1. Kódválasztás helyzet szerint

Helyzet	Helyes kód	Megjegyzés
Az oldal él, indexelhető	200	A tartalom legyen valódi, ne hibaüzenet
Az oldal véglegesen új címre költözött	301 vagy 308	Közvetlenül a végső címre mutasson
Az oldal ideiglenesen máshol érhető el	302 vagy 307	Csak ha valóban visszatér az eredeti cím
Az oldal nem létezik	404	Egyedi hibaoldal is lehet, de a kód legyen 404
Az oldal végleg megszűnt	410	Akkor, ha biztos, hogy nem tér vissza
Tervezett karbantartás	503	Retry-After fejléccel, rövid ideig
Belépéshez kötött tartalom	401 vagy 403	A kereső ezt nem indexeli

2. Egyetlen lépéses átirányítás

Minden átirányítás közvetlenül a végső, 200-as kódú URL-re mutasson. Ha egy költözésnél a régi átirányítások egy újabb átirányításra futnak, frissítsd őket, hogy kihagyják a közbenső lépést. A belső linkek pedig eleve a végső címre mutassanak, ne átirányításon keresztül.

3. Egységes URL-forma

Sok felesleges átirányítás abból fakad, hogy ugyanaz az oldal több alakban is elérhető: http és https, www-vel és nélküle, perjellel és anélkül a végén. Döntsd el, melyik a hivatalos forma, a többit egyetlen 301-gyel irányítsd rá, és a belső linkek, a sitemap és a canonical mind ezt a formát használják.

4. Hibakódok a sablonban

A tartalomkezelő vagy az alkalmazás sablonjának kell tudnia, mikor melyik kódot adja vissza. Ha egy termék, cikk vagy kategória nem létezik, a sablon 404-et adjon, ne 200-at üres tartalommal és ne 500-at egy kezeletlen hiba miatt. Ezt egyszer kell jól beállítani, és utána minden új oldalra érvényes.

Döntési szabály

Ha nem tudod eldönteni, melyik kódot használd, tedd fel a kérdést: mit akarok, hogy a kereső az URL-ről gondoljon? Ha azt, hogy él és értékes: 200. Ha azt, hogy máshol van, és ott is marad: 301. Ha azt, hogy most máshol van, de visszajön: 302. Ha azt, hogy nincs: 404. Ha azt, hogy végleg eltűnt: 410. Ha azt, hogy most nem elérhető, de hamarosan igen: 503.

Kidolgozott példa: a döntési szabály egy webáruházban

Egy webáruház négy tipikus helyzetre írt szabályt. Ha egy termék kifut, és van utódja, 301 mutat az utódra. Ha nincs utódja, de a kategóriája él, a termékoldal 410-et kap, a kategóriaoldalon pedig nem marad rá link. Ha egy termék csak átmenetileg nem kapható, az oldal 200-as kóddal él tovább, és a készletinformáció jelzi az állapotot. Ha egy akciós oldal néhány hétre egy szezonális gyűjtőoldalra vezet, 302-es átirányítás kerül rá, amelyet az akció végén levesznek. A szabályok leírása után a kódválasztás már nem egyéni döntés, hanem a folyamat része lett.

Gyakori hibák

A státuszkódokkal kapcsolatos hibák többsége nem látszik a böngészőben. Az oldal betöltődik, a felhasználó nem vesz észre semmit, a kereső viszont egészen mást kap, mint amit a csapat gondol. Ezért a legfontosabb szokás, hogy minden változtatás után a kódot is ellenőrizzük, ne csak a látványt.

Tipikus hibák

Hibaoldal 200-as kóddal. A soft 404 leggyakoribb oka. A kereső sikeres választ kap egy olyan oldalra, amely valójában hibaüzenet.
302 ott, ahol 301 kellene. Végleges költözésnél az átmeneti átirányítás zavaros jelzés, mert azt sugallja, hogy a régi cím visszatér.
Átirányítási láncok. Több egymásra épülő átirányítás, amely a költözések során halmozódott fel.
Tömeges átirányítás a főoldalra. Megszűnt tartalmaknál kényelmes megoldás, de a kereső sokszor soft 404-ként kezeli.
500 hiányzó tartalomra. Ha a sablon nem kezeli a nem létező elemet, szerverhibát ad 404 helyett, és ezzel eltorzítja a hibajelentéseket.
Karbantartási oldal 200-as kóddal. A kereső valódi tartalomnak tekintheti.

Tévhit: a 404 árt a webhelynek

Sokan úgy gondolják, hogy minden 404 büntetést hoz, ezért mindenáron el kell tüntetni. A valóságban a 404 a webhely normális működésének része. Ha egy URL soha nem létezett, vagy a tartalom megszűnt és nincs utódja, a 404 a helyes válasz. Gond akkor van, ha fontos, belső linkkel elért oldal ad 404-et, vagy ha a sok 404-et átirányításokkal próbálják elfedni.

Ellenpélda: a jó szándékú átirányítás

Egy webhely minden 404-es URL-t automatikusan a legközelebbi kategóriaoldalra irányított, abban a hitben, hogy így nem vész el forgalom. Az eredmény az lett, hogy a Search Console ezeknek jelentős részét soft 404-ként jelezte, a felhasználók pedig olyan oldalakra kerültek, amelyek nem feleltek a keresésükre. Az átirányításokat felülvizsgálták: ahol volt valódi megfelelő, ott 301 maradt, a többi URL visszakapta a 404-es kódot.

Rejtett hiba: a 403 és a tűzfal

Egy kevésbé ismert hiba, amikor egy biztonsági szolgáltatás vagy tűzfal a keresőrobotot tévesen gyanús forgalomnak ítéli, és 403-as kóddal vagy egy ellenőrző oldallal válaszol neki. A böngészőből nézve minden rendben van, a kereső viszont nem jut hozzá a tartalomhoz. Ezt a Search Console URL-ellenőrzője és a szervernaplók mutatják meg. Ha a Googlebot kéréseire aránytalanul sok 403 érkezik, a biztonsági szabályokat kell felülvizsgálni.

Tévhit: a státuszkód csak a fejlesztő dolga

A kód beállítása technikai feladat, de a döntés, hogy melyik kód kell, tartalmi és üzleti kérdés. Hogy egy megszűnt termék oldala 301-et vagy 410-et kap, azt a termékért és a tartalomért felelős ember tudja megmondani. Ha a döntést teljesen a fejlesztőre hagyják, jó eséllyel a legegyszerűbb megoldás születik meg, és az ritkán a legjobb a keresőnek.

Mérés

A státuszkódok mérése egyszerű eszközökkel is elvégezhető. A lényeg, hogy rendszeres legyen, és hogy egyszerre nézd a kereső szemszögét és a webhely valós viselkedését. A Search Console, egy feltérképező eszköz és a szervernaplók együtt adnak teljes képet.

Egy-egy URL ellenőrzése

Egy konkrét cím kódját gyorsan ellenőrizheted a böngésző fejlesztői eszközeinek hálózati fülén, vagy parancssorból egy fejléceket lekérő hívással. Az átirányításoknál nézd meg a teljes útvonalat: hány lépés van, és milyen kóddal végződik. A Search Console URL-ellenőrzője azt is megmutatja, milyen kódot kapott a Google, és melyik URL-t választotta elsődlegesnek.

A teljes webhely ellenőrzése

Egy feltérképező eszköz végigjárja a belső linkeket, és minden URL-hez rögzíti a kódot. Ebből kiderül, hány belső link mutat átirányításra vagy hibaoldalra, hol vannak láncok és hurkok. A Search Console oldal-indexelési jelentése az URL-eket okok szerint csoportosítja, a feltérképezési statisztikák pedig a válaszok megoszlását mutatják kódosztályok szerint. A szervernaplók megmutatják, milyen kódokat kapott ténylegesen a Googlebot.

Ellenőrzőlista

Ellenőrzés	Mit nézel	Elfogadható eredmény
Nem létező URL	Véletlen cím kódja	404 vagy 410
Belső linkek	Átirányításra vagy hibára mutató linkek	A belső linkek 200-as oldalra mutatnak
Átirányítások	Lépésszám, kód, cél	Egy lépés, a végleges költözés 301 vagy 308
URL-formák	http/https, www, perjel	Egy hivatalos forma, a többi rá irányít
Karbantartás	Karbantartási mód kódja	503
Sitemap	A sitemapban szereplő URL-ek kódja	Csak 200-as, indexelhető URL-ek

Kidolgozott példa: kódaudit egy webhelyköltözés után

Egy cég új tartalomkezelőre költöztette a webhelyét. A költözés után a csapat feltérképezte a régi URL-listát, és minden címre rögzítette a kódot és a végcélt. Három csoport rajzolódott ki. Az első csoportban minden rendben volt: egy lépésben, 301-gyel jutott el a régi cím az újra. A második csoportban kétlépéses láncok voltak, mert a régi rendszerben is maradtak korábbi átirányítások. A harmadik csoport 404-et adott, mert ezekhez az oldalakhoz senki nem rendelt új címet. A láncokat egy lépésre rövidítették, a 404-es csoportnál pedig egyenként eldöntötték, melyik kap releváns átirányítást, és melyik maradhat 404. A sitemapból minden nem 200-as URL kikerült.

Mérési ritmus

A státuszkódok ellenőrzését érdemes a webhely életének eseményeihez kötni. Minden költözés, sablonváltás, nagyobb tartalomtörlés és URL-szerkezet-módosítás után teljes feltérképezés indokolt. Ezen kívül havonta érdemes átnézni a Search Console jelentéseit, és negyedévente egy teljes belső linkellenőrzést futtatni. A legtöbb státuszkód-probléma nem egyik napról a másikra jelenik meg, hanem lassan halmozódik fel: egy-egy elfelejtett átirányítás, egy törölt oldal, amelyre még mutat link. A rendszeres ellenőrzés ezt a lassú romlást állítja meg.

A mérés eredményét érdemes egy egyszerű táblázatban vezetni: dátum, feltérképezett URL-ek száma, kódosztályonkénti megoszlás, átirányításra mutató belső linkek, láncok. Így egy-egy változás hatása azonnal látszik, és nem kell emlékezetből megítélni, romlott vagy javult a helyzet.