WordPress Kalıcı Bağlantılar 404 Hatası Veriyorsa 9 Çözüm

WordPress kalıcı bağlantı 404 hatasında ilk denenmesi gereken kontrollerden biri kalıcı bağlantı kurallarının yeniden oluşturulmasıdır.

WordPress, yazı türleri ve URL yapısı için oluşturduğu yeniden yazma kurallarını kalıcı bağlantı ayarları kaydedildiğinde yenileyebilir.

Uygulama adımları

1. WordPress yönetim paneline giriş yapın. Yönetici yetkisiyle siteye erişin.
2. Ayarlar → Kalıcı Bağlantılar bölümünü açın. Mevcut seçeneği kontrol edin.
3. URL yapısını değiştirmeyin. Yazı ismi veya kullanılan özel yapı aynen kalsın.
4. Değişiklikleri Kaydet düğmesine basın. WordPress’in rewrite kurallarını yenilemesini sağlayın.
5. Hatalı yazı URL’sini yeniden açın. Sorunun giderilip giderilmediğini kontrol edin.
6. Ürün ve kategori bağlantılarını test edin. Tek bir URL’yle yetinmeyin.

Neden işe yarayabilir?

Yeni bir eklenti, özel yazı türü veya URL yapısı nedeniyle eski kalan rewrite kuralları güncellenebilir.

Neden bazen işe yaramaz?

Apache .htaccess dosyasını okuyamıyorsa veya Nginx sunucu yapılandırması yanlışsa yeniden kaydetme tek başına yeterli olmayabilir.

Apache kullanan birçok WordPress kurulumunda güzel kalıcı bağlantılar .htaccess dosyasındaki yeniden yazma kurallarıyla çalışır.

Dosya silindiyse, içindeki kurallar bozulduysa veya WordPress’in kurulu olduğu dizinde bulunmuyorsa sayfalar 404 verebilir.

Kontrol adımları

1. Hosting dosya yöneticisini veya SFTP bağlantısını açın.
2. WordPress’in bulunduğu dizine gidin.
3. Gizli dosyaların görüntülenmesini etkinleştirin.
4. .htaccess dosyasını bulun.
5. Dosyayı değiştirmeden önce yedeğini alın.
6. WordPress rewrite kurallarını inceleyin.
7. Diğer eklenti ve güvenlik kurallarını kaydedin.

WordPress kök dizini örneği

public_html/
│
├── wp-admin/
├── wp-content/
├── wp-includes/
├── index.php
├── wp-config.php
└── .htaccess

Bu dizin yapısı, WordPress kök dizine kurulduğunda görülebilecek temsili bir örnektir.

Alt dizin, farklı document root veya özel sunucu yapılandırmalarında konum değişebilir.

Dosya izinleri

WordPress’in .htaccess dosyasını güncelleyememesi dosya sahipliği veya yazma yetkisiyle ilgili olabilir.

Dosya izni kontrol edilirken güvenli sahiplik ve hosting yapılandırması korunmalıdır.

Apache üzerinde WordPress’in okunabilir URL yapısını kullanabilmesi için gerekli yeniden yazma mekanizmasının etkin olması gerekir.

Apache mod_rewrite modülü çalışmıyorsa veya sunucu .htaccess kurallarını uygulamıyorsa kalıcı bağlantılar 404 verebilir.

Örnek sorun

Ana sayfa:
https://example.com/
Durum: 200 OK

Yazı sayfası:
https://example.com/ornek-yazi/
Durum: 404 Not Found

WordPress yönetimi:
Çalışıyor

Olası neden:
Apache rewrite kuralları uygulanmıyor.

Sunucuda kontrol edilmesi gerekenler

• Apache mod_rewrite modülü etkin mi?
• İlgili dizinde .htaccess kullanımına izin veriliyor mu?
• AllowOverride yapılandırması rewrite kurallarını kapsıyor mu?
• VirtualHost doğru document root kullanıyor mu?
• RewriteBase kurulum diziniyle uyumlu mu?
• Hosting, WordPress kurallarını başka bir seviyede mi yönetiyor?

Apache yapılandırma yaklaşımı

# Temsili Apache Directory yapılandırması

<Directory /var/www/example.com/public>
    AllowOverride All
</Directory>

Yukarıdaki örnek yalnızca AllowOverride mantığını açıklar. Gerçek dizin yolu ve uygulanacak izin kapsamı sunucuya göre belirlenmelidir.

mod_rewrite kontrolü

Kendi Apache sunucunuzu yönetiyorsanız modülün etkinliğini sunucu yapılandırması üzerinden inceleyebilirsiniz.

Paylaşımlı hosting kullanıyorsanız bu ayarlara erişim olmayabilir. Böyle durumlarda hosting desteği gerekir.

WordPress her zaman doğrudan Apache üzerinde çalışmaz.

Bazı sitelerde Nginx, Apache veya LiteSpeed farklı yapılarda kullanılabilir.

