A legfontosabb HTTP-kódok: 200, 301, 302, 404, 500

A HTTP-kódok néhány számjegybe sűrítve adnak hírt a weboldalad állapotáról. A 200-as kód sikeres lekérést, a 301 és 302 átirányítást, a 404 nem található tartalmat, az 500 pedig szerverhibát jelez. De mit kezdenek ezekkel a keresőmotorok, és melyek a legfontosabbak SEO-szempontból? Mutatjuk a legfontosabb infókat és a gyakorlati teendőket.

Mit jelentenek a különböző HTTP-kódok?

Amikor megnyitsz egy weboldalt, a böngésződ HTTP-kérést küld a weboldalt kiszolgáló szervernek. A szerver erre egy három számjegyből álló HTTP-státuszkóddal válaszol, amely jelzi, hogy a kérés sikeres volt-e, átirányításra van szükség, vagy valamilyen hiba történt.

A HTTP-kódok első számjegye határozza meg, hogy a válasz melyik kategóriába tartozik. Az RFC 9110 HTTP-szabvány öt fő csoportot különböztet meg:

HTTP-kód	Jelentése	Példa
1xx	Tájékoztató válaszok	100 Continue
2xx	Sikeres kérések	200 OK
3xx	Átirányítások és további műveletek	301 Moved Permanently
4xx	Kliensoldali hibák	404 Not Found
5xx	Szerveroldali hibák	500 Internal Server Error

A státuszkódok nemcsak azt befolyásolják, hogyan kezeli a böngésző a betöltést, az átirányításokat vagy a hibákat. A keresőoptimalizálásban is meghatározó szerepük van, hiszen a Googlebot ezekből is tájékozódik a weboldalak feltérképezésekor.

Nézzünk néhány gyakorlati SEO-példát:

• Átnevezel egy jól teljesítő blogcikket, és megváltozik az URL-je. Egy megfelelően beállított 301-es átirányítással jelezheted a Google-nek, hogy a tartalom végleg új címre költözött.
• Törölsz egy megszűnt terméket a webshopodból. Ha nincs megfelelő helyettesítő oldal, a 404-es válasz teljesen indokolt lehet.
• Egy WordPress-frissítés után 500-as hibát adnak az aloldalaid. Ha a probléma tartósan fennáll, a Google csökkentheti a feltérképezés gyakoriságát, és az érintett URL-ek idővel az indexből is kieshetnek.

A Google hivatalos dokumentációja ki is emeli, hogy az átirányítások az URL-ekhez kapcsolódó rangsorolási jelek, például a PageRank-ben is szerepet játszanak.

Az 1xx kódok tájékoztató jellegűek: azt jelzik, hogy a szerver megkapta a kérést, és a feldolgozás folytatódik.

Itt még bármi lehet. 

A feketeleves csak ezután következik. 

De kezdjük inkább a szerencsés esetekkel!

200 OK: A sikeres betöltés alapköve

A 2xx HTTP-kódok azt jelzik, hogy a szerver sikeresen fogadta, megértette és elfogadta a kliens kérését. Közülük a legismertebb a 200 OK státuszkód, amely lényegében annyit üzen: a kérés sikeresen teljesült, minden rendben.

Amikor például megnyitsz egy termékoldalt, a szerver jellemzően 200-as válaszkóddal küldi vissza a megjelenítéséhez szükséges HTML-dokumentumot. Ugyanez a kód érkezhet képek, PDF-fájlok vagy JSON-adatok sikeres lekérésekor is.

Miért fontos a 200-as státuszkód a SEO szempontjából?

A Googlebot számára a 200-as válasz azt jelzi, hogy a kért tartalom sikeresen lekérhető, így továbbítható az indexelési folyamat következő szakaszába. A keresőrobot az oldalon található hivatkozásokat is felfedezheti, amelyek a PageRank és más rangsorolási jelek továbbítása miatt fontos. A 200-as státuszkód tehát a hatékony belső linkelés előfeltétele. (És persze a külsőé is, csak erre általában kevés ráhatásod van.)

Van azonban egy fontos különbség: a 200 OK nem garantálja, hogy az oldal bekerül a Google indexébe.

