Deneme ortamından üretime taşınan bir sitede ana sayfa ve wp-adminçalışıyor, ancak bütün yazı adresleri web sunucusunun 404 sayfasına düşüyor. Kalıcı Bağlantı Ayarlarını kaydetmek kısa süreli çözüm gibi görünse de ikinci sunucuya giden istekler yine başarısız oluyor.
Bu tablo eksik içerikten çok rota yapılandırmasına işaret eder. Yeni yönlendirmeler eklemeden veya kalıcı bağlantıları tekrar tekrar kaydetmeden önce 404 yanıtını hangi katmanın ürettiğini belirleyin; ardından bütün sunucularda aynı web kök dizininin ve rewrite kurallarının etkin olduğunu doğrulayın.
Bu konu ne anlama gelir?
Kalıcı bağlantı 404 hatası, okunabilir adresin WordPress’in front controller’ı olan index.phpdosyasına ulaşmaması veya oluşan sorgunun içerikle eşleştirilememesidir. Web sunucusu kuralları, sanal sunucu ayarı, multisite yolları, özel yazı türlerinin kaydı, uç nokta çakışmaları ve tek bir içeriğin durumu ya da slug’ı bu hataya yol açabilir.
Sunucunun kendi 404 sayfası ile WordPress temasının 404 şablonu farklı ipuçları verir. Bütün okunabilir adreslerin bozulması da yalnız bir yazının bulunamamasından ayrıdır. Hedef yönlendirmesi, bozuk WordPress rotasını onarmaz.
Gerçekçi bir WordPress örneği
Örnekte /?p=123gibi doğrudan sorgu adresi yazıyı açarken /ornek-yazi/404 veriyor. Ana sayfa ve statik dosyalar da çalışıyor. Yük dengeleyicinin arkasındaki sunuculardan biri doğru front controller kuralını, diğeri ise eski sanal sunucu ayarını kullanıyor.
Kalıcı çözüm, etkin rewrite yapılandırmasını bütün sunuculara aynı şekilde dağıtıp güvenli biçimde yeniden yüklemektir. Ardından WordPress rewrite kuralları desteklenen yöntemle bir kez yenilenebilir; bu işlem sunucular arasındaki farkı gizleyen rutin bir çözüm olmamalıdır.
Neden önemlidir ve ne zaman kullanılır?
Bozuk kalıcı bağlantılar, yönetim paneli normal görünürken sitenin neredeyse bütün genel içeriğini erişilemez hâle getirebilir. Doğru teşhis, gerçekten silinmiş bir sayfayı sistem genelindeki rota hatasından ayırmayı da sağlar.
Ana sayfa, bir yazı, bir sayfa, arşiv, doğrudan sorgu adresi, REST yolu ve statik dosyadan oluşan küçük bir listeyi sınayın. Durum kodu ve 404 sayfasının görünümü, isteğin web sunucusunda mı kaldığını yoksa WordPress’e mi ulaştığını gösterir.
Yeni başlayanlar için anlaşılır yol
- Etkin web sunucusu yapılandırmasını yedekleyin ve nasıl geri yükleneceğini doğrulayın.
- WordPress Adresini, Site Adresini ve seçili kalıcı bağlantı yapısını kontrol edin.
- Bozulan okunabilir adresi doğrudan sorgu karşılığıyla kıyaslayıp 404’ü sunucunun mu WordPress’in mi ürettiğini belirleyin.
- Her sunucuda etkin sanal sunucu ayarını, web kök dizinini ve Apache ya da Nginx’in WordPress isteklerini
index.phpdosyasına ileten kuralını inceleyin. - Sunucu ayarı düzeltildikten sonra WordPress rewrite kurallarını desteklenen yöntemle bir kez yenileyin ve örnek rotaları yeniden sınayın.
İleri teknik yol
Apache’de gerçekten kullanılan sanal sunucu ve .htaccessiçin geçerli AllowOverrideayarı önemlidir. Nginx’te etkin try_fileskuralını inceleyin. Kapsayıcı veya cluster yapısında bütün düğümlerin aynı sürüm ve yapılandırmayı kullandığını doğrulayın.
Yalnız özel bir yazı türü, taksonomi, dil öneki veya multisite yolu bozuksa rewrite kaydının ne zaman yüklendiğini ve başka bir uç noktayla çakışıp çakışmadığını araştırın. Normal yazılar çalışırken sorun dar bir alanda kalabilir.
Riskler, sık hatalar, yedek ve geri dönüş
Barındırma ve güvenlik kurallarını yedeklemeden .htaccessdosyasının üzerine yazmayın. Rota hatasını geniş yönlendirmelerle gizlemek döngü veya yanıltıcı soft 404 sayfaları oluşturabilir. Kalıcı bağlantıları sürekli kaydetmek de yalnız bir sunucuyu geçici olarak düzeltebilir.
Yönetim paneli, REST, beslemeler veya statik dosyalar bozulursa, sunucu ayarı yeniden yüklenemezse ya da döngü oluşursa önceki yapılandırmaya dönün. Düzeltme bütün düğümlerde, önbellek süresi dolduktan ve hizmet yeniden başlatıldıktan sonra da çalışmalıdır.
AIOWS nasıl yardımcı olur?
AIOWS Yönlendirme Yöneticisi
AIOWS Yönlendirme Yöneticisi, WordPress içindeki açık yönlendirme kurallarını görünür tutarak bu katmanı kalıcı bağlantı rotasından ayırmaya yardımcı olur. İnceleme sırasında 404 yanıtını WordPress kuralının mı yoksa daha önce devreye giren CDN ya da web sunucusunun mu ürettiği anlaşılabilir.
Sunucudaki rewrite kuralı ve WordPress kalıcı bağlantı durumu netleşene kadar yönlendirmeleri değiştirmeyin. Yalnız belirli bir eski adres gerçekten yayındaki ilgili bir içeriğe taşındıysa yönetilen yönlendirme ekleyin; site genelindeki rota arızasını bununla kapatmayın.
Modül Apache veya Nginx ayarlarını onaramaz, cluster düğümlerini eşitleyemez ve eksik içeriği geri getiremez. Bu yazıdaki rolü, WordPress yönlendirme katmanını tanı sırasında denetlenebilir tutmaktır.
AIOWS Yönlendirme Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress 301 Yönlendirmesi: Güvenli Kurulum ve Test
- WordPress Yönlendirme Döngüsü: Gerçek Nedeni Bulma ve Çözme
- WordPress Sondaki Eğik Çizgi Yönlendirme Sorunları
Sonuç ve önerilen yol
404 yanıtını hangi katmanın ürettiğini belirleyin, okunabilir adresleri doğrudan sorgu karşılıklarıyla kıyaslayın ve her düğümde etkin rewrite yapılandırmasını doğrulayın. Rota katmanını düzeltin, gerekirse WordPress kurallarını bir kez yenileyin ve sorunu yönlendirmelerle gizlemeden örnek yolları tekrar sınayın.
