WordPress redirect: teljes útmutató

A WordPress redirect egy átirányítás, amely a régi URL-re érkező látogatót és keresőrobotot automatikusan egy új címre küldi. Végleges költözésnél 301-es, ideiglenesnél 302-es vagy 307-es kódot használj, megszűnt tartalomnál 410-et. Beállíthatod bővítménnyel, SEO pluginnal, .htaccess vagy Nginx szabállyal, illetve szerver- vagy CDN-szinten. A lényeg: közvetlen cél, lánc nélkül, mérve.

Alapfogalmak

Mielőtt bármit beállítasz, érdemes tisztázni a szókincset, mert a legtöbb átirányítási hiba fogalmi keveredésből születik. Az átirányítás lényege, hogy a szerver egy kérésre nem a kért tartalmat adja vissza, hanem egy állapotkódot és egy új címet (a Location fejlécben). A böngésző ezt követi, a keresőrobot pedig ebből értelmezi, mi történt az oldallal.

A WordPress környezetben három réteg adhat ki átirányítást: a webszerver (Apache vagy Nginx), maga a WordPress (PHP-szinten, bővítményen vagy a téma kódján keresztül), és egy elé tett réteg, például CDN vagy reverse proxy. Ugyanaz az URL tehát több helyen is kaphat szabályt, és ez a forrása a legtöbb meglepetésnek.

Az állapotkódok, amelyeket ismerned kell

Kód	Jelentés	Mikor használd
301	Végleges átirányítás	URL-csere, domainváltás, oldalak összevonása
302	Ideiglenes átirányítás (Found)	Rövid távú kampány, karbantartás alatti kerülőút
307	Ideiglenes, a kérés metódusát megtartja	Ideiglenes eset, ahol fontos, hogy például a POST kérés POST maradjon
308	Végleges, a metódust megtartja	Végleges eset, űrlapokat vagy API-végpontokat érintő költözés
410	Véglegesen megszűnt	Törölt tartalom, amelynek nincs releváns utódja
404	Nem található	Nem átirányítás, de gyakran ezzel kell összevetni a döntést

Mi az a forrás és a cél URL?

A forrás az a cím, amelyre a kérés érkezik (például /regi-szolgaltatas/), a cél pedig az, ahová küldöd (például /szolgaltatasok/weboldal-keszites/). Fontos részlet, hogy a forrás lehet pontos egyezés vagy minta (reguláris kifejezés). Egy mintára épülő szabály egyszerre több száz URL-t is kezelhet, ami hatékony, de egy rossz karakter is elég ahhoz, hogy a fél oldalt rossz helyre küldje.

Átirányítás, kanonikus URL, rel=canonical: nem ugyanaz

Gyakori tévhit, hogy a canonical címke átirányítás. Nem az. A canonical egy jelzés a keresőnek arról, melyik változatot tekintsd elsődlegesnek, de a látogató ugyanazon az oldalon marad. Az átirányítás viszont fizikailag elviszi a felhasználót. Ha egy oldalra már senkinek nem kell eljutnia, átirányítás kell. Ha két változatnak létjogosultsága van (például szűrt listák), canonical.

Lánc és hurok

Láncról beszélünk, ha A átirányít B-re, B pedig C-re. Hurok akkor van, ha a lánc visszaér önmagába (A, B, A), ilyenkor a böngésző hibát jelez. A lánc nem azonnal katasztrófa, de minden lépés lassít, és a keresőrobotok egy idő után abbahagyhatják a követést. A cél mindig az, hogy a forrás egy lépésben a végső címre mutasson.

Mit csinál magától a WordPress?

A WordPress beépítetten is kezel bizonyos átirányításokat. Ha megváltoztatod egy bejegyzés slugját, a rendszer eltárolja a régit, és megpróbálja a régi címre érkezőket az újra küldeni. A kanonikus átirányítás funkció a hiányzó perjelet, a www és nem-www eltérést vagy a kis-nagybetű-szerű apró eltéréseket is igazíthatja. Ez kényelmes, de nem helyettesíti a tudatos átirányítási tervet, főleg szerkezeti átalakításnál, ahol a slug-előzmény nem elég.

