Soft 404 olarak algılanan sayfalarda doğru sinyal nasıl verilir?

Soft 404 Nedir ve 200 OK Dönen Sayfa Neden Dizine Giremiyor?

Soft 404, sunucunun başarılı bir yanıt vermesine rağmen arama motorunun sayfayı fiilen boş, hata benzeri ya da sorgu niyetini karşılamayan bir belge olarak değerlendirmesidir. Google’ın 18 Aralık 2025’te güncellediği HTTP durum kodları dokümanı, 2xx yanıtlarının içeriği yalnızca işleme hattına taşıdığını; indekslemeyi garanti etmediğini açıkça belirtir. Bu nedenle 200 OK gören bir ekip, yine de Page Indexing raporunda soft 404 uyarısıyla karşılaşabilir.

Pratikte sorun çoğu zaman ‘sayfa var mı?’ sorusundan değil, ‘sayfa yeterince anlamlı mı?’ sorusundan çıkar. Özellikle kategori, filtre, şehir ve zayıf ürün URL’lerinde header, menü, footer ve benzer ürün blokları ana içeriği bastırdığında Googlebot sayfanın asıl değerini zayıf görür. Başlangıç çerçevesi için sözlük sayfasında soft 404 teriminin tam tanımı yararlıdır; asıl fark ise bu sınıflandırmanın sadece teknik değil, içerik kalitesi ve niyet uyumu problemi de olmasıdır.

İçerikli Sayfayı Soft 404 Yapan 5 Teknik Neden

İçerik taşıyan bir URL’nin soft 404 görünmesi genelde tek bir bug’dan değil, üst üste binen zayıf sinyallerden kaynaklanır. Google, kullanıcıya görünen son arayüzü değil, kendi tarama ve işleme sürecinde eline geçen belgeyi değerlendirir. Bu yüzden ekiplerin ‘ekranda metin var’ diyerek geçtiği sayfalar, Googlebot tarafında ince, eksik ya da tutarsız bir çıktı üretebilir.

2026’da en sık karşılaşılan desen, şablon ağırlığı yüksek sayfalarda JavaScript ile sonradan doldurulan ana içeriğin yeterince teslim edilememesidir. Buna yanlış canonical, eski noindex kalıntısı veya var olmayan URL’leri ana sayfaya toplu yönlendirme de eklenince arama motoru net bir durum okuyamaz. Sonuçta sayfa gerçek 404 değildir, ama kalite ve durum sinyali de ikna edici değildir.

• Thin content ve şablon baskısı: Ortak bileşenler ana metinden belirgin biçimde fazlaysa sayfa zayıf görünür.
• JavaScript render sorunu: Ham HTML ile işlenen DOM arasında büyük fark varsa Google eksik içerik görebilir.
• Yanlış canonical: Asıl URL başka sayfayı işaret ettiğinde mevcut belge kendi hakkını kaybeder.
• Noindex veya header karışıklığı: Meta robots ile X-Robots-Tag çelişirse indeksleme sinyali bulanıklaşır.
• Ana sayfaya toplu yönlendirme: Artık yaşamayan URL’leri topluca ana sayfaya taşımak soft 404 tuzağı üretir.

Teşhis Protokolü: curl, URL Inspection ve DOM Karşılaştırması

Soft 404 teşhisinde en güvenilir akış, aynı URL için dört veriyi yan yana okumaktır: curl -I çıktısı, canlı URL testi, render edilmiş DOM ve sunucu logu. Denetimlerde en hızlı sonuç veren yöntem budur; çünkü sorun çoğu zaman bu dört katmandan yalnızca birinde değil, aralarındaki uyumsuzlukta görünür. Kullanıcıya dolu görünen ama Googlebot’a şablon dönen sayfalar özellikle bu karşılaştırmada hemen ayrışır.

