Redirect loop: teljes útmutató

A redirect loop, magyarul átirányítási hurok, olyan hiba, amikor egy URL átirányításai körbeérnek, és a kliens soha nem jut el tartalomhoz. A böngésző egy idő után feladja és hibát jelez, a keresőrobot pedig nem tudja feltérképezni a lapot. A javítás mindig ugyanazzal kezdődik: végig kell követni a láncot, megtalálni az egymásnak ellentmondó szabályokat, és egyetlen, egyértelmű végső címet kijelölni.

Alapfogalmak

Az átirányítás egy utasítás a szervertől: ezt a címet ne itt keresd, hanem ott. Ha a „ott" is továbbküld, lánc keletkezik. Ha a lánc valamelyik pontja visszaküld egy korábbi címre, a lánc hurokká zárul. A kliens ilyenkor újra és újra ugyanazokat a címeket kéri, amíg el nem ér egy belső korlátot, és fel nem adja. A felhasználó egy hibaüzenetet lát, a lap tartalma pedig egyáltalán nem jelenik meg.

A hurok abban különbözik a többi átirányítási problémától, hogy nem lassít, hanem teljesen elzár. Egy hosszú lánc bosszantó, de működik. Egy hurokban a lap egyszerűen elérhetetlen. Ezért a hurok a sürgős hibák közé tartozik, főleg, ha fontos lapot, egy teljes könyvtárat vagy az egész oldalt érinti.

A téma a Technikai SEO része, és közvetlenül épül a redirect chain fogalmára: minden hurok egy lánc, amelynek nincs vége.

A legfontosabb fogalmak

Fogalom	Jelentés
Közvetlen hurok	A cím önmagára irányít, vagy két cím egymásra mutat
Közvetett hurok	Három vagy több cím zárt kört alkot
Feltételes hurok	Csak bizonyos helyzetben jön létre, például süti, nyelv, eszköz vagy bejelentkezés alapján
Rétegek közötti hurok	Két különböző rendszer, például CDN és szerver, egymással ellentétes szabályt követ
Végső cím	A cím, amelynek tartalommal, 200-as kóddal kellene felelnie

Milyen hibaüzenetet lát a látogató?

A böngészők eltérő szöveggel jelzik a hurkot. A Chrome és a rá épülő böngészők jellemzően a „túl sok átirányítás" üzenetet mutatják, ERR_TOO_MANY_REDIRECTS hibakóddal. A Firefox azt írja, hogy az oldal nem megfelelően irányít át. Az üzenet tehát nem mondja meg, melyik szabály a hibás, csak azt, hogy a böngésző feladta. A diagnózis ezért mindig a lánc végigkövetésével kezdődik.

Miért nehéz észrevenni?

Gyorsítótár. A böngésző megjegyezhet egy korábbi tartós átirányítást, így a fejlesztő gépén másként viselkedik az oldal, mint egy új látogatónál.
Sütik. A bejelentkezett szerkesztő sütijei miatt a hurok nála nem jelentkezik, csak a kijelentkezett látogatóknál és a robotoknál.
Feltételek. A nyelvi vagy földrajzi átirányítás csak bizonyos fejlécek mellett zárul hurokká.

Hogyan működik?

A hurok mechanikája egyszerű. A kliens kéri az A címet, a szerver B-re küldi. A kliens kéri B-t, a szerver A-ra küldi. Ez ismétlődik, amíg a kliens el nem ér egy belső határt. A böngészők és a keresőrobotok is korlátozzák, hány átirányítást követnek egymás után. A Google dokumentációja szerint a Googlebot legfeljebb tíz lépést követ, utána a címet átirányítási hibaként kezeli.

Egy tipikus hurok lépései

A kliens HTTPS-en kéri: https://example.com/
A CDN a kérést HTTP-n továbbítja a szervernek.
A szerver azt látja, hogy HTTP-n érkezett a kérés, és HTTPS-re irányít: 301, https://example.com/
A kliens újra HTTPS-en kéri a címet, a CDN újra HTTP-n továbbítja.
A szerver újra átirányít, és a kör bezárul.