Hogyan működik?

Egy átirányítás útja a kérés pillanatától a végső oldal betöltéséig több állomáson megy át. Ha érted a sorrendet, könnyebben kitalálod, melyik réteg felel egy furcsa viselkedésért, és hová érdemes a szabályt tenni.

A kérés útja lépésről lépésre

A böngésző vagy robot lekéri a régi URL-t.
Ha van CDN vagy proxy, az kapja meg először. Ha ott van szabály, már itt visszaküldheti az átirányítást, a szervered nem is látja a kérést.
A webszerver (Apache esetén a .htaccess és a virtuális host beállítás, Nginx esetén a szerverkonfiguráció) ellenőrzi a saját szabályait.
Ha a szerver nem irányít át, a kérés eljut a WordPresshez (index.php), betöltődik a mag, a bővítmények és a téma.
Egy átirányító bővítmény a betöltés korai szakaszában összeveti az URL-t a szabályaival, és ha talál egyezést, elküldi a megfelelő kódot és Location fejlécet.
Ha egyik réteg sem irányít át, a WordPress megpróbálja megjeleníteni a tartalmat, vagy 404-et ad.
A böngésző a kapott kód alapján lekéri a cél URL-t, és az egész kezdődik elölről.

Miért számít, melyik rétegen van a szabály?

Minél korábbi rétegen történik az átirányítás, annál kevesebb erőforrást használ. Egy CDN-szintű szabály úgy is válaszol, hogy a szerveredhez el sem jut a kérés. A szerverszintű szabály még nem tölti be a PHP-t. A bővítményes megoldás viszont minden egyes átirányított kérésnél elindítja a WordPress egy részét. Néhány tucat szabálynál ez a gyakorlatban alig érezhető, több ezres, nagy forgalmú listánál viszont már érdemes elgondolkodni a szerverszintű megoldáson.

A másik szempont a karbantarthatóság. A bővítményes felületet bárki kezeli a szerkesztőségből, a .htaccess fájlhoz viszont fejlesztői hozzáférés és óvatosság kell. Egy elírás a .htaccess fájlban az egész oldalt elérhetetlenné teheti.

Hogyan értelmezi a kereső?

A Google nyilvános dokumentációja szerint a végleges átirányítás erős jelzés arra, hogy a cél legyen a kanonikus változat, az ideiglenes pedig gyengébb jelzés. A keresőrobot az átirányításokat követi, de ésszerű határon belül: túl hosszú láncnál egy idő után feladhatja. A gyakorlati szabály ebből egyszerű: végleges változásnál végleges kódot adj, és tartsd rövidre az utat.

Gyorsítótár és böngésző

A 301-es választ a böngészők agresszíven gyorsítótárazhatják. Ez azt jelenti, hogy ha tévedésből 301-et állítottál be, majd visszavonod, a korábbi látogatók böngészője még egy ideig az eredeti célra viheti őket. Teszteléskor ezért használj privát ablakot vagy parancssori eszközt, és ha nem vagy biztos a döntésben, kezdj 302-vel, majd a végleges állapotot rögzítsd 301-gyel.

Kidolgozott példa: egy URL-szerkezet átalakítása

Szemléltető eset: egy blog eddig a /2023/05/cikk-cime/ formát használta, és átállsz a /blog/cikk-cime/ formára. Ha csak a permalink beállítást módosítod, a WordPress a régi címeket részben feloldhatja, de nem garantált, hogy minden külső link jól landol. A tiszta megoldás egy mintaalapú szabály: a forrás ^/\d{4}/\d{2}/(.*)$, a cél /blog/$1, 301-es kóddal. Ezzel egyetlen sor kezeli az összes régi cikkcímet, és lánc sem keletkezik, ha a cél már a végleges forma.

Fő módszerek

