5xx hibák: teljes útmutató

Az 5xx hibák olyan HTTP-válaszok, amelyekkel a szerver jelzi, hogy a kérés rendben volt, de ő maga nem tudta teljesíteni. A leggyakoribbak az 500, 502, 503 és 504. SEO szempontból a tartós vagy tömeges 5xx a gond: a Google lassítja a feltérképezést, és ha a hiba megmarad, az érintett oldalak kieshetnek az indexből.

Alapfogalmak

A HTTP-státuszkódok első számjegye megmondja, milyen típusú válaszról van szó. A 2xx sikert jelez, a 3xx átirányítást, a 4xx olyan hibát, amelyet a kliens oldalán kell keresni, például nem létező URL-t. Az 5xx osztály ezzel szemben a szerver hibája: a kérés formailag rendben volt, a szerver mégsem tudott érdemi választ adni. Ez a különbség a SEO szempontjából is lényeges, mert a kereső másként reagál arra, ha egy oldal nem létezik, és arra, ha létezik, de éppen nem elérhető.

Az 5xx hibák többnyire átmeneti természetűek. Egy túlterhelt adatbázis, egy újraindítás alatt álló alkalmazás, egy lejárt időkorlát mind rövid ideig tartó problémát okoz. A kereső ezért nem kezeli őket azonnali végleges jelzésként. Ha azonban a hiba napokig vagy hetekig fennáll, a kereső következtetése megváltozik, és az oldal kikerülhet a találatok közül.

A leggyakoribb 5xx kódok

Kód	Név	Mit jelent	Tipikus ok
500	Internal Server Error	Általános szerverhiba, közelebbi megjelölés nélkül	Programhiba, hibás konfiguráció, kezeletlen kivétel
502	Bad Gateway	A közvetítő szerver érvénytelen választ kapott a háttérszervertől	Leállt alkalmazásszerver, hibás proxy- vagy CDN-beállítás
503	Service Unavailable	A szerver átmenetileg nem tudja kiszolgálni a kérést	Karbantartás, túlterhelés, szándékos korlátozás
504	Gateway Timeout	A közvetítő szerver nem kapott időben választ	Lassú adatbázis-lekérdezés, túlterhelt háttérrendszer

Létezik több ritkább 5xx kód is, de a gyakorlatban a fenti négy adja az esetek nagy részét. Érdemes tudni, hogy a kódot nem mindig az a szerver adja, amelyen a webhely fut. Egy CDN, egy terheléselosztó vagy egy fordított proxy is visszaadhat 5xx választ, ha a mögötte álló rendszerrel nem tud kapcsolatot teremteni.

Miért fontos ez a SEO-nak?

A kereső csak azt tudja indexelni, amit le tud tölteni. Ha egy URL szerverhibát ad, a kereső nem látja a tartalmát, ezért nem tudja frissíteni az indexben tárolt változatot sem. Egyetlen rövid kiesés ritkán okoz gondot. A tartós vagy nagy arányú 5xx viszont két módon árt: a kereső csökkenti a feltérképezés ütemét, hogy ne terhelje tovább a szervert, és a sokáig elérhetetlen oldalakat idővel eltávolítja az indexből. A felhasználói oldalon is veszteség van: aki hibaoldalt kap, általában visszalép a találati listára.

Mi nem 5xx hiba?

A 404 és a 410. Ezek azt jelzik, hogy a tartalom nincs meg, nem azt, hogy a szerver hibázott.
A 429 Too Many Requests. Ez 4xx kód, a kliens túl sok kérést küldött. A Google a feltérképezésnél a szerverhibákhoz hasonlóan lassításra használja, de más osztályba tartozik.
Az időtúllépés válasz nélkül. Ha a kapcsolat létre sem jön, vagy a szerver semmit nem válaszol, az hálózati hiba, nem státuszkód. A Search Console külön kategóriában mutatja.

Ki látja a hibát először?

