WordPress .htaccess fájl visszaállítása alapállapotba

A .htaccess fájlba a WordPress, a bővítmények és a tárhely kezelőfelülete is írnak. Ha egy bővítmény hibás sort hagy benne, vagy kézi szerkesztés közben elírás kerül bele, a webhely 500-as hibát ad, vagy az aloldalak 404-es hibára futnak. Ilyenkor a leggyorsabb megoldás a fájl alapállapotba állítása, mert így néhány perc alatt kiderül, tényleg ez okozza-e a hibát.

A lépéseket 2026 októberében egy aWh cPanel tárhely tesztfiókon próbáltuk ki, WordPress 7.1-gyel. Egyetlen hibás sor a fájlban a teljes webhelyet 500-as hibára állította.

Mikor segít?

500 Internal Server Error egy bővítmény telepítése, törlése vagy a fájl kézi szerkesztése után.
A kezdőlap működik, de az aloldalak 404-es hibát adnak.
Átirányítási hurok („túl sok átirányítás”), amelyet egy bővítmény vagy egy kézi szabály okoz.

Ha a hibát egy frissítés okozta, előbb nézze meg az 500-as hiba bővítményfrissítés után cikket, mert a hiba oka ilyenkor többnyire nem a .htaccess.

Mit veszít, ha alapállapotba állítja?

A fájlban nem csak a WordPress szabályai vannak. Egy cPanel tárhelyen ilyen részeket találhat:

# BEGIN cPanel-generated php ini directives: a cPanel írja, többek között a PHP hibanapló helyét állítja be. Nélküle a tesztünkben a hibanapló ~/logs/php.error.log helyett a futó PHP-fájl mappájában lévő error_log fájlba került. A PHP-verzió nem változott: azt a Select PHP Version felület kezeli.
RewriteCond / RewriteRule sorok a WordPress-blokkon kívül: például a cPanel Átirányítások oldalán felvett átirányítások.
Bővítmények blokkjai: gyorsítótárazó és biztonsági bővítmények szabályai, általában a saját # BEGIN jelölésükkel. Vigyázzon a # Wordfence WAF blokkal: nélküle a webhely működik, de a Wordfence tűzfala tesztünkben észrevétlenül leállt.
Saját szabályok: például a robotok tiltásához vagy IP-címek kitiltásához felvett sorok.

Ezért a régi fájlt ne törölje, hanem nevezze át: a hasznos részeit később visszamásolhatja.

1. Nevezze át a régi fájlt

Nyissa meg a cPanel Fájlkezelő oldalát, és lépjen a WordPress gyökérkönyvtárába. Ez a fő domainnél a public_html, a többi domainnél a Tartományok oldalon látható Dokumentumgyökér (Mi a weboldalam gyökérkönyvtára?).
Ha nem látja a .htaccess fájlt, kapcsolja be a rejtett fájlok megjelenítését.
Jelölje ki a fájlt, kattintson az Átnevezés gombra, és adjon neki dátumos nevet, például .htaccess-2026-10-30.bak.

SSH-val ugyanez:

cd ~/public_html
mv .htaccess .htaccess-$(date +%F).bak

Webtárhelyen a Fájlkezelő menüponttal vagy FTP-n át végezheti el ugyanezt.

Ezután nyissa meg a webhelyet. Ha a kezdőlap és az admin felület betölt, a hiba a régi fájlban volt. Az aloldalak ilyenkor még 404-es hibát adhatnak, amíg létre nem hozza az új fájlt.

2. Hozzon létre új fájlt

A legegyszerűbb módszer az admin felület: lépjen a Beállítások › Közvetlen hivatkozások oldalra, és változtatás nélkül kattintson a Módosítások mentése gombra. A WordPress ekkor létrehozza a .htaccess fájlt a saját blokkjával. Ez csak akkor történik meg, ha nem az Egyszerű szerkezetet használja, annál nincs szükség a fájlra.

Kézzel is létrehozhatja, ha az admin felület nem érhető el. A Fájlkezelőben a Fájl gombbal hozzon létre egy pontosan .htaccess nevű fájlt, nyissa meg a Szerkesztés gombbal, és illessze be a WordPress alapértelmezett tartalmát:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ha a WordPress egy alkönyvtárban van (például pelda.hu/blog), a RewriteBase / sorba RewriteBase /blog/, az utolsó RewriteRule sorba pedig /blog/index.php kerüljön.

WP-CLI-vel az admin felület nélkül is újragenerálható, de a wp rewrite flush --hard parancs magában csak ezt a figyelmeztetést adja: Regenerating a .htaccess file requires special configuration, és nem hozza létre a fájlt. Ehhez ideiglenesen egy wp-cli.yml fájl kell a WordPress mappájába:

printf 'apache_modules:\n  - mod_rewrite\n' > wp-cli.yml
wp rewrite flush --hard
rm wp-cli.yml

A szerkezet WP-CLI-s módosításánál a wp rewrite structure parancs a proc_open tiltása miatt hibával zárul az aWh cPanel szerverein, a beállítást viszont elmenti; a hibáról a WP-CLI használatáról szóló cikk ír.

3. Ellenőrizze a webhelyet

Nyissa meg a kezdőlapot, egy bejegyzést, egy oldalt és az admin felületet. Ha a hiba megszűnt, jöhet a szabályok visszaállítása. Ha nem, a régi fájl nem volt ludas: nevezze vissza, és keressen tovább (lásd a cikk végét).

4. Tegye vissza a szükséges szabályokat

Nyissa meg a .bak fájlt, és csak azt másolja vissza, amire szüksége van, egyszerre egy részt, és minden lépés után töltse újra a webhelyet. A blokkokat a # BEGIN WordPress sor elé tegye, mert a WordPress a saját blokkját felülírhatja.

A cPanel PHP-blokkja: másolja vissza a # BEGIN cPanel-generated php ini directives és az # END cPanel-generated php ini directives közötti részt, a két jelölősorral együtt.
Az átirányítások: másolja vissza a sorokat, vagy vegye fel őket újra az Átirányítások oldalon.
A saját szabályok: ha egy sor után visszatér a hiba, az a hibás sor.
A bővítmények szabályai: ezeket ne másolja vissza kézzel. Kapcsolja ki, majd vissza az érintett bővítményt, vagy mentse el újra a beállításait, így a saját blokkját frissen megírja. Ha a hiba egy bővítmény bekapcsolása után tér vissza, az a bővítmény okozza. A Wordfence tűzfalához a varázslót kell újra lefuttatni.

Végül a .bak fájlt törölje, vagy töltse le magának, mert nem kell a webről elérhető mappában maradnia.

A régi fájl visszaállítása

Ha mégis a régi fájlra van szükség, nevezze át az újat (például .htaccess-uj.bak névre), a dátumos fájlt pedig vissza .htaccess névre.

Ha a visszaállítás nem segített

Nézze meg a hibanaplót: a cPanel Mutató csoportjában a Hibák oldalt vagy a ~/logs/php.error.log fájlt.
Olvassa el az 500-as hibáról, a fehér képernyőről és a PHP memóriakorlátról szóló cikkeket.
Kapcsolja be a hibakeresési módot.

A fájl általános szerkesztési szabályait a .htaccess fájlról szóló cikk, az átirányítási mintákat a .htaccess átirányításról szóló blogcikkünk mutatja be.