Nagbabalik ng 404 ang mga Post sa WordPress pero Gumagana ang Homepage

Kung maayos na naglo-load ang iyong homepage pero bawat indibidwal na post at page ay nagbabalik ng 404, nawawala o sira ang mga URL rewrite rule na inaasahan ng WordPress sa iyong .htaccess file. Ang pinakamabilis na ayos: pumunta sa Settings → Permalinks sa wp-admin at i-click ang Save Changes nang hindi binabago ang kahit ano. Pinipilit nito ang WordPress na i-regenerate ang rewrite block. Kung magpumilit pa rin ang mga 404, hindi writable ng web server ang iyong .htaccess, naka-configure ang Apache na huwag pansinin ito, o nasa Nginx ka (na hindi gumagamit ng .htaccess).

Bakit gumagana ang homepage pero hindi ang mga post

Gumagana ang iyong homepage dahil ang request sa / ay direktang inihahatid mula sa index.php sa document root. Walang kailangang rewriting.

Iba naman ang request sa /2026/my-post/. Ang path na iyon ay hindi tunay na folder sa disk. Para masagot ito ng WordPress, kailangang i-route ng Apache ang request papunta sa index.php sa loob, at pagkatapos ay babasahin ng WordPress ang REQUEST_URI, itutugma ito sa mga rewrite rule na naka-store sa opsyong rewrite_rules sa database, ire-resolve ang mga query var (WP::parse_request()), at ilo-load ang tamang post.

Ang pagpasa ng request mula Apache papunta sa index.php ang bahaging nasisira. Nakadepende ito nang buo sa block na ito sa .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

Ang dalawang linyang RewriteCond ay nagsasabi: kung ang hinihinging path ay hindi tunay na file (!-f) at hindi tunay na directory (!-d), ipadala ito sa index.php. Alisin ang block na iyon at hahanapin ng Apache ang literal na /2026/my-post/ na directory, hindi ito mahahanap, at magbabalik ito ng sarili nitong 404 — bago pa man makita ng WordPress ang request.

Bakit ino-overwrite ng WordPress ang .htaccess kapag nag-save ka ng permalinks

Ito ang bahaging madalas laktawan ng ibang gabay. Kapag na-click mo ang Save sa Permalinks screen, tinatawag ng WordPress ang flush_rewrite_rules(). Sa Apache na may writable na .htaccess, ito ang nagti-trigger ng save_mod_rewrite_rules(), na nagre-regenerate ng block sa itaas sa pamamagitan ng WP_Rewrite::mod_rewrite_rules() at isinusulat itong muli gamit ang insert_with_markers().

Ang insert_with_markers() ay ang mga linya lamang sa pagitan ng # BEGIN WordPress at # END WordPress ang hinihipo. Ang lahat ng nasa labas ng mga marker na iyon ay hindi ginagalaw. Ang lahat ng nasa loob ay tinatanggal at isinusulat muli. Sa mga mas bagong bersyon ng WordPress, iniimprenta pa nga ang babala nang direkta sa file:

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

Kaya ang “ino-overwrite ng WordPress ang aking .htaccess” ay totoo pero limitado: ang sariling markadong block lamang nito ang isinusulat muli, at kapag writable lang ang file. Kung hindi writable ang file, ang pag-save ay tahimik na walang ginagawa sa disk. Nagpapakita ang WordPress ng dilaw na notice sa Permalinks screen na nagsasabi sa iyong i-paste ang mga rule nang manu-mano, at kung mapalampas mo ang notice na iyon, mananatiling nawawala ang iyong rewrite block at patuloy na magbabalik ng 404 ang bawat post.

Paano ito ayusin, ayon sa pagkakasunod

1. I-save muli ang iyong permalinks. Settings → Permalinks → Save Changes. Walang kailangang i-edit. Pinapatakbo nitong muli ang flush at isinusulat muli ang block. Nireresolba nito ang karamihan ng kaso, kasama na ang mga lumang rule matapos ang isang migration.

