WordPress Yazıları 404 Veriyor: .htaccess Onarımı

Ana sayfa açılıyor ama yazılar ve sayfalar 404 veriyorsa, sorun büyük olasılıkla içeriğin kendisinde değil, adresleri WordPress'e yönlendiren sunucu kurallarındadır. İlk adım yedek almak, ikinci adım Ayarlar altındaki Kalıcı Bağlantılar ekranında ayarı yeniden kaydetmek, üçüncü adım .htaccess dosyasındaki WordPress kural bloğunun sağlam olup olmadığına bakmaktır. Blog, kurumsal site ya da küçük mağaza yönetiyorsanız teşhis tablosu sizi sırayla ilerletir.

Sorunu çözerken 404 ile soft 404'ü karıştırmamak gerekir; ikincisinin farkı için soft 404 hatası yazısına bakın. Kalıcı bağlantı ayarlarının geri kalanı WordPress SEO ayarları kontrol listesinde yer alır.

Belirti: ana sayfa açılıyor, yazılar 404

Belirtiyi üç denemeyle doğrulayın

1. Ana sayfayı açın; açılıyorsa WordPress çalışıyor demektir.
2. Bir yazının güzel adresini açın; 404 geliyorsa kural sorunu şüphesi doğrulanmıştır.
3. Aynı yazıyı ?p= ve yazı kimliğiyle açmayı deneyin; açılıyorsa içerik yerinde, sorun yalnızca güzel adreslerdedir.

WordPress belgesi (yeni sekmede açılır) varsayılan düz yapının ?p=N biçiminde olduğunu ve tüm sunucu ortamlarında çalıştığını söyler. Yani üçüncü deneme, sunucu kuralı sorununu içerik sorunundan ayırmanın pratik bir yoludur. Uygulama önerisi: yazının kimlik numarasını yönetim ekranında yazının düzenleme adresinden okuyabilirsiniz.

Belgenin sunucu hakkındaki tespiti

Aynı belge, hosting sağlayıcınızın güzel ve neredeyse güzel kalıcı bağlantıların doğru çalışması için web sunucusunu gerekli biçimde yapılandırmış olması gerektiğini, yapılandırılmadıysa sağlayıcıya başvurmanız gerektiğini söyler. Dolayısıyla sorun bazen sizin dosyanızda değil, sunucu yapılandırmasında olabilir ve düzeltme sağlayıcıdan gelir.

İlk teşhis: neyi ayırıyoruz

Kısa karar kuralı

Ana sayfa ve ?p= adresi çalışıyor, güzel adresler çalışmıyorsa kural sorunudur: ayarı yeniden kaydedin, sonra dosyaya bakın. Ana sayfa dahil her şey hata veriyorsa güzel adres kuralı sorunu değildir. Tek bir yazı 404 veriyorsa sunucu kurallarına dokunmayın; yazının durumuna ve slug'ına bakın.

mod_rewrite ve temel kural bloğu

Belgedeki blok

Apache HTTPD ve .htaccess belgesi (yeni sekmede açılır) WordPress'in güzel kalıcı bağlantıları işlemek için bu dosyayı değiştirdiğini söyler ve temel kural bloğunu şöyle verir:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Bloğu okumak

Bloğu satır satır okumak sorunun yerini bulmaya yardım eder. İki RewriteCond satırı, istenen adresin gerçek bir dosya ya da dizin olmadığı durumu seçer; bu durumda son RewriteRule isteği index.php dosyasına gönderir ve WordPress adresi çözer. Blokta bu satırlardan biri eksikse güzel adresler çalışmaz. Belgede bloğun satırlarının tek tek ne yaptığına dair bir açıklama yok. Uygulama önerisi: bu okumayı, kuralların yazılışına dayanan bir çalışma varsayımı olarak kullanın.

mod_rewrite hakkında belgenin söylediği

Belge, mod_rewrite için gerekli olanı Options bölümünde bir cümleyle söyler: FollowSymLinks seçeneği mod_rewrite için gereklidir. AllowOverride ayarı, dosya izinleri ve yedekleme gibi konuları bu belgede bulamazsınız; belgede bu konularda ifade yok. Bu ayarlar hosting sağlayıcınızın denetimindedir ve sorun çıkarsa sağlayıcıya sorulması gerekir.

Kalıcı bağlantıları yeniden kaydetme

