WordPress ana sayfası açıldığı hâlde yazı, sayfa, ürün veya kategori bağlantılarının 404 vermesi çoğunlukla rewrite kurallarının web sunucusuna uygulanmadığını gösterir. Kalıcı bağlantı ayarı, .htaccess, Nginx try_files, document root ve slug çakışmaları birlikte incelenmelidir.
404 Not Found
The requested URL was not found on this server
nginx: open() /var/www/html/ornek-yazi failed
WordPress güzel URL’leri fiziksel dosya olarak saklamaz. Web sunucusu isteği index.php’ye yönlendirir ve WordPress doğru içeriği bulur. Rewrite zinciri bozulduğunda ana sayfa çalışırken diğer URL’ler 404 dönebilir.
Apache üzerinde .htaccess yazılamıyorsa WordPress ayar ekranı kuralları gösterir ancak dosyaya kaydedemez. mod_rewrite ve AllowOverride yapılandırması da doğru olmalıdır.
Nginx .htaccess okumaz; server bloğunda uygun try_files kuralı gerekir. Apache örneğini Nginx sunucusuna kopyalamak çözüm sağlamaz.
Taşıma sonrası document root, siteurl/home, alt dizin ve cache kayıtları eski yolu gösterebilir. URL düzeltmesi veritabanında seri hâle getirilmiş verileri bozmayacak araçla yapılmalıdır.
Custom Post Type, sayfa, kategori ve ürün sluglarının çakışması da yalnız belirli içerik türlerinde 404 oluşturabilir. Rewrite flush geçici düzelip yeniden bozuluyorsa kodun flush işlemini yanlış kullandığı araştırılmalıdır.
Her istekte flush_rewrite_rules çalıştırmak performans sorunu oluşturur. Rewrite kuralları yalnız yapı değiştiğinde bir kez yenilenmelidir.
E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.
Anlamı: İstenen URL web sunucusu veya WordPress tarafından bulunamamıştır.
Muhtemel neden: Rewrite eksik, yanlış kök veya gerçek içerik yok.
Anlamı: WordPress çalışıyor ancak güzel URL rewrite edilmemiştir.
Muhtemel neden: .htaccess, mod_rewrite veya Nginx try_files.
Anlamı: Apache isteği index.php’ye yönlendirmemiştir.
Muhtemel neden: AllowOverride kapalı veya .htaccess kuralı yok.
Anlamı: Nginx URL’yi fiziksel dosya olarak aramıştır.
Muhtemel neden: try_files kuralı WordPress’e düşmüyor.
Anlamı: Yalnız taksonomi rewrite kuralı bozulmuştur.
Muhtemel neden: Slug çakışması, eklenti veya base ayarı.
Anlamı: Özel içerik türünün rewrite kaydı güncel değildir.
Muhtemel neden: Kod değişikliği sonrası flush yapılmamış veya slug çakışmış.
Anlamı: Yeni sunucuda rewrite/document root farklıdır.
Muhtemel neden: Taşıma sonrası vhost veya .htaccess eksik.
Anlamı: Sunucu 200 döndürürken içerik bulunamadı sayfası gösterir.
Muhtemel neden: Tema yanlış HTTP kodu üretiyor.
Bu ifadeyle eşleşen kayıt bulunamadı.
Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.
wp rewrite flush --hard
WordPress rewrite kurallarını ve destekleniyorsa .htaccess dosyasını yeniler.
wp rewrite list --format=table | head -n 40
İlk eşleşen rewrite kurallarını gösterir.
curl -sSIk https://example.com/?p=1
curl -sSIk https://example.com/ornek-yazi/
Düz query URL ile güzel URL’yi karşılaştırır.
ls -la .htaccess
cat .htaccess
Dosyanın varlığı, sahibi ve mevcut kuralları gösterir.
apachectl -M 2>/dev/null | grep rewrite
mod_rewrite modülünün yüklü olup olmadığını gösterir.
wp option get home
wp option get siteurl
Taşıma sonrası ana URL değerlerini doğrular.
WordPress hatasının temel nedeni aynıdır ancak log yolları, PHP ayar ekranları ve servis yönetimi kullanılan barındırma altyapısına göre değişir.
cPanel Apache/LiteSpeed ortamında .htaccess ve MultiPHP ayarları öne çıkar.
cd /home/KULLANICI/public_html && wp rewrite flush --hardPlesk’te Apache & nginx Settings ile document root ve rewrite davranışı kontrol edilir.
plesk repair web example.comPanelsiz sunucuda Apache AllowOverride veya Nginx try_files doğrudan yapılandırılır.
nginx -t 2>/dev/null || apachectl configtestİçeriğin varlığını doğrulayın, query URL ile güzel URL’yi karşılaştırın ve kullanılan web sunucusuna uygun rewrite yapılandırmasını yenileyin.
Yazı/sayfa durumunun published olduğunu ve çöp kutusunda olmadığını kontrol edin.
wp post list --post_status=publish --fields=ID,post_title,post_name?p=ID açılıyor ancak slug açılmıyorsa rewrite katmanına odaklanın.
curl -sSIk https://example.com/?p=1Panelden Kaydet veya WP-CLI rewrite flush kullanın.
wp rewrite flush --hardApache .htaccess veya Nginx try_files ayarını kullanılan stack’e göre kontrol edin.
apachectl -M 2>/dev/null | grep rewriteSayfa, kategori, ürün ve CPT aynı slugı kullanıyorsa benzersiz yapın.
wp rewrite listUygulama/CDN cache temizlendikten sonra gerçek 404 kodlarını yeniden tarayın.
curl -sSIk https://example.com/ornek-yazi/Rewrite veya .htaccess sorunu güçlü ihtimaldir.
wp rewrite flush --hardWooCommerce permalink, product base ve slug çakışması kontrol edilir.
wp option get woocommerce_permalinksCategory base, eklenti rewrite filtreleri ve aynı slugdaki sayfalar incelenir.
wp term list categoryDocument root, home/siteurl, web server config ve cache kayıtları kontrol edilir.
wp option get siteurlNormaldir; Nginx .htaccess okumaz. server block try_files ayarı düzeltilmelidir.
nginx -T | grep -n 'try_files' | headWordPress çalışır ancak güzel URL’leri index.php’ye yönlendiren rewrite kuralı çalışmıyordur.
WordPress rewrite kurallarını yeniler ve uygun ortamda .htaccess dosyasına yazar.
Hayır. Nginx için server block içinde try_files veya eşdeğer yönlendirme gerekir.
Gerçek kaldırılmış sayfalar için 404 normaldir; var olan önemli URL’lerin yanlışlıkla 404 vermesi trafik ve index kaybına yol açabilir.
Bulunamayan içerik gösterildiği hâlde sunucunun 200 başarılı kodu döndürmesidir.
Yeni document root, site URL’leri ve web sunucusu rewrite yapılandırması birlikte kontrol edilmelidir.
Özel içerik türünün rewrite kaydı, slug çakışması veya hatalı sürekli flush kodu sorun oluşturabilir.
cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.