Az 5xx hibák egyik alattomos tulajdonsága, hogy a csapat gyakran nem látja őket. A szerkesztők és a fejlesztők ugyanazokat az oldalakat nyitják meg nap mint nap, és ezek jó eséllyel a gyorsítótárból érkeznek. A kereső viszont a webhely teljes kiterjedését bejárja, a ritkán látogatott mélyebb oldalakkal együtt. Ezért nem ritka, hogy egy szerverhiba először a Search Console jelentésében tűnik fel, napokkal azután, hogy elkezdődött. A mérésről szóló szakasz ezért nem opcionális kiegészítés, hanem a kezelés része.

Hogyan működik?

Egy weboldal kiszolgálása ma ritkán egyetlen gépen történik. A kérés jellemzően egy CDN-en vagy terheléselosztón halad át, onnan egy webszerverre kerül, amely egy alkalmazásszervernek adja tovább, az pedig adatbázisból és egyéb szolgáltatásokból állítja össze a választ. Bármelyik láncszem hibázhat, és a kód gyakran azt árulja el, hol szakadt meg a lánc. Az 502 és az 504 jellemzően a közvetítő és a háttér közötti kapcsolatra utal, az 500 inkább az alkalmazás belső hibájára, az 503 pedig arra, hogy a szolgáltatás tudatosan vagy kényszerből nem fogad kéréseket.

Hogyan reagál a Googlebot?

A Google nyilvános dokumentációja szerint a Googlebot a szerverhibákat úgy értelmezi, hogy a webhely nehezen bírja a terhelést, ezért átmenetileg lassítja a feltérképezést. A már indexelt URL-ek egy rövid kiesés alatt az indexben maradnak. Ha a hiba tartósan fennáll, a Google végül eltávolítja az érintett URL-eket az indexből. A pontos időtartamokat a kereső nem köti szigorú számokhoz, ezért a biztonságos hozzáállás az, hogy minden 5xx-et a lehető leggyorsabban meg kell szüntetni.

Külön figyelmet érdemel a robots.txt. Ha a kereső a robots.txt fájlra szerverhibát kap, nem tudja, mit szabad feltérképeznie. A Google ilyenkor óvatosan viselkedik, és átmenetileg felfüggesztheti az egész webhely feltérképezését. Egy hibás robots.txt-kiszolgálás tehát az összes oldalra kihat, akkor is, ha maguk az oldalak rendben vannak.

Az 503 különleges szerepe

Az 503 az egyetlen 5xx kód, amelyet tudatosan érdemes használni. Tervezett karbantartásnál ez a helyes válasz, mert azt mondja: a szolgáltatás átmenetileg nem érhető el, később próbálkozz újra. A válaszhoz Retry-After fejléc is társítható, amely jelzi, mikor érdemes újra próbálkozni. A kereső ezt figyelembe veheti, de nem köteles szó szerint követni. A karbantartás tehát rövid legyen: egy napokig tartó 503 ugyanúgy tartós elérhetetlenségnek számít, mint bármely más szerverhiba.

Kidolgozott példa: a karbantartás két változata

Egy webáruház egy frissítés idejére egyszerű „Karbantartás miatt zárva" oldalt tett ki. Az első alkalommal ez az oldal 200-as kóddal ment ki minden URL-re. A kereső ezt valódi tartalomnak tekintette, és néhány termékoldal a karbantartási szöveggel került volna frissítésre, ha a leállás tovább tart. A következő frissítésnél a csapat ugyanazt az oldalt 503-as kóddal és Retry-After fejléccel szolgálta ki. A kereső így tudta, hogy átmeneti állapotról van szó, és nem írta felül a termékoldalak tárolt változatát. A karbantartási oldal kinézete nem változott, csak a kódja.

Szerverhiba és rangsorolás