En düşük riskli ilk adım, Ayarlar altındaki Kalıcı Bağlantılar ekranını açıp seçili yapıyı değiştirmeden kaydetmektir. Belge, WordPress'in güzel kalıcı bağlantıları işleyebilmek için .htaccess dosyasını değiştirdiğini söyler. Ayarı kaydetmenin kural bloğunu yeniden yazıp yazmadığı konusunda belgede açık bir ifade yok. Uygulama önerisi olarak bu adımı denemek makuldür, çünkü yapıyı değiştirmez ve geri alınabilir.

Adım adım

1. Yedek alın; sitenin dosyalarını ve .htaccess içeriğini ayrı bir metin dosyasına kopyalayın.
2. Ayarlar altında Kalıcı Bağlantılar ekranını açın. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.
3. Seçili yapıyı değiştirmeden sayfanın altındaki kaydet düğmesine basın.
4. Bir yazının güzel adresini yeni sekmede açın.
5. Hâlâ 404 geliyorsa bir sonraki bölüme geçin.

Kaydettikten sonra olası sonuçlar

Yapıyı değiştirmeyin

Sorunu çözmeye çalışırken yapıyı değiştirmek yeni bir sorun yaratır: bütün adresler değişir ve yönlendirme gerekir. Yapıyı yalnızca düz adres testi yapmak istiyorsanız geçici olarak değiştirmeyi düşünün, ama canlı sitede bunu yapmayın; ?p= adresini elle açmak aynı testi yapmanın daha güvenli yoludur.

.htaccess dosyasını onarmak

Önce yedek

Dosyada WordPress dışında başka kurallar olabilir: yönlendirmeler, güvenlik kuralları, önbellek kuralları. Onarırken bunları silmeyin. Dosyanın tam kopyasını alın, sonra WordPress'in kendi bloğunu belgedeki sağlam blokla karşılaştırın.

Bozulmanın biçimleri

Belgenin geri yükleme notu

Belge, kural bloğunun bozulmuş bir .htaccess dosyasını (örneğin hatalı çalışan bir eklenti yüzünden) onarmak için kullanılabileceğini söyler. Dosya erişim izinleri ve yazılabilirlik konusu belgede yok; dosyayı kaydedemiyorsanız hosting panelinin dosya yöneticisini ya da sağlayıcı desteğini kullanın.

Elle düzenlerken dikkat edilecekler

• Dosyayı düz metin düzenleyicide açın; kelime işlemci biçimlendirme karakterleri ekleyebilir.
• BEGIN WordPress ve END WordPress satırlarını olduğu gibi bırakın.
• Blokları iç içe yazmayın; her kural bloğu kendi başlangıç ve bitiş satırıyla kalsın.
• Belgeden kopyaladığınız satırlarda satır sonlarının bozulmadığını kontrol edin.
• Kaydettikten sonra dosyayı yeniden açıp içeriğin kaydedildiğini görün.

Uygulama önerisi: değişikliği küçük adımlarla yapın ve her adımdan sonra bir yazının güzel adresini açın. Büyük bir değişiklikten sonra çıkan hatanın hangi satırdan geldiğini ayırt etmek zordur.

Eklenti kaynaklı bozulma

Belge hatalı çalışan bir eklentiyi bozulmuş dosyanın olası nedeni olarak örnekler. Güvenlik, önbellek, yönlendirme ve SEO eklentileri .htaccess ile ilgili işlemler yapabilen eklenti türleridir; hangi eklentinin neyi değiştirdiği her eklentinin kendi belgesindedir ve burada bir ifade yok.

Eklentiyi bulmak

1. Sorunun başladığı tarihe en yakın zamanda kurulan veya güncellenen eklentileri listeleyin.
2. Önce yedeği alın, sonra bu eklentilerden birini devre dışı bırakın.
3. Her devre dışı bırakmadan sonra bir yazının güzel adresini açın.
4. Adres açılırsa son devre dışı bırakılan eklenti şüphelidir; yeniden etkinleştirmeden önce ayarlarını inceleyin.
5. Eklenti yeniden etkinleştirilince sorun dönüyorsa eklentinin .htaccess yazma seçeneğini kapatmak ya da eklentiyi değiştirmek gerekebilir.

Bir seferde bir değişiklik

Aynı anda birden fazla eklentiyi kapatmak suçluyu bulmayı zorlaştırır. Her adımda yalnızca bir değişiklik yapın ve sonucu not edin; hangi adımın düzelttiğini bilmek, sorunun tekrarında zaman kazandırır.

Eklentiyi silmeden önce