Bu sunucu türlerinin kalıcı bağlantı yapılandırması aynı değildir.

Nginx ve .htaccess farkı

Nginx, Apache’nin .htaccess dosyasını doğrudan işlemez.

Nginx tabanlı bağımsız WordPress sunucularında kalıcı bağlantı yönlendirmeleri sunucu yapılandırmasına eklenmelidir.

Temel Nginx örneği

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

Bu kural, gerçek bir dosya veya dizin bulunamadığında isteğin WordPress giriş dosyasına aktarılması için kullanılan yaygın örnektir.

LiteSpeed kullanılıyorsa

LiteSpeed Web Server Apache uyumlu yeniden yazma yapılandırmalarını destekleyebilir.

Ancak LiteSpeed Cache eklentisi kullanmak, sunucunun mutlaka LiteSpeed olduğu anlamına gelmez.

Kontrol edilecekler

• Gerçek web sunucusu türü nedir?
• Nginx bağımsız sunucu mu, Apache önünde proxy mi?
• İlgili domain doğru server block’a mı bağlı?
• location / içinde uygun try_files var mı?
• PHP işleme yapılandırması doğru mu?
• LiteSpeed kullanılıyorsa rewrite kuralları doğru yükleniyor mu?

Bütün yazılar değil yalnızca belirli bağlantılar 404 veriyorsa sorun içerik adresinin kendisinde olabilir.

WordPress’te yazı, sayfa, kategori, özel yazı türü ve taksonomi yolları arasında çakışma oluşabilir.

Örnek URL çakışması

WordPress sayfası:
https://example.com/projeler/

Özel yazı türü arşivi:
https://example.com/projeler/

Olası sorun:
İki farklı yapı
aynı URL yolunu kullanıyor.

Kontrol edilecekler

• Yazı gerçekten yayımlanmış mı?
• Yazı slug’ı değişmiş mi?
• Aynı slug’a sahip başka sayfa var mı?
• Özel yazı türünün rewrite slug’ı çakışıyor mu?
• Kategori veya taksonomi tabanı aynı yolu kullanıyor mu?
• Özel yazı türü eklentisi güncellendi mi?
• Eski bir URL üzerinden mi sayfa açılmaya çalışılıyor?

Özel yazı türü örneği

register_post_type(...)

rewrite:
slug = projeler

Mevcut WordPress sayfası:
slug = projeler

Sonuç:
URL yapıları çakışabilir.

Çözüm

1. Çakışan URL yollarını listeleyin.
2. Hangi içeriğin ilgili URL’yi kullanması gerektiğini belirleyin.
3. Gerekirse özel yazı türü veya sayfa slug’ını düzeltin.
4. Kalıcı bağlantıları yeniden kaydedin.
5. Eski URL için uygun yönlendirme gerekip gerekmediğini değerlendirin.

WordPress’te SEO, güvenlik, çoklu dil ve yönlendirme eklentileri URL davranışını değiştirebilir.

Rank Math yönlendirme modülü, özel redirect eklentileri ve tema kodları birlikte çalışıyorsa çakışmalar oluşabilir.

Örnek

Eski URL:
/eski-hizmet/

Rank Math yönlendirmesi:
/eski-hizmet/ → /yeni-hizmet/

Yeni URL:
/yeni-hizmet/

Ancak yeni sayfa:
404 Not Found

Sonuç:
Yönlendirme var fakat hedef içerik yok.

Böyle bir durumda 301 yönlendirmesinin çalışması, hedef sayfanın doğru açıldığını kanıtlamaz.

Kontrol edilecekler

• Rank Math yönlendirme modülünde ilgili URL var mı?
• Regex yönlendirme kuralı fazla geniş mi?
• Başka bir redirect eklentisi aynı yolu değiştiriyor mu?
• Cloudflare veya hosting ayrıca yönlendiriyor mu?
• functions.php içinde özel rewrite veya redirect kodu var mı?
• Çok dilli eklenti URL öneklerini değiştiriyor mu?
• Güncellemeden sonra eski rewrite kuralları kalmış mı?

Doğru müdahale

1. 404 veren URL’nin tam yönlendirme zincirini çıkarın.
2. Hangi katmanın yönlendirdiğini belirleyin.
3. Gereksiz veya hatalı kuralı bulun.
4. Değişikliği staging ortamında test edin.
5. Doğru nihai sayfanın HTTP 200 döndürdüğünü doğrulayın.

WooCommerce, WordPress kalıcı bağlantı sistemini ürünler, kategoriler, hesap sayfaları ve ödeme işlemleri için kullanır.

Bu nedenle yalnızca WooCommerce sayfalarında 404 görülmesi özel URL kurallarına işaret edebilir.

Yaygın sorunlar

