WordPress átírási szabályok ütközése: amikor egy bővítmény elviszi az URL-eidet

Scheo · 2026-09-24 · Frissítve: 2026-10-05 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha egy WordPress oldalon egyik napról a másikra 404-et ad a webhely fele, a keresés általában a szerveren indul. Megnézed a tárhelyet, a .htaccess fájlt, a PHP-hibanaplót, és semmi. Közben a válasz többnyire egy szinttel feljebb van, a WordPress saját átírási szabálykészletében, ahol két bővítmény ugyanarra az útvonal-előtagra pályázik, és az nyer, amelyik előrébb került a listán. Ez a cikk végigviszi, hogyan épül fel ez a lista, mi rontja el, és hogyan találod meg a tettest húsz perc alatt.

Hogyan dönti el a WordPress, melyik oldalt mutassa egy URL-re?

A WordPress egyetlen kérést sem old fel fájlként. Minden bejövő URL az index.php fájlba fut be, és egy regex-listán halad végig, amíg valamelyik minta nem illeszkedik rá. Hivatalosan igazolt, hogy ezt a listát a WP_Rewrite osztály építi fel, és a wp_options táblában, a rewrite_rules kulcs alatt tárolódik szerializált tömbként.

Egy sor a listában két részből áll, egy mintából és egy lekérdezésből. A minta illeszkedik az URL útvonal-részére, a lekérdezés pedig megmondja a WordPress-nek, mit keressen az adatbázisban. Így néz ki egy tipikus pár.

(.?.+?)/page/?([0-9]{1,})/?$ párja index.php?pagename=$matches[1]&paged=$matches[2]

A lényeg a sorrend. A lista tetején az úgynevezett top rules állnak, alul a bottom rules, és a feldolgozás az elsőtől halad lefelé. Amint egy minta illeszkedik, a WordPress megáll, lefuttatja a hozzá tartozó lekérdezést, és ami utána jönne, azt meg sem nézi. Az oldalak (page) gyűjtőszabálya, a (.?.+?)/?$, a lista legvégén ül, mert bármire illeszkedik. Ez a részlet magyarázza a 404-esek nagy részét.

Miért viszi el egy webshop vagy foglalási bővítmény a meglévő útvonalaidat?

Mert saját tartalomtípust regisztrál, és ahhoz saját előtagot kér, az új szabály pedig a lista elejére kerül, jóval az oldalak gyűjtőszabálya elé. Az oldalad megvan az adatbázisban, csak soha nem kerül rá a sor.

A bővítmény aktiváláskor vagy az init hookon lefuttat valami ilyesmit.

register_post_type('foglalas', array('public' => true, 'has_archive' => true, 'rewrite' => array('slug' => 'szolgaltatasok')));

Ettől a pillanattól kezdve a /szolgaltatasok/ kezdetű útvonalakra a foglalási tartalomtípus szabálya illeszkedik elsőként. Ha neked eddig volt egy Szolgáltatások nevű oldalad, és alatta hat aloldalad, a hat aloldal egyszerre lesz 404-es, mert a foglalási bővítmény szabálya azt mondja a WordPress-nek, hogy keressen egy foglalás típusú bejegyzést ilyen névvel, és olyan nincs.

Ugyanez történik a taxonómiák alapjával is. A WooCommerce termékkategória-alapja gyárilag product-category, magyar telepítéseknél sokan termek vagy kategoria értékre állítják, és ha közben egy másik bővítmény is regisztrál egy termek nevű archívumot, a kettő versenyezni kezd. Hivatalosan igazolt, hogy a WooCommerce ezeket az alapokat a permalink-beállítások képernyőjén engedi felülírni, tehát kódmódosítás nélkül is rendezhető.

Mit jelent a szabályok újragenerálása, és mikor elég a permalink mentése?

Az újragenerálás annyit tesz, hogy a WordPress eldobja a tárolt szabálylistát, és az összes aktív bővítmény és téma regisztrációi alapján újraépíti. Ezt hívja a kód flush_rewrite_rules() néven, és pontosan ez fut le akkor is, amikor a Beállítások, Közvetlen hivatkozások képernyőn megnyomod a Módosítások mentése gombot.