Érdemes elválasztani két kérdést: az indexben maradást és a helyezést. Egy átmenetileg elérhetetlen oldal az indexben maradhat, de amíg a kereső nem tudja letölteni, a frissítései sem jutnak el hozzá. Ha a hiba egy fontos oldalt érint, amelyet épp most frissítettél, a frissítés hatása is késik. Tartós hibánál pedig már nem a késés, hanem a kiesés a kockázat.

Fő módszerek

Az 5xx hibák kezelése három részből áll: megelőzés, gyors felismerés és helyes kommunikáció a kereső felé. A megelőzés a legolcsóbb, a felismerés a legfontosabb, a helyes kódválasztás pedig az, ami miatt a kereső türelmes marad egy átmeneti hiba idején.

1. Kapacitás és gyorsítótár

Sok 5xx hiba terhelésből fakad. Ha a szerver egy forgalmi csúcs vagy egy intenzív feltérképezés alatt összeomlik, a megoldás a kapacitás bővítése vagy a terhelés csökkentése. A gyorsítótárazás, akár a tartalomkezelő szintjén, akár CDN-nel, sok kérést leválaszt az alkalmazásszerverről. A statikus tartalom kiszolgálása olcsó, a dinamikus oldalak minden egyes legenerálása drága.

2. Hibakeresés a naplókból

Minden 5xx mögött van egy konkrét ok, amely a szerver vagy az alkalmazás hibanaplójában megtalálható. Az 500-as hibánál a kezeletlen kivétel vagy a hibás konfiguráció, az 502-nél a leállt háttérfolyamat, az 504-nél a túl lassú lekérdezés. A hibakeresés sorrendje: melyik URL-ek érintettek, mikor kezdődött, mi változott akkor, mit mond a hibanapló. A „mi változott" kérdés gyakran egyenesen a megoldáshoz vezet: egy frissítés, egy új bővítmény, egy módosított szerverbeállítás.

3. Helyes kód a helyes helyzetre

Helyzet	Helyes válasz	Amit kerülj
Tervezett, rövid karbantartás	503, Retry-After fejléccel	200-as karbantartási oldal
Nem létező URL	404 vagy 410	500, mert az alkalmazás nem kezeli a hiányzó elemet
Túl sok kérés egy klienstől	429 vagy 503	Csendes lassulás időtúllépésig
Váratlan programhiba	500, és azonnali javítás	Hibaüzenet 200-as kóddal

4. A feltérképezés terhelésének kezelése

Ha a kereső robotja okozza a terhelést, a helyes lépés nem a robot kizárása. A robots.txt tiltás megakadályozza a feltérképezést, de a tartalom sem frissül többé. Ha a szerver valóban nem bírja a kereső tempóját, rövid ideig 503 vagy 429 válasszal lehet jelezni a túlterhelést, és ezzel a Google lassít. Tartósan azonban a kapacitást kell a webhely méretéhez igazítani, hiszen a feltérképezés a láthatóság feltétele.

Döntési szabály

Ha egy URL 5xx-et ad, tedd fel sorban a kérdéseket. Létezik a tartalom? Ha nem, a kód legyen 404 vagy 410. Tervezett leállásról van szó? Akkor 503, és a leállás legyen rövid. Váratlan hiba? Akkor a naplóból keresd meg az okot, és javítsd. Ismétlődik a hiba bizonyos időszakokban? Akkor terhelési problémáról van szó, és a kapacitással vagy a gyorsítótárral kell foglalkozni.

Kidolgozott példa: 500-as hiba a hiányzó termékekre

Egy webáruház termékoldala egy azonosító alapján kérte le az adatokat az adatbázisból. Ha a termék már nem létezett, a lekérdezés üres eredményt adott, a sablon pedig ettől hibára futott, és 500-as kódot küldött. A Search Console így a kifutott termékeket szerverhibaként jelezte, a valódi szerverhibák pedig elvesztek ebben a zajban. A javítás egy egyszerű ellenőrzés volt a sablon elején: ha a termék nem létezik, a rendszer 404-et vagy 410-et ad vissza, esetleg 301-et, ha van utódtermék. Az 5xx jelentés ettől tisztább lett, és a következő valódi szerverhiba azonnal feltűnt benne.