Ez az egyik leggyakoribb hurok, és jól mutatja a lényeget: mindkét szabály önmagában helyes. A CDN jogosan kapcsolódik HTTP-n a szerverhez, ha így van beállítva, a szerver pedig jogosan akar HTTPS-t kikényszeríteni. A hiba abból fakad, hogy a szerver nem tudja, hogy a kliens eredetileg HTTPS-en jött. A megoldás vagy az, hogy a CDN is HTTPS-en kapcsolódik a szerverhez, vagy az, hogy a szerver a továbbító rendszer fejlécéből, például az X-Forwarded-Proto értékéből ismeri fel az eredeti protokollt.

Mit lát a keresőrobot?

A robot ugyanazt a kört járja, mint a böngésző, csak nem jelenít meg hibaüzenetet. A lapot nem tudja letölteni, ezért nem tudja indexelni, és ha korábban indexelve volt, idővel kieshet a találatok közül. A Search Console az oldalindexelési jelentésben átirányítási hibaként jelzi az érintett címeket. Ha a hurok feltételes, például csak süti nélkül jelentkezik, a robot megtapasztalja, a szerkesztő viszont nem, ezért a hiba sokáig rejtve maradhat.

Rétegek, ahol a szabályok élnek

Réteg	Példa	Tipikus ütközés
DNS és CDN	HTTPS-kényszerítés, hosztnév-normalizálás	A szerver fordított szabályt alkalmaz
Webszerver	Protokoll, www, záró perjel	Az alkalmazás ellentétes normalizálást végez
Alkalmazás vagy CMS	Oldalcím beállítás, nyelvi átirányítás	Eltérő alapcím a beállításokban és a szerverben
Bővítmény	Átirányító bővítmény, SEO-bővítmény	Két bővítmény ugyanazt a címet kezeli

Fő módszerek

A hurok javítása diagnosztikai munka. Nem elég egy szabályt átírni, mert ha nem az volt a hiba forrása, a hurok egy másik ponton bezárul. A módszer ezért mindig: követni, lokalizálni, egy helyen javítani, újra mérni.

1. A lánc végigkövetése

Az első lépés annak megnézése, milyen címek között kering a kliens. Ehhez a böngésző helyett jobb egy olyan eszköz, amely nem használ gyorsítótárat és sütit. A curl -sIL --max-redirs 15 parancs kiírja minden lépés állapotkódját és Location fejlécét. Ha a kimenetben ugyanaz a cím ismétlődik, megvan a kör. Érdemes a parancsot süti nélkül, majd a problémás süti megadásával is lefuttatni, ha feltételes hurokra van gyanú.

2. Az ütköző szabályok lokalizálása

A körben szereplő minden lépésnél meg kell állapítani, melyik réteg adta a választ. Segít a válaszfejlécek vizsgálata: a CDN-ek jellemzően saját azonosító fejlécet adnak, a CMS-bővítmények néha saját jelzést, a szerver pedig a Server fejlécben mutatkozik be. Ha a rétegek nem egyértelműek, átmenetileg ki lehet kapcsolni egy-egy szabályt egy tesztkörnyezetben, és figyelni, eltűnik-e a hurok.

3. Egy helyen legyen az igazság

A tartós megoldás az, hogy minden normalizálás, vagyis a protokoll, a hosztnév és a záró perjel kezelése, egyetlen rétegben történjen. Ha a CDN kényszeríti a HTTPS-t, a szerver ne tegye meg még egyszer, vagy csak úgy, hogy az eredeti protokollt a továbbított fejlécből olvassa. Ha a CMS alapcíme www-s, a szerver ne irányítson a www nélküli változatra.

Döntési szabály

Ha két szabály ugyanarra a kérdésre, például a protokollra vagy a hosztra, eltérő választ ad, az egyiket meg kell szüntetni, nem módosítani. Ha egy átirányítás feltételhez kötött, a feltétel teljesülésének meg kell szűnnie a célcímen, különben a célcím újra átirányít.