Képzeld el, hogy létrehozol egy új webshopkategóriát, amely tökéletesen betöltődik, és 200-as státuszkódot ad vissza. Ha azonban az oldal noindex utasítást tartalmaz, a Google nem fogja indexelni.

Érdemes ezért a státuszkód mellett az oldal indexelhetőségét is ellenőrizni, például a Google Search Console URL-vizsgálatával.

A 200-as kóddal tehát beállhatsz az indexelt oldalak sorába, de azért a Google első helyére szóló VIP jegyre ne számíts. Attól, hogy a szerver elégedett a teljesítményével, a keresőmotor még nem feltétlenül lesz az.

301 és 302 státuszkódok: állandó és ideiglenes átirányítások

A 3xx HTTP-kódok azt jelzik, hogy a kért tartalom eléréséhez további műveletre van szükség. Leggyakrabban azért, mert az oldal másik URL-re költözött. Ilyenkor a szerver megadja az új címet, a böngésző pedig automatikusan követi az átirányítást.

A látogató ebből rendszerint semmit sem vesz észre. A Google számára viszont egyáltalán nem mindegy, hogy 301-es vagy 302-es átirányítást használsz. Az egyik végleges költözést jelent, a másik csak ideiglenes tartózkodást.

301-es átirányítás: végleges költözés

A 301 Moved Permanently azt jelzi, hogy az adott tartalom véglegesen új URL-re került. Akkor érdemes alkalmazni, ha például megváltoztatod egy blogcikk címét és URL-jét, átalakítod a webshopod kategóriastruktúráját, vagy új domainre költözteted a weboldaladat.

SEO-szempontból a 301-es átirányítás erős jelzés a Google számára, hogy az új URL-t tekintse elsődlegesnek (kanonikusnak). Ennek megfelelően idővel jellemzően az új cím jelenik meg a keresési találatokban.

302-es átirányítás: átmeneti költözés

A 302 Found ezzel szemben ideiglenes átirányítást jelent. Például akkor használhatod, ha egy oldal helyett átmenetileg másik verziót jelenítesz meg egy A/B teszt során, vagy ha egy szolgáltatás ideiglenesen nem érhető el.

A Google ilyenkor alapvetően az eredeti URL megtartását részesíti előnyben, mivel az átirányítást nem tekinti erős jelzésnek a kanonikus URL megváltoztatására. Más jelek alapján azonban az új cím is bekerülhet az indexbe.

A két megoldás közötti legfontosabb különbségek:

Szempont	301-es átirányítás	302-es átirányítás
Időtartam	Végleges	Ideiglenes
Tipikus alkalmazás	URL-változás, domainköltözés	A/B teszt, átmeneti helyettesítés
Google által előnyben részesített URL	Új URL	Jellemzően eredeti URL
Kanonizálási jelzés	Erős	Nem ad erős jelzést az új URL mellett

Mi történik a PageRankkel az átirányítás során?

Régi SEO-tévhit, hogy a 301-es átirányítás szükségszerűen csökkenti a továbbadott linkértéket. A Google webhelyköltöztetési dokumentációja egyértelművé teszi, hogy a 301-es és más végleges átirányítások önmagukban nem okoznak PageRank-veszteséget.

A régi URL-re mutató backlinkek rangsorolási jelei így átadódnak az új, kanonikus URL-nek, ezzel is megőrizve a korábban megszerzett weboldal-tekintélyt.

A 302-es átirányításnál viszont a Google azt gondolja, hogy a régi oldal hamarosan úgyis visszatér, ezért alapesetben a korábbi változatot preferálja. Ha viszont túl sokáig áll fenn az – eredetileg – ideiglenes átirányítás, előbb-utóbb az újat fogja kanonikusnak tekinteni.

A tanulság? Ha végleg elköltöztetsz egy oldalt, használj 301-es átirányítást, és frissítsd a belső hivatkozásokat is. Ha csak átmeneti megoldásról van szó, válaszd a 302-est.

Kliensoldali hibák: 404 Not Found

A 4xx HTTP-kódok azt jelzik, hogy a szerver nem tudja teljesíteni a kliens kérését. Ennek oka lehet egy elgépelt URL, hiányzó jogosultság vagy egyszerűen egy olyan tartalom, amely már nem létezik. Ebbe a csoportba tartozik például a 401 Unauthorized, a 403 Forbidden és a legismertebb, 404 Not Found státuszkód is.

