Egy weboldal minden válasza két rétegből áll: abból, amit az ember lát a képernyőn, és abból, amit a szerver a HTTP-fejlécben mond. A keresőrobotok és az AI-válaszmotorok crawlerei az utóbbit olvassák. Ha a két réteg ellentmond egymásnak, például a látogató azt olvassa, hogy „ez a termék megszűnt”, a Googlebot viszont 200 OK-t kap, akkor a kereső a fejlécnek hisz. A státuszkódok rendbetétele ezért nem szerverüzemeltetési aprómunka, hanem az egyik legolcsóbb technikai beavatkozás, amit egy magyar webshop vagy szolgáltatói oldal megtehet.
Mit üzen valójában egy státuszkód a keresőnek?
Röviden: azt, hogy az adott URL-t hosszú távon meg kell-e tartani az indexben, át kell-e vinni egy másikra, vagy ki kell-e venni belőle.
A kereső szempontjából a kódok három csoportba esnek. Az állandó átirányítás (301, 308) azt mondja: ez az URL megszűnt, a helyére végleg egy másik lép, a rangsorolási jelzéseket vidd át oda, a régit pedig hosszabb távon ejtsd ki. Az ideiglenes átirányítás (302, 307) ezzel szemben azt mondja: most máshol van a tartalom, de a régi URL visszatér, tartsd meg indexeltnek. A hibakódok (404, 410, 451) pedig azt, hogy itt nincs mit indexelni.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint a mai rendszerben az átirányítás típusa önmagában nem jelent jelzésvesztést, tehát nem igaz a régi tévhit, hogy a 302 „elnyeli” az erőt. A típus viszont továbbra is meghatározza, melyik URL-t választja a kereső kanonikusnak, és a keresési találatban melyik cím jelenik meg.
Mi a különbség a 301 és a 302 között, ha a Google mindkettőt követi?
Az, hogy a 301 esetén a célcím lesz a kanonikus URL, a 302 esetén viszont a kiindulási cím marad az.
Ez a gyakorlatban ott csattan, amikor egy termék régi URL-jét 302-vel viszed egy új oldalra. A kereső ilyenkor jó eséllyel a régi, tartalom nélküli címet tartja meg találatként, és azt mutatja a felhasználónak. A belső linkjeid, a hivatkozások és a korábbi teljesítmény egy olyan URL körül gyűlnek, amelyről te már régen lemondtál. Ugyanez igaz a nyelvi vagy protokoll-alapú átirányításokra is: egy 302-vel megoldott HTTP-ről HTTPS-re terelés éveken át kettős állapotban tartja a domaint.
Hivatalosan igazolt: a Google közlése szerint egy tartósan fenntartott ideiglenes átirányítást idővel állandóként is kezelhet. Szakmai feltételezés: ez a felismerés viszont nem azonnali, és a köztes hetekben-hónapokban a kanonizálás bizonytalan, ami ingadozó megjelenéseket okozhat. Erre nincs nyilvános, számokkal alátámasztott hivatalos leírás, ezért kezeld óvatosan.
Mikor kell 307-et vagy 308-at használni, és mi köze ehhez a HSTS-nek?
A 307 és a 308 a 302 és a 301 szigorúbb testvére: megőrzik az eredeti HTTP-metódust és a kérés törzsét.
A régi 301 és 302 mellett a böngészők történelmi okokból megtehetik, hogy egy POST kérést GET-té alakítanak az átirányítás után. Ez űrlapoknál, kosárba tevésnél, API-hívásoknál adatvesztést okoz. A 308 (állandó) és a 307 (ideiglenes) ezt kizárja. Tartalmi oldalaknál, ahol GET kérésekről van szó, a 301 és a 308 SEO-szempontból egyenértékű, a 302 és a 307 szintén. Alkalmazás- és API-rétegben viszont a 307 és 308 a helyes választás.
A 307 azonban egy másik helyen is felbukkan, és ez zavarja meg a legtöbb embert. Ha az oldalad HSTS fejlécet küld (Strict-Transport-Security), a böngésző a következő látogatáskor már el sem indítja a HTTP-kérést, hanem belül átírja HTTPS-re. A Chrome fejlesztői eszközeiben ez 307 Internal Redirect néven jelenik meg. Hivatalosan igazolt: ez böngészőn belüli lépés, nem szerverválasz. A robotok és a curl nem ezt látják, tehát a valódi szerveroldali 301-et akkor is meg kell tartanod, ha a böngésződben már csak a 307-et látod.
Mikor jobb a 410 a 404-nél?
Akkor, amikor biztosan tudod, hogy a tartalom véglegesen megszűnt, és nem tér vissza ugyanazon a címen.
A 404 azt jelenti: most nem találom. Ez lehet átmeneti hiba, elgépelt URL, félresikerült telepítés. A 410 azt jelenti: volt, elment, ne keresd. Hivatalosan igazolt: a Google dokumentációja szerint mindkettő eltávolításhoz vezet, és a kettő kezelése között nincs lényegi rangsorolási különbség. A Google munkatársai ugyanakkor többször jelezték, hogy a 410-et valamivel határozottabban dolgozzák fel.
Saját tapasztalat: nagy, több ezer kifutott terméket cipelő magyar webshopoknál a tömeges 410 használata rendszerint gyorsabban tisztítja ki a crawl-jelentést, mint a 404, és a Search Console lefedettségi riportja is olvashatóbb lesz tőle, mert elválik egymástól a szándékos kivezetés és a valódi hiba. Ez a saját mérésem, nem hivatalos garancia. A legrosszabb megoldás egyébként egyik sem: az, amikor a megszűnt termékoldal szép „nincs ilyen termék” szöveget mutat, de 200 OK-t küld. Ezt hívja a Google lágy 404-nek, és ilyenkor a kereső maga találgat.
Mit jelent a 451, és mikor jön elő?
A 451-es kód azt közli, hogy a tartalom jogi okból nem szolgálható ki.
Az RFC 7725 szabvány hozta be, és tipikusan bírósági végzés, hatósági blokkolás, szerzői jogi eltávolítás vagy jogszabályi kötelezettségen alapuló területi korlátozás mögött jelenik meg. Magyar oldalaknál ritka, de nem ismeretlen: előfordul szerencsejáték- és gyógyszerpiaci korlátozásoknál, illetve akkor, ha egy szolgáltató bizonyos országokból érkező kéréseket jogi megfelelés miatt zár ki. SEO-szempontból a 451 nem indexelhető állapot. Szakmai feltételezés: ha kizárólag jogi kockázat miatt zárnál ki egy régiót, a 451 őszintébb jelzés, mint a csendes 404, mert audit során is dokumentálja a döntés okát.
Melyik kódot melyik helyzetben használd?
Nyolc olyan helyzet, ami magyar webshopoknál és szolgáltatói oldalaknál hetente előkerül:
- Termék végleg kifutott, nincs utódja: 410. Vedd ki a sitemapból, és szedd le róla a belső linkeket is, különben a robot újra és újra visszatér rá.
- Termék kifutott, de van közvetlen utódja: 301 az utód termékoldalra. Csak akkor, ha tényleg ugyanazt az igényt szolgálja ki, különben lágy 404 lesz belőle.
- Sok termék fut ki egyszerre, konkrét utód nélkül: 301 a szűk, releváns kategóriára. Ha a kategória is túl távoli, inkább 410.
- Oldal átnevezve, URL-struktúra változott: 301, egy az egyben a régi címről az újra. Ne gyűjtőoldalra terelj mindent.
- Kampányoldal lejárt, jövőre visszatér: a legjobb, ha az URL él, 200-zal, átírt tartalommal. Ha mégis átirányítasz, 302 vagy 307 a helyes.
- Akciós aloldal a szezon után: tartsd meg ugyanazon az URL-en évről évre, 200-zal. Az évente újragyártott, majd 301-gyel eldobott szezonális URL-ekkel elveszted a felépült előzményt.
- Domain költözik: 301 minden URL-re, egy az egyben, plusz a Search Console címváltoztatás eszköze. Az átirányítást legalább egy évig tartsd fenn.
- Ideiglenes karbantartás: se 302, se 404. A helyes válasz 503 kód
Retry-Afterfejléccel, mert ez az egyetlen, ami azt üzeni: gyere vissza később, ne törölj semmit.
Egy dolgot érdemes kivenni ebből a logikából: a paraméteres, szűrős vagy nyelvi duplikációkat általában nem átirányítással kezeljük, hanem kanonikus jelöléssel. Az átirányítás akkor jó eszköz, ha a régi címnek tényleg nincs többé létjogosultsága.
Hogyan ellenőrzöd a tényleges státuszkódot?
Fejlécből, nem szemre. Két megbízható út van rá, és mindkettő percek alatt megtanulható.
- Böngészőben nyisd meg a fejlesztői eszközöket (F12 vagy jobb gomb, majd Vizsgálat), válts a Network (Hálózat) fülre, jelöld be a
Disable cacheopciót, majd frissíts. A dokumentum sorára kattintva a Headers panelen látod a Status Code értéket és a teljes átirányítási láncot. - Parancssorból:
curl -I https://pelda.hu/regi-oldal. Ez csak a fejlécet kéri le. A teljes lánc követéséhez:curl -sIL https://pelda.hu/regi-oldal | grep -E "^HTTP|^location".
Két buktató a curl körül. Az első: a -I HEAD kérést küld, és van szerver, ami erre másképp válaszol, mint egy valódi GET-re. Ilyenkor használj curl -sS -o /dev/null -D - https://pelda.hu/oldal parancsot, ami rendes GET-et küld, de csak a fejlécet írja ki. A második: sok tárhely blokkolja az alapértelmezett curl azonosítót, ezért érdemes böngésző-azonosítót adni neki a -A kapcsolóval. Nagyobb oldalnál pedig ne kézzel ellenőrizz, hanem crawlerrel nézd végig az egész átirányítási térképet.
Miért félrevezető, amit a böngészőben látsz?
Mert a böngésző a végállapotot mutatja, nem az odavezető utat, és közben maga is beleszól a folyamatba.
- A böngésző az állandó átirányításokat agresszíven gyorsítótárazza. Ha egyszer rosszul állítottál be egy 301-et, a saját gépeden még hetekig a régi célra fut, hiába javítottad ki. Inkognitó ablak vagy curl segít.
- A HSTS miatti
307 Internal Redirectnem szerverválasz, tehát a robotok más láncot járnak be, mint te. - A JavaScriptes vagy meta refresh alapú átirányítás a szemnek ugyanaz, a fejléc szintjén viszont 200 OK marad. A kereső ezt gyengébb, bizonytalanabb jelzésként kezeli.
- A lágy 404 pontosan azért veszélyes, mert vizuálisan tökéletes hibaoldalt látsz, miközben a szerver 200-zal válaszol, és a kereső indexelhetőnek gondolja.
- A CDN, a WordPress-gyorsítótár és a szerveroldali szabályok egymásra rakódhatnak, így három-négy ugrásos lánc keletkezik, amiből a böngésző címsorában csak a végpont látszik.
Miért a hosszú távú 302 a leggyakoribb csendes hiba?
Saját tapasztalat: a magyar webshopok technikai átvizsgálásainál a legtöbbször visszatérő probléma nem a hiányzó tartalom és nem a lassú oldal, hanem az évek óta ideiglenesként fenntartott átirányítás. Az ok szinte mindig ugyanaz: a webshopmotorok, bővítmények és tárhelypanelek átirányítási felületei alapértelmezésben 302-t kínálnak, mert az a biztonságosabb választás egy tesztelés közben. Aztán a teszt élessé válik, és a beállítás ott marad.
Ez azért csendes hiba, mert semmi nem romlik el látványosan. Az oldal működik, a látogató odaér, ahová akart, hibaüzenet sehol. Csak a kanonizálás bizonytalan, csak a régi URL marad benne az indexben, csak a jelentésekben szóródik szét ugyanaz a forgalom két cím között. Szakmai feltételezés: a válaszmotorok és AI-asszisztensek korában ez a bizonytalanság többe kerülhet, mint korábban, mert ezek a rendszerek gyakran egyetlen kanonikus URL-t idéznek forrásként, és nem mérlegelnek két verzió között. Ez logikus következtetés, de nyilvános mérés még nem támasztja alá.
Milyen ellenőrzőlistával zárd le az átirányítási munkát?
- Minden érintett URL-t fejlécből ellenőriztél, nem böngészőből, gyorsítótár nélkül.
- Nincs kettőnél több ugrás egy láncban, és nincs kör (A vissza B-re, B vissza A-ra).
- Az állandó változások 301-esek vagy 308-asok, az ideiglenesek 302-esek vagy 307-esek, és tudod indokolni, melyik miért az.
- A véglegesen kivezetett oldalak 410-et adnak, és eltűntek a sitemapból és a belső linkekből.
- Nincs 200-zal válaszoló hibaoldal, tehát nincs lágy 404.
- Az átirányítás célja tartalmilag tényleg megfelel a kiindulási oldalnak, nem csak a kezdőlapra terel.
- Karbantartás alatt 503 megy ki
Retry-Afterfejléccel. - Domainköltözésnél a Search Console címváltoztatását is elvégezted, és az átirányítás legalább egy évig él.
Ez a lista nem garantál helyezésjavulást, viszont megszünteti azokat a félreértéseket, amelyek miatt a kereső rossz URL-t választ. A tapasztalatom szerint ez az a fajta munka, aminek az eredménye nem látszik azonnal, de nélküle minden későbbi tartalmi fejlesztés kisebb hatásfokkal működik.
Források és további olvasnivalók
- Google Search Central: Redirects and Google Search (átirányítási útmutató)
- Google Search Central: How to remove a page from Google, valamint a lágy 404-ekről szóló hibaelhárítási dokumentáció
- Google Search Central: Site move with URL changes és a Search Console címváltoztatás eszköz súgója
- RFC 9110: HTTP Semantics (a 3xx és 4xx kódok szabványos jelentése)
- RFC 7725: An HTTP Status Code to Report Legal Obstacles (451)
- RFC 6797: HTTP Strict Transport Security (HSTS)
- MDN Web Docs: HTTP response status codes
- Chrome DevTools dokumentáció: Network panel
- Az állandó változás 301 vagy 308, az ideiglenes 302 vagy 307: a különbség abban van, mit tart meg hosszú távon a kereső indexe.
- A véglegesen megszűnt, utód nélküli oldalnál a 410 tisztább jelzés, mint a 404, mert nem hagy nyitva kérdést.
- A böngészőben látott 307 gyakran a HSTS miatti belső átirányítás, nem szerverválasz: a robotok nem ezt kapják.
- A státuszkódot fejlécből ellenőrizd (Network fül vagy curl -I), mert a képernyőn látott szöveg akár 200 OK mögött is állhat.
- A hónapokig, évekig fenntartott 302 a magyar webshopok leggyakoribb csendes technikai hibája.
Gyakori kérdések
Elveszik-e a rangsorolási erő 301-es átirányításnál?
A Google hivatalos közlése szerint az átirányítás típusa önmagában ma már nem okoz jelzésvesztést, tehát a 301 nem „nyel el” erőt. Az igazi kockázat máshol van: ha nem releváns célra irányítasz, vagy hosszú láncot építesz, akkor a kereső a célt lágy 404-nek értékelheti, és az átvitel valóban gyengül.
Mennyi ideig kell fenntartani egy 301-es átirányítást?
Domainköltözésnél és nagyobb URL-átalakításnál legalább egy évig, a Google saját ajánlása szerint is. Ha megteheted, tartsd fenn tovább: a régi címekre külső hivatkozások és könyvjelzők évekig mutathatnak, és az átirányítás megszüntetése után ezek egy csapásra hibaoldalra futnak.
A 404 rontja az oldalam megítélését?
Önmagában nem. A Google többször megerősítette, hogy a nem létező URL-ekre adott 404 természetes állapot, és nem büntetés. Akkor válik problémává, ha valódi, forgalmat hozó oldalak esnek ki miatta, vagy ha rengeteg belső link mutat hibás címekre, mert az feleslegesen köti le a bejárási kapacitást.
Miért látok 307-et, ha én 301-et állítottam be?
Szinte biztosan a HSTS miatt. Ha az oldalad Strict-Transport-Security fejlécet küld, a böngésző a következő látogatáskor már belül átírja a HTTP-címet HTTPS-re, és ezt jelzi 307 Internal Redirect néven. Ez böngészőn belüli lépés: a keresőrobot a szervered valódi 301-ét kapja, ezért azt is meg kell tartanod.
Melyik a jobb megszűnt terméknél: 410 vagy átirányítás?
Ha van tényleg releváns utód vagy szűk kategória, akkor 301 arra. Ha nincs, akkor 410, mert a nem releváns célra terelt átirányítás félrevezeti a látogatót és lágy 404-et eredményezhet. A gyakorlatban ezt terméktípusonként érdemes eldönteni, nem egyetlen globális szabállyal.
Hogyan tudom egyszerre sok URL státuszkódját ellenőrizni?
Kisebb listánál curl parancsot futtathatsz ciklusban, fejléc-kiírással. Nagyobb oldalnál viszont crawler eszközre van szükség, ami végigjárja a teljes átirányítási térképet, és megmutatja a láncokat, köröket és a lágy 404-eket is. A Search Console oldalindexelési riportja ezt kiegészíti azzal, hogy a Google ténylegesen mit tapasztalt.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.