302 átirányítás: teljes útmutató

A 302 átirányítás egy ideiglenes HTTP-átirányítás: a szerver azt jelzi, hogy a kért tartalom most egy másik címen érhető el, de az eredeti URL marad az érvényes. A kereső ezért jellemzően az eredeti címet tartja meg az indexben. Akkor való, ha a változás valóban átmeneti, például karbantartás, készlethiány vagy rövid kampány idejére, és a régi cím hamarosan visszatér.

Alapfogalmak

Az átirányítás azt jelenti, hogy a szerver egy kérésre nem a tartalommal felel, hanem egy másik címmel, ahová a böngészőnek vagy a keresőrobotnak tovább kell mennie. A válasz két részből áll: egy 3xx kezdetű állapotkódból és egy Location fejlécből, amely megmondja a célcímet. A 302-es kód jelentése a szabvány szerint „Found", vagyis a kért erőforrás ideiglenesen máshol található. Ez az „ideiglenesen" szó a lényeg, és szinte minden SEO-döntés ebből következik.

A 302 átirányítás nem hiba, és nem is rosszabb a 301-nél. Egyszerűen mást mond. A 301 azt üzeni, hogy a tartalom végleg elköltözött, az új címet kell használni. A 302 azt üzeni, hogy most menj oda, de a régi cím továbbra is érvényes, később ide gyere vissza. Aki a kettőt összekeveri, az a keresőnek rossz információt ad arról, melyik URL a lap valódi címe.

A téma a Technikai SEO része, és szorosan kapcsolódik a többi átirányítás-típushoz, a kanonikus címkezeléshez és a feltérképezéshez. Aki érti, hogy a kereső hogyan választ egy URL-csoporton belül egyetlen megjelenítendő címet, az a 302-es kód helyét is könnyen megtalálja.

A 3xx átirányítások összehasonlítása

Kód	Jelentés	Tartós?	Kérési metódus	Tipikus használat
301	Moved Permanently	Igen	A böngészők POST kérést GET-re válthatnak	Végleges költözés, domainváltás, URL-szerkezet átalakítása
302	Found	Nem	A böngészők POST kérést GET-re válthatnak	Átmeneti kerülőút, karbantartás, rövid kampány
303	See Other	Nem	A folytatás mindig GET	Űrlapküldés utáni továbbítás egy eredménylapra
307	Temporary Redirect	Nem	A metódus nem változhat	Ideiglenes átirányítás, ahol a POST-nak POST-nak kell maradnia
308	Permanent Redirect	Igen	A metódus nem változhat	Végleges átirányítás API-knál, űrlapvégpontoknál

A táblázatból látszik, hogy SEO szempontból két csoport van: a tartós (301, 308) és az ideiglenes (302, 303, 307) átirányítások. A kereső számára a metódus kérdése ritkán számít, mert a robot szinte mindig GET kéréssel dolgozik. Ami számít, az a tartósság. A részletes kódlistát a HTTP státuszkódok útmutatója tartalmazza.

Szerveroldali és kliensoldali átirányítás

A 302-es kódot a szerver küldi, még mielőtt a böngésző bármit megjelenítene. Ezt nevezzük szerveroldali átirányításnak, és ez a legtisztább jelzés a kereső felé. Léteznek kliensoldali megoldások is: a meta refresh címke és a JavaScriptes átirányítás. Ezek a lap betöltése után lépnek működésbe, a szerver közben 200-as kóddal felel. A kereső ezeket is felismerheti, de lassabban és kevésbé egyértelműen értelmezi, ezért ahol lehet, a szerveroldali megoldás a jobb választás.

Szerveroldali 302: egyértelmű állapotkód, azonnali továbbítás, a kereső egyből érti.
Meta refresh: a HTML-ben elhelyezett utasítás, késleltetéssel vagy anélkül. A késleltetés nélküli változatot a Google a saját dokumentációja szerint inkább tartós átirányításként kezeli, tehát nem helyettesíti a 302-t.
JavaScript: csak akkor működik, ha a lap renderelése megtörténik, ami a keresőnél késhet. Végső megoldásnak jó, alapnak nem.

Hogyan működik?

A folyamat a böngésző és a kereső felől nézve hasonlóan indul. A kliens elkéri az eredeti URL-t, a szerver 302-es kóddal és egy Location fejléccel válaszol, a kliens pedig új kérést küld a megadott címre. A felhasználó ebből általában csak annyit érzékel, hogy a címsorban másik URL jelenik meg. A különbség abban van, mit jegyez meg a kliens és mit jegyez meg a kereső.

