Redirect chain: teljes útmutató

A redirect chain, magyarul átirányítási lánc, akkor jön létre, amikor egy URL nem közvetlenül a végső címre irányít, hanem egy vagy több közbülső átirányításon keresztül. Minden lépés plusz kérés, ami lassítja a betöltést és a feltérképezést. A javítás lényege, hogy minden régi cím és minden belső link egyetlen lépésben, közvetlenül a végső, 200-as kódot adó címre mutasson.

Alapfogalmak

Egy átirányítás önmagában egyszerű: az A cím azt mondja, menj B-re. Lánc akkor keletkezik, amikor B sem a végállomás, hanem azt mondja, menj C-re, és így tovább. A felhasználó ebből legfeljebb egy kis késést érzékel, a böngésző ugyanis csendben végigjárja a lépéseket. A keresőrobot viszont minden lépést külön kérésként kezel, és a lánc hossza, valamint a lépések típusa befolyásolja, mit ért meg a lapról.

A lánc szinte soha nem szándékos. Többnyire rétegződés eredménye: egy oldal évek alatt átesik egy HTTPS-váltáson, egy domainváltáson, egy URL-szerkezet átalakításán, és minden alkalommal valaki új szabályt ír a régiek mellé, ahelyett hogy a régieket frissítené. Így egy tíz éve létező cím ma három vagy négy ugrással jut el a mostani lapig.

A téma a Technikai SEO alapjai közé tartozik, és szorosan összefügg a 301 és a 302 átirányítással, valamint a hurkokkal.

A legfontosabb fogalmak

Fogalom	Jelentés
Hop, ugrás	Egy átirányítási lépés két cím között
Forráscím	Az a cím, amelyet a látogató vagy a robot eredetileg kér
Végső cím	Az a cím, amely már nem irányít tovább, hanem tartalommal felel
Láncolt átirányítás	Két vagy több egymást követő ugrás a forrás és a végső cím között
Vegyes lánc	Lánc, amelyben tartós és ideiglenes átirányítás is szerepel
Hurok	Lánc, amely visszatér egy korábbi címre, és soha nem ér véget

Lánc vagy hurok?

A kettőt gyakran összekeverik, pedig a következményük eltér. A láncnak van vége: lassú, de a tartalom végül betöltődik. A huroknak nincs vége: a böngésző egy idő után hibaüzenettel feladja, a tartalom nem jelenik meg. Minden hurok lánc, de nem minden lánc hurok. A hurkok felderítéséről és javításáról a redirect loop útmutató szól részletesen.

Honnan tudod, hogy lánccal van dolgod?

Az első jel gyakran nem technikai, hanem gyakorlati: egy régi link lassan nyílik meg, vagy egy kampánylink mérése hiányos. A második jel a Search Console, ahol átirányítási hibák vagy sok átirányított oldal jelenik meg. A harmadik jel egy feltérképezés, amely a lépések számát is kiírja. Ha egy cím kérésekor egynél több 3xx válasz érkezik egymás után, az lánc, függetlenül attól, hogy a végén betöltődik-e a tartalom.

Hogyan működik?

A kliens elkéri a forráscímet, a szerver 3xx kóddal és egy Location fejléccel felel. A kliens kéri a következő címet, és ez addig ismétlődik, amíg egy válasz nem 200-as kóddal jön, vagy amíg a kliens fel nem adja. Minden lépés egy teljes kérés: kapcsolatfelvétel, esetleg új TLS-kézfogás, ha más a hoszt, várakozás a válaszra.

Egy tipikus lánc felépítése

A látogató egy régi linkre kattint: http://example.com/termekek/kave
1. ugrás: HTTP-ről HTTPS-re, https://example.com/termekek/kave
2. ugrás: www nélküli címről www-re, https://www.example.com/termekek/kave
3. ugrás: záró perjel hozzáadása, https://www.example.com/termekek/kave/
4. ugrás: a régi szerkezetről az újra, https://www.example.com/kave/
A végső cím 200-as kóddal felel.