2. Suriin na umiiral at writable ang .htaccess. Nakatira ito sa parehong folder ng wp-config.php. Isa itong dotfile, kaya i-enable ang “show hidden files” sa iyong FTP client o gamitin ang:

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

Kung nawawala ito, gumawa ng isa at i-paste ang tamang block. Kung nasa subdirectory ang iyong install, dapat tumugma ang RewriteBase at ang final rewrite target sa path na iyon — ang pagkakamali dito ang pinakakaraniwang dahilan kung bakit nag-404 pa rin ang isang manu-manong na-paste na block. Ang aming .htaccess generator ay bumubuo ng eksaktong block para sa iyong install path para hindi ka na manghula.

3. Kumpirmahin na pinapayagan ang Apache na basahin ang .htaccess. Kung ang virtual host ay may AllowOverride None, buong-buong hindi pinapansin ng Apache ang file anuman ang laman nito. Kailangan mo ng AllowOverride All (o hindi bababa sa FileInfo) sa WordPress directory. Nasa server config ito, hindi sa .htaccess, kaya kailangan nito ng server access:

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

4. Kumpirmahin na naka-enable ang mod_rewrite. Sa Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Sa Nginx, walang .htaccess. Napupunta ang mga rewrite sa server block sa halip:

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

Mabilis na diagnostic: kaninong 404 ito?

Tingnan ang 404 page. Kung ito ay isang walang-estilong Apache o host error page, hindi kailanman naabot ng Apache ang WordPress — iyon ay problema sa .htaccess o sa server config (mga hakbang 2–4). Kung ito ay ang naka-estilong 404 ng iyong theme, natatanggap ng WordPress ang request pero hindi ito matugma — luma na ang mga rule sa database, at ang muling pag-save ng permalinks (hakbang 1) ang ayos. Ang pagkakaibang ito lamang ang nakakatipid sa karamihan ng tao ng isang oras na paghula.

Ano ang hindi dapat gawin

Huwag munang i-deactivate ang lahat ng iyong plugin. Ang purong sintomas na “nag-404 ang mga post, gumagana ang homepage” ay problema sa rewrite, hindi conflict ng plugin. Ang pag-disable ng mga plugin ang laging unang sagot sa mga forum pero halos hindi ito nakakaapekto rito.

Huwag i-chmod 777 ang iyong .htaccess. Kailangan ng WordPress na writable ang file ng web server user, na hindi pareho sa world-writable. Ang 644 na may tamang owner ay maayos at ligtas; ang 777 ay isang butas sa seguridad na hindi rin naman aayos sa routing.

Huwag mag-paste ng custom rewrite rules sa loob ng mga marker na # BEGIN WordPress / # END WordPress. Buburahin ang mga ito sa susunod na pag-save ng permalinks ng sinuman. Ilagay ang mga custom directive sa ibabaw ng linyang # BEGIN WordPress.

Huwag i-reinstall ang WordPress. Maayos ang mga core file. Ito ay iisang nawawalang block ng teksto, hindi isang sirang install.

Huwag sisihin ang iyong theme. Ang permalink routing ay bahagi ng WordPress core. Hindi ito magagawa ng isang theme at hindi rin ito maaayos ng isang theme.

Naiipit pa rin?

Kung na-save mo na muli ang permalinks, nakumpirma na naroon at writable ang block, at itinakda mo na ang AllowOverride All, ang natitirang pinaghihinalaan ay isang security plugin o isang host-level rule na nagre-regenerate o nagla-lock sa .htaccess nang hindi mo alam. Suriin ang modification timestamp ng file agad matapos ang isang permalink save — kung hindi ito nagbago, may humaharang sa pagsulat. I-regenerate ang isang malinis na block gamit ang .htaccess generator, i-paste ito, at i-test muli gamit ang hard refresh.