Átirányítás .htaccess-ben, Nginx-ben vagy bővítménnyel

Scheo · 2026-10-25 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha WordPress-oldalon URL-t váltasz, kategóriát nevezel át vagy domaint költöztetsz, a 301-es átirányítás dönti el, hogy a régi címre érkező látogató és keresőrobot hová jut. Három helyen kezelheted: Apache vagy LiteSpeed alatt az .htaccess fájlban, Nginx alatt a szerverkonfigurációban, vagy egy Redirection-típusú bővítményben. Mindhárom működik, de máshol törik el, és ez a különbség akkor derül ki, amikor már baj van. Az alábbiakban jelölöm, mi hivatalosan igazolt (dokumentációban leírt), mi saját tapasztalat, és mi szakmai feltételezés.

Mi a lényegi különbség a három megoldás között?

A szerverszintű átirányítás (.htaccess, Nginx) még a WordPress betöltése előtt válaszol, a bővítményes viszont csak azután, hogy a PHP és az adatbázis-kapcsolat már elindult. Ebből következik szinte minden más eltérés: a sebesség, a hibatűrés és az, hogy mi történik költözéskor.

• .htaccess: könyvtárszintű konfigurációs fájl, amelyet az Apache (és a LiteSpeed) minden kérésnél beolvas, ha a szerver engedélyezi (AllowOverride). Megosztott tárhelyen gyakran ez az egyetlen szerverszintű lehetőséged.
• Nginx-konfiguráció: a szerver indításakor vagy újratöltésekor töltődik be, kérésenként nem olvassa újra. Hozzáférés kell hozzá (VPS, saját szerver vagy olyan tárhely, amely engedi az egyedi szabályokat).
• Bővítmény: a szabályok adatbázis-táblában vannak, a WordPress felületén szerkeszted őket, és a legtöbb ilyen eszköz a 404-es hibákat is naplózza.

Hivatalosan igazolt: az Apache dokumentációja kifejezetten azt írja, hogy ha hozzáférsz a fő szerverkonfigurációhoz, kerüld az .htaccess használatát, mert kérésenkénti fájlolvasással jár. Az Nginx dokumentációja pedig rögzíti, hogy az Nginx nem támogatja az .htaccess fájlokat.

Melyik a leggyorsabb?

Az Nginx-konfigurációban megírt átirányítás a leggyorsabb, utána jön az .htaccess, és a bővítményes a leglassabb, mert ahhoz a teljes WordPressnek el kell indulnia. Egy-egy átirányításnál a különbség a felhasználó számára alig érzékelhető, de láncoknál, sok egyidejű robotkérésnél és gyenge tárhelyen összeadódik.

Saját tapasztalat: átlagos megosztott tárhelyen a bővítményes 301 válaszideje jellemzően a WordPress „üres” oldalbetöltési idejéhez közelít, míg a szerverszintű szinte azonnal visszajön. A pontos számot mindig a saját szervereden mérd meg curl-lel (lásd a tesztelési részt), mert tárhelyenként nagyon eltér.

Szakmai feltételezés: a robotforgalom (keresők és AI-crawlerek) jelentős része régi, átirányított URL-eket kér le. Ha ezeket a WordPressnek kell kiszolgálnia, az a szerver terhelését szükségtelenül növeli, ezért nagy forgalmú oldalon a szerverszintű megoldás terhelés szempontjából is jó eséllyel előnyösebb.

Melyiket könnyebb karbantartani?

A bővítmény a legkényelmesebb, mert nem kell hozzá fájlhoz vagy szerverhez nyúlni, a szerverszintű szabályok viszont átláthatóbbak és verziókezelhetők. A választás azon múlik, ki tartja karban az oldalt.