Şüpheli eklentiyi bulduysanız hemen silmeyin. Önce eklentinin ayarlarında .htaccess dosyasına yazma, yönlendirme kuralları ekleme veya güvenlik kuralları üretme gibi seçenekleri arayın. Seçeneği kapatmak sorunu giderebilir ve eklentinin diğer işlevlerini korur. Seçenek yoksa ya da kapatmak yetmiyorsa eklentiyi değiştirmek gerekir; bu karar eklentinin belgesine ve sizin ihtiyacınıza bağlıdır.

Eklentiyi kaldırırsanız dosyada bıraktığı satırlar yerinde kalabilir. Belgede bu davranışa dair ifade yok; bu yüzden kaldırdıktan sonra .htaccess içeriğini yeniden okuyun ve eklentiye ait artık satırların kalıp kalmadığına bakın. Eklentiye ait olduğundan emin olmadığınız satırı silmeyin.

Sunucu Apache değilse

.htaccess dosyası Apache sunucuları içindir. Sunucunuz Nginx ya da başka bir yazılım çalıştırıyorsa kurallar farklı bir yerde, sunucu yapılandırmasında bulunur. Belgenin bu bölümünde Nginx için bir ifade yok. Hangi sunucunun çalıştığını hosting panelinden ya da sağlayıcıdan öğrenin. Nginx üzerinde güzel adres kuralı sunucu yapılandırmasıyla kurulduğundan, .htaccess dosyasını düzenlemek bir işe yaramaz.

Tek tek yazıların 404 vermesi

Her 404 kural sorunu değildir. Yalnızca bir iki yazı 404 veriyorsa nedeni yazının kendisinde aramak gerekir. Bu durumda .htaccess dosyasına dokunmak yeni bir sorun çıkarabilir.

Slug değişimi ve yönlendirme

Yayımlanmış bir yazının slug'ı değiştiğinde eski adres 404 verir. WordPress belgesi kalıcı bağlantıların değiştirilmemesi gerektiğini söyler; yine de değiştirdiyseniz eski adresten yeniye kalıcı yönlendirme kurun. Yönlendirme zinciri oluşmaması için hedefi son adrese yazın; ayrıntılar yönlendirme zincirleri yazısında anlatılmıştır.

Hosting veya sunucu değişikliğinden sonra

Siteyi başka bir sunucuya taşıdıktan sonra yazıların 404 vermesi, yeni sunucuda yeniden yazma kurallarının çalışmamasından kaynaklanabilir. WordPress belgesi bu konuda net bir görev dağılımı verir: sunucuyu güzel adresler için yapılandırmak hosting sağlayıcının işidir.

Sağlayıcıya sorulacak sorular

• Sunucuda hangi web sunucusu yazılımı çalışıyor, Apache mi başka biri mi?
• Sitenin kök dizininde .htaccess dosyasının işlenmesine izin veriliyor mu?
• Yeniden yazma modülü etkin mi?
• Sunucu hata günlüğünde, sorunun başladığı zamana ait bir kayıt var mı?

Belgede AllowOverride ve modül etkinleştirme konusunda ifade yok; bu nedenle bu soruları sağlayıcıya yöneltmek en güvenli yoldur.

Taşıma sonrası adres testi

Taşımadan hemen sonra ana sayfayı değil, bir yazıyı ve bir kategori arşivini açın. Ana sayfa çalıştığı için taşıma başarılı sayılırsa, yazıların 404 verdiğini ancak okuyucu şikâyetiyle öğrenirsiniz.

Destek talebini doğru yazmak

Sorun hosting tarafındaysa açık bir destek talebi çözümü hızlandırır. Talepte şunlar bulunsun:

1. Belirti: ana sayfa açılıyor, yazıların güzel adresleri 404 veriyor, ?p= adresi açılıyor.
2. Sorunun başladığı tarih ve hemen öncesinde yapılan değişiklik (eklenti güncellemesi, taşıma, ayar).
3. Test için örnek bir yazı adresi.
4. Yaptığınız adımlar: ayarı yeniden kaydetmek, .htaccess bloğunu belgeye göre onarmak, eklenti eleme.
5. Sağlayıcıdan istediğiniz: sunucu türü ve yeniden yazma ayarının doğrulanması, ilgili hata günlüğü kaydı.

Talebe site yönetici parolası, veritabanı bilgisi ya da başka gizli bilgi yazmayın. Sağlayıcının ihtiyaç duyduğu bilgiyi kendi güvenli kanalından isteyin.

404 ile sunucu hatasını ayırmak

