Fișierul .htaccess implicit WordPress: cod și restaurare

Fișierul .htaccess implicit din WordPress este scurtul bloc RewriteEngine pe care software-ul îl scrie în .htaccess-ul din rădăcina site-ului tău, pentru ca permalinkuri precum /2026/10/nume-articol/ să funcționeze în loc să dea 404. Arată așa:

# 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

Aceste reguli provin din codul pe care WordPress îl folosește pentru a genera blocul și corespund ghidului .htaccess al WordPress. WordPress mai scrie trei linii de comentariu imediat după # BEGIN WordPress, care avertizează că modificările dintre marcatori vor fi suprascrise. Ele nu schimbă modul în care funcționează regulile.

Într-o instalare în subfolder, WordPress pune calea subfolderului atât în RewriteBase, cât și în ultima regulă, de exemplu RewriteBase /blog/ și RewriteRule . /blog/index.php [L]. Rețelele multisite folosesc un bloc diferit, iar WordPress nu scrie automat acest fișier pentru ele.

Esențialul

• WordPress generează acest bloc pe Apache și LiteSpeed când are drept de scriere și permalinkurile prietenoase sunt active. Este suficient să deschizi Setări > Permalinkuri.
• Dacă fișierul lipsește sau este corupt, permalinkurile returnează 404, în timp ce pagina principală se încarcă în continuare, pentru că nu are nevoie de regulile de rewrite.
• Pune tot ce adaugi tu sau un plugin deasupra # BEGIN WordPress, niciodată între marcatori. WordPress înlocuiește tot ce se află între ei când actualizează fișierul.

Ce face fiecare linie

RewriteEngine On activează modulul mod_rewrite al Apache pentru acest director; fără el, regulile de mai jos nu fac nimic.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] lasă URL-ul neschimbat (asta înseamnă -) și copiază antetul Authorization al cererii într-o variabilă de server. WordPress citește această variabilă pentru a prelua un nume de utilizator și o parolă trimise în antet, cum ar fi o parolă de aplicație.

RewriteBase / setează prefixul de cale pe care Apache îl folosește pentru URL-urile rescrise. WordPress îl setează în funcție de locul în care se află site-ul, așa că o instalare în subfolder primește RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] este o protecție: dacă cererea este deja index.php, rewrite-ul se oprește și cererea trece neschimbată.

Cele două linii RewriteCond reprezintă logica reală. %{REQUEST_FILENAME} !-f și !-d întreabă „această cerere NU corespunde unui fișier real și NU corespunde unui director real?”. Ambele trebuie să fie adevărate pentru ca regula finală să se declanșeze, așa că o imagine reală, un fișier CSS sau un PDF încărcat sunt servite direct și nu ajung niciodată la rutarea WordPress.

RewriteRule . /index.php [L] este cea care face permalinkurile să funcționeze. Tot ce a trecut de cele două condiții este trimis la index.php, iar WordPress decide ce articol, pagină sau arhivă înseamnă acel URL.

Când WordPress recreează acest fișier, și când nu reușește

WordPress reîmprospătează regulile de rewrite de fiecare dată când se încarcă ecranul Setări > Permalinkuri, așa că e suficient să îl deschizi și nu trebuie să apeși Salvează modificările. Dacă .htaccess lipsește, WordPress îl creează, atâta timp cât folderul are drept de scriere și permalinkurile prietenoase sunt active. Dacă fișierul există și are drept de scriere, WordPress înlocuiește blocul dintre marcatori.

Asta nu rezolvă problema în aceste cazuri:

• Fișierul sau folderul său nu are drept de scriere pentru utilizatorul cu care rulează PHP. Ecranul afișează o eroare care spune că fișierul .htaccess nu are drept de scriere, împreună cu regulile de lipit. Pe unele găzduiri, PHP rulează cu un alt utilizator de sistem decât cel care deține fișierele încărcate prin FTP, așa că permisiuni care par corecte într-un client FTP pot bloca totuși WordPress.
• Folosești nginx. Ghidul nginx al WordPress spune că nginx nu are un fișier de configurare la nivel de director, precum .htaccess, iar WordPress nu poate schimba configurația serverului. Rutarea echivalentă este o directivă try_files în configurația serverului, pe care trebuie să o editeze un administrator.
• AllowOverride este setat pe None pentru directorul site-ului tău în configurația principală Apache. Documentația Apache spune (citat în original): “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Adică fișierele .htaccess sunt complet ignorate, dacă nu le activezi explicit pentru un director. WordPress poate scrie un fișier perfect, iar acesta tot nu are niciun efect. Regulile de rewrite au nevoie de AllowOverride FileInfo (sau All), lucru pe care s-ar putea să trebuiască să îl schimbe hostul tău.
• Permalinkurile tale sunt setate pe Simplu. URL-urile simple nu au nevoie de reguli de rewrite, așa că WordPress nu creează fișierul pentru ele.

Cum îl restaurezi manual

Dacă articolele și paginile dau 404, în timp ce pagina principală funcționează, primul lucru de verificat este un .htaccess lipsă sau stricat. Repară-l în doi pași.

1. Încearcă întâi soluția dintr-un click. Deschide Setări > Permalinkuri în wp-admin și apasă Salvează modificările fără să schimbi nimic. Dacă WordPress poate scrie fișierul, asta îl regenerează. Dacă nu poate, ecranul afișează eroarea și regulile de care ai nevoie.