Kétféle újragenerálás van. A soft flush csak az adatbázisban lévő listát írja újra. A hard flush emellett a .htaccess fájlt is újraírja, ami Apache alatt számít, nginx alatt viszont nincs jelentősége, mert ott a szabályokat a szerver konfigurációja tartalmazza. Hivatalosan igazolt, hogy a WordPress fejlesztői dokumentációja költséges műveletnek nevezi a flush-t, és kifejezetten arra kéri a bővítmények íróit, hogy ne minden oldalbetöltésnél hívják meg, hanem csak aktiváláskor.

Saját tapasztalat, hogy a fórumokon örökzöld „mentsd el a permalinkot" tanács azért gyógyít meg annyi esetet, mert a bővítmény frissítéskor új szabályt regisztrált, de az aktiválási hook nem futott le újra, így a tárolt lista elavult maradt. Ilyenkor a mentés tényleg elég.

Amit viszont fontos látni, hogy az újragenerálás nem döntőbíró. Ha két bővítmény ugyanazt az előtagot kéri, a flush után is ugyanaz a kettő fog versenyezni, csak frissen. A flush az elavult listát javítja, az ütközést nem.

Azt, hogy a mentés változtatott-e bármin, egy sorszámlálással is eldöntheted. Futtasd le a wp rewrite list --format=csv | wc -l parancsot a mentés előtt és után. Ha a két szám megegyezik, és a problémás URL ugyanúgy 404-et ad, akkor a lista nem volt elavult, vagyis ütközést keresel, és a következő szakasz lépéseire van szükséged.

Hogyan derítsd ki, melyik szabály viszi el az URL-t?

Az alábbi sor staging környezetben fut le tisztán, éles oldalon csak az első három lépést javaslom. Mindegyikhez WP-CLI kell.

1. Mentsd el a jelenlegi állapotot, mielőtt bármihez hozzányúlsz. wp option get rewrite_rules --format=json > elotte.json
2. Kérdezd meg, melyik szabály fogja meg a problémás címet. wp rewrite list --match=/szolgaltatasok/karpittisztitas/ --format=table --fields=match,query,source A source oszlop megmondja, melyik forrásból (page, post-type-archive, category, egyedi) származik a szabály.
3. Keress ütköző előtagokat a teljes listában. wp rewrite list --format=csv --fields=match,source | grep szolgaltatas Ha ugyanarra az előtagra két különböző source is megjelenik, megvan az ütközés.
4. Nézd meg, mely tartalomtípusok milyen előtagot kérnek. wp post-type list --fields=name,public,has_archive majd a gyanús típusra wp eval 'print_r(get_post_type_object("foglalas")->rewrite);'
5. Mentsd el a permalink-beállítást parancssorból, és nézd meg, változik-e a helyzet. wp rewrite flush --hard
6. Kapcsold ki a gyanús bővítményt, generálj újra, és hasonlítsd össze a két listát. wp plugin deactivate foglalo-bovitmeny && wp rewrite flush && wp option get rewrite_rules --format=json > utana.json majd diff <(jq -S . elotte.json) <(jq -S . utana.json)
7. Ellenőrizd a választ HTTP-szinten, ne csak böngészőből, mert a böngésző gyorsítótára félrevezet. curl -sI https://pelda.hu/szolgaltatasok/karpittisztitas/ | head -n 1

A hatodik lépés diffje a legbeszédesebb. Ha a bővítmény kikapcsolása után visszakerül a listába az a húsz sor, ami a te oldalaidhoz tartozik, akkor bizonyítottad az ütközést, nem csak feltételezed. Utána kapcsold vissza a bővítményt, és a megoldást az előtag szintjén keresd.

Mit nézz meg, ha hirtelen megszaporodnak a 404-es hibák?