Sık gördüğümüz senaryo şudur: tarayıcıda ürün açıklaması ve SSS alanı vardır, ancak ham HTML yalnızca başlık, breadcrumb ve çok kısa bir stok mesajı taşır. JavaScript geç çalıştığı için Google’ın ilk işlediği belge zayıf kalır. Search Console Page Indexing raporu açıklaması, böyle durumlarda canlı URL testi yapmayı ve test edilen sayfanın ekran görüntüsüyle işlenen HTML’yi incelemeyi özellikle önerir; soft 404 maddesinde de sayfaya daha fazla bilgi eklenmesi gerektiğini açıkça söyler.

Ham yanıtı doğrularken önce status code, Location, cache davranışı, canonical ve X-Robots-Tag kontrol edilir. Sonra canlı URL testinde seçilen canonical, robots erişimi ve işlenen HTML okunur. Eğer robots.txt yanlışlıkla kritik kaynakları engelliyor, canonical başka URL’ye gidiyor veya render sonrası ana içerik eksik kalıyorsa, sorun 200 kodunun kendisi değil teslim edilen sinyal paketidir. Sunucu logu da gerçek Googlebot’un aynı yanıtı alıp almadığını doğrulayan son kontrol katmanıdır.

• curl katmanı: 200, 301, 404 veya 410 gerçekten ne dönüyor, önce bunu netleştirin.
• Inspection katmanı: Canlı URL testinde canonical, erişim ve render çıktısını birlikte okuyun.
• Kaynak katmanı: Ham HTML ile işlenen DOM arasında içerik farkı varsa render zincirini düzeltin.
• Log katmanı: Googlebot’un farklı varyanta, cache’e veya yönlendirme yoluna düşmediğinden emin olun.

Doğru Sinyali Vermek: HTTP Kodu Seçimi ve İçerik Güçlendirme

Sayfa gerçekten faydalıysa çözüm 404’e kaçmak değil, 200 OK altında daha net bir belge teslim etmektir. Ana içeriği yukarı taşımak, sorgu niyetine doğrudan cevap veren özgün metin eklemek, şablon tekrarını azaltmak ve mümkünse SSR ya da güvenilir prerender kullanmak soft 404 riskini ciddi biçimde düşürür. Google’ın 2025 sonu güncellemesinin özü de budur: 2xx yalnızca kapıyı açar, içerik o kapıdan geçecek kadar güçlü olmalıdır.

Sayfa artık yaşamıyorsa veya eşdeğer bir hedefe taşındıysa durum kodunu dürüst seçmek gerekir. IANA HTTP Status Code Registry 15 Eylül 2025 güncellemesinde 404 ve 410 kayıtlarını yine RFC 9110’a bağlar. RFC 9110 ise 404’ün mevcut temsil bulunamadığını, 410’un ise kaynağın artık kalıcı olarak kaldırıldığını anlattığını söyler. Yani tükenen ama yerine eşdeğer kategori önerisi olan ürün için ilgili kategoriye 301 düşünülebilir; karşılığı kalmayan kampanya sayfasında 410 daha nettir.

En sık yapılan hata, var olmayan ya da zayıf sayfaları ana sayfaya toplu yönlendirmektir. Bu yaklaşım kullanıcı için de arama motoru için de bağlamı bozar. Google’ın HTTP durum kodları dokümanı 3xx sonrası asıl hedef içeriğinin işlendiğini belirtir; alakasız ana sayfa hedefi verildiğinde sorun çözülmez, yalnızca biçim değiştirir. Doğru yaklaşım, yaşayan URL’de içeriği kuvvetlendirmek; taşınan URL’de en alakalı yeni hedefe tek adımlı 301 vermek; tamamen kalkmış URL’de ise 404 veya 410 kullanmaktır.

• 200 OK: Sayfa niyetle uyumlu, özgün ve yeterli ana içerik taşıyorsa.
• 301: İçerik gerçekten yeni ve ilgili bir URL’ye taşındıysa.
• 404: Sayfanın karşılığı yoksa ve kalıcılık konusunda net değilseniz.
• 410: İçerik bilinçli ve kalıcı olarak kaldırıldıysa.
• Toplu ana sayfa yönlendirmesi: Teknik olarak kolay, SEO açısından ise çoğu durumda zayıf sinyaldir.