• Ürün permalink tabanı değişmiş olabilir.
• Ürün slug’ı başka içerikle çakışabilir.
• Hesap endpoint adı değiştirilmiş olabilir.
• WooCommerce rewrite kuralları yenilenmemiş olabilir.
• Eski ürün URL’si hâlâ bağlantılarda kullanılıyor olabilir.
• Ürün taslak veya özel durumuna alınmış olabilir.

WooCommerce ürün URL örneği

Ürün:
/urun/ornek-urun/

Beklenen:
200 OK

Gerçek sonuç:
404 Not Found

Kontrol:
Ürün yayın durumu
Ürün slug'ı
WooCommerce permalink tabanı
WordPress rewrite kuralları

WooCommerce hesap endpoint örneği

Hesabım:
/hesabim/

Siparişler:
/hesabim/orders/

Sipariş görüntüleme:
/hesabim/view-order/123/

Not:
Gerçek endpoint adları ve
hesap sayfası slug'ları
mağazaya göre değişebilir.

WooCommerce’in resmî belgelerinde bazı endpoint adreslerinin çalışabilmesi için gerekli parametreleri taşıması gerektiği açıklanır.

Örneğin sipariş görüntüleme endpoint’i çoğunlukla bir sipariş kimliği gerektirir.

Çözüm sırası

1. Ürün veya endpoint URL’sini belirleyin. Hangi yol 404 veriyor?
2. WooCommerce ayarlarını inceleyin. Ürün permalink ve gelişmiş endpoint yapılarını kontrol edin.
3. URL çakışmalarını bulun. Aynı slug’ı kullanan başka içerik var mı?
4. Kalıcı bağlantıları kaydedin. Rewrite kurallarını yenileyin.
5. Ödeme ve hesap akışlarını test edin. Sadece ürün sayfasıyla yetinmeyin.

WordPress siteleri başka hosting paketine taşındığında veya alan adı değiştirildiğinde kalıcı bağlantı sorunları oluşabilir.

Özellikle sunucu document root dizini, WordPress adresi, Site adresi ve rewrite tabanı birbiriyle uyumlu olmalıdır.

Örnek yanlış taşıma

Eski site:
https://old.example.com/

Yeni site:
https://example.com/

WordPress adresi:
https://old.example.com/

Site adresi:
https://example.com/

Olası sorun:
URL ve yönlendirme tutarsızlığı.

Alt dizin örneği

WordPress kurulum dizini:
/blog/

İstenen URL:
https://example.com/blog/ornek-yazi/

Yanlış rewrite tabanı:
/

Uygun yapılandırma:
Gerçek kurulum ve yayın yoluna göre belirlenir.

Kontrol edilecekler

• WordPress Adresi ve Site Adresi doğru mu?
• Domain DNS doğru sunucuya mı gidiyor?
• Document root doğru WordPress dizini mi?
• Sunucu eski siteye yönlendirme yapıyor mu?
• Alt dizin rewrite kuralları doğru mu?
• WWW ve HTTPS tercihleri tutarlı mı?
• Veritabanındaki eski dahili bağlantılar etkilenmiş mi?

Site adresi nasıl kontrol edilir?

WordPress’te Ayarlar → Genel ekranından WordPress Adresi ve Site Adresi alanlarını inceleyin.

Ancak bazı kurulumlarda bu değerler wp-config.php veya başka sunucu yapılandırmalarıyla sabitlenmiş olabilir.

Kalıcı bağlantı hatasını düzeltmenize rağmen bazı kullanıcılar hâlâ 404 görebilir.

Bu durum CDN, sayfa önbelleği veya sunucunun farklı katmanlarındaki eski yanıtlarla ilgili olabilir.

LiteSpeed Cache, WordPress sitelerinde optimizasyon amacıyla kullanılabilir.

Ancak her 404 hatasının nedeni LiteSpeed değildir.

Kontrol edilecekler

• Kalıcı bağlantı düzeltmesinden sonra önbellek temizlendi mi?
• CDN eski 404 yanıtını saklıyor mu?
• Farklı cihaz ve ağlarda aynı sonuç mu görülüyor?
• Sunucu gerçekten 404 mü döndürüyor?
• URL arada 301 veya 302 yönlendirme yapıyor mu?
• Sunucu loglarında ilgili isteğin kaydı var mı?
• 404 yanıtı WordPress’ten mi, proxy katmanından mı geliyor?
• Hosting kaynaklı farklı sunucular arasında yapılandırma farkı var mı?

Güvenli test sırası

1. Önce mevcut durumu kaydedin. URL ve HTTP yanıtını not edin.
2. WordPress permalink kurallarını kontrol edin. İlk çözümün uygulandığını doğrulayın.
3. Önbelleği kontrollü temizleyin. WordPress ve CDN katmanlarını ayırın.
4. Temiz oturumda test edin. Farklı cihaz veya ağ kullanın.
5. Sunucu günlüklerini inceleyin. Gerçek isteğin hangi katmanda hata verdiğini belirleyin.
6. Kalıcı düzeltmeyi doğrulayın. Birden fazla gerçek URL’de test yapın.