Blog details
Search Console’da “soft 404” görmek can sıkıcıdır çünkü sayfa ortada vardır, ama Google o sayfayı yok hükmünde sayar. Genelde sorun tek bir URL değildir; yanlış yönlendirme, ince içerik, boş filtre sayfası ya da 200 dönen hata şablonu zincir halinde ortaya çıkar.
Bu yüzden mesele yalnızca raporu temizlemek değil, sayfanın verdiği mesajla sunucunun verdiği yanıtı eşleştirmektir. Aşağıdaki adımlar, soft 404 hatalarını bulup kalıcı biçimde düzeltmek için en kısa yolu gösterir.
Soft 404 aslında ne demek?
Soft 404, teknik olarak “sayfa var” diyen ama pratikte kullanıcıya faydalı içerik sunmayan URL’ler için ortaya çıkar. En tipik örnek, ekranda “Ürün bulunamadı” yazdığı halde sunucunun 200 OK dönmesidir. Google bunu gerçek bir içerik sayfası gibi görmez.
Klasik 404 ile fark burada başlar. Gerçek 404, URL’nin artık olmadığını açıkça söyler. Soft 404 ise belirsizdir. Sayfa açılır, ama içeriği yoktur, çok zayıftır ya da yönlendirme alakasızdır. Bu belirsizlik taramayı boşa harcatır ve raporları kirletir.
Google’ın 404 hata yönergesinde da önemli bir nokta var: Doğru dönen 404’ler tek başına sorun değildir. Sorun, aslında bulunamayan ya da işe yaramayan sayfaların 200 ile dönmesidir.
Kullanıcı “sayfa yok” görüyorsa, sunucu da çoğu durumda aynı şeyi söylemelidir.
Sorunun etkisi yalnızca indeksleme tarafında kalmaz. Sitemap içinde yaşayan ama gerçekte boş olan URL’ler, tarama bütçesini gereksiz tüketir. Ayrıca ekip içinde yanlış alarm üretir. İçerik ekibi sayfayı canlı sanır, geliştirici ekip şablonu doğru zanneder, SEO tarafı da neden indekslenmediğini çözmeye çalışır.
Yine de her boş görünen sayfa soft 404 değildir. Örneğin iç site aramasında geçici olarak sonuç çıkmaması, o URL’nin tamamen geçersiz olduğu anlamına gelmez. Eğer sayfa hâlâ kullanıcıya yardımcı oluyorsa, benzer içerikler gösteriyorsa ve kasıtlı bir işlev taşıyorsa 200 uygun olabilir. Kısacası karar, URL’nin amacına göre verilir. Google’ın gördüğü şey sadece metin miktarı değil, sayfanın niyetle ne kadar uyumlu olduğudur.
Google Search Console’da soft 404 nasıl tespit edilir?
İlk durak, Google Search Console içindeki “Dizinleme > Sayfalar” raporudur. Burada “Soft 404” satırına girip etkilenen URL’leri dışa aktarın. Tek tek bakmadan önce kalıp arayın. Aynı klasörde toplanıyorlar mı, aynı şablondan mı geliyorlar, yoksa belirli parametreleri mi taşıyorlar?
Sonra örnek URL’leri “URL Denetleme” ile açın. “Canlı URL’yi test et” sonucu önemlidir çünkü bazen rapordaki veri eski olur. Ardından tarayıcıda sayfayı açın ve sadece görünen içeriğe değil, sunucu yanıtına da bakın. Geliştirici araçları, curl -I komutu ya da log kayıtları burada iş görür. Ekranda “bulunamadı” yazıp başlıkta 200 dönüyorsa, sorun nettir.
Bir adım daha ileri gidin. URL sitemap’te yer alıyor mu, site içi link alıyor mu, canonical başka sayfayı mı gösteriyor? Search Console içindeki keşif detayları da yardımcı olur; URL’nin sitemap’ten mi, dahili bir linkten mi, yoksa başka bir kaynaktan mı bulunduğunu görmek kök nedeni hızla ortaya çıkarır.
Özellikle filtre URL’leri, etiket arşivleri ve ?page=999 gibi uç sayfalar soft 404 listesine kümeler halinde düşer. Büyük yapılarda bu denetimi tarama araçlarıyla hızlandırmak gerekir; düzenli teknik kontrol, profesyonel SEO danışmanlığı süreçlerinde de bu yüzden ilk aşamalardan biridir.
Ayrıca robots.txt ile gizlenmiş URL’lere dikkat edin. Bir URL gerçekten 404 dönmeliysa, Google’ın bunu görmesi gerekir. Robots.txt ile engellemek, hatayı çözmez; sadece teşhisi zorlaştırır. CDN ya da önbellek kullanıyorsanız eski 200 yanıtlarının cache’te kalıp kalmadığını da kontrol edin.
Yaygın soft 404 senaryoları ve doğru yanıt kodu
Soft 404’lerin çoğu aynı birkaç şablondan çıkar. Sorunu hızlı çözmek için URL’leri tek tek değil, senaryo bazlı ele almak daha verimlidir.
200 dönen “bulunamadı” sayfaları
En sık görülen örnek özel 404 tasarımıdır. Sayfa güzel görünür, arama kutusu ve menü vardır, ama sunucu 200 döner. Aynı sorun uygulama tarafında da olur. Örneğin /urun/eski-model-x adresinde “Ürün bulunamadı” mesajı vardır, fakat HTTP yanıtı 200’dür. Bu durumda doğru çözüm, sayfayı gerçekten 404 ya da kalıcı kaldırıldıysa 410 döndürmektir.
Benzer durum içerik sitelerinde de görülür. /blog/yanlis-slug adresi bulunamaz, ama tema yine de normal sayfa şablonunu yükler. Kullanıcı hata mesajı görür, bot 200 alır. Aradaki çelişki, soft 404 üretir.
Silinmiş ürün sayfaları ve yanlış yönlendirmeler
E-ticarette stoktan kalkan ürünler bu rapora sık düşer. Eğer ürünün net bir karşılığı varsa, 301 ile en yakın alternatife yönlendirin. Örneğin /urun/iphone-13-mavi-128gb artık yoksa ve yerine yeni sürüm geldiyse, ürün ailesindeki en yakın canlı sayfaya 301 mantıklıdır.
Ancak her silinen URL ana sayfaya gitmemeli. Bu, hatayı kapatmaz. Çoğu durumda Google bunu alakasız yönlendirme sayar.
Tüm eski URL’leri ana sayfaya 301 ile göndermek, soft 404 üretmenin en kolay yollarından biridir.
Eşdeğer içerik yoksa 404 yeterlidir. Sayfa bilinçli ve kalıcı olarak kaldırıldıysa 410 daha nettir. 410, “bu içerik geri gelmeyecek” mesajını açık verir. Özellikle kampanya, sezon ürünü ya da artık satılmayan model sayfalarında bu ayrım işe yarar.
Filtre URL’leri, boş kategori ve etiket sayfaları
/kategori/erkek-ayakkabi?renk=mor&numara=49 gibi kombinasyonlar sık sorun çıkarır. Sonuç yoksa ve bu kombinasyonlar sınırsız biçimde üretilebiliyorsa, bu URL’leri indexlenebilir bırakmak anlamlı değildir. Üretimi kısıtlayın, gerekirse noindex uygulayın, geçersiz kombinasyonlar için 404 düşünün.
Boş kategori ve etiket sayfaları da benzer. /etiket/kampanya-2021/ gibi eski arşivler bazen tek cümleyle yayında kalır. Kullanıcıya değer sunmuyorsa sayfayı güçlendirin, birleştirin ya da kaldırın. İnce içerik, soft 404 tetikleyebilen bir senaryodur; Wix’in soft 404 açıklaması da bu noktaya değinir.
Bir başka örnek, sonuçsuz arama sayfalarıdır. /arama?q=zxq123 adresi boş dönebilir. Eğer bu sayfa kullanıcıya alternatif öneriler, popüler aramalar ve yararlı yönlendirme sunuyorsa 200 kabul edilebilir. Ancak sistem sınırsız ve anlamsız arama URL’leri üretiyorsa, bunları indeks dışında tutmak daha doğrudur.
Aşağıdaki tablo, doğru yanıtı seçmeyi hızlandırır:
| Durum | Kullanılacak kod | Kısa açıklama |
|---|---|---|
| Sayfa geçerli, içerik yeterli, kullanıcıya faydalı | 200 | Sayfa canlıdır ve indexlenebilir olabilir |
| Sayfa yok, benzer bir alternatif de yok | 404 | Standart ve doğru yanıt |
| Sayfa kalıcı olarak kaldırıldı | 410 | Kaldırma niyetini daha açık gösterir |
| Eski URL’nin güçlü ve yakın bir karşılığı var | 301 | Değeri en alakalı yeni sayfaya taşır |
Kısa kural basit: URL’nin gerçek durumunu saklamayın. Yanıt kodu, sayfanın ne olduğunu dürüst biçimde anlatmalıdır.
Düzeltme sonrası kontrol listesi ve doğrulama adımları
Bir URL’yi düzeltmek yetmez, düzeltmenin gerçekten çalıştığını da kanıtlamanız gerekir. Çünkü aynı şablon açık kaldıysa hata birkaç gün içinde yeniden çıkar. Özellikle CMS, önbellek ve CDN kullanan sitelerde eski yanıtların devam etmesi sık görülür.
Önce şu kontrol listesini bitirin:
- Sitemap’ten artık yaşamayan URL’leri çıkarın.
- Site içi linklerde eski adreslere verilen bağlantıları güncelleyin.
- 301 zinciri ve alakasız yönlendirme olup olmadığını test edin.
- “Bulunamadı”, “ürün yok”, “sonuç bulunamadı” mesajı veren şablonların HTTP yanıtını ölçün.
- Boş kategori, etiket ve filtre sayfalarının gerçekten gerekli olup olmadığını karar verin.
- Canonical, noindex ve yanıt kodu arasında çelişki bırakmayın.
Sonra doğrulamaya geçin. Süreç kısa ama disiplin ister:
- Düzeltilen URL’leri canlı test edin ve gerçek yanıt kodunu görün.
- Search Console’da ilgili örnek URL’leri yeniden denetleyin.
- “Düzeltmeyi doğrula” isteğini gönderin.
- Birkaç gün sonra raporu tekrar açın ve yeni örnekler aynı şablondan mı geliyor diye kontrol edin.
Genelde yeniden tarama 1 ila 2 hafta içinde görünür. Yine de büyük sitelerde bu süre uzayabilir. Bu yüzden tekil URL yerine şablon mantığıyla düşünün. Örneğin ürün şablonu, arama şablonu ve filtre şablonu ayrı ayrı test edilmelidir. Log kayıtlarında Googlebot’un yeni durumu gerçekten gördüğünü kontrol etmek de iyi bir adımdır.
Büyük ekiplerde iş akışını kalıcı hale getirmek gerekir. İçerik ekibi boş etiket açmamalı, geliştirici ekip hata sayfasını 200 ile sunmamalı, SEO ekibi de sitemap ve yönlendirme kurallarını düzenli gözden geçirmelidir. Süreci standartlaştırmak isteyen ekipler için kurumsal düzeyde SEO çalışmaları yaklaşımı bu yüzden önemlidir.
Sonuç
Soft 404 sorunu çoğu zaman tek bir teknik hatadan değil, yanlış eşleşen sinyallerden çıkar. Sayfa bir şey söyler, sunucu başka bir şey döner, Google da buna güvenmez.
Çözüm, URL’leri tek tek susturmak değil, her sayfanın amacını netleştirmektir. Gerçekten yoksa 404 ya da 410 dönün, geçerli bir alternatifi varsa 301 kullanın, sayfa faydalıysa 200’ü koruyun.
Doğru yanıt kodu, temiz sitemap ve yerinde yönlendirme bir araya geldiğinde Search Console raporu da sakinleşir, tarama da daha tutarlı hale gelir.