V datoteko .htaccess pišejo WordPress, vtičniki in upraviteljski vmesnik gostovanja. Če vtičnik v njej pusti napačno vrstico ali med ročnim urejanjem vanjo pride tipkarska napaka, spletno mesto vrne napako 500 ali podstrani vrnejo napako 404. Takrat je najhitrejša rešitev ponastavitev datoteke na privzeto stanje, ker se tako v nekaj minutah pokaže, ali napako res povzroča ta.

Korake smo oktobra 2026 preizkusili na testnem računu gostovanja cPanel aWh, z WordPress 7.1. Ena sama napačna vrstica v datoteki je celotno spletno mesto postavila na napako 500.

Kdaj pomaga?

• 500 Internal Server Error po namestitvi ali izbrisu vtičnika ali po ročnem urejanju datoteke.
• Začetna stran deluje, podstrani pa vrnejo napako 404.
• Zanka preusmeritev („preveč preusmeritev”), ki jo povzroči vtičnik ali ročno pravilo.

Če je napako povzročila posodobitev, najprej poglej članek Napaka 500 po posodobitvi vtičnika, ker vzrok napake takrat večinoma ni .htaccess.

Kaj izgubiš, če jo ponastaviš?

V datoteki niso le pravila WordPressa. Na gostovanju cPanel lahko najdeš take dele:

• # BEGIN cPanel-generated php ini directives: piše ga cPanel, med drugim nastavi mesto dnevnika napak PHP. Brez njega je v našem preizkusu dnevnik napak namesto v ~/logs/php.error.log prišel v datoteko error_log v mapi tekoče datoteke PHP. Različica PHP se ni spremenila: to upravlja vmesnik Select PHP Version.
• Vrstice RewriteCond / RewriteRule zunaj bloka WordPress: na primer preusmeritve, dodane na strani Preusmeritve v cPanelu.
• Bloki vtičnikov: pravila vtičnikov za predpomnjenje in varnost, običajno z lastno oznako # BEGIN. Pazi na blok # Wordfence WAF: brez njega spletno mesto deluje, požarni zid Wordfence pa se je v našem preizkusu neopazno ustavil.
• Lastna pravila: na primer vrstice, dodane za blokiranje robotov ali blokiranje naslovov IP.

Zato stare datoteke ne briši, temveč jo preimenuj: njene uporabne dele lahko pozneje prekopiraš nazaj.

1. Preimenuj staro datoteko

1. Odpri stran Upravitelj datotek v cPanelu in pojdi v korenski imenik WordPress. Pri glavni domeni je to public_html, pri drugih domenah pa Korenski imenik dokumentov, viden na strani Domene (Kateri je korenski imenik moje spletne strani?).
2. Če datoteke .htaccess ne vidiš, vklopi prikaz skritih datotek.
3. Označi datoteko, klikni gumb Preimenuj in ji daj ime z datumom, na primer .htaccess-2026-10-30.bak.

S SSH isto:

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

Na spletnem gostovanju to opraviš s točko menija Upravitelj datotek ali prek FTP.

Nato odpri spletno mesto. Če se začetna stran in skrbniški vmesnik naložita, je bila napaka v stari datoteki. Podstrani lahko takrat še vračajo napako 404, dokler ne ustvariš nove datoteke.

2. Ustvari novo datoteko

Najpreprostejši način je skrbniški vmesnik: pojdi na stran Nastavitve › Trajne povezave in brez sprememb klikni gumb Shrani spremembe. WordPress takrat ustvari datoteko .htaccess s svojim blokom. To se zgodi le, če ne uporabljaš zgradbe Preprosto, pri njej datoteka ni potrebna.

Ročno jo lahko ustvariš tudi, če skrbniški vmesnik ni dosegljiv. V Upravitelju datotek z gumbom Datoteka ustvari datoteko z imenom natanko .htaccess, jo odpri z gumbom Uredi in prilepi privzeto vsebino WordPress:

# 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

Če je WordPress v podimeniku (na primer pelda.hu/blog), naj bo v vrstici RewriteBase / RewriteBase /blog/, v zadnji vrstici RewriteRule pa /blog/index.php.

Z WP-CLI jo je mogoče znova ustvariti tudi brez skrbniškega vmesnika, vendar ukaz wp rewrite flush --hard sam izpiše le opozorilo Regenerating a .htaccess file requires special configuration in datoteke ne ustvari. Za to je v mapi WordPress začasno potrebna datoteka wp-cli.yml:

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

Pri spremembi zgradbe z WP-CLI se ukaz wp rewrite structure na strežnikih cPanel aWh zaradi prepovedi proc_open konča z napako, nastavitev pa shrani; o napaki piše članek o uporabi WP-CLI.

3. Preveri spletno mesto

Odpri začetno stran, prispevek, stran in skrbniški vmesnik. Če je napaka izginila, sledi obnovitev pravil. Če ne, stara datoteka ni bila kriva: preimenuj jo nazaj in išči naprej (glej konec članka).

4. Vrni potrebna pravila

Odpri datoteko .bak in prekopiraj nazaj le tisto, kar potrebuješ, en del naenkrat, in po vsakem koraku znova naloži spletno mesto. Bloke postavi pred vrstico # BEGIN WordPress, ker lahko WordPress svoj blok prepiše.

1. Blok PHP cPanela: prekopiraj nazaj del med # BEGIN cPanel-generated php ini directives in # END cPanel-generated php ini directives, skupaj z obema označevalnima vrsticama.
2. Preusmeritve: prekopiraj vrstice nazaj ali jih znova dodaj na strani Preusmeritve.
3. Lastna pravila: če se po vrstici napaka vrne, je to napačna vrstica.
4. Pravila vtičnikov: teh ne kopiraj nazaj ročno. Prizadeti vtičnik izklopi in znova vklopi ali znova shrani njegove nastavitve, tako svoj blok napiše na novo. Če se napaka vrne po vklopu vtičnika, jo povzroča ta vtičnik. Za požarni zid Wordfence je treba znova zagnati čarovnika.

Na koncu datoteko .bak izbriši ali jo prenesi zase, ker ji ni treba ostati v mapi, dosegljivi s spleta.

Obnovitev stare datoteke

Če vseeno potrebuješ staro datoteko, preimenuj novo (na primer v .htaccess-uj.bak), datoteko z datumom pa nazaj v .htaccess.

Če obnovitev ni pomagala

• Poglej dnevnik napak: stran Napake v skupini Meritve v cPanelu ali datoteko ~/logs/php.error.log.
• Preberi članke o napaki 500, belem zaslonu in omejitvi pomnilnika PHP.
• Vklopi način za odpravljanje napak.

Splošna pravila urejanja datoteke prikazuje članek o datoteki .htaccess, vzorce preusmeritev pa naš blogovski zapis o preusmeritvah v .htaccess.