Mind a négy szabály önmagában helyes. Együtt viszont négy felesleges kérést okoznak, és ha bármelyik közülük ideiglenes, vagy egy szerkesztő később módosítja, a lánc eltörhet. A helyes állapot az, hogy az eredeti cím egyetlen 301-gyel a végső címre mutasson.

Mit csinál a keresőrobot a lánccal?

A Google dokumentációja szerint a Googlebot legfeljebb tíz átirányítási lépést követ egy kérés során. Ha ennyin belül nem jut el tartalomhoz, a címet átirányítási hibaként kezeli, és a Search Console is ilyen hibát jelez. A tíz lépés elsőre soknak tűnik, de nem cél, hanem felső határ. Egy lánc már jóval előtte is káros lehet, mert minden lépés a feltérképezési keret egy darabját fogyasztja, és minden lépésnél elromolhat valami.

A lánc a kanonikus cím kiválasztását is befolyásolhatja. Ha a lépések között ideiglenes átirányítás van, a kereső kevésbé biztos abban, hogy a végső cím a kanonikus. Ha a lánc tartós lépésekből áll, a jelzés erősebb, de a feltérképezési költség ugyanúgy megmarad.

Mit veszít a felhasználó?

Időt. Minden lépés várakozással jár. Mobilhálózaton, ahol a késleltetés nagyobb, ez jobban érezhető.
Megbízhatóságot. Ha a lánc egyik szeme más szerveren vagy CDN-en fut, annak hibája az egész láncot megállítja.
Követési adatokat. Egyes lépéseknél a lekérdezési paraméterek elveszhetnek, ha a szabály nem viszi tovább őket, így a kampánymérés hiányos lesz.

Fő módszerek

A lánc javításának két oldala van. Az egyik a szerveroldali szabályok rendbetétele, hogy minden forrás egy lépésben jusson el a végső címhez. A másik a hivatkozások frissítése, hogy a belső linkek, a sitemap és a canonical címkék eleve a végső címre mutassanak, és a láncot senki se indítsa el.

1. Leltár készítése

Először össze kell gyűjteni az összes címet, amelyre átirányítás vonatkozik. Forrásai: a szerver konfigurációja, a CMS átirányító bővítménye, a CDN szabályai, a régi sitemapek, a külső linkeket listázó eszközök, a Search Console linkjelentése és a szervernapló. A cél egy táblázat, amelyben minden sor egy forráscím és a hozzá tartozó végső cím.

2. A szabályok lapítása

A lapítás azt jelenti, hogy minden forrás közvetlenül a végső címre mutat. Ha A-ból B-be, B-ből C-be vezet szabály, akkor az új szabály A-ból C-be vezet, és B-ből is C-be. A régi közbülső szabályt nem szabad törölni, ha B-re is mutatnak linkek, csak át kell írni.

Forrás	Régi cél	Régi lánc hossza	Új cél	Új hossz
http://example.com/termekek/kave	https://example.com/termekek/kave	4 ugrás	https://www.example.com/kave/	1 ugrás
https://example.com/termekek/kave	https://www.example.com/termekek/kave	3 ugrás	https://www.example.com/kave/	1 ugrás
https://www.example.com/termekek/kave/	https://www.example.com/kave/	1 ugrás	https://www.example.com/kave/	1 ugrás

3. Általános szabályok összevonása

A protokoll-, hoszt- és perjelszabályokat érdemes egyetlen szabályba összevonni, amely egyszerre állítja be a HTTPS-t, a www-t és a záró perjelet. Így egy rosszul írt régi cím sem négy, hanem egy lépésben jut el a helyére. Ezt a szerver konfigurációjában célszerű megoldani, a legkorábbi ponton, még az alkalmazás előtt.

4. A hivatkozások frissítése