A kérés-válasz lépései

A kliens GET kérést küld az eredeti címre.
A szerver válasza: 302 Found, a Location fejlécben a célcím.
A kliens új kérést küld a célcímre.
A célcím, ideális esetben, 200-as kóddal és a tartalommal felel.
Ha a célcím újabb átirányítást ad, lánc keletkezik, amely minden lépéssel lassít.

Egy egyszerű válaszfejléc így néz ki:

Sor	Tartalom
Állapotsor	HTTP/1.1 302 Found
Location	https://example.com/akcio-tavasz/
Cache-Control	no-store vagy rövid max-age, ha nem akarod, hogy a böngésző megjegyezze

Gyorsítótárazás

A böngészők a 301-es választ hajlamosak hosszan megjegyezni, így egy elhibázott végleges átirányítást nehéz visszacsinálni: a látogató gépe a régi címet meg sem kérdezi újra. A 302 ebben barátságosabb. A szabvány szerint alapértelmezés szerint nem gyorsítótárazható, csak ha a válasz kifejezetten engedi, például Cache-Control vagy Expires fejléccel. Ezért ideiglenes helyzetekben a 302 azért is jobb, mert a változás visszavonása után a látogatók azonnal az eredeti tartalmat kapják.

Mit kezd vele a kereső?

A kereső egy URL-csoporton belül kiválaszt egy kanonikus címet, és azt jeleníti meg a találatok között. Ehhez több jelzést mérlegel: a canonical címkét, az átirányításokat, a belső linkeket, a XML sitemapben szereplő címeket. A Google dokumentációja szerint a tartós átirányítás erős jelzés arra, hogy a cél legyen a kanonikus, az ideiglenes átirányítás viszont gyenge jelzés. Ez a gyakorlatban azt jelenti, hogy 302 esetén a kereső többnyire az eredeti URL-t tartja meg a találati listában, és a tartalmat a célcímről tölti be.

Fontos, hogy ez mérlegelés, nem szabály. Ha egy 302 hosszú ideig változatlanul áll, és minden más jelzés is a célcímre mutat, a kereső dönthet úgy, hogy a célcímet tekinti kanonikusnak. Ezért nem érdemes arra építeni, hogy a 302 „megvédi" az eredeti címet. Ha a változás végleges, azt végleges átirányítással kell jelezni.

Fő módszerek

A 302 átirányítást többféle szinten lehet beállítani: a webszerver konfigurációjában, az alkalmazás kódjában, a tartalomkezelő egy bővítményével vagy egy CDN, illetve terheléselosztó szabályával. A választás attól függ, ki kezeli az oldalt, és mennyire kell dinamikusnak lennie a szabálynak. A lényeg mindenhol ugyanaz: a válasz állapotkódja 302 legyen, a Location fejléc pedig egy abszolút, működő címre mutasson.

Beállítási szintek

Szint	Előny	Hátrány	Mikor válaszd
Webszerver (Apache, Nginx)	Gyors, az alkalmazás el sem indul	Konfigurációs hozzáférés kell, hibánál az egész oldal érintett lehet	Karbantartás, egyszerű mintaalapú szabályok
Alkalmazás kódja	Feltételhez köthető (nyelv, készlet, bejelentkezés)	Fejlesztői munka, tesztelni kell	Dinamikus döntések, például elfogyott termék
CMS-bővítmény	Felületről kezelhető, naplóz	Lassíthat, a bővítmény alapértelmezése eltérhet	Szerkesztők által kezelt kampány-átirányítások
CDN vagy peremszabály	A felhasználóhoz közel fut, gyors	A szabályok szétszóródhatnak a rendszerek között	Földrajzi vagy kampányalapú terelés

Mikor jó választás a 302?

A döntési szabály egyszerű: ha tudod, mikor tér vissza az eredeti tartalom, vagy biztos, hogy visszatér, akkor 302. Ha nem tudod, vagy nem fog visszatérni, akkor 301. A tipikus jó esetek:

Karbantartás. Egy aloldal néhány órára vagy napra átirányít egy tájékoztató lapra. Ha az egész oldal áll, erre inkább az 503-as kód való, átirányítás nélkül, a lenti tévhitek között erről még lesz szó.
Átmeneti készlethiány. Egy termék rövid időre elfogy, és a lap addig egy hasonló termékre vagy a kategóriára mutat. Ha a termék véglegesen megszűnik, az már más döntés.
Időhöz kötött kampány. Egy állandó cím, például egy „akciók" URL, mindig az aktuális kampánylapra mutat. Maga az állandó cím marad a fontos, a cél változik.
A/B teszt. A látogatók egy része egy változatra kerül. Ilyenkor a változatlapon a canonical is az eredetire mutasson, hogy a kereső ne tekintse önálló lapnak.
Bejelentkezés és munkamenet. Egy védett lap a belépőoldalra küldi a nem azonosított látogatót, majd vissza. Ez nem SEO-kérdés, de fontos, hogy a robot ne ezt a láncot lássa a nyilvános lapokon.

Mikor nem jó választás?

Domainváltás, HTTP-ről HTTPS-re költözés, URL-szerkezet végleges átalakítása. Ezek mind végleges változások, a helyük a 301 átirányítás.
Megszűnt tartalom, amelynek nincs megfelelő utódja. Ilyenkor a 404 vagy 410 őszintébb, mint egy átirányítás a kezdőlapra, lásd a 404 hiba útmutatót.
Duplikált tartalom összevonása, ahol mindkét cím elérhető marad. Erre a canonical címke a jobb eszköz.

Kidolgozott példa: szezonális kategória

Egy webáruház minden nyáron indít egy strandfelszerelés kategóriát, ősszel pedig megszünteti. Az első években a kategória URL-je ősszel 404-et adott, tavasszal újra élt. A kereső minden évben elölről tanulta meg a lapot, és a linkek, amelyek közben rá mutattak, fél évig hibás lapra futottak.

A javítás: a kategória URL-je egész évben megmaradt. Szezonon kívül 302-vel a „kerti és szabadidős" főkategóriára irányított, szezonban pedig újra saját tartalommal, 200-as kóddal felelt. A belső menüből szezonon kívül kikerült, így a látogató nem futott bele feleslegesen. A kereső az eredeti címet tarthatta meg, a külső hivatkozások pedig működő lapra vittek. Az ideiglenesség itt valódi volt, ezért a 302 volt a helyes kód.

Kidolgozott példa: a rossz 302

Egy szolgáltató átköltözött egy új domainre. A fejlesztő a régi domain minden címét 302-vel irányította át, mert a keretrendszer átirányító függvénye alapértelmezés szerint ezt küldte. Hónapokkal később a régi domain címei még mindig megjelentek a találatok között, a Search Console-ban pedig az új címek egy része „Duplikált, a Google más kanonikust választott" állapotban állt. A változás végleges volt, a kód viszont ideiglenest jelzett. A megoldás a szabály 301-re cserélése volt, és a belső linkek, valamint a sitemap átírása az új címekre, hogy minden jelzés egy irányba mutasson.

Gyakori hibák

A 302-vel kapcsolatos hibák nagy része nem szándékos. A keretrendszerek, a CMS-bővítmények és a szerverek egy része alapértelmezésként 302-t küld, ha a fejlesztő nem ad meg mást. Emiatt sok oldalon úgy él végleges költözés, hogy senki nem döntött arról, hogy ideiglenes legyen.

A leggyakoribb hibák és javításuk

Hiba	Mi történik	Javítás
Végleges költözés 302-vel	A kereső az eredeti címet tartja meg, a jelzések megoszlanak	301 vagy 308, a belső linkek frissítése
Évek óta álló „ideiglenes" átirányítás	Senki sem tudja, miért van, a kereső maga dönt	Döntés: vagy megszüntetni, vagy véglegesíteni
302 a kezdőlapra minden megszűnt lapról	A kereső soft 404-ként kezelheti, a látogató elveszik	Tematikus célcím vagy 404/410
Láncba fűzött átirányítások	Lassulás, a robot idő előtt feladhatja	Minden szabály közvetlenül a végső címre mutasson
Belső linkek átirányított címre	Felesleges kérések, zavaros jelzés	A linkeket a végső címre kell írni
302-es cím a sitemapben	Ellentmondó jelzés: a sitemap indexelendőnek mondja	A sitemapbe csak 200-as, kanonikus cím kerüljön

Tévhitek

