WordPress Yazıları 404 Veriyor ama Ana Sayfa Çalışıyor

Ana sayfanız sorunsuz açılıyor ama her yazı ve sayfa 404 veriyorsa, WordPress’in dayandığı URL yeniden yazma kuralları .htaccess dosyanızda eksik ya da bozuktur. En hızlı çözüm: wp-admin’de Ayarlar → Kalıcı Bağlantılar ekranına gidin ve hiçbir şeyi değiştirmeden Değişiklikleri Kaydet düğmesine tıklayın. Bu, WordPress’i yeniden yazma bloğunu yeniden oluşturmaya zorlar. 404’ler devam ediyorsa; ya .htaccess dosyanız web sunucusu tarafından yazılabilir değildir, ya Apache dosyayı yok saymaya yapılandırılmıştır, ya da Nginx kullanıyorsunuzdur (Nginx .htaccess dosyasını hiç kullanmaz).

Ana sayfa neden çalışır ama yazılar çalışmaz

Ana sayfanız çalışır çünkü / adresine gelen bir istek, doğrudan belge kökündeki index.php üzerinden karşılanır. Herhangi bir yeniden yazma gerekmez.

/2026/my-post/ adresine gelen bir istek ise farklıdır. Bu yol, diskte gerçek bir klasör değildir. WordPress’in buna yanıt verebilmesi için Apache’nin isteği dahili olarak index.php’ye yönlendirmesi gerekir; ardından WordPress REQUEST_URI değerini okur, bunu veritabanındaki rewrite_rules seçeneğinde saklanan yeniden yazma kurallarıyla eşleştirir, sorgu değişkenlerini çözer (WP::parse_request()) ve doğru yazıyı yükler.

Bozulan kısım, Apache’den index.php’ye geçiş kısmıdır. Bu tamamen .htaccess içindeki şu bloğa bağlıdır:

# 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

İki RewriteCond satırı şunu söyler: istenen yol gerçek bir dosya değilse (!-f) ve gerçek bir dizin değilse (!-d), isteği index.php’ye gönder. Bu bloğu kaldırırsanız Apache gerçek bir /2026/my-post/ dizini arar, bulamaz ve kendi 404’ünü döndürür — üstelik WordPress isteği hiç görmeden önce.

WordPress kalıcı bağlantıları kaydederken .htaccess’i neden üzerine yazar

Çoğu rehberin atladığı kısım budur. Kalıcı Bağlantılar ekranında Kaydet düğmesine tıkladığınızda WordPress flush_rewrite_rules() fonksiyonunu çağırır. Yazılabilir bir .htaccess bulunan Apache’de bu, save_mod_rewrite_rules() fonksiyonunu tetikler; bu fonksiyon da yukarıdaki bloğu WP_Rewrite::mod_rewrite_rules() aracılığıyla yeniden oluşturur ve insert_with_markers() kullanarak dosyaya geri yazar.

insert_with_markers() yalnızca # BEGIN WordPress ile # END WordPress arasındaki satırlara dokunur. Bu işaretleyicilerin dışındaki her şey olduğu gibi bırakılır. İçindeki her şey ise silinir ve yeniden yazılır. Yeni WordPress sürümleri uyarıyı doğrudan dosyaya bile basar:

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

Yani “WordPress .htaccess dosyamın üzerine yazıyor” ifadesi doğrudur ama sınırlıdır: yalnızca kendi işaretli bloğunu yeniden yazar ve yalnızca dosya yazılabilir olduğunda. Dosya yazılabilir değilse, kaydetme işlemi diske sessizce hiçbir şey yapmaz. WordPress, Kalıcı Bağlantılar ekranında kuralları elle yapıştırmanızı söyleyen sarı bir bildirim gösterir; bu bildirimi gözden kaçırırsanız yeniden yazma bloğunuz eksik kalır ve her yazı 404 vermeye devam eder.

Nasıl düzeltilir, sırasıyla

1. Kalıcı bağlantılarınızı yeniden kaydedin. Ayarlar → Kalıcı Bağlantılar → Değişiklikleri Kaydet. Herhangi bir düzenleme gerekmez. Bu, temizleme işlemini yeniden çalıştırır ve bloğu yeniden yazar. Bir taşıma işleminden sonra kalan eskimiş kurallar dahil vakaların çoğunu çözer.