Belső linkek. A menü, a lábléc, a szövegközi linkek és a sablonok mind a végső címre mutassanak.
Sitemap. A XML sitemap csak 200-as kódot adó, kanonikus címeket tartalmazzon.
Canonical. A canonical címke se mutasson átirányított címre, mert az ellentmondó jelzés.
Hreflang és strukturált adat. Ezekben is könnyen bennmaradnak régi címek.
Külső linkek. A legértékesebb hivatkozó oldalakat érdemes megkeresni és frissítést kérni, de ez a legkevésbé kontrollálható rész, ezért a szerverszabály legyen rendben akkor is, ha a link marad.

Döntési szabály

Ha egy forráscím és a végső cím között egynél több lépés van, a szabályt lapítani kell. Ha egy belső link átirányított címre mutat, a linket kell javítani, nem az átirányítást. Ha egy lépés ideiglenes, de a változás végleges, a lépést tartósra kell cserélni.

Kidolgozott példa: webáruház két migráció után

Egy webáruház először HTTPS-re költözött, két évvel később pedig új platformra, ahol a termék-URL-ek szerkezete megváltozott. A második migrációnál a fejlesztők csak a régi platform HTTPS-es címeit irányították át az újakra. A régi, HTTP-s linkek így először a régi HTTPS-címre, onnan az újra jutottak, és ahol a záró perjel is eltért, még egy lépés jött. Egy feltérképezés azt mutatta, hogy a külső linkek jelentős része két-három ugrással érkezett.

A javítás egy leképezési táblából indult, amely minden valaha létező termékcímet a mostani címhez rendelt. Ebből egyetlen szabálykészlet készült, amely a protokolltól és a hoszttól függetlenül egy lépésben irányított. A belső sablonokban maradt régi linkeket egy keresés-csere javította. Az eredmény egylépéses átirányítás lett minden ismert forrásra, és a Search Console átirányítási hibái eltűntek.

Kidolgozott példa: nyelvi lánc

Egy kétnyelvű oldal a gyökércímet a böngésző nyelve szerint irányította a /hu/ vagy az /en/ mappára, a mappa pedig a nyitólapra, amely egy harmadik lépésben a legfrissebb kampánylapra mutatott. A robot így három lépésben jutott el egy időszakos lapra, amely ráadásul hetente változott. A megoldás az volt, hogy a nyelvi mappák saját, állandó nyitólapot kaptak, és a kampány ezen a lapon belül jelent meg kiemelésként, nem átirányításként.

Gyakori hibák

A láncok ritkán egyetlen rossz döntésből születnek. Jellemzően több, egymástól független, egyenként ésszerű szabály találkozásából. Ezért a hibákat is érdemes rendszer szerint nézni, nem egyenként.

Hiba	Miért alakul ki	Javítás
Egymásra épülő migrációk	Az új szabályok a régiek mellé kerülnek, nem helyettük	Leképezési tábla, lapított szabályok
Külön szabály a protokollra, hosztra, perjelre	Különböző időpontokban, különböző emberek írták	Egy összevont normalizáló szabály
Belső linkek régi címekre	A sablonok és a régi tartalmak nem frissültek	Keresés-csere, sablonjavítás
CMS és szerver egyszerre irányít	Két rendszer kezeli ugyanazt a címet	Egy helyen legyen a szabály
Vegyes 301 és 302	Egy bővítmény vagy keretrendszer alapértelmezése	Minden végleges lépés tartós kódot kapjon
Elveszett paraméterek	A szabály nem adja tovább a lekérdezési részt	A paraméterek átvitelének beállítása ott, ahol kell

Tévhitek

„Amíg tíz lépés alatt van, nincs gond." A tíz a követés felső határa, nem ajánlás. Már két lépés is felesleges kérés, amely ráadásul hibalehetőség.
„A lánc minden lépése értékvesztés." Erre nincs megbízható, nyilvános bizonyíték. A lánc valódi költsége a lassulás, a feltérképezési keret pazarlása és a törékenység, nem egy lépésenként levonódó százalék.
„A régi szabályokat törölni kell." Nem. A régi forráscímeket továbbra is kezelni kell, csak a céljukat kell a végső címre állítani. Ha a szabály eltűnik, a régi link 404-re fut.