Gyors ellenőrzés hibabejelentés után

Kérd le az érintett URL-t egy HTTP-fejlécet megjelenítő eszközzel, és nézd meg a pontos kódot.
Próbáld ki több különböző sablontípusú URL-lel, hogy kiderüljön, egy oldalt vagy egy egész típust érint-e.
Nézd meg a hibanaplót ugyanarra az időpontra.
Kérdezd meg, mi változott a webhelyen vagy a szerveren a hiba kezdete előtt.
Javítás után az URL-ellenőrzővel győződj meg arról, hogy a Google is rendben lévő választ kap.

Gyakori hibák

Az 5xx körüli hibák egy része technikai, más része folyamatbeli. A technikai hibák a kódválasztásban és a konfigurációban vannak, a folyamatbeliek abban, hogy senki nem figyeli a jelzéseket, vagy a figyelmeztetés rossz emberhez jut.

Tipikus hibák

Karbantartási oldal 200-as kóddal. A kereső valódi tartalomként kezelheti, és a tárolt változat helyére a karbantartási szöveg kerülhet.
Nem létező elemre 500-as hiba. Ha az alkalmazás egy hiányzó termékazonosítónál kivételt dob, a nem létező oldal szerverhibaként jelenik meg, és elfedi a valódi szerverhibákat.
Hibaoldal 200-as kóddal. Egy „Valami hiba történt" oldal, amelyet a rendszer sikeres válaszként küld ki. Ez nemcsak az 5xx-et rejti el, hanem soft 404 gyanúját is keltheti.
A robots.txt kiszolgálásának elhanyagolása. Ha ez a fájl szerverhibát ad, az egész webhely feltérképezése leállhat.
Csak a főoldal figyelése. A legtöbb elérhetőség-figyelő a nyitólapot nézi, pedig a hiba sokszor csak egy sablontípust érint, például a termékoldalakat.

Tévhit: egy kiesés azonnal rontja a helyezést

Egy rövid, egyszeri szerverhiba miatt nem kell pánikba esni. A kereső számol azzal, hogy a szerverek néha nem elérhetők, és egy átmeneti hiba után az URL-ek visszatérnek a korábbi állapotba. A kockázatot a tartós és a visszatérő hiba jelenti. Ezért a helyes reakció nem az ijedtség, hanem a gyors javítás és az okok feltárása, hogy a hiba ne ismétlődjön.

Ellenpélda: amikor a CDN elfedi a gondot

Egy CDN a gyorsítótárból gyakran akkor is kiszolgálja az oldalakat, ha a háttérszerver hibát ad. Ez a látogatónak jó, a hibakeresésnek viszont nehezíti a dolgát. Elképzelhető, hogy a gyakran látogatott oldalak rendben megjelennek, miközben a ritkábban lekért URL-ek, amelyek nincsenek a gyorsítótárban, 502-t vagy 504-et adnak. A kereső éppen ezekkel a ritka URL-ekkel találkozik gyakran, ezért a hibát ő látja előbb, mint a csapat.

Tévhit: a hibaoldal kinézete számít

Sokan a hibaoldal megtervezésére fordítanak energiát, és ez a látogatónak hasznos is. A keresőt azonban a kód érdekli. Egy szép, magyarázó hibaoldal 200-as kóddal rosszabb, mint egy csupasz 503 a helyes fejlécekkel, mert az előbbi félrevezeti a keresőt. A két szempont egyébként nem zárja ki egymást: a jól megtervezett oldal is kiszolgálható a megfelelő státuszkóddal.

Mérés

Az 5xx hibák mérése több forrásból áll össze, mert egyik forrás sem mutat teljes képet. A Search Console azt mutatja, mit tapasztalt a Google, a szervernaplók azt, mi történt valójában, a figyelőrendszerek pedig azt, mikor és mennyi ideig tartott a hiba.

Search Console

