Így számolhatsz le a lassító 301-es átirányítási láncokkal
Átirányítási hibák a valóságban: mikor csinál 301-es láncot a rendszer és hogyan szüntesd meg
Az átirányítás önmagában nem probléma. Sőt, a webes infrastruktúra természetes része. Domainváltás, HTTPS-re terelés, www és nem www verzió egységesítése, régi URL-struktúra leváltása – mind legitim ok egy 301-es átirányításra. A gond ott kezdődik, amikor a rendszer nem egyetlen tiszta 301-es választ ad, hanem láncot épít. Egy URL átirányít a másikra, az a harmadikra, az pedig egy negyedikre. A végeredmény: lassuló oldal, romló SEO, felesleges szerverterhelés és bizonytalan indexelés.
A gyakorlatban ez nem elméleti hiba, hanem napi szintű jelenség. Az 1b.hu-nál rendszeresen találkozunk olyan projektekkel, ahol a 301-es lánc nem egy tudatos döntés eredménye, hanem évek alatt felhalmozott konfigurációs maradványok következménye. És sokszor a tulajdonos nem is tud róla.
Hogyan alakul ki egy 301-es lánc?
A legtöbb lánc nem egyetlen fejlesztő hibájából születik. Inkább apró, egymástól független módosítások összeadódásából. Például az oldal eredetileg http:// formában működött. Később beállították a HTTPS kényszerítést. Ez már egy 301-es ugrás. Ezután egységesítették a www-s verziót nem www-ra. Ez újabb 301. Majd jött egy URL-struktúra módosítás, például /blog/ helyett /cikkek/. Ez is 301.
Ha ezek nem egyetlen lépésben, közvetlenül a végleges célra irányítanak, hanem egymás után aktiválódnak, akkor a böngésző és a keresőrobot három-négy átirányításon megy keresztül, mire eljut a végleges oldalra.
Ez nemcsak időveszteség. Minden egyes átirányítás új HTTP-kérést jelent. Több DNS-lekérdezés, több SSL-kézfogás, több szerverválasz. Mobilhálózaton ez különösen érezhető. A felhasználó nem látja a háttérben zajló folyamatot, csak azt érzékeli, hogy az oldal lassú.
A CMS és a pluginok rejtett szerepe
Sok 301-es lánc nem szerveroldali .htaccess vagy NGINX konfigurációból indul, hanem a tartalomkezelő rendszerből. WordPress esetén például egy SEO plugin automatikusan átirányítja a törölt bejegyzéseket. Egy másik plugin canonicalizálja a perjeles és perjel nélküli URL-eket. Közben a szerveren is van egy globális redirect szabály.
Ezek egymásra rakódnak. A rendszer nem „rossz”, csak túl sok helyen próbálja ugyanazt a problémát megoldani. Az eredmény viszont láncolt 301.
Az 1b.hu-nál tipikus forgatókönyv, hogy egy ügyfél migráció után panaszkodik a sebességre. A szerver rendben van, a cache működik, a CPU-terhelés alacsony. A hiba végül a redirect logban derül ki: a főoldal négy ugrással érhető el.
Miért probléma SEO szempontból?
A Google ma már jól kezeli a 301-es átirányításokat. De a láncok nem optimálisak. Minden ugrás csökkenti az átadott linkértéket, és növeli annak esélyét, hogy a robot nem követi végig a teljes útvonalat.
Ha egy régi, erős backlink egy olyan URL-re mutat, amely három lépésben jut el a céloldalra, akkor az átadott autoritás gyengébb lehet, mintha közvetlen 301-es irányítás történne.
Ráadásul a crawl budget is véges. Egy nagyobb oldalon, ahol több ezer URL létezik, a keresőrobot nem szeret fölösleges átirányításokkal időt veszíteni. Ha túl sok a lánc, az indexelési prioritás romolhat.
Hogyan derítsd ki, hogy van-e 301-es láncod?
Az első lépés a tudatosság. Nem elég a böngésző címsorát nézni. Szükség van technikai vizsgálatra. Egy egyszerű curl parancs vagy fejlesztői eszköz is megmutatja a redirect útvonalat. SEO audit eszközök pedig feltérképezik az egész oldalt, és listázzák a több lépéses átirányításokat.
Fontos külön kezelni a belső és külső forrásokat. Ha a saját menüd egy már átirányított URL-re mutat, az azonnal javítható. Ha külső link mutat régi címre, akkor a szerveroldali szabályokat kell optimalizálni.
A cél mindig az, hogy az első kérés azonnal a végleges URL-re vezessen. Nem köztes állomásokon keresztül.
Hogyan szüntesd meg a láncot?
A megoldás nem az, hogy törlöd az összes átirányítást. Az átirányítás szükséges eszköz. A kulcs az egyszerűsítés.
Először térképezd fel a teljes útvonalat. Például:
http → https
https + www → https nem www
régi slug → új slug
Ez három külön szabály lehet. Ezeket egyetlen, végleges célra mutató 301-re kell összevonni. Az ideális állapot az, amikor bármelyik variációból közvetlenül a végleges, kanonikus URL-re jutsz.
Fontos az is, hogy a belső linkeket frissítsd. Nem elég szerveroldalon javítani. Ha a tartalomban még mindig a régi URL szerepel, a lánc tovább él.
Egy másik tipikus hiba a trailing slash kezelése. Ha a rendszer külön kezeli a /oldal és /oldal/ verziót, az újabb felesleges redirecthez vezethet. Egységes döntés kell, majd ennek megfelelő konfiguráció.
Mikor elfogadható egy rövid lánc?
Elméletben a cél a nulla lánc. A gyakorlatban egyetlen köztes lépés néha elkerülhetetlen, például komplex migráció esetén. De három vagy több 301-es ugrás már figyelmeztető jel.
Ha domainváltás történik, érdemes a régi domaint közvetlenül az új végleges URL-re irányítani, nem pedig a régi struktúra logikáját követve több lépésben.
Az 1b.hu-nál bevett gyakorlat, hogy minden migráció után külön redirect-audit készül. Nem azért, mert kötelező, hanem mert hosszú távon ez spórolja meg a legtöbb erőforrást. Egy tiszta redirect-struktúra gyorsabb betöltést, jobb felhasználói élményt és stabilabb indexelést eredményez.
A végső cél: tiszta architektúra
A 301-es lánc nem látványos hiba. Nem omlik össze miatta az oldal. Nem dob 500-as hibát. Éppen ezért veszélyes. Csendben lassít, csendben gyengít, csendben rontja a struktúrát.
A megoldás nem bonyolult, de fegyelmezett gondolkodást igényel. Egységes URL-stratégia, központosított redirect-kezelés, rendszeres audit és tudatos belső linkelés.
Egy jól felépített weboldal esetében az átirányítás nem folyamatos toldozás-foldozás, hanem egyszeri, precíz beavatkozás. Ha ezt sikerül elérni, a 301-es nem ellenség lesz, hanem kontrollált eszköz a rendszerben.