Default .htaccess File ng WordPress: Nilalaman at Paano Ibalik

Ang default na .htaccess file ng WordPress ay ang maikling RewriteEngine block na isinusulat ng software sa .htaccess sa root ng site mo, para ma-resolve ang mga permalink tulad ng /2026/10/pangalan-ng-post/ sa halip na mag-404. Ganito ito:

# 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

Ito ang eksaktong block, kinuha mula sa opisyal na gabay ng WordPress sa Apache HTTP Server at sa rewrite logic na naidokumento sa HelpHub page tungkol sa pretty permalinks. Kung ang RewriteBase mo ay hindi / — halimbawa dahil naka-install ang WordPress sa isang subfolder — tutugma ito sa landas na iyon sa halip, at normal din ito, at ginagawa mismo ng WordPress.

Mga pangunahing punto

• Awtomatikong gagawin ng WordPress ang block na ito, sa Apache at LiteSpeed lang, sa tuwing writable ang file at na-save mo ang Settings > Permalinks.
• Kung nawawala o sira ang file, mag-404 ang lahat ng permalink maliban sa homepage, dahil ang homepage lang ang mahahanap kung wala ang rewrite rules.
• Anumang idinagdag mo o ng isang plugin ay dapat nasa itaas ng # BEGIN WordPress, hindi kailanman sa loob ng mga marker — nirerewrite ng WordPress ang lahat sa pagitan sa bawat pag-save ng permalink.

Kailangan mong ibalik ang file gamit ang tunay mong path at ilang extra rule? Ang WordPress .htaccess generator ay bumubuo ng tama diretso sa browser mo.

Ano ang gawa ng bawat linya

Ang RewriteEngine On ay nag-aktibo sa mod_rewrite module ng Apache para sa directory na ito; kung wala ito, wala ng bisa ang lahat ng sumusunod.

Sinasabi ng RewriteBase / sa Apache na ang mga rewritten path ay relative sa root ng site. Isinasaayos ito ng WordPress ayon sa tunay na kinalalagyan ng site — ang install sa subfolder ay tumatanggap ng RewriteBase /blog/, hindi /.

Ang RewriteRule ^index\.php$ - [L] ay isang guard na walang epekto: kung ang request ay index.php na, huminto na ang rewrite at dumaan ang request nang hindi nagbabago.

Ang dalawang linyang RewriteCond ang tunay na lohika. Tinatanong ng %{REQUEST_FILENAME} !-f at !-d na “ang request na ito ba ay HINDI tumutugma sa isang tunay na file, at HINDI tumutugma sa isang tunay na directory?”. Dapat totoo ang dalawa para gumana ang huling rule — kaya ang isang tunay na larawan, CSS file, o na-upload na PDF ay direktang isisilbi at hinding-hindi makakaabot sa routing ng WordPress.

Ang RewriteRule . /index.php [L] ang nagpapagana sa mga permalink: anumang nakaligtas sa dalawang kondisyon sa itaas — ibig sabihin, hindi tunay na file o folder — ay ipinapadala sa index.php, at ang sariling routing ng WordPress (WP_Query, rewrite tags) ang nagdedesisyon kung aling post, pahina, o archive talaga ang ibig sabihin ng URL na iyon.

Kailan ginagawa ulit ng WordPress ang file na ito, at kailan hindi

Sinusubukan ng WordPress na isulat ang .htaccess mismo sa bawat pagbubukas mo ng Settings > Permalinks at pag-click sa Save Changes, kahit walang nagbago sa screen. Ang pag-save na ito ay nag-trigger ng flush_rewrite_rules(), na sumusubok na buksan ang .htaccess para isulat at ilagay ang kasalukuyang block sa pagitan ng mga marker.

Tahimik na mabibigo ang pagsubok na ito, iiwan ang file na nawawala o laos, kapag:

• Hindi writable ang file o ang parent folder nito para sa user na pinagpapatakbo ng PHP. Sa maraming shared hosting, tumatakbo ang PHP bilang ibang system user kaysa sa nag-upload ng mga file via FTP, kaya ang mga permission na mukhang tama sa isang FTP client ay puwede pa ring humadlang sa pagsulat ng WordPress.
• Nasa nginx ka. Ang .htaccess ay mekanismo lamang ng Apache at LiteSpeed (ipinaliwanag mismo ng dokumentasyon ng Apache sa AllowOverride kung bakit: walang configuration file ang nginx kada direktoryo na binabasa nito ulit sa bawat request). Ang katumbas sa nginx ay isang try_files directive sa loob ng server block, na puwede lang i-edit ng may access sa server; hindi mabibigyan ng WordPress ang file na ito para sa iyo.
• AllowOverride ay nakatakda sa None para sa directory ng site mo sa pangunahing configuration ng Apache. Ito ang setting na nagpapahintulot sa isang .htaccess na magbago-balewala ng anuman; malinaw ang dokumentasyon ng Apache: sa AllowOverride None, “ganap na binabalewala ang mga .htaccess file” — puwedeng isulat ng WordPress ang perpektong file, at mananatili itong walang epekto hanggang mabago ang setting na ito sa antas ng server.
• Natanggal ang file o hindi talaga umiral, at walang na-trigger na regeneration sa pag-save — ang pinakakaraniwang sanhi ay dati nang pareho ang istruktura ng permalink, kaya walang nakita ang WordPress na pagbabago para isulat ulit.

Paano ito ibalik nang manual

Kung ang mga post at pahina ay 404 habang gumagana pa rin ang homepage, ito ang karaniwang palatandaan ng nawawala o sirang .htaccess. Ayusin ito sa dalawang hakbang.

