Bir ürün sayfasını ziyaret ediyorsunuz. Sayfa açılıyor, ama içerik yok. Yalnızca "Bu ürün artık mevcut değil" ya da "Aradığınız sayfa bulunamadı" yazan bir şablon görüyorsunuz. Tarayıcı çubuğundaki URL geçerli, sayfa yüklendi, hiçbir hata mesajı yok. Arka planda sunucu Google'a HTTP 200 kodu göndermiştir: "Her şey yolunda, içerik burada." Ama içerik yoktur.
Bu durum soft 404 olarak tanımlanır. Gerçek bir 404, sunucunun "bu sayfa mevcut değil" anlamında 404 yanıt kodu göndermesidir; Google bu kodu alır, sayfayı indekse almaz ya da indeksten çıkarır. Soft 404'te ise sunucu 200 göndermektedir, teknik açıdan başarılı bir yanıt. Google sayfayı tarar, içeriği inceler ve anlamlı bir şey bulamazsa sayfayı 404'e benzer biçimde değerlendirmeye başlar. Protokol başarılı, içerik başarısız. Bu çelişki tespit sürecini zorlaştıran şeydir.
Standart tarama araçları yanıt kodlarına göre hata listesi üretir. 404, 500, yönlendirme hataları bu listede belirir. Ama 200 kodu dönen bir sayfa araç açısından sorunsuzdur; içeriğin ne olduğuna bakmaz. Dolayısıyla soft 404'ler rutin teknik SEO analizinin standart hata raporlarına düşmez. Görünmezlikleri birikmeye devam etmelerine zemin hazırlar.
200 yanıt kodu ile gerçekten içerik sunmak birbirinden farklı sinyaller taşır
HTTP protokolünde 200 yanıt kodu "istek başarıyla işlendi" anlamına gelir. Sunucu isteği aldı, yanıtını üretti ve gönderdi. Ama bu yanıtın içinde ne olduğu protokol düzeyinde kontrol edilmez. Sunucu boş bir HTML sayfası da, "ürün bulunamadı" şablonu da, zengin içerikli bir ürün sayfası da 200 koduyla gönderebilir.
Google bu yanıtı aldığında hem kodu hem de içeriği işler. Kod 200 olsa bile içerik anlamlı değilse Google bunu fark eder. Özellikle şu örüntüler soft 404 sinyali olarak okunur: sayfa yalnızca bir hata mesajı ya da "içerik bulunamadı" bildirimi barındırıyorsa, sayfadaki metin miktarı belirli bir eşiğin çok altındaysa ya da içerik siteye özgü değil de şablonun sabit metinlerinden ibaret kalıyorsa. Google bu sayfaları "crawler tarafından bulunan ama içerik açısından sorunlu" kategorisinde işaretler.
Bu değerlendirme sunucu tarafında görünmez. Sunucu logları 200 döndürmeye devam eder. Tarama araçları hata bayrağı dikmez. Yalnızca Google'ın içerik analizi ve Google Search Console raporları bu durumu yüzeye çıkarır. İki sinyal kaynağını (yanıt kodu ve içerik kalitesi) ayrı ayrı değerlendiren bir denetim yaklaşımı olmadan soft 404'ler arka planda büyümeye devam eder.
Google soft 404'ü hangi koşullarda tespit eder ve nasıl değerlendirir
Google bir sayfayı taradığında içeriği işler, metni ayrıştırır ve sayfanın ne hakkında olduğunu anlamaya çalışır. Bu süreçte sayfa az miktarda metin barındırıyorsa ya da mevcut metin hata bildirimlerine benziyorsa, Google sayfanın gerçek bir içerik sunmadığı değerlendirmesine ulaşır. Bu değerlendirme otomatik bir sinyal üretir: "soft 404".
Google'ın bu tanımayı yaparken kullandığı kesin eşikler kamuoyuyla paylaşılmamıştır. Ama pratikte şu örüntü güvenilir biçimde gözlemlenmektedir: e-ticaret sitelerinde stokta olmayan ürün sayfaları, sayfa şablonu korunmuş ama ürün bilgileri boşaltılmış durumdaysa Google bu sayfaları çoğunlukla soft 404 olarak işaretler. Benzer şekilde, kullanıcıya "0 sonuç" döndüren arama sayfaları da bu kategoriye girer, URL parametreli bir arama yapılmış, sayfa 200 kodu vermiş ama içerikte yalnızca "sonuç bulunamadı" metni vardır.
Google soft 404 olarak değerlendirdiği sayfaları indeksten çıkarabilir ya da indekslemeyi durdurabilir. Bu karar hızlı gerçekleşmez; önce düşük öncelikli olarak işaretlenir, tarama sıklığı azalır, ardından kapsam raporunda "hariç tutulan" kategorisine düşer. Bu süreçte sayfa sıralamada görünmüyor ama sitemap'te duruyor, tarama bütçesinden pay alıyor ve indeks kalitesini düşürüyor olabilir. Müdahale yapılmadan bırakılırsa etki sessizce birikir.
GSC'deki soft 404 uyarıları sorunun yalnızca görünen kısmıdır
Google Search Console'un "Kapsam" (Coverage) raporunda "Hariç tutulan" sekmesi altında "Soft 404" başlığı bulunur. Bu başlık altında Google'ın soft 404 olarak tanımladığı URL'lerin listesine ulaşılabilir. Her URL için "URL'yi denetle" seçeneği kullanılarak sayfanın son tarama tarihini, son taramada görülen içeriği ve Google'ın değerlendirmesini görmek mümkündür.
Bu liste önemli bir başlangıç noktasıdır ama eksiksiz değildir. GSC yalnızca Google'ın zaten fark ettiği ve raporladığı soft 404'leri gösterir. Google henüz taramadığı ya da taradığı halde henüz soft 404 olarak sınıflandırmadığı sayfaları bu raporda listelemez. Özellikle büyük sitelerde Google'ın tüm URL'leri sık sık taraması mümkün olmadığından, soft 404 olması gereken ama GSC'de görünmeyen yüzlerce URL bulunabilir. GSC raporu temiz görünse de sorun var olabilir.
GSC raporunun bir diğer sınırı segment eksikliğidir. Rapor URL'leri listeler ama bu URL'lerin hangi şablondan ya da hangi içerik kategorisinden geldiğini otomatik olarak gruplamaz. 200 URL soft 404 olarak listelendiğinde bunların 180'inin aynı stok dışı ürün şablonundan geldiğini görmek için URL yapısını kendiniz analiz etmeniz gerekir. Bu gruplamayı yapmadan önceliklendirme ve müdahale planı kurulamaz.
Hangi sayfa türleri soft 404 üretmeye en yatkındır
Dinamik içerik barındıran her site türü soft 404 riskiyle karşılaşır, ama bazı sayfa tipleri bu riski çok daha yoğun taşır.
E-ticaret sitelerinde stok dışı ürün sayfaları en yaygın kaynaktır. Bir ürün satışa kapatıldığında sayfa genellikle kaldırılmaz; şablon korunur ama ürün bilgileri boşaltılır ya da yalnızca "stok dışı" mesajı kalır. Sayfa teknik olarak çalışıyor, URL geçerli, sunucu 200 döndürüyor. Google içeriğe baktığında anlam taşıyan bir şey bulamaz. Sezonluk ürünlerin yoğun olduğu sitelerde bu durum yüzlerce URL üretebilir.
Site içi arama sonuç sayfaları ikinci büyük kaynaktır. Kullanıcı bir arama yapıyor, 0 sonuç dönüyor, sayfa "aramanızla eşleşen içerik bulunamadı" mesajı gösteriyor. URL parametreli bu sayfa indekslenebilir durumdaysa Google tarafından taranır. İçerik açısından boş olan bu sayfa soft 404 olarak değerlendirilir. Benzer mantıkla, sıfır ürün döndüren filtrelenmiş kategori sayfaları da bu kategoriye girer: /elektronik/?renk=sari&beden=XXL kombinasyonu hiçbir ürünle eşleşmiyorsa dönen sayfa içerik taşımaz.
Kullanıcı profil ve hesap sayfaları da risk taşır. Silinmiş ya da askıya alınmış bir kullanıcı profilinin URL'si hâlâ 200 kodu veriyorsa, Google bu sayfayı taradığında içerik yerine boş şablon ya da "bu kullanıcı mevcut değil" mesajıyla karşılaşır. Forum siteleri, topluluk platformları ve UGC (kullanıcı içeriği) barındıran siteler bu konuda özellikle dikkatli olmalıdır. Taranabilirlik sorunları arasında en hızlı birikenlerin başında kullanıcı kaynaklı boş sayfalar gelir.
Soft 404'leri tespit etmek için içerik sinyali ve yanıt kodu birlikte okunmalıdır
Yanıt kodu kontrolü tek başına soft 404'ü yakalayamaz. Bunun yerine iki veri kaynağını birleştiren bir yaklaşım gerekir: sunucunun ne kodu gönderdiği ve sayfanın ne içerik barındırdığı.
GSC'nin Kapsam raporu ilk tara noktasıdır. "Soft 404" başlığının altındaki URL listesi indirilir. Her URL için URL Denetleme aracıyla son tarama snapshot'ına bakılır; Google'ın o anda sayfada ne gördüğü render edilmiş HTML olarak sunar. Bu görünüm içeriğin ne durumda olduğunu doğrular ya da çürütür.
GSC dışında kalan potansiyel soft 404'ler için ise sayfa tipine göre hedefli inceleme yapılır. Stok dışı ürün sayfaları için ürün kataloğuyla URL listesi karşılaştırılır; stokta olmayan ürünlerin URL'leri ayrı bir listeye alınır. Arama sonuç sayfaları için robots.txt ya da canonical ile bu URL'lerin taranıp taranmadığı kontrol edilir. Screaming Frog ile yapılan taramada Custom Extraction modülü kullanılarak belirli bir CSS seçicisindeki metin miktarı sayılabilir; ürün başlığı alanı boş olan URL'ler otomatik olarak listelenebilir.
Log analizi bu tespiti derinleştirir. Googlebot'un sık ziyaret etmesine karşın içerik güncellemesi görülmeyen URL'ler (yani bot defalarca geliyor ama sayfa değişmiyor) soft 404 adayı olabilir. Log verisi bu örüntüyü görünür kılar: aynı URL'ye kısa aralıklarla gelen Googlebot istekleri ve her seferinde aynı boş içerikle karşılaşması, sayfanın crawl bütçesini verimsiz kullandığının göstergesidir.
Soft 404 sorununu çözmek yanıt kodunu değiştirmekten daha fazlasını gerektirir
Soft 404'e verilen ilk tepki çoğunlukla yanıt kodunu 404'e çevirmektir. Bu bazı durumlarda doğru karardır; ama her zaman değil. Hangi müdahalenin uygun olduğu sayfanın neden soft 404 ürettiğine bağlıdır.
Sayfanın kalıcı olarak anlamsız kaldığı durumlarda (silinen içerik, kapatılan hesap, kaldırılan ürün) gerçek 404 ya da 410 (kalıcı kaldırma) kodu göndermek doğru karardır. Bu kod değişikliği Google'a açık bir sinyal verir: sayfa artık mevcut değil, indeksten çıkar. Eğer bu URL'ye değerli bir harici backlink geliyorsa, içeriği farklı ama alakalı bir sayfaya 301 ile yönlendirmek link değerini kurtarır.
Ama bazı soft 404 durumlarında sayfa geçici olarak boş kalmaktadır. Stok dışı ürün sayfası ilerleyen dönemde yeniden aktif hale gelebilir; bu sayfayı 404'e çevirmek ve sonra geri getirmek, Google'ın yeniden indekslemesi için zaman kaybı yaratır. Bu senaryoda ürün geçici olarak devre dışıysa canonical ile ana kategori sayfasına işaret etmek, sayfanın indekste kalmasını sağlarken boş içerik sorununu kısmen yönetir. Sayfayı zenginleştirmek de bir seçenektir: stok dışı bile olsa benzer ürünleri gösteren, kullanıcıya alternatif sunan bir içerik eklemek sayfayı anlamlı hale getirir ve soft 404 değerlendirmesini ortadan kaldırabilir.
Sıfır sonuç dönen arama sayfaları için ise tercih edilen yöntem bu URL'lerin taranmasını engellemektir. robots.txt ile arama parametreli URL'lerin tamamını Googlebot'tan gizlemek ya da bu sayfaların meta robotlarına noindex eklemek, boş sayfaların bütçe tüketmesini önler. Bu yaklaşım içerik üretmeden sorunu çözer; kaynak yatırımı gerektirmez.
Soft 404 sorununu diğer sayfa hatalarından ayıran temel özellik, sunucu tarafında herhangi bir hata sinyali üretmemesidir. Standart izleme araçları sessiz kalır. Etki yavaş ve kümülatif çalışır: crawl bütçesi boş sayfalara harcanır, indeks gereksiz URL'lerle şişer, sıralama potansiyeli olan sayfalar bu kaynaktan pay alamaz. Tespiti ayrı bir süreç olarak kurmak (yanıt kodu raporlarına değil, içerik ve GSC sinyal kombinasyonuna dayanmak) bu birikimi görünür kılmanın tek yoludur. Görünür olduktan sonra ise her URL tipi için uygun müdahaleyi seçmek, problemi hem sunucu hem içerik hem de tarama katmanında temizler.