A 404-es válasz azt jelenti, hogy a szerver ugyan sikeresen fogadta a kérést, de a megadott címen nem találja a keresett erőforrást. Ez lehet egy törölt blogcikk, megszűnt termékoldal, hiányzó kép vagy akár egy rosszul beállított belső hivatkozás.

Fontos azonban, hogy a 404-es státuszkód nem feltétlenül jelent technikai hibát. Bizonyos esetekben éppen ez a helyes szerverválasz.

Mikor jelent SEO-problémát a 404-es hibakód?

A SEO egyik makacs tévhite, hogy minden 404-es oldal káros a weboldal keresőbeli teljesítményére. Pedig a 404-es válasz önmagában nem jelent rangsorolási büntetést. A Google számára teljesen természetes, hogy egyes tartalmak idővel megszűnnek.

A Google hivatalos dokumentációja szerint a 404-es választ adó URL-eket a kereső nem indexeli, a korábban indexelt oldalakat pedig idővel eltávolítja a találatok közül. Ez azonban nem jelenti azt, hogy a weboldal többi URL-jének rangsorolása automatikusan romlana.

A probléma inkább akkor kezdődik, amikor egy értékes, korábban organikus forgalmat szerző oldal válik véletlenül elérhetetlenné.

Nézzünk néhány tipikus esetet:

• Megváltozik egy webshop kategóriaoldalának URL-je, de a régi címről elmarad a 301-es átirányítás. A Google továbbra is találkozhat a régi URL-lel, amely immár 404-es választ ad, miközben az új kategóriaoldalnak külön kell megszereznie a keresőbeli láthatóságát.
• Törölsz egy népszerű blogcikket, amelyre több releváns külső weboldal is hivatkozik. Ha nincs megfelelő helyettesítő tartalom vagy átirányítás, az eredeti URL-hez kapcsolódó értékes hivatkozási jeleket nem tudod egy új oldal javára konszolidálni.
• Egy belső link hibás URL-re mutat. A felhasználó zsákutcába kerül, a keresőrobot pedig olyan URL feltérképezésével foglalkozik, amelyen nincs hasznos tartalom.

Minden 404-es oldalt át kell irányítani 301-gyel?

Nem. A megfelelő megoldás attól függ, hogy mi történt az eredeti tartalommal.

Ha egy oldal végleg új URL-re költözött, vagy van egyértelműen releváns helyettesítője, akkor a 301-es átirányítás általában a legjobb választás. Ezzel a látogatókat a megfelelő tartalomhoz irányíthatod, miközben a Google számára is jelzed az új címet.

Ha viszont egy termék végleg megszűnt, és nincs valóban megfelelő alternatívája, a 404-es válasz teljesen indokolt. Ugyanez igaz egy olyan blogcikkre is, amelynek tartalma már nem aktuális, és nem érdemes frissíteni vagy helyettesíteni.

Arra viszont érdemes figyelni, hogy a megszűnt URL-eket ne irányítsd automatikusan a főoldalra. A Google webhelyköltöztetési útmutatója szerint a tartalmilag irreleváns céloldalakra mutató tömeges átirányításokat a kereső akár soft 404 hibaként is értelmezheti.

Attól, hogy minden út a főoldalra vezet, még nem lesz a weboldaladból Róma. Legfeljebb egy rosszul kitáblázott útvesztő.

Mi az a soft 404, és miért érdemes elkerülni?

A soft 404 olyan helyzet, amikor a szerver sikeres, jellemzően 200 OK HTTP-választ küld vissza, miközben az oldal valójában nem tartalmazza a keresett információt.

Képzelj el egy webshopot, ahol egy törölt termék URL-je továbbra is 200-as státuszkódot ad, de a látogató csak a „A keresett termék nem található” üzenetet látja. Technikai szempontból a szerver szerint minden rendben, a tartalom viszont egészen mást állít.

A soft 404 más helyzetekben is előfordulhat:

• Az oldal üres vagy szinte semmilyen érdemi tartalmat nem jelenít meg.
• Egy JavaScript-hiba miatt nem töltődik be a fő tartalom.
• A nem létező URL-ek egy általános hibaoldalt jelenítenek meg, de a szerver 200-as kódot küld.
• A megszűnt oldalak irreleváns céloldalra, például a főoldalra irányítanak át.

A Google algoritmusai a megjelenített tartalom alapján felismerhetik az ellentmondást, és az érintett URL-t soft 404-ként azonosíthatják. Az ilyen oldalakat kizárhatják a keresési indexből.

Ráadásul a soft 404-ek a feltérképezési erőforrásokat is feleslegesen használhatják, hiszen a keresőrobot olyan URL-ekre térhet vissza, amelyek valójában nem kínálnak értékes tartalmat.

A tanulság? Nem minden 404-es hibát kell kijavítani, és nem minden megszűnt oldalt kell megmenteni. A jó technikai SEO nem arról szól, hogy mindenáron eltüntesd a hibakódokat a riportokból, hanem arról, hogy a keresőmotorok és a felhasználók mindig a megfelelő választ kapják. Néha ez a válasz egyszerűen csak annyi: az oldal nem található.

Mit jelent az 500-as státuszkód, és hogyan bénítja meg a weboldalt?

Míg a 404-es hibánál a szerver nem találja a keresett tartalmat, az 500 Internal Server Error esetében már maga a kiszolgálás ütközik problémába. A szerver megkapta a kérést, de egy váratlan belső hiba miatt nem tudja teljesíteni.

Ide tartozik többek között az 502 Bad Gateway, az 503 Service Unavailable és az 504 Gateway Timeout is.

Az 500-as kód egyfajta gyűjtőválasz: akkor jelenhet meg, amikor a szerver olyan problémával találkozik, amelyre nem tud pontosabb hibakódot adni. Magyarán valami elromlott, de a szerver még a hiba természetéről sem tud sokkal többet mondani. Ezért sokak számára az 500-as státuszkód a legkevésbé megnyugtató üzenet.

Mi okozhat 500-as szerverhibát?

Az 500-as hibák hátterében számos technikai probléma állhat. A leggyakoribbak:

• Szoftveres és programozási hibák: hibás PHP-kód, nem kezelt kivételek, inkompatibilis WordPress-bővítmények vagy egy rosszul sikerült CMS-frissítés.
• Hibás szerverbeállítások: helytelen .htaccess szabályok, konfigurációs problémák vagy nem megfelelő fájljogosultságok.
• Adatbázis-problémák: megszakadó adatbázis-kapcsolat, hibás lekérdezések vagy túlterhelt adatbázis-szerver.
• Erőforráshiány: a PHP-memórialimit túllépése, túlterhelt szerver vagy a rendelkezésre álló számítási kapacitás kimerülése.

Hogyan hat az 500-as hiba a Google indexelésére és a rangsorolásra?

Az 500-as hibák SEO-szempontból különösen veszélyesek, mert a Googlebot ilyenkor nem kap feldolgozható tartalmat a kért URL-ről.

Képzelj el egy webshopot, ahol egy új bővítmény telepítése után a termékoldalak tömegesen 500-as hibával kezdenek válaszolni. A látogatók nem tudnak vásárolni, a keresőrobotok pedig nem férnek hozzá a termékadatokhoz.

Egyetlen félresikerült frissítés így egyszerre okozhat bevételkiesést és keresőoptimalizálási problémákat.

A Google HTTP-státuszkódokról szóló dokumentációja szerint ráadásul az 5xx válaszok hatására a keresőrobotok csökkenthetik a feltérképezés gyakoriságát. A csökkenés mértéke összefügg azzal, hogy hány URL ad vissza szerverhibát.

Ennek több következménye lehet:

• Lassuló feltérképezés: a Google ritkábban látogathatja meg az oldalakat, ami az új vagy frissített tartalmak felfedezését is késleltetheti.
• Indexelési problémák: a hibás URL-ek tartalmát a Google nem tudja feldolgozni, tartós elérhetetlenség esetén pedig a korábban indexelt oldalak is kikerülhetnek a keresési találatokból.
• Organikus láthatóság és forgalom csökkenése: ha az érintett oldalak eltűnnek a találatokból, megszűnhet az általuk generált keresési forgalom is.
• Romló felhasználói élmény: a látogatók nem jutnak hozzá a keresett információhoz, és nagyobb eséllyel hagyják el a weboldalt.