• Ha a tartalomszerkesztő vagy a marketinges kezeli az URL-eket, a bővítmény felülete csökkenti a hibalehetőséget. Egy elgépelt .htaccess sor 500-as hibával az egész oldalt leállíthatja.
• Ha fejlesztő kezeli az oldalt, a konfigurációs fájl (főleg Nginxnél egy külön, beemelt fájl) Gitben követhető, visszaállítható, és egy pillantással látszik, mi történik.
• A bővítmények egy része a WordPress „régi slug” mechanizmusával is ütközhet. Hivatalosan igazolt: a WordPress magja a bejegyzés slugjának módosításakor eltárolja a régi slugot, és a régi címet magától átirányítja. Ezt sokan nem tudják, és feleslegesen duplán is felveszik.

Saját tapasztalat: évek után a legtöbb probléma abból jön, hogy az átirányítások egyszerre három helyen élnek (.htaccess, bővítmény, tárhelypanel), és senki nem tudja, melyik nyer. Döntsd el, hol a „hivatalos” lista, és máshová ne vegyél fel szabályt.

Hogyan állnak a regex-támogatással?

Mindhárom megoldás kezeli a reguláris kifejezéseket, de összetett mintákat (lekérdezési paraméter, több feltétel) a szerverszintű szabályokkal lehet a legpontosabban leírni.

Az Apache-ban a RedirectMatch és a mod_rewrite (RewriteCond, RewriteRule) ad regexet. Az Nginx PCRE-t használ, támogatja a nevesített csoportokat is. A Redirection bővítményben szabályonként bekapcsolható a regex mód, és lekérdezési paraméterekre külön illesztési beállítások vannak. Saját tapasztalat: a bővítményes regex hibáját nehezebb észrevenni, mert nem kapsz szintaktikai hibaüzenetet, csak nem illeszkedik a szabály.

Mi történik tárhelyváltáskor vagy a bővítmény kikapcsolásakor?

A bővítményes átirányítás a bővítmény kikapcsolásának pillanatában megszűnik, az .htaccess pedig tisztán Nginx-es tárhelyre költözve némán hatástalanná válik. Ez a két leggyakoribb csendes hiba.

• Bővítmény kikapcsolása: a szabályok az adatbázisban maradnak, de nem futnak. Egy hibakereséskor „mindent kikapcsolok” lépés után a régi URL-ek 404-et adnak, amíg vissza nem kapcsolod.
• Költözés Apache-ról Nginxre: az .htaccess fájl átmegy a többi fájllal, látszólag minden rendben, de az Nginx figyelmen kívül hagyja. A hiba csak a Search Console 404-es jelentéseiben vagy a forgalomesésben derül ki.
• Költözés LiteSpeedre: a LiteSpeed olvassa az .htaccess fájlt, így a szabályok jellemzően működnek, de az egzotikusabb direktívákat érdemes ellenőrizni.
• Bővítményes oldal költözése: mivel a szabályok az adatbázisban vannak, az adatbázissal együtt költöznek, ez a bővítmény egyik valódi előnye.
• Oldal-gyorsítótárazás: saját tapasztalat, hogy ha a gyorsítótárazó bővítmény már elmentette a régi URL HTML-jét, az kiszolgálhatja a régi oldalt a bővítményes átirányítás helyett. Új szabály után ürítsd a gyorsítótárat.

Hasznos biztonsági háló, hogy a Redirection bővítmény a szabályokat Apache- és Nginx-formátumban is exportálni tudja. Költözés előtt mentsd ki így, és ha a cél szerver Nginx, ebből indulva írd át.

Milyen mintaszabályokat használhatsz?

Az alábbi minták a három leggyakoribb esetet fedik le: egyetlen URL, egy teljes könyvtár és egy lekérdezési paraméteres régi cím. Élesítés előtt mindig tesztkörnyezetben vagy alacsony forgalmú időszakban próbáld ki őket, és készíts mentést az eredeti fájlról.

Egyedi URL átirányítása

Apache (.htaccess), a WordPress saját blokkja elé írva:

Redirect 301 /regi-szolgaltatas/ https://www.pelda.hu/szolgaltatasok/weboldal-karbantartas/

Nginx, a server blokkon belül:

location = /regi-szolgaltatas/ { return 301 https://www.pelda.hu/szolgaltatasok/weboldal-karbantartas/; }

Az = pontos egyezést jelent, így a szabály nem kap el más, hasonlóan kezdődő címet.

Teljes könyvtár átirányítása

Apache-ban a Redirect előtag-egyezéssel dolgozik, és a cím maradékát magától hozzáfűzi, így a /blog/akarmi/ a /hirek/akarmi/ címre megy:

Redirect 301 /blog/ https://www.pelda.hu/hirek/

Nginxben nevesített csoporttal:

location ^~ /blog/ { rewrite ^/blog/(?<rest>.*)$ /hirek/$rest permanent; }

Figyelj rá, hogy a Redirect a /blog előtagot a /blogger elején is megtalálja, ezért mindig perjellel zárd a forrást.

Lekérdezési paraméteres régi cím

Régi webshopokban gyakori a /termek.php?id=42 típusú cím. Apache-ban a Redirect nem látja a lekérdezést, ide mod_rewrite kell:

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)id=42(&|$)
RewriteRule ^termek\.php$ /termekek/kek-polo/ [R=301,L,QSD]

A QSD jelző (Apache 2.4-től) eldobja a régi lekérdezést, így az nem ragad hozzá az új címhez. Nginxben:

location = /termek.php { if ($arg_id = "42") { return 301 /termekek/kek-polo/; } }

Ha több száz ilyen párod van, ne írj mindegyikhez külön blokkot. Nginxben a map direktíva egy külön fájlból olvas kulcs-érték párokat (map $request_uri $uj_cim { include /etc/nginx/redirects.map; }), a server blokkban pedig egyetlen feltétel kezeli mindet. Hivatalosan igazolt: a map hash-táblát használ, így nagy listánál is hatékony marad.

Hogyan teszteld, hogy tényleg jól működik?

A 301-et ne a böngészőben teszteld, mert az tartósan gyorsítótárazza, és egy hibás szabály még a javítás után is „működni” látszik. Használj curl-t.

1. Fejlécek lekérése: curl -I https://www.pelda.hu/regi-szolgaltatas/. A válaszban 301 állapotkódot és a helyes Location fejlécet kell látnod.
2. Lánc követése: curl -sIL https://www.pelda.hu/regi-szolgaltatas/ | grep -iE "^HTTP|^location". Ideális esetben egy ugrás után 200-at kapsz. Két-három lépéses láncnál (http, www, perjel, új slug) vond össze a szabályokat.
3. Csak a lényeg: curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" URL. Egy URL-listán ciklusban futtatva gyorsan átnézhetsz akár több száz régi címet.
4. Lekérdezéses változatok: teszteld a paraméter nélküli, a több paraméteres és a fordított sorrendű változatot is, hogy a szabály ne kapjon el olyat, amit nem kellene.
5. Böngészős ellenőrzés: csak inkognitó ablakban vagy a fejlesztői eszközök „Disable cache” opciójával, és a Hálózat fülön nézd az állapotkódot.
6. Gyorsítótárak: ürítsd az oldalgyorsítótárat, a szerveroldali gyorsítótárat és a CDN-t, mielőtt végleges eredményt mondasz.
7. Nginx-szintaxis: újratöltés előtt mindig nginx -t, és csak hibátlan eredmény után reload.
8. Utókövetés: néhány hét múlva nézd meg a Search Console oldalindexelési jelentését és a szervernaplót, maradt-e 404 vagy átirányítási hiba.

Hivatalosan igazolt: a Google Search Central szerint a szerveroldali 301 és 308 állandó átirányításnak számít, és a kanonikus URL kiválasztásánál erős jelzés. Azt is javasolja, hogy költözésnél az átirányításokat legalább egy évig tartsd fenn. Az átirányítás önmagában nem jelent helyezésmegtartást, csak azt segítheti, hogy a régi oldal jelei az újra kerüljenek.

Hogyan vidd át lépésről lépésre a bővítményes szabályokat szerverszintre?