1. Subukan muna ang one-click fix. Pumunta sa Settings > Permalinks sa WordPress dashboard at i-click ang Save Changes nang hindi binabago ang anuman. Kung writable ang file, ito mismo ay sapat para gawin itong muli at tapos na.

2. Kung hindi ito nag-ayos, gawin ang file nang manual. Kumonekta via FTP/SFTP o ang file manager ng host mo, pumunta sa folder kung saan naka-install ang WordPress (ang may wp-config.php), at tingnan kung umiiral talaga ang .htaccess — isa itong hidden file, itinatago ito ng ilang file manager bilang default; i-on ang “show hidden files.”

• Kung nawawala, gumawa ng bagong file na eksaktong .htaccess ang pangalan (hindi .txt, walang anuman bago ang tuldok).
• I-paste ang default block sa itaas, iayos ang RewriteBase kung nasa subfolder ang WordPress.
• I-save, tapos i-reload ang permalink ng isang post para kumpirmahin na gumagana ito.

Kung patuloy na 404 matapos ito, lumipat ang sanhi mula “nawawala ang .htaccess” patungo sa “binabalewala ang .htaccess” — tanungin ang host mo tungkol sa AllowOverride, dahil ang tamang file sa isang directory na inutusan ang Apache na balewalain ito ay kumikilos nang eksaktong pareho sa walang file.

Sariling mga rule mo laban sa block ng WordPress

Ang isang plugin o manual na pag-edit ay puwedeng magdagdag ng sariling mga rule — redirect, hotlink protection, cache header. Ito ay ibang block, bukod sa ginagawa ng WordPress, at hindi dapat magkapatong ang dalawa:

# Mga rule na idinagdag mo o ng isang plugin — SA ITAAS ng mga marker ng WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # halimbawa: hotlink protection, cache rules, atbp.
</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

Anumang nailagay sa pagitan ng # BEGIN WordPress at # END WordPress ay tahimik na mabubura sa susunod na pag-save ng sinuman sa Permalinks screen, dahil itinuturing ng WordPress ang buong bahaging iyon bilang sarili nito at isusulat ito ulit sa kabuuan. Ito ang pinakakaraniwang sanhi ng “nawala ang custom rule ko” — hindi talaga ito sinadyang tinanggal, nasa loob lang ito ng isang block na itinuturing ng WordPress bilang sarili nito. Para sa mga redirect sa partikular, tingnan ang tamang paggawa ng WordPress .htaccess redirect rules para malaman kung saan dapat ilagay ang mga ito at paano iwasan ang mga loop.

Ito rin ang pinakakaraniwang sanhi ng biglaang 500 Internal Server Error kaagad pagkatapos i-edit ang file: isang rule na kinopya mula sa forum post na isinulat para sa ibang bersyon ng Apache (2.2 na Order/Deny syntax na nahalo sa 2.4 na Require syntax) ay sumisira sa parsing ng buong file, kasama ang block ng WordPress sa ibaba nito, at bumabagsak ang buong site — hindi lang ang bahaging hinawakan mo.

Lagpas sa default block

Ang default block ay humahawak lang ng permalink routing. Kung nais mo rin na higpitan ang access sa mga sensitibong file o magdagdag ng kaunting .htaccess rules na talagang nagpapaliit ng attack surface — pagharang sa PHP execution sa /uploads, pagtanggi sa direktang request sa wp-config.php — tingnan ang WordPress .htaccess security rules na talagang nakakatulong. At kung mag-404 ang permalinks sa ibang dahilan — maling permalink structure, caching layer na nagsisilbi ng lumang mga rule, multisite conflicts sa mga subdirectory — binabalikan ng WordPress permalinks na hindi gumagana ang ibang mga sanhi.

Mga madalas itanong

Ano ang default .htaccess file ng WordPress? Ito ang RewriteEngine block na isinusulat ng WordPress sa pagitan ng # BEGIN WordPress at # END WordPress para ma-resolve ang permalinks tungo sa index.php sa halip na mag-404.

Ano ang eksaktong default .htaccess code ng WordPress? RewriteEngine On, RewriteBase /, isang pass-through rule para sa index.php, dalawang kondisyon na nagsusuri na hindi tunay na file o directory ang request, at isang huling rule na nagpapadala ng lahat ng natitira sa index.php. Nakalagay sa itaas ng gabay na ito ang kumpletong block.

Bakit 404 ang lahat ng post ko maliban sa homepage? Mahahanap ang homepage kahit walang anumang rewrite rule; kailangan ng ibang permalink ang mga ito. Ang nawawala o sirang .htaccess sa Apache ay eksaktong gumagawa ng pattern na ito.

Ginagawa ba uli ng WordPress ang .htaccess nang awtomatiko? Kung writable lang ang file — i-trigger ito ng pag-save ulit ng Settings > Permalinks. Kung hindi writable ang file, nawawala sa isang host na hindi ito awtomatikong ginagawa, o nakapatay ang AllowOverride, hindi ito maaayos ng WordPress para sa iyo at kailangan mong gawin o ayusin ang file nang manual.

Bakit walang .htaccess file ng WordPress ang nginx? Gumagana lang ang .htaccess sa Apache at LiteSpeed. Walang configuration file ang nginx kada directory at ganap na binabalewala ang .htaccess; ang parehong routing ay isinusulat bilang try_files rule sa server block ng nginx.

Bakit nasira ang .htaccess ko matapos ko i-save ang permalinks? Nailagay ang isang custom rule sa loob ng mga marker na # BEGIN WordPress / # END WordPress sa halip na sa itaas nito, at nirerewrite ng WordPress ang buong bahaging iyon sa susunod na pag-save ng permalinks.

---

Buuin ang malinis at tamang .htaccess — default permalink block kasama ang anumang security o redirect rules na talagang kailangan mo — gamit ang libreng WordPress .htaccess generator.