Postingan WordPress Menampilkan 404 tapi Homepage Normal

Kalau homepage kamu tampil normal tapi setiap postingan dan halaman menampilkan 404, berarti aturan URL rewrite yang diandalkan WordPress hilang atau rusak di file .htaccess kamu. Cara paling cepat: masuk ke Settings → Permalinks di wp-admin lalu klik Save Changes tanpa mengubah apa pun. Itu memaksa WordPress meregenerasi blok rewrite. Kalau 404-nya masih muncul, kemungkinan .htaccess kamu tidak bisa ditulis oleh web server, Apache dikonfigurasi untuk mengabaikannya, atau kamu memakai Nginx (yang sama sekali tidak menggunakan .htaccess).

Kenapa homepage jalan tapi postingan tidak

Homepage kamu jalan karena request ke / langsung dilayani dari index.php di document root. Tidak butuh rewrite sama sekali.

Request ke /2026/postingan-saya/ beda ceritanya. Path itu bukan folder sungguhan di disk. Supaya WordPress bisa menjawabnya, Apache harus merutekan request itu secara internal ke index.php, lalu WordPress membaca REQUEST_URI, mencocokkannya dengan aturan rewrite yang tersimpan di opsi rewrite_rules di database, menyelesaikan query vars (WP::parse_request()), dan memuat postingan yang benar.

Serah terima dari Apache ke index.php inilah bagian yang rusak. Ini sepenuhnya bergantung pada blok berikut di .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

Dua baris RewriteCond itu artinya: kalau path yang diminta bukan file sungguhan (!-f) dan bukan direktori sungguhan (!-d), arahkan ke index.php. Hapus blok itu dan Apache akan mencari direktori literal /2026/postingan-saya/, tidak menemukannya, lalu mengembalikan 404 versinya sendiri — sebelum WordPress sempat melihat request-nya.

Kenapa WordPress menimpa .htaccess saat kamu menyimpan permalink

Bagian ini yang biasanya dilewati kebanyakan panduan. Saat kamu klik Save di layar Permalinks, WordPress memanggil flush_rewrite_rules(). Di Apache dengan .htaccess yang bisa ditulis, itu memicu save_mod_rewrite_rules(), yang meregenerasi blok di atas lewat WP_Rewrite::mod_rewrite_rules() dan menuliskannya kembali menggunakan insert_with_markers().

insert_with_markers() hanya menyentuh baris di antara # BEGIN WordPress dan # END WordPress. Semua yang di luar penanda itu dibiarkan apa adanya. Semua yang di dalamnya dibuang dan ditulis ulang. Versi WordPress yang lebih baru bahkan mencetak peringatan langsung di dalam file:

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

Jadi anggapan “WordPress menimpa .htaccess saya” itu benar tapi sempit: ia hanya menulis ulang blok bertandanya sendiri, dan hanya kalau file-nya bisa ditulis. Kalau file-nya tidak bisa ditulis, proses save diam-diam tidak melakukan apa pun ke disk. WordPress menampilkan notifikasi kuning di layar Permalinks yang menyuruh kamu menempelkan aturannya secara manual, dan kalau kamu melewatkan notifikasi itu, blok rewrite kamu tetap hilang dan setiap postingan terus menampilkan 404.

Cara memperbaikinya, secara berurutan

1. Simpan ulang permalink kamu. Settings → Permalinks → Save Changes. Tidak perlu diubah apa pun. Ini menjalankan ulang flush dan menulis ulang blok. Cara ini menyelesaikan sebagian besar kasus, termasuk aturan basi setelah migrasi.

2. Cek apakah .htaccess ada dan bisa ditulis. File-nya ada di folder yang sama dengan wp-config.php. Ini file tersembunyi (dotfile), jadi aktifkan “show hidden files” di klien FTP kamu atau pakai:

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

Kalau hilang, buat file-nya dan tempelkan blok yang benar. Kalau instalasi kamu ada di subdirektori, RewriteBase dan target rewrite terakhir harus cocok dengan path itu — salah di sini adalah alasan paling umum kenapa blok yang ditempel manual tetap menghasilkan 404. Generator .htaccess kami membangun blok yang persis untuk path instalasi kamu supaya kamu tidak perlu menebak-nebak.

3. Pastikan Apache diizinkan membaca .htaccess. Kalau virtual host-nya diset AllowOverride None, Apache akan mengabaikan file-nya sepenuhnya terlepas dari isinya. Kamu butuh AllowOverride All (atau setidaknya FileInfo) pada direktori WordPress. Ini ada di konfigurasi server, bukan .htaccess, jadi butuh akses server:

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

4. Pastikan mod_rewrite aktif. Di Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Di Nginx, tidak ada .htaccess. Rewrite ditaruh di server block:

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

Diagnosis cepat: 404 punya siapa?

Perhatikan halaman 404-nya. Kalau itu halaman error Apache atau hosting yang polos tanpa gaya, berarti Apache tidak pernah sampai ke WordPress — itu masalah .htaccess atau konfigurasi server (langkah 2–4). Kalau itu halaman 404 tema kamu yang bergaya, berarti WordPress menerima request-nya tapi tidak bisa mencocokkannya — aturan di database sudah basi, dan menyimpan ulang permalink (langkah 1) adalah solusinya. Perbedaan satu ini menyelamatkan kebanyakan orang dari satu jam menebak-nebak.

Yang jangan dilakukan

Jangan menonaktifkan semua plugin dulu. Gejala murni “postingan 404, homepage jalan” adalah masalah rewrite, bukan konflik plugin. Menonaktifkan plugin adalah jawaban refleks di forum dan hampir tidak pernah menyentuh masalah ini.

Jangan chmod 777 file .htaccess kamu. WordPress butuh file yang bisa ditulis oleh user web server, yang tidak sama dengan bisa ditulis oleh siapa saja (world-writable). 644 dengan owner yang benar sudah cukup dan aman; 777 adalah lubang keamanan yang toh tidak akan memperbaiki routing-nya.

Jangan menempelkan aturan rewrite kustom di dalam penanda # BEGIN WordPress / # END WordPress. Aturan itu akan terhapus saat berikutnya ada yang menyimpan permalink. Taruh direktif kustom di atas baris # BEGIN WordPress.

Jangan menginstal ulang WordPress. File core-nya baik-baik saja. Ini soal satu blok teks yang hilang, bukan instalasi yang rusak.

Jangan menyalahkan tema kamu. Routing permalink adalah bagian dari WordPress core. Tema tidak bisa menyebabkannya dan tidak bisa memperbaikinya.

Masih buntu?

Kalau kamu sudah menyimpan ulang permalink, memastikan blok-nya ada dan bisa ditulis, dan menyetel AllowOverride All, tersangka yang tersisa adalah plugin keamanan atau aturan tingkat hosting yang meregenerasi atau mengunci .htaccess diam-diam. Periksa timestamp modifikasi file tepat setelah menyimpan permalink — kalau tidak berubah, ada sesuatu yang memblokir penulisan. Regenerasi blok yang bersih dengan generator .htaccess, tempelkan, lalu tes ulang dengan hard refresh.