Articolele WordPress returnează 404, dar pagina principală funcționează

Dacă pagina principală se încarcă fără probleme, dar fiecare articol și pagină individuală returnează 404, regulile de rescriere a URL-urilor pe care se bazează WordPress lipsesc sau sunt defecte în fișierul tău .htaccess. Cea mai rapidă rezolvare: mergi la Setări → Legături permanente în wp-admin și apasă Salvează modificările fără să schimbi nimic. Asta forțează WordPress să regenereze blocul de rescriere. Dacă erorile 404 persistă, înseamnă că fișierul tău .htaccess nu poate fi scris de serverul web, că Apache este configurat să îl ignore sau că folosești Nginx (care nu utilizează deloc .htaccess).

De ce funcționează pagina principală, dar articolele nu

Pagina ta principală funcționează pentru că o cerere către / este servită direct din index.php din rădăcina site-ului. Nu este nevoie de nicio rescriere.

O cerere către /2026/articolul-meu/ este diferită. Calea aceea nu este un folder real pe disc. Pentru ca WordPress să răspundă la ea, Apache trebuie să direcționeze intern cererea către index.php, iar WordPress citește apoi REQUEST_URI, o compară cu regulile de rescriere stocate în opțiunea rewrite_rules din baza de date, rezolvă variabilele de interogare (WP::parse_request()) și încarcă articolul potrivit.

Predarea cererii de la Apache către index.php este partea care se strică. Ea depinde în întregime de acest bloc din .htaccess:

# 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

Cele două linii RewriteCond spun: dacă calea cerută nu este un fișier real (!-f) și nu este un director real (!-d), trimite-o către index.php. Elimină acest bloc și Apache va căuta un director literal /2026/articolul-meu/, nu îl va găsi și va returna propriul 404 — înainte ca WordPress să vadă vreodată cererea.

De ce WordPress suprascrie .htaccess când salvezi legăturile permanente

Aceasta este partea pe care majoritatea ghidurilor o sar. Când apeși Salvează pe ecranul Legături permanente, WordPress apelează flush_rewrite_rules(). Pe Apache cu un .htaccess care poate fi scris, acest lucru declanșează save_mod_rewrite_rules(), care regenerează blocul de mai sus prin WP_Rewrite::mod_rewrite_rules() și îl rescrie folosind insert_with_markers().

insert_with_markers() atinge doar liniile dintre # BEGIN WordPress și # END WordPress. Tot ce este în afara acestor marcaje rămâne neatins. Tot ce este în interior este eliminat și rescris. Versiunile mai noi de WordPress chiar afișează avertismentul direct în fișier:

Any changes to the directives between these markers will be overwritten.

Așadar, „WordPress îmi suprascrie .htaccess” este adevărat, dar limitat: rescrie doar propriul bloc marcat și doar când fișierul poate fi scris. Dacă fișierul nu poate fi scris, salvarea nu face nimic pe disc, în tăcere. WordPress afișează o notificare galbenă pe ecranul Legături permanente care îți spune să lipești regulile manual, iar dacă ratezi acea notificare, blocul tău de rescriere rămâne lipsă și fiecare articol continuă să returneze 404.

Cum să rezolvi problema, pas cu pas

1. Re-salvează legăturile permanente. Setări → Legături permanente → Salvează modificările. Nu sunt necesare modificări. Asta reia flush-ul și rescrie blocul. Rezolvă majoritatea cazurilor, inclusiv regulile învechite după o migrare.

2. Verifică dacă .htaccess există și poate fi scris. Se află în același folder ca wp-config.php. Este un fișier ascuns (dotfile), așa că activează „afișează fișierele ascunse” în clientul tău FTP sau folosește:

ls -la /path/to/wordpress/.htaccess

Dacă lipsește, creează-l și lipește blocul corect. Dacă instalarea ta se află într-un subdirector, RewriteBase și ținta finală de rescriere trebuie să corespundă acelei căi — greșeala aici este cel mai frecvent motiv pentru care un bloc lipit manual tot returnează 404. Generatorul nostru de .htaccess construiește blocul exact pentru calea instalării tale, ca să nu fie nevoie să ghicești.

3. Confirmă că Apache are voie să citească .htaccess. Dacă virtual host-ul are AllowOverride None, Apache ignoră complet fișierul, indiferent de conținutul lui. Ai nevoie de AllowOverride All (sau cel puțin FileInfo) pe directorul WordPress. Aceasta se află în configurația serverului, nu în .htaccess, deci necesită acces la server:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Confirmă că mod_rewrite este activat. Pe Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Pe Nginx nu există .htaccess. Rescrierile se pun în schimb în blocul server:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Diagnostic rapid: al cui este 404-ul?

Uită-te la pagina de 404. Dacă este o pagină de eroare nestilizată de la Apache sau de la hosting, Apache nu a ajuns niciodată la WordPress — aceea este o problemă de .htaccess sau de configurare a serverului (pașii 2–4). Dacă este pagina de 404 stilizată de tema ta, WordPress primește cererea, dar nu o poate potrivi — regulile din baza de date sunt învechite, iar re-salvarea legăturilor permanente (pasul 1) este rezolvarea. Această singură distincție economisește majorității oamenilor o oră de ghicit.

Ce să nu faci

Nu dezactiva mai întâi toate plugin-urile. Un simptom pur de tipul „articolele dau 404, pagina principală funcționează” este o problemă de rescriere, nu un conflict de plugin-uri. Dezactivarea plugin-urilor este răspunsul reflex de pe forumuri și aproape niciodată nu are legătură cu asta.

Nu da chmod 777 fișierului tău .htaccess. WordPress are nevoie ca fișierul să poată fi scris de utilizatorul serverului web, ceea ce nu este același lucru cu a fi scriibil de toată lumea. 644 cu proprietarul corect este bine și sigur; 777 este o breșă de securitate care oricum nu va repara direcționarea.

Nu lipi reguli de rescriere personalizate în interiorul marcajelor # BEGIN WordPress / # END WordPress. Vor fi șterse data viitoare când cineva salvează legăturile permanente. Pune directivele personalizate deasupra liniei # BEGIN WordPress.

Nu reinstala WordPress. Fișierele de bază sunt în regulă. Este vorba de un singur bloc de text lipsă, nu de o instalare coruptă.

Nu da vina pe tema ta. Direcționarea legăturilor permanente ține de nucleul WordPress. O temă nu o poate cauza și nu o poate repara.

Tot blocat?

Dacă ai re-salvat legăturile permanente, ai confirmat că blocul este prezent și poate fi scris și ai setat AllowOverride All, suspectul rămas este un plugin de securitate sau o regulă la nivel de hosting care regenerează sau blochează .htaccess pe la spatele tău. Verifică marcajul temporal de modificare al fișierului imediat după o salvare a legăturilor permanente — dacă nu s-a schimbat, ceva blochează scrierea. Regenerează un bloc curat cu generatorul de .htaccess, lipește-l și retestează cu o reîmprospătare forțată.