Ellenpélda

Egy csapat a láncok felszámolásakor minden régi szabályt törölt, és csak az újakat hagyta meg, mert azt gondolta, hogy a kereső már úgyis az új címeket ismeri. A régi külső linkek ettől kezdve 404-es lapra vitték a látogatókat. A lánc eltűnt, de a hivatkozások értéke és a forgalom egy része is. A helyes megoldás nem a szabályok törlése, hanem az átírása lett volna.

Kinek a felelőssége?

A láncok egyik oka, hogy az átirányítások kezelése szétszóródik: a fejlesztő a szerverben, a szerkesztő a CMS-ben, az üzemeltető a CDN-ben ír szabályt, és egyikük sem látja a teljes képet. Érdemes egyetlen felelőst és egyetlen nyilvántartást kijelölni, ahol minden átirányítás szerepel a forrással, a céllal, a típussal és az okkal. Ez nem bürokrácia, hanem a legolcsóbb megelőzés.

Mérés

A láncok mérése azért fontos, mert szemmel nem látszanak. A böngésző csendben végigjárja őket, a címsorban csak a végső cím jelenik meg. Mérni ezért eszközzel kell, és nem csak egyszer, mert minden tartalmi vagy technikai változtatás új láncot hozhat létre.

Eszközök és módszerek

Parancssor. A curl -sIL végigjárja a láncot és kiírja minden lépés fejlécét. Így egyedi címeket gyorsan ellenőrizni lehet.
Böngésző fejlesztői eszközei. A Hálózat fülön a „Preserve log" bekapcsolásával minden lépés látszik.
Feltérképező program. A legtöbb ilyen eszköz külön jelentést ad az átirányítási láncokról, a lépések számával és típusával.
Search Console. Az oldalindexelési jelentés az átirányítási hibákat és az átirányított oldalakat külön kategóriában mutatja. Az URL-vizsgálat megmutatja, melyik címet látja a Google a lánc végén.
Szervernapló. Megmutatja, a keresőrobot milyen gyakran kér átirányított címeket, ami a feltérképezési keret pazarlásának közvetlen jele.

Ellenőrzőlista

Ellenőrzés	Célállapot
Lépések száma forrásonként	Legfeljebb egy
Belső linkek átirányított címre	Nulla
Sitemapben átirányított cím	Nulla
Canonical átirányított címre	Nulla
Ideiglenes lépés végleges változásnál	Nulla
Végső cím állapotkódja	200
Hurok	Nincs

Mikor mérj?

Minden migráció, domainváltás vagy URL-szerkezet módosítás előtt és után.
Új CMS-bővítmény vagy CDN-szabály bevezetésekor.
Negyedévente egy teljes feltérképezéssel, hogy a lassan felhalmozódó láncok is kiderüljenek.
Ha a Search Console átirányítási hibát jelez.

Nagy oldalon a láncok a crawl budget kérdésével is összefüggnek: minden felesleges lépés olyan kérés, amelyet a robot új vagy frissült tartalomra is fordíthatna. A mérés ezért nem csak technikai rend, hanem a feltérképezés hatékonyságának része.

Az eredmény értékelése

A javítás után két dolgot érdemes figyelni. Az egyik a technikai állapot: egy ismételt feltérképezés mutassa, hogy a láncok eltűntek, és a belső linkek egyike sem fut átirányításra. A másik a kereső viselkedése: a Search Console-ban az átirányítási hibák száma csökkenjen, az URL-vizsgálat pedig a végső címet mutassa kanonikusnak. A forgalomra gyakorolt hatást óvatosan érdemes értelmezni, mert a láncok megszüntetése elsősorban a hibalehetőségeket és a pazarlást csökkenti, nem egy közvetlen rangsorolási tényező javítása.