Fișierul .htaccess implicit din WordPress: ce conține și cum îl restaurezi

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ă se rezolve în loc să dea 404. Are următoarea formă:

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

Acesta este blocul exact, reprodus din ghidul oficial WordPress despre Apache HTTP Server și din logica de rewrite documentată pe pagina HelpHub despre permalinkuri prietenoase. Dacă RewriteBase al tău nu este / — de exemplu pentru că WordPress este instalat într-un subfolder — acesta va corespunde în schimb acelui traseu, lucru la fel de normal și generat chiar de WordPress.

Esențialul

• WordPress generează acest bloc automat, doar pe Apache și LiteSpeed, de fiecare dată când fișierul este scriptibil și salvezi Setări > Permalinkuri.
• Dacă fișierul lipsește sau este corupt, toate permalinkurile cu excepția paginii principale returnează 404, pentru că doar pagina principală poate fi găsită fără regulile de rewrite.
• Orice adaugi tu sau un plugin trebuie să fie peste # BEGIN WordPress, niciodată în interiorul marcatorilor — WordPress rescrie tot ce e între ei la fiecare salvare a permalinkurilor.

Ai nevoie să reconstruiești fișierul cu traseul tău real și câteva reguli în plus? Generatorul .htaccess pentru WordPress asamblează unul corect direct în browser.

Ce face fiecare linie

RewriteEngine On activează modulul mod_rewrite al Apache pentru acest director; fără această linie, tot ce urmează este inert.

RewriteBase / îi spune Apache că traseele rescrise sunt relative la rădăcina site-ului. WordPress setează asta în funcție de locul real al instalării — o instalare în subfolder primește RewriteBase /blog/, nu /.

RewriteRule ^index\.php$ - [L] este o gardă fără efect: 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 — astfel o imagine reală, un fișier CSS sau un PDF încărcat sunt servite direct și nu intră niciodată în contact cu rutarea WordPress.

RewriteRule . /index.php [L] este cea care face permalinkurile să funcționeze: tot ce a supraviețuit celor două condiții de mai sus — deci nu este un fișier sau folder real — este trimis la index.php, iar rutarea proprie a WordPress (WP_Query, etichete de rewrite) decide ce articol, pagină sau arhivă înseamnă de fapt acel URL.

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

WordPress încearcă să scrie .htaccess singur de fiecare dată când deschizi Setări > Permalinkuri și apeși Salvează modificările, chiar dacă nu s-a schimbat nimic pe ecran. Acea salvare declanșează flush_rewrite_rules(), care încearcă să deschidă .htaccess pentru scriere și să introducă blocul curent între marcatori.

Această încercare eșuează silențios, lăsând fișierul lipsă sau neactualizat, atunci când:

• Fișierul sau folderul său părinte nu sunt scriptibile pentru utilizatorul cu care rulează PHP. Pe multe găzduiri partajate, PHP rulează cu un utilizator de sistem diferit de cel care a încărcat fișierele prin FTP, așa că permisiuni care par corecte într-un client FTP pot bloca în continuare scrierea WordPress.
• Folosești nginx. .htaccess este un mecanism exclusiv Apache și LiteSpeed (chiar documentația Apache despre AllowOverride explică de ce: nginx nu are un fișier de configurare per director pe care să îl recitească la fiecare cerere). Echivalentul pe nginx este o directivă try_files în blocul server, editabilă doar de cineva cu acces la server; WordPress nu poate scrie niciodată asta pentru tine.
• AllowOverride este setat pe None pentru directorul site-ului tău în configurația principală Apache. Aceasta este setarea care permite unui .htaccess să suprascrie orice; documentația Apache este explicită: cu AllowOverride None, “fișierele .htaccess sunt complet ignorate” — WordPress poate scrie un fișier perfect, iar acesta va rămâne fără efect până când setarea este schimbată la nivel de server.
• Fișierul a fost șters sau nu a existat niciodată, iar ceva din procesul de salvare nu a declanșat o regenerare — cel mai des pentru că permalinkurile aveau deja aceeași structură, așa că WordPress nu a văzut nicio schimbare de rescris.

Cum îl restaurezi manual

Dacă articolele și paginile dau 404 în timp ce pagina principală funcționează în continuare, acesta este semnul tipic al unui .htaccess lipsă sau stricat. Repară-l în doi pași.