Kidolgozott példa: WordPress alapcím

Egy oldal HTTPS-re költözött. A szerver minden HTTP-kérést HTTPS-re irányított, de a WordPress beállításaiban a webhely címe HTTP-vel maradt. A CMS ezért a HTTPS-kérést visszairányította a HTTP-s alapcímre, a szerver pedig újra HTTPS-re. A látogatók „túl sok átirányítás" hibát kaptak. A javítás a CMS-ben tárolt két alapcím, a webhely és a kezdőlap címének HTTPS-re állítása volt. Utána a szerver és a CMS ugyanazt a végső címet tekintette helyesnek, és a hurok megszűnt.

Kidolgozott példa: nyelvi süti

Egy kétnyelvű oldal a kezdőlapot egy nyelvi sütiből olvasott érték szerint irányította a /hu/ vagy az /en/ mappára. A /hu/ mappa azt ellenőrizte, van-e süti, és ha nem volt, visszaküldte a látogatót a kezdőlapra, hogy ott kapjon egyet. A sütit viszont csak a nyelvválasztó felület állította be, az átirányítás nem. Süti nélküli kliens, így a keresőrobot is, a kezdőlap és a /hu/ között keringett. A megoldás: a /hu/ és az /en/ mappa süti nélkül is tartalommal felel, a süti csak a kezdőlapi választásnál számít.

Ellenőrzőlista a javításhoz

A kör minden lépése azonosítva van, címmel és réteggel.
Egyértelmű, melyik a végső cím.
A normalizálás egy rétegben történik.
A feltételes átirányítások célcíme nem teljesíti újra a feltételt.
A tesztelés süti nélkül, gyorsítótár nélkül és a keresőrobot felhasználói ügynökével is megtörtént.
A javítás után a belső linkek és a XML sitemap a végső címre mutat.

Gyakori hibák

A hurkok többsége néhány visszatérő mintából ered. Ha ezeket ismered, a diagnózis jóval gyorsabb, mert az első néhány gyanúsítottat azonnal meg tudod nézni.

Minta	Mi történik	Javítás
HTTPS-kényszerítés CDN mögött	A szerver HTTP-t lát, és újra HTTPS-re küld	HTTPS a CDN és a szerver között, vagy a továbbított protokoll figyelése
www és nem www ütközés	A szerver egyik, a CMS a másik változatot tartja helyesnek	Egy kijelölt hosztnév minden rétegben
Záró perjel ütközés	Egyik szabály hozzáadja, a másik elveszi	Egységes perjelszabály egy helyen
Kölcsönös átirányítás	Két cím egymásra irányít egy régi és egy új szabály miatt	A régi szabály törlése vagy a céljának javítása
Süti- vagy munkamenet-függő átirányítás	Süti nélkül a kör nem ér véget	A célcím süti nélkül is feleljen tartalommal
Két bővítmény ugyanazon a címen	Egymás szabályait írják felül	Egy bővítmény kezelje az átirányításokat

Tévhitek

„Nálam működik, tehát nincs hurok." A saját böngésző gyorsítótára és sütijei elfedhetik a hibát. A tesztelés mindig tiszta klienssel történjen.
„A sütik törlése megoldja." A látogatónál segíthet, ha a hiba süti-függő, de a szerveroldali ok marad, és a keresőrobotnál tovább jelentkezik.
„A hurok csak az adott lapot érinti." Ha a hurok egy általános szabályból ered, például protokoll- vagy hosztnormalizálásból, az egész oldal érintett lehet.

Ellenpélda: rossz javítás

Egy csapat a hurkot úgy „javította", hogy a szerver HTTPS-kényszerítését kikapcsolta. A hurok megszűnt, de a HTTP-s változat ettől kezdve közvetlenül is elérhetővé vált, így ugyanaz a tartalom két címen élt. A kereső két változatot talált, a jelzések megoszlottak. A helyes javítás nem egy szabály kikapcsolása, hanem annak biztosítása, hogy a rétegek ugyanazt a végső címet tartsák helyesnek.