Négy fő utad van az átirányítás beállítására WordPress alatt. Egyik sem jobb minden helyzetben, a választás a szabályok számától, a forgalomtól és attól függ, ki fogja kezelni őket hosszú távon.

1. Önálló átirányító bővítmény

Az egyik legismertebb ingyenes megoldás a Redirection nevű bővítmény. Ezekben jellemzően felvehetsz egyedi szabályokat, mintákat, csoportokat hozhatsz létre, és naplózhatod a 404-es hibákat, amelyekből új szabályokat gyárthatsz. Előnye, hogy nem kell fájlokhoz nyúlnod, és a szerkesztők is tudják kezelni. Hátránya, hogy PHP-szinten fut, és ha a naplózást mindenre bekapcsolva hagyod, az adatbázis idővel felduzzadhat.

2. A SEO bővítmény átirányítás-kezelője

Ha már használsz SEO bővítményt, érdemes megnézni, nincs-e benne átirányító modul, így nem kell külön bővítményt telepíteni. A Rank Math beépített átirányítás-modullal rendelkezik, a Yoast SEO-nál ez a fizetős változat része, az All in One SEO-nál pedig a Pro csomagok kiegészítőjeként érhető el. A pontos funkciókészlet verziónként változhat, ezért a saját telepítésednél ellenőrizd. A részletekhez nézd meg a Rank Math: teljes útmutató, a Yoast SEO: teljes útmutató és az All in One SEO: teljes útmutató anyagokat.

Egy kényelmi előny: ezek a modulok gyakran felajánlják, hogy URL-módosításkor vagy törléskor azonnal létrehozzák a szabályt. Ez sok elfelejtett átirányítást megelőz.

3. Szerverszintű szabály (.htaccess vagy Nginx)

Apache alatt a .htaccess fájlba írt szabály (Redirect 301 vagy RewriteRule) a WordPress betöltése előtt fut. Nginx alatt a szerverkonfigurációban adod meg a return vagy rewrite utasítást, ehhez általában tárhelyszolgáltatói vagy rendszergazdai hozzáférés kell. Ez a leggyorsabb és legstabilabb módszer domainváltáshoz, HTTPS-kényszerítéshez és nagy, mintaalapú szabálykészletekhez. Mindig készíts biztonsági mentést a fájlról módosítás előtt, és a WordPress saját blokkján (a BEGIN WordPress és END WordPress jelölések között) kívül dolgozz, különben a rendszer felülírhatja.

4. CDN- vagy tárhelyszintű szabály

Több CDN és menedzselt WordPress tárhely saját felületen kínál átirányítási szabályokat. Ez akkor jó választás, ha a forgalom nagy, vagy ha a régi domain már nem is mutat a WordPress szerveredre. Hátránya, hogy a szabályok kívül esnek a WordPress-felületen, így a csapat könnyen megfeledkezik róluk.

Döntési szabály: melyiket válaszd?

Helyzet	Ajánlott módszer
Néhány tucat egyedi URL, szerkesztők kezelik	SEO bővítmény modulja vagy önálló bővítmény
Domainváltás, HTTP-ről HTTPS-re, www egységesítés	Szerver vagy CDN
Több száz URL egy mintával	Szerverszintű regex szabály
Több ezer egyedi, nem mintázható URL	Szerverszintű térkép (például Nginx map) vagy CDN-lista
Ideiglenes kampány-átirányítás	Bővítmény, 302-es kóddal, lejárati emlékeztetővel

Egy szabály alapelv: ugyanarra az URL-re csak egy rétegben legyen szabály. Ha a szerver és a bővítmény is kezel egy címet, abból előbb-utóbb lánc vagy hurok lesz.

Gyakori hibák

Az átirányítási problémák jó része nem bonyolult technikai hiba, hanem figyelmetlenség vagy rossz döntés. Az alábbiak a leggyakoribbak, mindegyikhez a javítás módjával.

Minden törölt oldal a főoldalra megy