2. .htaccess dosyasının var olduğunu ve yazılabilir olduğunu kontrol edin. Dosya, wp-config.php ile aynı klasörde bulunur. Nokta dosyasıdır, bu yüzden FTP istemcinizde “gizli dosyaları göster” seçeneğini açın ya da şunu kullanın:

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

Dosya eksikse oluşturun ve doğru bloğu yapıştırın. Kurulumunuz bir alt dizinde bulunuyorsa, RewriteBase ve son yeniden yazma hedefi o yolla eşleşmelidir — bunu yanlış ayarlamak, elle yapıştırılan bir bloğun hâlâ 404 vermesinin en yaygın nedenidir. .htaccess oluşturucumuz, tahmin yürütmenize gerek kalmadan kurulum yolunuza uygun tam bloğu oluşturur.

3. Apache’nin .htaccess dosyasını okumasına izin verildiğini doğrulayın. Sanal ana bilgisayarda AllowOverride None ayarı varsa, Apache içeriği ne olursa olsun dosyayı tamamen yok sayar. WordPress dizininde AllowOverride All (ya da en azından FileInfo) gerekir. Bu ayar .htaccess içinde değil sunucu yapılandırmasında bulunur, dolayısıyla sunucu erişimi gerektirir:

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

4. mod_rewrite’ın etkin olduğunu doğrulayın. Debian/Ubuntu’da:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Nginx’te .htaccess yoktur. Yeniden yazmalar bunun yerine server bloğuna girilir:

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

Hızlı teşhis: bu 404 kimin?

404 sayfasına bakın. Şekilsiz bir Apache veya barındırma hata sayfasıysa, Apache WordPress’e hiç ulaşmamıştır — bu bir .htaccess ya da sunucu yapılandırması sorunudur (adım 2–4). Eğer temanızın şekillendirilmiş 404 sayfasıysa, WordPress isteği alıyor ama eşleştiremiyordur — veritabanındaki kurallar eskimiştir ve kalıcı bağlantıları yeniden kaydetmek (adım 1) çözümdür. Bu tek ayrım çoğu kişiyi bir saatlik tahminden kurtarır.

Yapılmaması gerekenler

Önce tüm eklentilerinizi devre dışı bırakmayın. Salt “yazılar 404, ana sayfa çalışıyor” belirtisi bir yeniden yazma sorunudur, bir eklenti çakışması değil. Eklentileri devre dışı bırakmak forumlarda refleks halinde verilen bir yanıttır ama bu soruna neredeyse hiç dokunmaz.

.htaccess dosyanıza chmod 777 uygulamayın. WordPress’in dosyanın web sunucusu kullanıcısı tarafından yazılabilir olmasına ihtiyacı vardır; bu, herkese açık yazılabilir olmakla aynı şey değildir. Doğru sahibiyle 644 yeterli ve güvenlidir; 777 ise yönlendirmeyi zaten düzeltmeyecek bir güvenlik açığıdır.

Özel yeniden yazma kurallarını # BEGIN WordPress / # END WordPress işaretleyicilerinin içine yapıştırmayın. Biri kalıcı bağlantıları bir sonraki kaydettiğinde silinirler. Özel yönergeleri # BEGIN WordPress satırının üzerine koyun.

WordPress’i yeniden kurmayın. Çekirdek dosyalar sorunsuzdur. Bu, bozuk bir kurulum değil, eksik bir metin bloğudur.

Temanızı suçlamayın. Kalıcı bağlantı yönlendirmesi WordPress çekirdeğine aittir. Bir tema buna neden olamaz ve düzeltemez.

Hâlâ takıldınız mı?

Kalıcı bağlantıları yeniden kaydettiyseniz, bloğun mevcut ve yazılabilir olduğunu doğruladıysanız ve AllowOverride All ayarını yaptıysanız, geriye kalan şüpheli bir güvenlik eklentisi ya da .htaccess dosyasını arkanızdan yeniden oluşturan veya kilitleyen bir sunucu düzeyi kuraldır. Bir kalıcı bağlantı kaydından hemen sonra dosyanın değişiklik zaman damgasını kontrol edin — değişmediyse, bir şey yazma işlemini engelliyordur. .htaccess oluşturucu ile temiz bir blok yeniden üretin, yapıştırın ve sert bir yenileme (hard refresh) ile tekrar test edin.