Her hata sayfası aynı sorunu göstermez. 404, istenen adresin bulunamadığını; 5xx ise sunucunun isteği işleyemediğini bildirir. İkisinin çözümü farklıdır.

Google'ın 5xx davranışı

Google belgesine göre 5xx ve 429 hataları tarayıcıların geçici olarak yavaşlamasına yol açar; yavaşlama, hata veren adres sayısıyla orantılıdır. Hata sürerse dizinde olan adresler sonunda düşürülür, sunucu yeniden 2xx dönmeye başlayınca tarama hızı kademeli olarak artar. Bu nedenle sunucu hatasını hızla gidermek, 404'ü gidermek kadar önemlidir. Belgeler ne kadar sürede düşürme olacağını söylemez.

Hata günlüğünü okumak

Hosting panelinizde sunucu hata günlüğüne erişim varsa, sorunun başladığı saatteki kayıtlara bakın. Kayıt içeriği sağlayıcıya göre değişir ve gizli bilgi içerebilir; günlükten kopyaladığınız satırları paylaşmadan önce yol, kullanıcı adı ve benzeri bilgileri gözden geçirin. Günlüğü okuyamıyorsanız sağlayıcıdan ilgili zaman aralığındaki kayıtları isteyin.

Düzeltme sonrası tarama kontrolü

Google 404'e nasıl davranır

Google'ın durum kodları belgesi (yeni sekmede açılır) 429 dışındaki bütün 4xx hatalarının aynı biçimde ele alındığını söyler: sayfa yok sayılır, daha önce dizinde olan bir adres dizinden çıkarılır ve yeni karşılaşılan 404 sayfaları işlenmez. 5xx hataları ise tarayıcıların geçici olarak yavaşlamasına yol açar, hata sürerse dizindeki adresler düşürülür. Belge bir süre sınırı vermez; yalnızca "zamanla" ve "kademeli olarak" ifadelerini kullanır.

Soft 404 olasılığı

Belgeye göre 2xx kodu döndürüp hata benzeri içerik gösteren sayfalar Search Console'da soft 404 olarak işaretlenebilir. Düzeltme sırasında eksik bir kural, 404 yerine ana sayfa içeriğini 200 koduyla gösteriyorsa bu durumu ayrıca kontrol edin. Durum kodlarının anlamı HTTP durum kodları rehberinde anlatılır.

Kontrol listesi

• Beş farklı türden adresi açın: yazı, sayfa, kategori arşivi, etiket arşivi, görsel eki.
• Her birinin 200 döndürdüğünü ve içeriğin doğru olduğunu görün.
• Var olmayan bir adres uydurup açın; 404 sayfası göründüğünü doğrulayın.
• Sitemap'teki birkaç adresi örnekleyin.
• Önbellek eklentisinin ve CDN önbelleğinin temizlendiğinden emin olun.
• Search Console'daki ilgili sayfa dizinleme raporunu birkaç gün sonra yeniden gözden geçirin.

Önbellek katmanları

Sorun giderildiği hâlde tarayıcıda hâlâ 404 görüyorsanız önbelleğe bakın. Önbellek eklentisi, hosting önbelleği ve CDN eski hata sayfasını tutabilir. Her katmanı temizleyin ve gizli pencerede ya da farklı bir cihazda yeniden deneyin. Belgelerde önbellek davranışına dair bir ifade yok; bu adım bir uygulama önerisidir.

Search Console ile izleme

Search Console'daki "Page indexing" raporu, 404 olarak görülen adresleri listeleyebilir. Arayüzü Türkçe kullanıyorsanız rapor adı farklı görünebilir. Düzeltmeden sonra listeyi birkaç gün arayla yeniden okuyun ve hâlâ 404 görünen adreslerin gerçekten var olması gereken adresler mi yoksa bilinçli silinmiş içerik mi olduğunu ayırın. Belgeler, bir adresin ne kadar sürede yeniden işleneceğini söylemez; beklemeyi planınıza katın.

Örnek senaryo: bir halı yıkama işletmesinin web sitesi

Örnek senaryo: Bir halı yıkama işletmesi sitesinde güvenlik eklentisini güncelledikten sonra bakım rehberi yazılarının 404 verdiğini fark eder. Ana sayfa açılmaktadır.