1. Încearcă întâi soluția dintr-un click. Du-te la Setări > Permalinkuri în panoul WordPress și apasă Salvează modificările fără să schimbi nimic. Dacă fișierul este scriptibil, asta singură îl regenerează și problema e rezolvată.

2. Dacă nu ajută, creează fișierul manual. Conectează-te prin FTP/SFTP sau managerul de fișiere al hostului, mergi în folderul în care este instalat WordPress (cel care conține wp-config.php) și verifică dacă .htaccess există deloc — este un fișier ascuns, 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 blocul implicit de mai sus, ajustând RewriteBase dacă WordPress este într-un subfolder.
• Salvează și reîncarcă permalinkul unui articol pentru a confirma că funcționează.

Dacă tot dă 404 după asta, cauza s-a schimbat de la “lipsește .htaccess” la “.htaccess este ignorat” — întreabă hostul despre AllowOverride, pentru că un fișier corect într-un director în care Apache are ordin să îl ignore se comportă identic cu absența fișierului.

Regulile tale proprii față de blocul WordPress

Un plugin sau o editare manuală poate adăuga reguli proprii — redirecționări, protecție hotlinking, headere de cache. Acesta este un bloc distinct și separat de cel generat de WordPress, iar cele două nu ar trebui niciodată să se suprapună:

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
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 este șters silențios la următoarea salvare a ecranului de Permalinkuri, pentru că WordPress tratează întreg acel segment ca fiind al său și îl rescrie integral. Aceasta este cea mai comună cauză pentru “regula mea personalizată a dispărut” — nu a fost eliminată intenționat niciodată, ci se afla într-un bloc pe care WordPress îl consideră al lui. Pentru redirecționări în special, vezi regulile de redirecționare .htaccess WordPress făcute corect pentru a afla unde trebuie plasate și cum eviți buclele.

Este și cea mai comună cauză a unei erori 500 Internal Server Error brusce imediat după editarea fișierului: o regulă copiată de pe un forum scrisă pentru o altă versiune de Apache (sintaxa Order/Deny din 2.2 mixată cu sintaxa Require din 2.4) rupe analiza întregului fișier, inclusiv blocul WordPress de dedesubt, și site-ul întreg cade — nu doar partea pe care ai modificat-o.

Dincolo de blocul implicit

Blocul implicit se ocupă doar de rutarea permalinkurilor. Dacă vrei și să întărești accesul la fișiere sensibile sau să adaugi acel pumn de reguli .htaccess care reduc cu adevărat suprafața de atac — blocarea execuției PHP în /uploads, refuzarea cererilor directe către wp-config.php — vezi regulile de securitate .htaccess WordPress care ajută cu adevărat. Iar dacă permalinkurile dau 404 dintr-un alt motiv — structură de permalinkuri greșită, un strat de cache care servește reguli vechi, conflicte multisite în subdirectoare — 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 pentru ca permalinkurile să se rezolve spre index.php în loc să dea 404.

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

De ce toate articolele mele dau 404, cu excepția paginii principale? Pagina principală poate fi găsită fără nicio regulă de rewrite; orice alt permalink are nevoie de ele. Un .htaccess lipsă sau corupt pe Apache produce exact acest model.

WordPress recreează .htaccess automat? Doar dacă fișierul este scriptibil — resalvarea Setări > Permalinkuri declanșează asta. Dacă fișierul nu este scriptibil, lipsește pe un host care nu îl generează automat, sau AllowOverride este dezactivat, WordPress nu poate repara asta pentru tine și trebuie să creezi sau să corectezi fișierul manual.

De ce nginx nu are un fișier .htaccess WordPress? .htaccess funcționează doar pe Apache și LiteSpeed. nginx nu are fișier de configurare per director și ignoră complet .htaccess; aceeași rutare se scrie ca o regulă try_files în blocul server din nginx.

De ce s-a stricat .htaccess după ce am salvat permalinkurile? O regulă proprie a fost plasată în interiorul marcatorilor # BEGIN WordPress / # END WordPress în loc de peste ei, iar WordPress a rescris întreg acel segment la următoarea salvare a permalinkurilor.

---

Reconstruiește un .htaccess curat și corect — bloc implicit de permalinkuri plus orice regulă de securitate sau redirecționare de care ai cu adevărat nevoie — cu generatorul gratuit .htaccess pentru WordPress.