- Egy régi URL-től az új célig ideális esetben pontosan egy ugrás vezet, nem kettő vagy három.
- 301-et akkor használj, ha a változás végleges és nem tervezed visszaállítani; ideiglenes helyzetre 302 vagy 307 való.
- Ha nincs releváns új megfelelő, a 410 vagy a 404 tisztább jelzés, mint a kezdőlapra terelés.
- A protokoll-, a hosztnév- és az útvonalváltást egyetlen összevont szabályban érdemes kezelni, különben láncot építesz.
- Migráció után a belső linkeket, a sitemapet és a canonical elemeket is át kell írni az új URL-ekre, nem elég az átirányításra hagyatkozni.
Az átirányítás a technikai SEO egyik legunalmasabb területe, mégis ez okozza a leghosszabb ideig észrevétlenül maradó forgalomvesztést. A baj ritkán abból származik, hogy valaki elfelejtett átirányítani. Sokkal gyakrabban abból, ahogyan átirányított: két-három lépcsőn keresztül, ideiglenes státuszkóddal, vagy egyenesen a kezdőlapra terelve mindent, aminek nem találtak új helyet.
Ebben a cikkben végigmegyünk azon, mi számít láncnak, mikor indokolt a 301 és mikor nem, hogyan keletkezik a végtelen hurok, és milyen ellenőrzőlistán érdemes végigfutni egy költöztetés után. A példák magyar kkv-helyzetekre vannak szabva: CMS-váltás, domainegyesítés, régi szolgáltatásoldalak összevonása.
Mi számít átirányítási láncnak, és miért gond?
Átirányítási lánc akkor keletkezik, amikor egy régi cím nem közvetlenül a végleges célra mutat, hanem egy másik, szintén átirányított címre. Egy ugrás rendben van, kettő már figyelmeztető jel, háromnál több egyértelmű hiba.
Tovább a témában: SSL beállítás · Weboldal költöztetés és tárhelyváltás Ajka
A lánc szinte mindig észrevétlenül épül fel, mert minden egyes szabály önmagában logikus. Vegyünk egy tipikus esetet: egy vidéki gépészeti vállalkozás oldala évekkel ezelőtt kapott SSL-tanúsítványt, majd később egységesítették a www-s alakot, végül CMS-t váltottak és megváltozott az útvonalstruktúra. Az eredmény négy állomás:
http://pelda.hu/szolgaltatasok/klimaszereleshttps://pelda.hu/szolgaltatasok/klimaszereleshttps://www.pelda.hu/szolgaltatasok/klimaszereleshttps://www.pelda.hu/szolgaltatasaink/klimaszereles/
Három ugrás azért van, mert három külön szabály fut egymás után, ahelyett hogy egyetlen összevont szabály egyből a végleges címre küldene. Hivatalosan igazolt: a Google dokumentációja szerint a Googlebot egy feltérképezési kísérlet során legfeljebb tíz átirányítási ugrást követ, azon túl a lánc feldolgozását későbbre halasztja. Vagyis a néhány lépcső önmagában nem katasztrófa, de minden ugrás késleltetés, plusz kérés és plusz hibalehetőség.
Saját tapasztalat: a láncok gyakorlati kára nem elsősorban valamiféle elveszett erőérték, hanem a lassulás és az elromlás esélye. Egy mobilhálózaton három ugrás érezhető várakozás a látogatónak, a mérőkódok pedig hajlamosak elveszíteni az eredeti hivatkozó forrást, így a forgalom közvetlen látogatásként jelenik meg.
Mikor kell 301, és mikor nem szabad?
301-et akkor használj, ha a tartalom véglegesen új címre került, és nem tervezed visszaállítani a régit. Minden más helyzet más eszközt kíván.
Indokolt a 301 ezekben az esetekben:
- domainváltás vagy két márkanév alatt futó oldal egyesítése,
- http-ről https-re állás,
- a www-s és a www nélküli alak egységesítése,
- URL-struktúra megváltozása CMS-váltáskor,
- két majdnem azonos tartalmú oldal összevonása egybe,
- véglegesen kivezetett termék, amelynek van egyértelmű utódja.
Nem 301 való ezekbe a helyzetekbe:
- Ideiglenes karbantartás: ilyenkor 503-as státuszkód a helyes, kiegészítve a
Retry-Afterfejléccel. Az átirányítás azt üzeni, hogy az oldal végleg megszűnt. - Átmenetileg nem rendelhető termék: maradjon a 200-as oldal, rajta a készletinformációval és alternatívákkal. A kereső és a látogató is ezen a címen keresi vissza.
- Megszűnt szolgáltatás releváns utód nélkül: itt a 410 a tisztább jelzés, mert egyértelműen közli, hogy a tartalom szándékosan került ki.
- Szezonális vagy kampányoldal: ha jövőre visszatér, 302 vagy 307 a megfelelő.
Hivatalosan igazolt: a Google leírásai szerint, ha sok régi URL-t a kezdőlapra irányítasz át, a rendszer ezt jó eséllyel lágy 404-ként kezeli, mert a célon nincs meg az az információ, amit a felhasználó keresett. Vagyis a tömeges kezdőlapra terelés nem menti meg a régi oldalak teljesítményét, csak eltakarja a hibát.
Mi a különbség a 301, 302, 307 és 308 között?
A négy kód két tengely mentén különbözik: végleges vagy ideiglenes a változás, illetve megőrzi-e a rendszer az eredeti HTTP-metódust.
- 301 (Moved Permanently): végleges. A böngészők agresszíven gyorsítótárazzák, a POST kérést a gyakorlatban GET-re válthatja.
- 302 (Found): ideiglenes. A kereső jelzésként azt olvassa ki, hogy a régi cím marad az elsődleges.
- 307 (Temporary Redirect): ideiglenes, de kötelezően megőrzi a metódust és a kérés törzsét. Űrlapfeldolgozásnál ez a helyes ideiglenes forma.
- 308 (Permanent Redirect): a 301 szigorú megfelelője, szintén megőrzi a metódust.
Szakmai feltételezés: a keresők hosszú távon a tartósan fennálló 302-t is végleges költözésként értelmezhetik, de erre építeni felesleges kockázat. Ha a szándékod végleges, mondd ki egyértelműen 301-gyel. A meta refresh és a JavaScriptes átirányítás technikailag feldolgozható, de lassabb és törékenyebb megoldás, ezért szerveroldali választ érdemes előnyben részesíteni.
Egy fontos, gyakran kimaradó részlet: a 301-et a böngésző hosszú ideig megjegyzi. Ha véletlenül rossz célra állítod be, a saját géped a javítás után is a hibás címre visz, amíg ki nem üríted a gyorsítótárat. Ezért teszteld inkubáció nélkül, parancssorból.
Hogyan alakul ki a végtelen hurok, és hogyan bontod ki?
A hurok szinte mindig két, egymásról nem tudó réteg terméke: a szerverkonfiguráció és a CMS vagy egy bővítmény ugyanazt a szabályt ellentétes irányban írja elő.
A három leggyakoribb forrás a gyakorlatban:
- a szerver a www nélküli alakra irányít, a CMS beállítása viszont a www-s címet tekinti kanonikusnak,
- a tartalomkiszolgáló hálózat rugalmas SSL-módban http-n kéri le a forrást, a szerver pedig mindent https-re küld,
- a záró perjel kezelése eltér: az egyik szabály hozzáteszi, a másik leszedi.
A diagnózis egyetlen paranccsal elvégezhető, amely kiírja a teljes ugrássort:
curl -sIL https://pelda.hu/regi-oldal | grep -E "HTTP/|[Ll]ocation:"
Ha a kimenetben ugyanaz a két cím váltakozik, hurokban vagy. A megoldás nem az, hogy egy harmadik szabályt írsz hozzá, hanem hogy megkeresed, hány helyen van egyáltalán átirányítási logika: a szerverkonfigurációban, a .htaccess fájlban, a CMS beállításaiban, az esetleges átirányításkezelő bővítményben és a tartalomkiszolgáló hálózat felületén. Egy szabály maradjon, a többit kapcsold ki.
Hogyan készíts URL-térképet a költöztetés előtt?
Az átirányítási terv a migráció legfontosabb dokumentuma, és a fejlesztés megkezdése előtt kell elkészülnie, nem az élesítés estéjén.
- Teljes leltár: gyűjtsd össze a régi URL-eket több forrásból. Feltérképező eszköz futtatása, a régi sitemap fájlok, a Search Console oldaljelentése, a webanalitika legalább tizenkét havi belépőoldal-listája, a hivatkozásokat kimutató eszközök és a szerver hozzáférési naplója. Egyik forrás sem teljes önmagában.
- Rangsorolás: jelöld meg azokat a címeket, amelyekre külső hivatkozás mutat, amelyek szerves forgalmat hoznak, vagy amelyeken ajánlatkérés születik. Ezek kapják a kézi figyelmet.
- Egy az egyhez megfeleltetés: táblázatban vezesd, régi cím, új cím, típus, felelős oszlopokkal. Ahol nincs valódi megfelelő, ott ne erőltess kapcsolatot, inkább a legközelebbi kategóriaoldal vagy a 410 legyen a döntés.
- Mintázatok először, kivételek utána: ha a struktúra kiszámíthatóan változik, egyetlen szabály sok száz címet lefed. A kivételek listája ezután jön.
- Összevont kanonikus szabály: a protokoll és a hosztnév egységesítése menjen egy lépésben.
Apache környezetben egy egyedi útvonalszabály így néz ki:
RewriteRule ^szolgaltatasok/klimaszereles/?$ /szolgaltatasaink/klimaszereles/ [R=301,L]
Nginx alatt a kanonikus alak egyetlen ugrással:
server { listen 80; server_name pelda.hu www.pelda.hu; return 301 https://www.pelda.hu$request_uri; }
A lényeg mindkét esetben ugyanaz: a régi cím a végleges, https-es, www-s, helyes útvonalú és helyes perjelezésű célra mutasson, egy lépésben.
Mit ellenőrizz a migráció utáni első két hétben?
Az élesítés utáni tíz-tizennégy nap dönti el, hogy a költöztetés simán vagy fájdalmasan zajlik. Az alábbi lista végigfutása néhány óra munka, és a legtöbb tartós kárt megelőzi.
- Ugrásszám: a legfontosabb száz régi címre futtass ellenőrzést, és nézd meg, hogy mindegyik pontosan egy ugrással ér célba, 301-gyel és 200-as végállapottal.
- Sitemap: az új sitemap kizárólag 200-as státuszú, végleges címeket tartalmazzon. Átirányított URL a sitemapben ellentmondásos jelzés.
- robots.txt: ellenőrizd, hogy a staging környezetből nem került át tiltó szabály. Ez a leggyakoribb egyszeri, mégis legdrágább hiba.
- Canonical elemek: minden új oldal önmagára mutasson, ne a régi címre.
- Belső linkek: a menü, a lábléc, a szövegközi hivatkozások és a képek forrásai már az új címeket használják. Az átirányításra hagyatkozó belső linkelés generálja utólag a láncokat.
- Search Console: domainváltásnál használd a címváltoztatás eszközt, és tartsd meg a régi tulajdont is, hogy lásd a lefutást. Figyeld az oldalak jelentésben az átirányítással jelölt és a nem talált kategóriák alakulását.
- Naplófájl: hetente nézd át a 404-es kéréseket. Itt jönnek elő azok a régi címek, amelyekről senki nem tudott.
- Külső érintettek: hirdetési fiókok céloldalai, e-mail sablonok, Google cégprofil, közösségi oldalak, partneroldalak, nyomtatott anyagokon szereplő címek, QR-kódok.
- Strukturált adatok és hreflang: ha ezek régi URL-eket tartalmaznak, javítsd őket.
Hivatalosan igazolt: a Google ajánlása szerint az átirányításokat legalább egy évig fenn kell tartani, mert ennyi idő alatt cserélődnek le a külső hivatkozások és a könyvjelzők. Saját tapasztalat: kkv-oldalaknál érdemesebb egyszerűen soha nem kikapcsolni őket, mert az adminisztratív nyereség elenyésző a kockázathoz képest.
Milyen átirányítási hibákat látni a leggyakrabban kkv-oldalakon?
Saját tapasztalat: a hibák meglepően ismétlődőek, és szinte mindig a fenti alapelvek egyikének megsértéséből fakadnak.
- Minden régi cím a kezdőlapra megy, mert így volt a leggyorsabb.
- Az ékezetes vagy régi, kódolt karaktereket tartalmazó URL-ek kimaradnak a tervből, mert a feltérképező eszköz máshogy írja őket, mint a szerver.
- A https és a www egységesítése két külön szabályban van, tehát minden régi hivatkozás automatikusan két ugrás.
- Egy átirányításkezelő bővítmény és a szerverkonfiguráció ugyanazt a szabályt tartja karban, egymással ellentétesen.
- A CMS alapértelmezésben ideiglenes kódot ad, és senki nem nézi meg, mit küld valójában.
- A második vagy harmadik költöztetés után a korábbi átirányítások egymásra épülnek, ahelyett hogy mindegyik közvetlenül az aktuális végállapotra mutatna.
Ez az utolsó pont a legalattomosabb. Ha három évvel később újra változik a struktúra, ne a legutóbbi szabályt bővítsd, hanem írd át a régi bejegyzéseket is az új végcélra. Így a lánc soha nem nő egy ugrás fölé.
Hogyan érinti mindez az AI-válaszmotorokat?
A válaszmotorok ugyanazon a HTTP-rétegen keresztül érik el az oldalt, mint a klasszikus keresők, tehát az átirányítási hibák ugyanúgy kihatnak rájuk.
Hivatalosan igazolt: a nagyobb modellszolgáltatók dokumentálják a saját feltérképező ügynökeiket és azt, hogy azok tiszteletben tartják a robots.txt szabályait. Szakmai feltételezés: a valós idejű, ügynöki lekérések szűkebb időkorláttal dolgoznak, mint egy türelmes keresőrobot, ezért egy többlépcsős lánc vagy egy lassú, gyorsítótárazatlan átirányítás nagyobb eséllyel vezet oda, hogy az adott forrás egyszerűen kimarad a válaszból. Ezt nyilvános, mérhető adat egyelőre nem támasztja alá, de a kockázat csökkentése amúgy is egybeesik a jó gyakorlattal.
Gyakorlati következtetés: a stabil, ritkán változó, egyértelmű URL a legjobb befektetés. Ha egy szolgáltatásoldal címe öt éve ugyanaz, minden hivatkozás, idézet és mentett hely érvényes marad. Ez nem garantál sem helyezést, sem említést egyetlen rendszerben sem, de érdemben csökkenti annak esélyét, hogy technikai okból veszíts láthatóságot.
Források és további olvasnivalók
- Google Search Central: Redirects and Google Search
- Google Search Central: Site move with URL changes
- Google Search Console Súgó: Címváltoztatás eszköz
- Google Search Central: Soft 404 hibák kezelése
- RFC 9110: HTTP Semantics (3xx státuszkódok)
- MDN Web Docs: HTTP redirections
- Bing Webmaster Guidelines
- OpenAI: GPTBot és crawler dokumentáció
- Schema.org, W3C
Gyakori kérdések
Hány átirányítási ugrás fogadható el?
A cél mindig az egy ugrás. A Google dokumentációja szerint a Googlebot egy kísérlet során legfeljebb tíz ugrást követ, de ez felső korlát, nem ajánlás. Kettő fölött érdemes felülvizsgálni a szabályokat, mert onnantól már lassulást és hibalehetőséget okoz.
Mi történik, ha minden régi oldalt a kezdőlapra irányítok át?
A Google leírásai szerint az ilyen tömeges terelés jó eséllyel lágy 404-ként lesz kezelve, mert a célon nincs meg a keresett tartalom. A látogató sem találja meg, amiért kattintott. Ha nincs releváns új oldal, tisztább megoldás a 410 vagy egy jól felépített kategóriaoldal.
Meddig kell fenntartani az átirányításokat?
A Google ajánlása szerint legalább egy évig, mert ennyi idő alatt frissülnek a külső hivatkozások és a mentett címek. Kisebb oldalaknál a szabályok fenntartása nem jelent terhet, ezért a gyakorlatban érdemes véglegesen megtartani őket.
Honnan tudom, hogy 301 vagy 302 megy ki valójában?
Parancssorból ellenőrizheted: a curl -sIL parancs kiírja a teljes ugrássort a státuszkódokkal együtt. Böngészőben a fejlesztői eszközök hálózati fülén is látszik. Sok CMS és bővítmény alapértelmezésben ideiglenes kódot küld, ezért ezt konkrétan meg kell nézni, nem elég feltételezni.
Az átirányítás átviszi a régi oldal teljesítményét?
Egy helyesen beállított 301 azt jelzi a keresőknek, hogy az új cím az utód, és a jelzések nagyrészt átvezetődnek. Ez azonban nem garantál változatlan helyezéseket, főleg ha a céloldal tartalma vagy szándéka eltér a régiétől. Minél közelebbi a megfeleltetés, annál kisebb az ingadozás.
Mi a teendő, ha végtelen hurokra fut az oldal?
Először derítsd ki, hány helyen van átirányítási logika: szerverkonfiguráció, .htaccess, CMS-beállítás, bővítmény, tartalomkiszolgáló hálózat. A hurok szinte mindig két ellentétes szabályból áll össze. A megoldás az egyik réteg kikapcsolása, nem egy újabb szabály hozzáadása.
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.