1. Üç denemeyi yapar: ana sayfa açılıyor, güzel adres 404, ?p= adresi açılıyor. Kural sorunu olduğunu anlar.
2. Dosyaları ve .htaccess içeriğini yedekler.
3. Kalıcı Bağlantılar ekranında ayarı değiştirmeden kaydeder; sorun sürer.
4. .htaccess dosyasında WordPress bloğunun eksik olduğunu görür ve belgedeki sağlam bloğu geri yazar; diğer kuralları yerinde bırakır.
5. Güvenlik eklentisinin dosya yazma seçeneğini inceler ve kapatır; sorun tekrarlamaz.
6. Beş türden adresi açar, var olmayan bir adres uydurup 404 sayfasını doğrular, önbelleği temizler.

Önleme

Güncelleme günü rutini

Eklenti, tema ve WordPress güncellemeleri .htaccess ile ilgili değişiklikler getirebilir. Güncellemeyi tek bir iş olarak planlayın ve şu sırayı izleyin.

1. Dosya ve veritabanı yedeği alın, .htaccess içeriğinin kopyasını ayrıca saklayın.
2. Güncellemeleri tek tek yapın; her güncellemeden sonra bir yazının ve bir kategori arşivinin adresini açın.
3. Bir sorun çıkarsa son güncellemeyi geri alın ve hangi güncellemenin sorunu başlattığını kayda geçirin.
4. Güncellemeler bitince beş türden adresi bir kez daha test edin.
5. Kaydı tarihle birlikte saklayın.

Hızlı özet akış

Geri alınamaz adımlardan kaçınmak

Teşhis sırasında veri silen veya yapıyı değiştiren adımlardan uzak durun. Yapıyı değiştirmek, eklentiyi silmek, veritabanını sıfırlamak ve dosyaları toplu silmek bu türdendir. Teşhis adımlarının tamamı geri alınabilir olmalıdır: ayarı yeniden kaydetmek, eklentiyi geçici devre dışı bırakmak, bloğu yedekle birlikte yeniden yazmak. Geri alınamaz bir adımı denemeden önce, sağlayıcıdan yedek veya bir geri yükleme noktası istemeyi düşünün.

Bu sorunun SEO tarafı

404 veren bir yazı, okuyucunun yanı sıra tarayıcılara da hata gösterir. Google belgesi 404'e giden adresin dizinden çıkarılacağını ve yeni karşılaşılan 404 sayfalarının işlenmeyeceğini söyler. Bu yüzden sorun ne kadar kısa sürede giderilirse dizinde kalan adresler o kadar az etkilenir; belgeler somut bir süre veya kayıp büyüklüğü vermez. Düzeltmeden sonra sitemap'in sağlıklı yanıt verdiğini ve adreslerin 200 döndürdüğünü doğrulayın.

Kullanıcıya görünen bozulma

Ziyaretçi 404 sayfasıyla karşılaştığında yazının var olup olmadığını bilemez. Sorun fark edildiği anda düzeltmek, hem okuyucu deneyimi hem de tarayıcıların hata görmesi açısından önemlidir. Düzeltme birkaç saat sürecekse sağlayıcının bakım sayfası seçeneklerini sorun; bakım sayfası uygularken sunucu hatası kodu döndürmek, Google belgesine göre tarayıcıları geçici olarak yavaşlatır, ancak dizindeki adresleri hemen düşürmez.

Düzeltmeyi kaydetmek

Onarımdan sonra neyin bozulduğunu, neyin düzelttiğini ve tarihi kısa bir kayıtta tutun. Aynı sorun yeniden çıktığında ilk teşhis tablosundaki satırı doğrudan bu kayıttan seçersiniz.

Veteriner kliniği sitesi örneği: 404'ün müşteriye etkisi

Örnek senaryo: bir veteriner kliniği sitesinde aşı takvimi ve çalışma saatleri sayfaları var. Bir sabah ana sayfa açılıyor, ama randevu bilgisi sayfası 404 veriyor. Klinik personeli telefonların arttığını fark ediyor. Burada teknik hatanın ilk görünür sonucu aramanın düşmesi değil, müşterinin bilgiye ulaşamayıp telefona yönelmesidir. Bu yüzden ilk iş, en kritik üç sayfayı belirleyip önce onları denemektir.

Müdahale sırası tablosu

Kontrol listesi: onarımdan sonra

• Ana sayfa, bir yazı, bir sayfa ve bir kategori adresi açıldı mı?
• Telefondan ve gizli pencerede de aynı sonuç görülüyor mu?
• Önbellek eklentisi varsa temizlendi mi?
• Değişen dosyanın yedeği ayrı bir yerde duruyor mu?
• Olay kısa bir notla, hangi adımın işe yaradığıyla kaydedildi mi?