Fontos különbséget tenni az átmeneti és a tartós szerverhibák között. Egy rövid ideig fennálló 500-as válasz nem jelenti automatikusan az oldal indexből történő eltávolítását. A Google a már indexelt URL-eket kezdetben megőrizheti, és később újra megpróbálhatja lekérni őket.

Ez a türelmi idő viszont tényleg nagyon rövid ideig tart. A Google feltérképezési sebességről szóló útmutatója kifejezetten figyelmeztet arra, hogy az egy-két napnál tovább fennálló szerverhibák már az indexelést is veszélyeztethetik.

500-as hibajelzést észlelve tehát muszáj minél hamarabb beavatkoznod.

Hogyan ismerheted fel és javíthatod az 500-as hibákat?

A szerverhibák kezelésénél a gyors felismerés legalább olyan fontos, mint maga a javítás. Érdemes ezért rendszeresen ellenőrizni a weboldalad technikai állapotát.

1. Ellenőrizd a Google Search Console jelentéseit!

A Search Console Oldalak indexelése jelentésében a „Szerverhiba (5xx)” kategóriában találhatod azokat az URL-eket, amelyek lekérésekor a Google szerveroldali hibát tapasztalt.

A Feltérképezési statisztikák jelentésében azt is vizsgálhatod, hogy megnövekedett-e a hibás szerverválaszok aránya. Ez különösen akkor hasznos, ha a probléma nem minden lekérésnél jelentkezik.

2. Vizsgáld meg a szervernaplókat!

A szerver error log fájljai sok esetben segítenek azonosítani a hiba valódi okát. Kiderülhet például, hogy egy PHP-folyamat memóriahiány miatt áll le, hogy egy WordPress-bővítmény lehet a ludas, vagy hogy az adatbázis-kapcsolattal van gond.

3. Ellenőrizd a legutóbbi módosításokat!

Ha a hiba közvetlenül egy frissítés, bővítménytelepítés vagy szerverkonfiguráció-módosítás után jelentkezett, érdemes először ezek hatását megvizsgálni. Szükség esetén egy korábbi, működő verzió visszaállítása jelentheti a leggyorsabb megoldást.

4. A javítás után ellenőrizd az indexelést!

A szerverhiba elhárítása után először ellenőrizd, hogy a korábban hibás URL-ek ismét megfelelően betöltődnek-e, és 200 OK státuszkóddal válaszolnak-e.

Ezután térj vissza a Google Search Console Oldalak indexelése → Szerverhiba (5xx) jelentéséhez, és indítsd el a Javítás ellenőrzése folyamatot. Ezzel arra kéred a Google-t, hogy ismét vizsgálja meg a korábban hibás URL-eket, és ellenőrizze, megszűnt-e a probléma.

Ha egy fontos oldal időközben kiesett a Google indexéből, az URL-ellenőrző eszközben az Élő URL tesztelése funkcióval megvizsgálhatod az aktuális állapotát, majd szükség esetén kérheted az újraindexelését. A javítás és az indexelési kérelem azonban nem garantálja, hogy az oldal azonnal visszakerül a találatok közé.

Szükség esetén frissítheted és újra beküldheted az XML-webhelytérképet is, de ezt mindig a javítás után tedd meg, mert önmagában nem oldja meg a szerverhibát, és nem garantál azonnali újraindexelést.

Végül még egy fontos technikai különbség: ha tervezett karbantartás miatt ideiglenesen nem tudod kiszolgálni az oldalt, az általános 500-as hiba helyett megfelelőbb lehet az 503 Service Unavailable válasz, szükség esetén Retry-After fejléc kíséretében. Ez egyértelműbben jelzi az átmeneti elérhetetlenséget, bár tartósan ezt a státuszkódot sem érdemes fenntartani.

A tanulság? A több napig fennálló 500-as hiba az egyik legveszélyesebb SEO-katasztrófa lehet, amit jobb minél előbb elhárítani. 

Hiszen a Google viszonylag türelmes vendég. De még ő sem fog a végtelenségig egy elérhetetlen weboldal ajtaján kopogtatni.