Miért ismétlődnek a hurkok?

A hurkok visszatérésének fő oka, hogy a javítás egy konkrét tünetre vonatkozik, nem a mögötte álló szerkezetre. Ha a normalizálás továbbra is két rétegben történik, a következő beállításmódosítás, bővítményfrissítés vagy szerverköltözés ugyanazt a hibát hozza vissza, csak más formában. Ezért minden javítás után érdemes leírni, melyik réteg felel a protokollért, a hosztnévért és a perjelért, és ezt a leírást a csapat közös dokumentációjában tartani. A következő változtatásnál így az első kérdés az lesz, hogy a módosítás melyik réteget érinti, és ütközhet-e a meglévő szabályokkal.

Mérés

A hurkok mérése kétféle: azonnali diagnózis, amikor a hiba már jelentkezett, és rendszeres megelőzés, hogy a változtatások ne hozzanak létre újakat. Az utóbbi a fontosabb, mert egy hurok az egész oldalt elérhetetlenné teheti néhány perc alatt.

Eszközök

Parancssor. A curl -sIL egy maximális lépésszámmal. Ha elérik a korlátot, hurok vagy túl hosszú lánc van.
Böngésző fejlesztői eszközei. A Hálózat fülön, megőrzött naplóval és letiltott gyorsítótárral.
Feltérképező program. A legtöbb eszköz külön jelöli a hurkokat és a lépéskorlátot elérő láncokat.
Search Console. Az oldalindexelési jelentés átirányítási hibái és az URL-vizsgálat élő tesztje.
Szervernapló. Ha ugyanaz a kliens rövid idő alatt sokszor kéri ugyanazt a néhány címet 3xx válasszal, az hurokra utal.
Elérhetőség-figyelő. Egy külső szolgáltatás, amely a fontos címeket rendszeresen lekéri és riaszt, ha nem 200-as kód érkezik a lánc végén.

Ellenőrzés változtatás után

Mikor	Mit nézz meg
HTTPS-bevezetés, tanúsítványváltás	A kezdőlap és néhány mélyebb lap HTTP-n és HTTPS-en, www-vel és nélküle
CDN bekapcsolása vagy módosítása	A szerver és a CDN közötti protokoll, az SSL-mód
CMS-alapcím módosítása	A szerverszabályok és a CMS beállításai egyeznek-e
Új átirányító bővítmény	Ütközik-e a meglévő szerver- vagy bővítményszabályokkal
Nyelvi vagy földrajzi terelés	Süti nélkül és nyelvi fejléc nélkül is véget ér-e a lánc

Tesztmátrix

A fontos címeket négy változatban érdemes lekérni: HTTP és HTTPS, www-vel és anélkül. Mind a négynek legfeljebb egy lépésben ugyanarra a végső címre kell jutnia. Ehhez jön még a süti nélküli és a keresőrobot felhasználói ügynökével végzett kérés. Ez a mátrix néhány perc alatt lefuttatható, és a hurkok nagy részét még élesítés előtt kiszűri.

A hurkok és a hosszú láncok a crawl budget szempontjából is károsak: a robot olyan kérésekre költ, amelyek soha nem vezetnek tartalomhoz. Az átirányítási kódok jelentéséről a HTTP státuszkódok útmutatója ad áttekintést.

Mit jelent a sikeres javítás?

A javítás akkor tekinthető késznek, ha a tesztmátrix minden változata egy lépésben a végső címre jut, a végső cím 200-as kóddal felel, és a Search Console élő URL-vizsgálata is tartalmat lát. Az indexelési jelentésben az átirányítási hibák csak fokozatosan tűnnek el, mert a robotnak újra fel kell térképeznie az érintett címeket. Ha a hiba sok címet érintett, érdemes a javítás után a sitemapet újra beküldeni, hogy a feltérképezés hamarabb elérje őket.