Kényelmesnek tűnik, de a keresők az ilyen, tartalmilag nem kapcsolódó átirányítást gyakran soft 404-ként kezelik, vagyis olyan oldalként, amely valójában nem létezik. A látogató sem azt kapja, amit keresett. Javítás: ha van tematikusan rokon oldal, oda irányíts. Ha nincs, adj 410-et vagy 404-et egy hasznos hibaoldallal.

Lánc a migrációk után

Tipikus eset: 2022-ben az A-t B-re irányítottad, 2024-ben B-t C-re. Most A két lépésben ér célba. Javítás: időnként frissítsd a régi szabályokat, hogy közvetlenül a végső címre mutassanak, és új szabálynál mindig nézd meg, nem forrása-e már valami korábbi átirányításnak.

302 végleges változásnál

Sok bővítmény vagy kézzel írt kód alapértelmezésként 302-t ad (a PHP header függvénye például Location fejlécnél alapból 302-t küld, ha nem adsz meg mást). Ha a költözés végleges, ez gyengébb jelzés, mint kellene. Javítás: ellenőrizd a tényleges kódot, ne a felület feliratát.

Ütköző rétegek és hurok

Klasszikus forgatókönyv: a CDN HTTPS-re kényszerít, a szerver viszont a CDN felől HTTP-t lát, és visszairányít HTTP-re. Az eredmény végtelen hurok. Ugyanez előfordulhat, ha a WordPress Webhely címe beállítás nem egyezik azzal, amit a szerver kényszerít (például www és nem-www). Javítás: egy helyen döntsd el a protokollt és a domain formáját, a többi réteg ehhez igazodjon.

Túl mohó reguláris kifejezés

Egy /termek mintájú szabály a /termekek-osszehasonlitasa/ címet is elkaphatja, ha nincs lezárva. Javítás: használj kezdő és záró jelölést (^ és $), és teszteld a mintát legalább öt valós és öt "nem szabad egyeznie" URL-lel.

Paraméterek elvesztése

Ha a kampány URL-ekben UTM-paraméterek vannak, egy rosszul beállított szabály eldobhatja őket, és az analitikában eltűnik a forrás. Javítás: nézd meg, hogyan kezeli az eszközöd a lekérdezési paramétereket (megtartja, eldobja vagy egyezésnél figyelembe veszi), és állítsd be tudatosan.

Belső linkek frissítésének elhagyása

Az átirányítás nem ok arra, hogy a menüben, a láblécben és a cikkekben a régi címek maradjanak. Minden belső link, ami átirányításon megy át, felesleges lépés. Javítás: migráció után keresd és cseréld a régi URL-eket az adatbázisban (óvatosan, mentés után, szerializált adatokat kezelő eszközzel).

Ellenőrzőlista élesítés előtt

A kód megfelel a szándéknak (végleges: 301 vagy 308, ideiglenes: 302 vagy 307)?
A cél tartalmilag releváns, és 200-as kódot ad?
Nincs lánc: a cél nem irányít tovább?
Ugyanarra a forrásra csak egy rétegben van szabály?
A regex nem fog meg nem kívánt URL-eket?
A belső linkek már az új címre mutatnak?
Az XML oldaltérkép csak a végső URL-eket tartalmazza?
Privát ablakban vagy parancssorból tesztelted, nem gyorsítótárból?

Mérés

Egy átirányítás nem ér véget a beállítással. Az igazi kérdés az, hogy a forgalom, az indexelés és a linkek valóban átkerültek-e. Ehhez néhány egyszerű, rendszeres ellenőrzés kell.

Technikai ellenőrzés: mit ad vissza a szerver?

A legmegbízhatóbb próba a parancssor. A curl -I https://pelda.hu/regi-cim/ parancs a fejléceket mutatja: itt látod a pontos állapotkódot és a Location értéket. A curl -IL változat végigköveti a láncot, így azonnal kiderül, hány lépés van. Böngészőben a fejlesztői eszközök Hálózat fülén ugyanezt megnézheted, ha bekapcsolod a napló megőrzését.