Exportáld a szabályokat, tisztítsd meg a listát, írd be a szerverkonfigurációba, teszteld, és csak a sikeres teszt után kapcsold ki a bővítményes szabályokat. A sorrend azért számít, mert így egyetlen pillanatra sem marad átirányítás nélkül a régi cím.

1. Export: a bővítmény exportfunkciójával mentsd ki a teljes listát (Apache vagy Nginx formátumban, illetve CSV-ben a táblázatos munkához).
2. Tisztítás: töröld a duplikátumokat, a már 404-et adó célokat és a láncokat. Ha A a B-re, B pedig a C-re mutat, írd át A-t közvetlenül C-re.
3. Sorrend a fájlban: a konkrét, egyedi szabályok kerüljenek az általános minták elé, és mind a WordPress saját átírási blokkja elé, különben a WordPress kapja el a kérést.
4. Párhuzamos teszt: a szerverszintű szabály élesítése után a bővítményes még aktív, de a szerver válaszol előbb. A curl-lel ellenőrizd, hogy a válasz fejlécei már a szervertől jönnek (a bővítményes válaszban gyakran saját azonosító fejléc is szerepel).
5. Kivezetés: csak ezután tiltsd le vagy töröld a bővítményes szabályokat, a 404-naplózást pedig nyugodtan hagyd bekapcsolva.

Saját tapasztalat: a tisztítás lépésnél rendszerint kiderül, hogy a lista jelentős része elavult vagy láncba fűzött. Ezt érdemes táblázatban végigmenni, mielőtt bármi a szerverkonfigurációba kerül.

Melyik megoldás melyik oldalméretnél ésszerű?

Saját nézőpontom szerint a döntést az átirányítások száma, a minták összetettsége és a szerver-hozzáférés együtt adja ki, nem az, melyik eszköz a „legjobb”. Az alábbi sávok saját tapasztalaton alapuló hüvelykujjszabályok, nem szabványok.

• Kis oldal (néhány tucat átirányítás, nincs szerver-hozzáférés): a Redirection-típusú bővítmény teljesen ésszerű. A 404-naplózás itt sokat ér, mert megmutatja, mit keresnek a látogatók. Egy szabályt tarts be: a bővítményt hibakereséskor se kapcsold ki gondolkodás nélkül.
• Közepes oldal (néhány száz átirányítás, Apache vagy LiteSpeed): a végleges, ritkán változó szabályokat (domaincsere, http-https, könyvtárak) tedd .htaccess-be, az alkalmi, szerkesztők által felvett egyedi URL-eket hagyd a bővítményben. Írd le egy belső dokumentumban, mi hol él.
• Nagy oldal vagy migráció (ezres nagyságrend, webshop, több nyelv): szerverszint, Nginx alatt map-fájllal, Apache alatt lehetőleg a fő konfigurációban. A listát táblázatból generáld, verziókezeld, és minden módosítás után futtasd le a curl-es ellenőrzést a teljes listán.
• Bármilyen méretnél, ha Nginx-re költözöl: az .htaccess szabályait előre fordítsd át, és a költözés napján teszteld a teljes listát.

Szakmai feltételezés: az AI-alapú keresők és válaszmotorok ugyanúgy követik a 301-et, mint a hagyományos robotok, ezért a tiszta, lánc nélküli átirányítás jó eséllyel azt is segíti, hogy egy korábban idézett oldaladra mutató hivatkozás ne vesszen el. Erről nincs részletes nyilvános dokumentáció, ezért kezeld óvatosan.

Források és további olvasnivalók

• Google Search Central: Átirányítások és a Google Kereső
• Google Search Central: Webhely áthelyezése URL-módosításokkal
• Apache HTTP Server dokumentáció: .htaccess útmutató, mod_alias és mod_rewrite
• Nginx dokumentáció: ngx_http_rewrite_module és ngx_http_map_module
• WordPress fejlesztői dokumentáció: wp_old_slug_redirect
• Redirection bővítmény hivatalos dokumentációja (redirection.me)
• IETF RFC 9110: HTTP Semantics (301 és 308 állapotkódok)