Search Console’da Validate Fix ve SEOYEN ile Toplu Teşhis

Düzeltmeden sonra iş bitmez; sinyalin Google tarafından yeniden okunması gerekir. Page Indexing raporu, Validate Fix sürecinin tipik olarak iki haftaya kadar sürebildiğini ve bazı vakalarda daha uzun sürdüğünü belirtir. Önce birkaç örnek URL kontrol edilir, sonra bilinen sorunlu küme sırayla yeniden taranır. Bu yüzden tek bir URL’yi düzeltip doğrulama başlatmak yerine aynı kalıbı taşıyan tüm benzer sayfaları birlikte temizlemek daha güvenlidir.

URL sayısı yükseldiğinde manuel kontrol pahalı hale gelir. Ahrefs, SEMrush, SEOptimer, Moz ve SE Ranking benzer denetimleri farklı modüllerle yürütür; SEOYEN ise site sağlığı aracı, Türkçe arayüzü, yerel Türkçe desteği ve tek platform yaklaşımıyla bu kümeleri daha yönetilebilir hale getirir. Özellikle ekibiniz teknik SEO ile içerik operasyonunu aynı panelde görmek istiyorsa, güncel paket ayrıntılarını fiyatlandırma sayfası üzerinden kontrol etmek daha sağlıklı olur.

Doğrulama sürecinde bakmanız gereken tek metrik hata sayısı değildir. Soft 404’dan çıkan URL’lerin gerçekten indekslenip hedef sorgularda geri dönüp dönmediğini izlemek gerekir. Bunun için Page Indexing raporunu, canlı URL testini ve sıralama takibi görünümünü birlikte değerlendirmek anlamlıdır. Böylece teknik düzeltmeyi yalnızca rapor temizliği olarak değil, görünürlük ve trafik etkisi olarak da okuyabilirsiniz.

Adım Adım: Soft 404 İşaretlenen Sayfada Doğru Sinyal Verme

Aşağıdaki akış, içerik barındırmasına rağmen soft 404 görünen URL’lerde en az sürtünmeyle ilerler. Mantık basittir: önce Google’ın gerçekten ne gördüğünü netleştirir, sonra içerik ve durum kodunu dürüst biçimde hizalarsınız.

1. Search Console’da Soft 404 raporunu filtreleyin. Etkilenen URL’leri aynı şablon veya aynı sayfa tipi altında gruplayın; tek tek değil, desen olarak bakın.
2. URL Inspection ile mevcut durumu kaydedin. Canlı URL testinde indeksleme durumu, seçilen canonical ve işlenen görünümü not edin.
3. Ham HTTP yanıtını doğrulayın. curl -I ile status code, Location, cache ve X-Robots-Tag değerlerini kontrol edin.
4. Ham HTML ile işlenen DOM’u karşılaştırın. Tarayıcıda gördüğünüz ana içerik gerçekten ilk belgede var mı, bunu netleştirin.
5. Tetikleyiciyi ayırın. Thin content, JS render, canonical, noindex veya yanlış yönlendirme hangisi baskınsa onu işaretleyin.
6. Doğru teknik düzeltmeyi uygulayın. Ya içeriği güçlendirin ve teslimatı düzeltin ya da dürüstçe 301, 404 veya 410’a geçin.
7. Validate Fix başlatın ve sonucu izleyin. Yeniden tarama tamamlandığında yalnızca hata düşüşünü değil, indekslenme ve sıralama geri dönüşünü de kontrol edin.

Bu akışı ekip içinde standartlaştırmak, aynı sorunun yeni URL kümelerinde tekrarlanmasını da azaltır. URL Inspection adımlarını görsel olarak izlemek isteyen ekipler için Google Search Central’ın walkthrough videoları faydalı bir destek materyalidir; ancak karar yine her zaman ham yanıt, render edilmiş belge ve niyet uyumuna göre verilmelidir.

Sıkça Sorulan Sorular