Uygulama önerisi: işe yarayan adımı not edin. Aynı sorun aylar sonra tekrar çıktığında listeyi baştan keşfetmek yerine kayda bakarsınız.

Yanlış anlaşılan nokta: 404 gören herkes aynı şeyi görüyor

Bir yöneticinin oturum açıkken gördüğü sayfa ile ziyaretçinin gördüğü sayfa farklı olabilir. Önbellek veya oturum durumu yüzünden sorun yalnız bazı cihazlarda ortaya çıkıyorsa, denemeyi oturumsuz bir pencerede de tekrarlamak teşhisi netleştirir. Belgelerde bu konuda başka bir ayrıntı yok.

Karar kuralı: hangi durumda yardım istenir

Uygulama önerisi: ayarı yeniden kaydetmek ve dosyadaki bloğu denetlemek sonuç vermediyse düzenlemeyi bırakın ve barındırma sağlayıcısına neleri denediğinizi yazın. Deneme listesi sağlayıcının teşhis süresini kısaltır ve aynı adımların tekrarlanmasını önler. Sağlayıcıya şu bilgileri vermek yeterlidir: sorunun başladığı gün, o günden önce yapılan değişiklik, etkilenen örnek adresler ve ana sayfanın açılıp açılmadığı. Belgelerde sağlayıcının yanıt süresine dair bir ifade yok; bu yüzden kritik sayfalar için geçici bir duyuru veya telefon bilgisi hazırlamak da makul bir önlemdir.

Uygulama önerisi: sorun giderildikten sonra, hangi sayfaların müşteri için kritik olduğunu içeren kısa bir liste tutun. Bir sonraki olayda ilk denenecek adresler hazır olur, ekipten biri tatildeyse bile başka biri aynı sırayla ilerleyebilir. Liste yalnız adres, sayfanın işlevi ve sorumlu kişiden oluşabilir.

Sık Sorulan Sorular

Ana sayfa açılıyor ama yazılar 404 veriyor, ilk ne yapmalıyım?

Önce yedek alın, sonra Ayarlar altındaki Kalıcı Bağlantılar ekranında seçili yapıyı değiştirmeden kaydedin. Düzelmezse .htaccess dosyasındaki WordPress kural bloğunu belgedeki sağlam blokla karşılaştırın.

.htaccess dosyasında olması gereken temel kural bloğu nedir?

WordPress belgesi bloğu BEGIN WordPress ve END WordPress satırları arasında RewriteEngine On, RewriteBase /, index.php kuralı, iki RewriteCond satırı ve RewriteRule . /index.php [L] satırıyla verir.

Bozulmuş .htaccess dosyasının nedeni eklenti olabilir mi?

Evet. Belge, kural bloğunun örneğin hatalı çalışan bir eklenti yüzünden bozulmuş bir dosyayı onarmak için kullanılabileceğini söyler. Eklentileri tek tek devre dışı bırakarak şüpheliyi bulabilirsiniz.

Sunucum Nginx ise ne yapmalıyım?

Belgede Nginx için bir ifade yok. .htaccess dosyası Apache içindir. Nginx kuralları sunucu yapılandırmasında bulunur, bu yüzden hosting sağlayıcınıza başvurun.

404 veren yazılar Google'da dizinden çıkar mı?

Google belgesine göre 404 dahil 429 dışındaki 4xx hataları aynı ele alınır ve dizinde olan bir adres dizinden çıkarılır. Belgede ne kadar süre sonra çıkarılacağına dair bir ifade yok.

Sorunu çözemezsem kime başvurmalıyım?

WordPress belgesi, güzel kalıcı bağlantıların çalışması için web sunucusunun gerekli biçimde yapılandırılmasının hosting sağlayıcıya ait olduğunu söyler. Yapılandırma sorunu varsa sağlayıcı desteğine başvurun.

Sonuç

Yazıların 404 vermesi bir kural sorunuysa şu sırayla ilerleyin: yedek alın, ?p= adresiyle içeriğin yerinde olduğunu doğrulayın, Kalıcı Bağlantılar ayarını değiştirmeden kaydedin, .htaccess dosyasındaki WordPress bloğunu belgedeki bloğa göre onarın, sorun sürüyorsa eklentileri tek tek eleyin. Sunucu Apache değilse ya da yapılandırma sağlayıcıdadır, destek isteyin.

Siteniz tekrar sağlıklı çalıştığında okuyucuya hizmet eden içerikleri çoğaltmak isterseniz makale yazımı hizmetimize göz atabilirsiniz.