A hirtelen jelző a legfontosabb nyom. Ami egyszerre, sok URL-en romlik el, az szinte sosem tartalmi hiba, hanem szabály- vagy konfigurációs változás. Ez az ellenőrzőlista a leggyorsabb sorrendben halad.

• Időbeli egybeesés. Nézd meg a bővítmény- és téma-frissítések naplóját, és keresd, melyik történt a 404-hullám kezdete előtt.
• Mintázat a hibás URL-ekben. Ha mindegyik ugyanazzal az előtaggal kezdődik, előtag-ütközés. Ha szétszórtak, inkább a permalink-szerkezet változott.
• A permalink-szerkezet maga. wp option get permalink_structure Ha valaki dátumosra váltott, több ezer URL esik ki egyszerre.
• A szabálylista mérete és épsége. Ha a rewrite_rules opció üres, a WordPress minden kérésre a gyűjtőszabályt használja, és a 404-esek általánosak lesznek.
• A .htaccess fájl írhatósága Apache alatt. Ha nem írható, a hard flush némán elbukik, és a szabályok a szerverig el sem jutnak.
• Objektum-gyorsítótár és oldal-gyorsítótár. Redis vagy Memcached mögött a régi szabálylista bent ragadhat, ezért flush után ürítsd a gyorsítótárat is.
• Átirányítás-kezelő bővítmény. Két ilyen egymás mellett hurkot vagy felesleges 404-et gyárthat.
• Többnyelvű réteg. A nyelvi előtag és a tartalomtípus előtagja együtt új ütközési felületet nyit.
• Search Console lefedettségi jelentés. Megmutatja, mely URL-eket látta a Google korábban jónak, és mikortól kapott hibát.
• Szerver hozzáférési napló. A 404-es sorok időbélyege pontosabb kezdőpontot ad, mint bármelyik felület.

Tényleg hiba ez, vagy csak két bővítmény ugyanarra az előtagra pályázik?

Saját tapasztalat, hogy az ilyen ügyek túlnyomó részében egyik bővítmény sem hibás. Mindkettő pontosan azt csinálja, amit a dokumentációja ígér, csak ugyanaz a szó kellett nekik. A magyar nyelvű telepítéseken a szűkös készlet a probléma, mert a szolgaltatas, termek, foglalas, esemeny, program, blog és kosar előtagokra rengeteg bővítmény pályázik.

Ebből az következik, hogy a hibajegy helyett névtér-osztásra van szükség. A legtöbb komoly bővítmény ad felületi beállítást az előtagjához. Ahol nincs ilyen, ott szűrővel is átírható, és a módosítást egy saját kis bővítménybe vagy a gyerektéma functions.php fájljába érdemes tenni.

add_filter('register_post_type_args', function($args, $type) { if ($type === 'foglalas') { $args['rewrite']['slug'] = 'idopontfoglalas'; } return $args; }, 10, 2);

A szűrő után kötelező egy újragenerálás, különben a régi lista marad. Ami viszont ennél is fontosabb, az a már indexelt címek sorsa. Ha a bővítmény URL-jei hónapok óta élnek, és a keresőben szerepelnek, az előtag megváltoztatása egy új 404-hullámot indít, csak a másik oldalon. Ilyenkor a régi előtagról 301-es állandó átirányítás kell az újra, és a belső linkeket is át kell írni.

Az átirányítás formája attól függ, mi marad a régi előtag alatt. Ha az előtag teljesen kiürül, egyetlen mintaszabály elég. Apache alatt ez a .htaccess fájlba kerül RedirectMatch 301 ^/regi-elotag/(.*)$ /uj-elotag/$1 formában, nginx alatt a szerver konfigurációjába rewrite ^/regi-elotag/(.*)$ /uj-elotag/$1 permanent; alakban.