2. Dacă nu ajută, creează fișierul manual. Conectează-te prin FTP/SFTP sau prin managerul de fișiere al hostului și mergi în folderul rădăcină al site-ului, de obicei cel care conține wp-admin. Verifică dacă .htaccess există. Numele începe cu un punct, așa că unele manageri de fișiere îl ascund implicit; activează „arată fișierele ascunse”.

• Dacă lipsește, creează un fișier nou cu numele exact .htaccess (fără .txt, nimic înainte de punct).
• Lipește regulile afișate de WordPress sau blocul implicit de la începutul acestui ghid. Într-o instalare în subfolder, ajustează RewriteBase și ultima regulă.
• Salvează și reîncarcă permalinkul unui articol pentru a confirma că funcționează.

Dacă tot dă 404, .htaccess poate fi ignorat. Verifică AllowOverride cu hostul tău, pentru că Apache ignoră un fișier corect când această opțiune este dezactivată.

Regulile tale proprii față de blocul WordPress

Un plugin sau o editare manuală poate adăuga reguli proprii, cum ar fi redirecționări, protecție hotlinking sau antete de cache. Ține-le în afara blocului WordPress și deasupra lui, ca să ruleze înaintea regulii lui finale care preia restul cererilor:

# Reguli adăugate de tine sau de un plugin: DEASUPRA marcatorilor WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # exemplu: protecție hotlinking, reguli de cache etc.
</FilesMatch>

# 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

Tot ce este plasat între # BEGIN WordPress și # END WordPress se pierde data următoare când WordPress actualizează fișierul, iar pentru asta e suficientă încărcarea ecranului Permalinkuri. Liniile dinainte și de după marcatori se păstrează. Pentru redirecționări în special, vezi regulile de redirecționare .htaccess WordPress făcute corect, ca să afli unde trebuie plasate și cum eviți buclele.

O eroare 500 Internal Server Error imediat după editarea fișierului indică ceea ce tocmai ai schimbat. Documentația Apache spune că jurnalul de erori va numi probabil o directivă nepermisă sau o eroare de sintaxă. Regulile copiate dintr-un tutorial vechi pot face asta: Order este o comandă invalidă în Apache 2.4, cu excepția cazului în care mod_access_compat este încărcat. Anulează modificarea ca să repornești site-ul, apoi citește jurnalul de erori.

Dincolo de blocul implicit

Blocul implicit se ocupă doar de rutarea permalinkurilor și de antetul Authorization. Pentru a întări accesul la fișiere sensibile, de exemplu blocarea execuției PHP în /uploads sau refuzarea cererilor directe către wp-config.php, vezi regulile de securitate .htaccess WordPress care ajută cu adevărat. Dacă permalinkurile dau 404 din alt motiv, cum ar fi o structură greșită, un strat de cache care servește reguli vechi sau un conflict multisite în subdirector, permalinkurile WordPress care nu funcționează trece prin celelalte cauze.

Întrebări frecvente

Ce este fișierul .htaccess implicit din WordPress? Este blocul RewriteEngine pe care WordPress îl scrie între # BEGIN WordPress și # END WordPress în fișierul .htaccess din rădăcina site-ului. Transmite antetul Authorization către PHP și trimite la index.php orice cerere care nu este un fișier sau un folder real.

Care este codul exact al .htaccess implicit din WordPress? RewriteEngine On, o regulă care transmite antetul Authorization către PHP, RewriteBase /, o regulă de trecere pentru index.php, două condiții care verifică faptul că cererea nu este un fișier sau un folder real și o regulă finală care trimite tot restul la index.php. Blocul complet se află la începutul acestui ghid.

De ce toate articolele mele dau 404, cu excepția paginii principale? Un fișier .htaccess lipsă sau corupt pe Apache produce acest tipar. Serverul găsește pagina principală fără reguli de rewrite. Orice alt permalink are nevoie de aceste reguli pentru a ajunge la index.php, așa că fără ele Apache caută un fișier care nu există și returnează 404.

WordPress recreează .htaccess automat? Da, pe Apache sau LiteSpeed cu mod_rewrite, dacă permalinkurile prietenoase sunt active și WordPress poate scrie acolo. Este suficient să deschizi Setări > Permalinkuri. Un fișier lipsă are nevoie de un folder cu drept de scriere, iar un fișier existent trebuie să aibă drept de scriere. Altfel, ecranul afișează o eroare, împreună cu regulile de lipit manual.

De ce nginx nu are un fișier .htaccess WordPress? nginx nu are un fișier de configurare la nivel de director, precum .htaccess din Apache. Aceeași rutare se scrie ca o regulă try_files în configurația serverului nginx, pe care trebuie să o editeze un administrator, deoarece WordPress nu o poate schimba.

De ce s-a stricat .htaccess după ce am salvat permalinkurile? Verifică dacă o regulă proprie a fost plasată între marcatorii # BEGIN WordPress și # END WordPress. WordPress înlocuiește tot ce se află între ei când actualizează fișierul, așa că regula se pierde. Păstrează regulile proprii deasupra marcatorilor.

Surse

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Codul sursă WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Reconstruiește un .htaccess curat și corect, cu blocul implicit de permalinkuri și regulile de securitate sau redirecționare de care ai cu adevărat nevoie, folosind generatorul gratuit .htaccess pentru WordPress.