Tömeges ellenőrzés crawlerrel

Migráció után a régi URL-lista (például a régi oldaltérképből vagy egy korábbi crawl exportjából) a legértékesebb adatod. Futtasd végig egy webes feltérképező eszközzel lista módban, és szűrj a következőkre:

4xx és 5xx válaszok a régi címeken (hiányzó szabály)
Egynél több átirányítási lépés (lánc)
Olyan cél, amely nem 200-as kódot ad
Túl sok forrás ugyanarra a célra, főleg a főoldalra (gyanús tömeges átirányítás)

Search Console

A Google Search Console oldalindexelési jelentésében külön kategóriában láthatod az átirányítással rendelkező oldalakat és a 404-eseket. Migráció után ezt hetente érdemes nézni. Ha egy régi URL sokáig "átirányítással rendelkező" állapotban marad, az normális, a lényeg, hogy az új cél indexelve legyen. Domainváltásnál a címváltoztatás eszköz is a rendelkezésedre áll a régi tulajdonban.

Analitika és 404-napló

Nézd meg a forgalmat oldalanként a változás előtt és után. Ha a régi oldal havi szemléltető 1 000 látogatást hozott, az új címnek idővel hasonló nagyságrendet kell mutatnia. Jelentős visszaesésnél vizsgáld meg, a cél tényleg ugyanazt a kérdést válaszolja-e meg. Az átirányító bővítmények 404-naplója vagy a szerver hozzáférési naplója megmutatja, mely régi címekre érkezik még forgalom szabály nélkül.

Mérési workflow egy migrációhoz

Változás előtt: crawl, régi URL-lista exportja, a fő oldalak forgalmának és helyezéseinek mentése.
Élesítés napján: a teljes régi lista ellenőrzése lista módban, a hibák azonnali javítása.
Első hét: napi pillantás a 404-naplóra, Search Console indexelési jelentés.
Első hónap: heti forgalom-összevetés oldalcsoportonként.
Negyedévente: láncok felszámolása, elavult ideiglenes szabályok törlése vagy véglegesítése.

Meddig tartsd meg a szabályokat?

Nincs egyetlen helyes időtartam. A Google kommunikációja alapján egy végleges átirányítást érdemes legalább egy évig fenntartani, de ha a régi URL-re külső linkek mutatnak, érdemes akár határozatlan ideig megtartani. Egy szabály fenntartása olcsó, a megszüntetése viszont elveszett látogatókat jelenthet.

Kapcsolódó részletes útmutatók

Az átirányítás a WordPress SEO technikai alapjainak egyik eleme, és szorosan összefügg azzal, melyik SEO bővítményt használod. Az alábbi anyagokban részletesen megtalálod a tágabb keretet és az egyes bővítmények beállításait, beleértve az átirányítási funkciókat is.

Áttekintő anyagok

Ha a nagy képet keresed, kezdd a témakör kezdőoldalával és a teljes WordPress SEO útmutatóval. Ezek abban segítenek, hogy az átirányítást ne elszigetelt feladatként kezeld, hanem az URL-szerkezet, a belső linkelés és az indexelés részeként.

Bővítmény-specifikus útmutatók

Ha már eldöntötted, melyik SEO bővítményt használod, a hozzá tartozó útmutató megmutatja, hol találod az átirányítási beállításokat, és mire figyelj a többi SEO-funkcióval együtt. Választás előtt hasznos összevetni őket: a fő különbség gyakran az, hogy az átirányítás-kezelő melyik csomagban érhető el, és mennyire illeszkedik a csapatod munkamenetébe.

Hogyan haladj tovább?

Egy gyakorlati sorrend: először rögzítsd a domain és a protokoll végleges formáját szerverszinten, utána válassz egyetlen eszközt az egyedi szabályokhoz, végül építsd be a mérési workflow-t a havi karbantartásba. Ha ezt a három lépést következetesen tartod, a legtöbb átirányítási probléma meg sem jelenik, a ritka kivételeket pedig a 404-napló időben jelzi.