Ha viszont a régi előtag alatt a saját oldalaid tovább élnek, mint a fenti példában a Szolgáltatások aloldalai, a mintaszabály azokat is elvinné. Ilyenkor listázd ki a bővítmény bejegyzéseit a wp post list --post_type=foglalas --fields=ID,post_name paranccsal, és csak ezekre a címekre vegyél fel egyenkénti átirányítást. A végén ellenőrizd, hová mutat a régi cím. curl -sI https://pelda.hu/regi-elotag/pelda-bejegyzes/ | grep -i location

Mit jelent egy eltűnt URL a keresőnek és az AI-válaszmotoroknak?

Hivatalosan igazolt, hogy a Google a tartósan 404-et adó címeket kiveszi az indexből, és hogy a 301-es átirányítást tekinti az állandó költözés jelzésének. Ez önmagában ismert, a helyreállítás pedig idővel jó eséllyel megtörténik, bár sem a sebességre, sem a korábbi pozíciók visszaszerzésére nincs garancia.

Az AI-válaszmotorok felől nézve a kockázat más súlyú. Szakmai feltételezés, hogy a nyelvi modellekre épülő válaszrendszerek ritkábban és rendszertelenebbül járják újra a forrásaikat, mint a klasszikus keresőrobotok, mert a válaszaikat részben indexelt pillanatképekből és részben élő lekérésből állítják össze. Ha egy ilyen rendszer egyszer megtanulta, hogy egy adott URL-en van a válasz, és az az URL 404-et kezd adni, az idézés megszakad, a hivatkozás pedig a felhasználó szemében is hibásnak látszik. Ezért éri meg egy átirányítási térképet vezetni minden slug-változásról, és ezért nem érdemes az URL-eket kozmetikai okból mozgatni.

Hogyan előzd meg a következő ütközést?

• Új webshop- vagy foglalási bővítményt először staging környezetben aktiválj, és aktiválás után azonnal futtasd le a rewrite list parancsot.
• Tartsd verziókövetésben vagy legalább havi mentésben a rewrite_rules opció JSON-exportját, mert így a diff bármikor rendelkezésre áll.
• Vezess egy rövid slug-térképet arról, melyik előtag melyik bővítményhez tartozik, és ezt nézd meg minden új telepítés előtt.
• Állíts be 404-figyelést a belső oldalakra. Az uptime-monitor általában a főoldalt nézi, az viszont ilyenkor tökéletesen működik, tehát riasztás sem lesz.
• Bővítmény-frissítés után ellenőrizd a három legfontosabb sablonoldalt curl-lel, ne szemre.

Az egész ügy attól lesz kezelhető, hogy a szabálylistát adatnak tekinted, amit ki lehet íratni, el lehet menteni és össze lehet hasonlítani. Amíg a WordPress útvonal-feloldása fekete doboz marad, minden ilyen eset órákat visz el. Amint kiíratod, tizenöt perc.

Milyen URL-eket hoz létre egy WordPress foglalási rendszer?

Egy WordPress foglalási rendszer jellemzően háromféle útvonalat hoz létre. Az első a saját tartalomtípusok archívuma és egyedi oldalai (szolgáltatás, munkatárs, helyszín, esemény), a második ezek taxonómiái, a harmadik a foglalási folyamat végpontjai. Ütközést az első kettő okoz, mert ezek szabályai kerülnek a lista elejére.

Az, hogy egy adott bővítmény melyiket használja, a felépítésétől függ. Saját tapasztalat, hogy a gyakorlatban négy típussal találkozol.

• Rövidkóddal vagy blokkal beágyazott foglaló. A naptár egy általad létrehozott oldalon jelenik meg, a bővítmény saját átírási szabályt nem regisztrál. Útvonal-ütközés szempontjából ez a legkisebb kockázat.
• Egyedi tartalomtípusra épülő rendszer. A szolgáltatások, munkatársak vagy események külön bejegyzéstípusként élnek, saját előtaggal és gyakran archívummal. Itt keletkezik a cikk elején leírt helyzet.
• WooCommerce-re épülő foglalás. A foglalható szolgáltatás termékként él, ezért a címe a termék-alap alá kerül, és a WooCommerce permalink-beállításai határozzák meg.
• Végpontokat használó rendszer. Az add_rewrite_endpoint() függvénnyel a meglévő címek végére fűz egy szakaszt, például az ügyfélfiók alá a saját foglalások listáját. Ez ritkán ütközik oldallal, újragenerálás nélkül viszont maga a végpont ad 404-et.