„A 302 nem ad át értéket." A Google képviselői korábban nyilvánosan jelezték, hogy az átirányítások típusától függetlenül nem vész el a hivatkozások értéke. A gond a 302-vel nem az érték elvesztése, hanem az, hogy a kereső melyik címet tekinti kanonikusnak.
„A 302 idővel magától 301 lesz." Az állapotkód nem változik magától. Legfeljebb a kereső értelmezése változhat, ha a jelzések tartósan egy irányba mutatnak. Erre építeni nem érdemes.
„Karbantartáskor mindent a karbantartó lapra kell 302-vel irányítani." Ha az egész oldal átmenetileg nem elérhető, az 503-as kód a pontosabb jelzés, lehetőleg Retry-After fejléccel. Ezzel a kereső tudja, hogy később próbálkozzon újra, és nem a karbantartó lapot tanulja meg. A részleteket az 5xx hibák útmutatója írja le.

Ellenpélda: amikor a 302 okoz hurkot

Egy nyelvválasztó logika a böngésző nyelve alapján 302-vel irányította a látogatót a megfelelő nyelvi változatra. A keresőrobot nem küldött nyelvi fejlécet, ezért az alapértelmezett változatra került, ahonnan egy másik szabály visszairányította a gyökérre. A robot a két cím között ugrált, a lapok egy része nem került be az indexbe. Az ilyen esetek elemzéséhez a redirect loop útmutató ad részletes módszert. A tanulság: az automatikus, feltételhez kötött 302-eket mindig érdemes nyelvi fejléc és süti nélkül is kipróbálni.

Mérés

A 302-ek mérése három kérdésre felel: hol vannak, miért vannak, és még mindig ideiglenesek-e. Az első kérdésre a feltérképező eszközök válaszolnak, a második a dokumentáción és a csapat emlékezetén múlik, a harmadik pedig a dátumokon. Ezért a mérés nem egyszeri, hanem rendszeres feladat.

Eszközök

Böngésző fejlesztői eszközei. A Hálózat fülön minden kérés állapotkódja és a Location fejléc látszik. Gyors, egyedi ellenőrzéshez elég.
Parancssor. A curl -I kapcsolóval csak a fejlécet kéred le, a -L kapcsolóval a teljes láncot végigjárod. Így a böngésző gyorsítótára nem torzít.
Feltérképező program. Egy teljes oldalt végigjár, és listázza az összes 3xx választ, a láncokat és a hurkokat.
Search Console. Az URL-vizsgálat megmutatja, melyik címet választotta a Google kanonikusnak. Az oldalindexelési jelentésben az „Átirányítással rendelkező oldal" kategória listázza az átirányított címeket.
Szervernapló. Megmutatja, milyen gyakran kéri a keresőrobot az átirányított címeket, és hová megy tovább.

Ellenőrzőlista a 302-ekhez

Kérdés	Jó válasz	Ha nem
Tudjuk, miért van ez az átirányítás?	Igen, le van írva, van gazdája	Kideríteni, vagy megszüntetni
Van tervezett vége?	Igen, dátummal	Ha nincs, valószínűleg 301 kell
A célcím 200-as kódot ad?	Igen, közvetlenül	A láncot le kell rövidíteni
Az eredeti cím szerepel a sitemapben?	Csak ha az eredeti a kanonikus és hamarosan visszatér	A célcímet sem kell felvenni, ha az csak kerülőút
A belső linkek az eredeti címre mutatnak?	Igen, ha az marad a kanonikus	Tisztázni, melyik cím a végleges
A Search Console melyik címet mutatja kanonikusnak?	Az eredetit	A jelzések ellentmondanak, felül kell vizsgálni

Rendszeres felülvizsgálat

Érdemes egy egyszerű nyilvántartást vezetni az ideiglenes átirányításokról: forrás, cél, ok, felelős, tervezett vége. Egy negyedéves feltérképezéssel össze lehet vetni a valós állapotot a nyilvántartással. Ami lejárt, azt meg kell szüntetni vagy véglegesíteni. Ami nincs a nyilvántartásban, arról ki kell deríteni, honnan jött. Ez a munka jellemzően kevés időt vesz igénybe, és megelőzi azt, hogy évekkel később senki ne tudja, miért mutat egy fontos kategória egy régi kampánylapra.

Ha nagy számú ideiglenes átirányítás van egy oldalon, az a crawl budget szempontjából is számít: minden átirányított cím plusz kérés a robotnak. Kis oldalon ez ritkán gond, nagy webáruháznál viszont érdemes figyelni.