Az oldal-indexelési jelentésben a nem indexelt oldalak okai között szerepel a szerverhiba (5xx) kategória. A feltérképezési statisztikák jelentés a válaszok megoszlását és a gazdagép állapotát mutatja, benne azt is, voltak-e gondok a robots.txt lekérésével, a DNS-sel vagy a szerver elérhetőségével. Az URL-ellenőrző egy-egy címre valós időben is megmutatja, milyen választ kap a Google.

Szervernaplók és figyelés

A hozzáférési naplókból kiszűrhető, mely URL-ek adtak 5xx választ, milyen gyakran, és melyik kliensnek. Ha a Googlebot kéréseire aránytalanul sok 5xx érkezik, az arra utal, hogy a szerver a feltérképezés terhelését nem bírja. Egy külső elérhetőség-figyelő percenként vagy néhány percenként lekér néhány kiválasztott URL-t, és riaszt, ha hibát kap. Érdemes minden fontos sablontípusból egy-egy URL-t felvenni, nem csak a főoldalt.

Ellenőrzőlista

Lépés	Mit nézel	Elfogadható eredmény
Search Console indexelés	Szerverhiba (5xx) sor	Üres vagy csak elszigetelt esetek
Feltérképezési statisztikák	Gazdagép állapota, válaszok megoszlása	Nincs jelentős probléma a robots.txt-vel és a szerverrel
Hozzáférési napló	5xx arány sablontípusonként	Nincs sablon, amely rendszeresen hibázik
Karbantartási oldal	A karbantartási mód kódja	503, Retry-After fejléccel
Hiányzó elemek	Nem létező azonosító kódja	404 vagy 410, nem 500
Riasztás	Ki kapja a figyelmeztetést	Az, aki javítani is tud

Kidolgozott példa: visszatérő esti 504-esek

Egy hírportál Search Console-jában időről időre megugrott a szerverhibák száma. A főoldal figyelése semmit nem mutatott, mert a nyitólap a CDN gyorsítótárából jött. A hozzáférési napló szerint az 504-esek szinte kizárólag az archív oldalakon jelentkeztek, és mindig ugyanabban az esti időszakban. Kiderült, hogy ekkor futott egy adatbázis-mentés, amely lelassította a régi cikkeket kiszolgáló lekérdezéseket. A mentést áthelyezték egy kisebb forgalmú időszakra, az archív oldalakat pedig hosszabb ideig tárolta a gyorsítótár. A figyelőbe felvettek egy archív URL-t is, hogy a következő hasonló hiba ne csak a Search Console-ból derüljön ki.

Mérési ritmus

Az elérhetőség-figyelés folyamatos, a riasztás azonnali. A Search Console jelentéseit elég hetente átnézni, nagyobb frissítés vagy szerverköltözés után pedig naponta, amíg a helyzet stabil nem lesz. A naplók elemzése havonta vagy problémás időszak után indokolt. A lényeg, hogy az 5xx ne a forgalom csökkenéséből derüljön ki, hanem jóval előtte.

Szerverköltözés és nagy frissítés

A legtöbb tömeges 5xx egy nagy változás körül jelentkezik: szerverköltözés, tartalomkezelő-frissítés, új bővítmény, DNS-módosítás. Ilyenkor érdemes előre felkészülni. A változás előtt rögzítsd a normál állapotot: mennyi a szerverhiba a naplóban és a Search Console-ban. A változás után az első napokban sűrűbben nézd a figyelőt és a feltérképezési statisztikákat. Ha a hibák száma megugrik, a visszaállítás lehetősége legyen előkészítve, mert egy gyors visszalépés kevesebbe kerül, mint napokig tartó szerverhiba.

A költözés utáni ellenőrzésnél ne csak a főoldalt nézd. Kérj le egy-egy URL-t minden fontos sablontípusból, a robots.txt-t és az XML sitemapot is, mert ezek bármelyikének hibája a feltérképezés egészére kihathat.