A magyarított telepítéseken a gond többnyire akkor jelentkezik, amikor valaki a beállításokban az angol alapértelmezett előtagot magyarra írja át, és éppen azt a szót választja, amelyik már oldalként él a webhelyen. Hogy a te telepítéseden mit regisztrált a bővítmény, azt egy szűrt lista megmutatja. wp rewrite list --format=csv --fields=match,source | grep -iE 'foglal|booking|service|appointment|event'

Hogyan válassz WordPress foglalási rendszert úgy, hogy ne üssön ki meglévő oldalakat?

Olyan WordPress foglalási rendszert válassz, amelynek az URL-előtagja felületről átírható, és amelyet aktiválás előtt staging környezetben össze tudsz vetni a meglévő oldalaid slugjaival. A funkciólista mellett ez a két szempont mutatja meg előre, lesz-e 404-hullám a bevezetés napján.

Az alábbi sorrend staging környezetre készült, éles oldalon csak az első lépést futtasd.

1. Listázd ki a legfelső szintű oldalaid slugjait, mert ezek a foglalt előtagjaid. wp post list --post_type=page --post_parent=0 --fields=ID,post_name,post_title
2. Nézd meg a bővítmény dokumentációjában, milyen tartalomtípusokat és taxonómiákat regisztrál, és milyen alapértelmezett előtaggal. Ha a dokumentáció erről hallgat, a következő lépés úgyis megmutatja.
3. Mentsd el a szabálylistát, aktiváld a bővítményt, mentsd el újra, és hasonlítsd össze a kettőt ugyanazzal a diff paranccsal, amit a diagnózisnál láttál. Az új sorok előtagjait vesd össze az első lépés listájával.
4. Ellenőrizd, hogy az előtag a beállítások között átírható-e. Ha csak szűrővel módosítható, azt a kódot a bővítmény minden nagyobb frissítése után neked kell újra ellenőrizned.
5. Kapcsold ki, amire nincs szükséged. Több bővítmény engedi, hogy a tartalomtípus archívumát vagy a nyilvános egyedi oldalait letiltsd. Ha a foglalás rövidkóddal megy egy saját oldalon, ezekre az útvonalakra nincs szükség.
6. Próbáld ki a kikapcsolást is. Deaktiválás és újragenerálás után a bővítmény sorainak el kell tűnniük a listából, a saját oldalaidnak pedig 200-as választ kell adniuk.
7. Zárd a kört HTTP-szintű ellenőrzéssel a legfontosabb oldalakon, a foglaló oldalt is beleértve.

Szakmai feltételezés, hogy hosszabb távon az jár jobban, aki a keresőből látogatott szolgáltatás-oldalait hagyományos WordPress oldalként tartja, és a foglalót csak beágyazza rájuk. Így ha később foglalási rendszert cserélsz, a naptár változik, az URL-ek viszont a helyükön maradnak, és sem átirányítási térképre, sem újraindexelésre nem lesz szükség.

Források és további olvasnivalók

• WordPress Developer Resources, Rewrite API és a flush_rewrite_rules() függvény referenciája
• WordPress Developer Resources, WP_Rewrite osztály és a register_post_type() paraméterei
• WordPress Support, Using Permalinks
• WP-CLI Command Reference, wp rewrite és wp option
• WooCommerce Developer Documentation, termék- és kategória-permalink beállítások
• Google Search Central, Crawling and indexing dokumentáció, ezen belül a 404-es és soft 404-es hibák kezelése, valamint az oldalköltöztetés URL-változással
• MDN Web Docs, HTTP válaszkódok (301, 404, 410)
• W3C, Architecture of the World Wide Web, Volume One (URI-tartósság)
• Schema.org, WebPage és BreadcrumbList típusok