200 OK Yanıtı

TL;DR — 200 OK yanıtı, sunucunun “here’s the page you asked for, everything’s fine.” (çeviri) “İstediğiniz sayfa burada; her şey yolunda.” demesidir. Google’da görünmesini istediğiniz her sayfada görmek istediğiniz sessiz başarı kodudur. Ancak 200 tek başına sayfanın dizine alınacağını garanti etmez; Google içeriğin dizine alınmaya değer olup olmadığına yine bakar. Gerçekte bozuk veya boş olan bir sayfada 200 dönmesi yeşil ışık değil, hatadır.

200 OK ne anlama gelir

Tarayıcınız veya Googlebot bir sunucudan sayfa istediğinde, sunucu başka bir şey göndermeden önce üç haneli bir durum koduyla yanıt verir. 200 OK, “all good” (çeviri) “her şey yolunda” kodudur: sunucu istediğiniz şeyi bulur ve genellikle sayfanın içeriğiyle birlikte geri verir. (Teknik olarak spesifikasyon bazı durumlarda gövdesi boş bir 200’e izin verir; fakat insanların okuyacağı bir sayfa için her zaman gerçek bir gövde istersiniz.) Bu, genellikle fark etmediğiniz koddur; çünkü hiçbir şeyin yanlış gitmediğini söyler. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox, Ahrefs HTTP durum kodları rehberinde bunu üç kelimeyle özetler: “200 OK – All good. Everything is successful.” (çeviri) “200 OK — Her şey yolunda. Her şey başarılı.”

Sitenizde aramada bulunmasını istediğiniz sayfaların döndürmesi gereken kod tam olarak 200’dür.

200 neden hikâyenin tamamı değildir

“200 ne anlama gelir?” sayfalarının çoğunun atladığı nokta şudur: 200, sayfanızın dizine eklenmek üzere değerlendirilmesini sağlar; dizine girmesini garanti etmez. Bunlar birbirinden çok farklı iki şeydir.

200’ü kapıdan içeri sokan bir bilet olarak düşünün. Kapıdan geçtikten sonra Google, içeriği tutmaya değer bulup bulmadığına karar verir: kalite yüksek mi, başka bir sayfanın yakın kopyası mı, zayıf veya boş mu, Google’a dışarıda kalmasını söyleyen bir noindex etiketi var mı? Bunlardan herhangi biri, tamamen sağlıklı görünen 200 yanıtlı bir sayfanın yine de dizine alınmamasına yol açabilir.

Bu nedenle sayfa 200 döndürdüğü hâlde Google’da görünmüyorsa sorun durum kodu değil, içerik veya kurulumdur.

Tuzak: Gerçekte “not found” (çeviri) “bulunamadı” olan 200

En sinsi hata, içeriği “this doesn’t exist.” (çeviri) “bu mevcut değil” derken 200 döndüren sayfadır. Stokta olmayan bir ürünün boş sayfasını, hâlâ boş bir şablon yükleyen silinmiş makaleyi veya sıfır sonuçlu arama sayfasını düşünün: sunucu neşeli bir 200 gönderir, ama ortada gerçek bir şey yoktur.

Google kodun ötesine, gerçek içeriğe bakar; sayfanın boş veya hatalı olduğuna karar verir ve Search Console’da soft 404 olarak etiketler; gerçek “bulunamadı” sayfası gibi davranır. Bu konu soft-404-errors makalesinde ayrıntılıdır; kısa sürüm şu: sayfa gerçekten yoksa 200 değil 404 veya 410 döndürmelidir.

Hatırlanacak tek kural

Google’da olmasını istediğiniz sayfa gerçek içerikle birlikte 200 döndürmelidir. Sayfa yoksa 404 veya 410 kullanın. Taşındıysa 301 ile yönlendirin. Başka bir sayfanın kopyasıysa canonical etiketi kullanın. Google’ın tam ifadesini, 200 ile 204 ayrımını ve Googlebot’un gerçekte ne aldığını nasıl kontrol edeceğinizi öğrenmek için İleri Düzey sekmesine geçin.

TL;DR — 200 OK, standart 2xx başarı kodudur (RFC 9110 §15.3.1): sunucu isteği yerine getirir ve GET/HEAD için gövde, kaynağın bir gösterimidir. Varsayılan olarak sezgisel biçimde önbelleklenebilir. SEO açısından gerekli ama yeterli değildir — Google’ın kendi dokümanı “may index the content, but that’s not guaranteed,” (çeviri) “içeriği dizine ekleyebileceğini, ancak bunun garanti edilmediğini” söyler; kalite, yinelenen/zayıf içerik ve noindex 200’ün üzerine ayrıca değerlendirilir. Klasik başarısızlık soft 404’tür: hata veya boş içeriği 200 ile sarmalamak; Google bunu içerik katmanında algılar ve koddan bağımsız soft 404 bildirir. 200’ü (beklenen gövde), 204’ten (boş gövde, sayfalarda soft 404 gibi ele alınır) ve 304’ten (önbellek sinyali, dizine ekleme kararı değil) ayırın. Googlebot’un ne aldığını doğrulayın; cloaking, bot engelleme, coğrafi kurallar ve CDN/WAF yapılandırması tarayıcınızdan farklı bir kod sunabilir.

Spesifikasyonda 200 ne anlama gelir

Güncel yetkili kaynak RFC 9110’dur (HTTP Semantics) ve §15.3.1 açıkça şöyle der: “The 200 (OK) status code indicates that the request has succeeded.” (çeviri) “200 (OK) durum kodu, isteğin başarıyla tamamlandığını belirtir.” Gövdenin içeriği, istek yöntemine bağlıdır. Sayfalar açısından önemli yöntemlerde — GET ve HEAD — içerik, hedef kaynağın bir temsilidir. RFC ayrıca bir ayrım koyar: CONNECT yanıtları dışında, ileti çerçevelemesi sıfır uzunluğu açıkça belirtmiyorsa 200 yanıtının içerik taşıması beklenir. Dolayısıyla “200 yanıtının her zaman gövdesi vardır” ifadesi mutlak bir kural değil, kısa bir anlatımdır. Uygulamada dizine eklenmesini istediğiniz bir sayfanın hedefi boş değil, gerçek bir gövdedir. Bir 200, önbellek denetimi aksini söylemedikçe varsayılan olarak “sezgisel biçimde önbelleklenebilir”; bu nedenle sık taranan sayfalarda ETag ve Last-Modified gibi doğrulayıcı başlıklar önemlidir. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Teknik olarak 200 yalnızca sayfalar için değildir. RFC, “success” (çeviri) “başarı”nın yöntem başına ne anlama geldiğini şöyle sıralar:

GET dışındaki yöntemlerde çoğu zaman 200 görmezsiniz. MDN, başarılı PUT veya DELETE isteklerinin “often do not result in a 200 OK response,” (çeviri) “çoğu zaman 200 OK yanıtıyla sonuçlanmadığını” ve 201 Created ya da 204 No Content yanıtlarının daha yaygın olduğunu belirtir. Bunlar sayfa URL’lerinin SEO’su açısından önemli değildir; akılda tutulması gereken, dizine eklenmesini istediğiniz bir belge için hedefin gerçek gövdeli bir 200 yanıtı olduğudur.

Dizin ekleme için gerekli, ama yeterli değil

Bu, doğru anlaşılması gereken en önemli noktadır ve rakip sözlük sayfalarının çoğu burada düpedüz yanılır. “200 means the page gets indexed.” (çeviri) “200, sayfanın dizine alındığı anlamına gelir.” derler. Google’ın kendi belgesi aksini söyler: “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (çeviri) “Google’ın aldığı her şeyi ürüne özgü sonraki işleme aşamasına aktarır. Google Search için sonraki sistem dizine ekleme hattıdır. Dizinleme sistemleri içeriği dizine alabilir, ancak bunu garanti etmez.”

Dolayısıyla 200, sayfanın arama sonuçlarındaki kaderi hakkında değil, HTTP yanıtı hakkında bir sözleşmedir. 200’den sonra Google bağımsız olarak şunları değerlendirir:

• Kalite — zayıf, düşük değerli veya otomatik üretilmiş sayfalar dizine alınmayabilir.
• Yinelenme — güçlü bir URL’nin yakın kopyası, kendi başına dizine alınmak yerine o URL altında birleştirilebilir (canonical etiketinin kontrol ettiği şey budur).
• Yönergeler — meta etiketteki noindex veya X-Robots-Tag üstbilgisindeki yönerge, kusursuz 200 olsa bile sayfayı dizin dışında tutar.

Patrick’in Ahrefs rehberi aile düzeyinde aynı ayrımı yapar: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (çeviri) “Başarı sınıfındaki kodların çoğu sayfaların dizine eklenmesine izin verir. Ancak içeriksiz yanıtlar soft hata olarak ele alınır ve dizine eklenmez.” 200 bir sayfayı dizinlemeye uygun kılar; onu dizine alınmış yapmaz.

Soft 404 tuzağı

“200 hikâyenin tamamı değildir” sözünün en açık örneği soft 404’tür. Google’ın durum kodları belgesi mekanizmayı şöyle açıklar: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (çeviri) “İçerik Google Search açısından bir hataya, boş sayfaya veya hata mesajına işaret ediyorsa Search Console bir soft 404 hatası gösterir.” Buradaki önemli nokta, sınıflandırmanın HTTP koduna değil oluşturulan içeriğe dayanmasıdır. Google’ın dizine ekleme hattı 200’ün ötesine bakar; sayfadaki içerik “bulunamadı” izlenimi veriyorsa onu gerçek bir 404 gibi sınıflandırıp raporlar.

Kontrol edilmesi gereken durumlar şunlardır: sayfası artık boş bir şablon yükleyen üretimden kalkmış ürün, hâlâ 200 kabuğu döndüren silinmiş makale, sıfır öğeli filtrelenmiş kategori veya “nothing here” (çeviri) “burada hiçbir şey yok” mesajlı arama sonucu. Her biri teknik olarak doğru bir 200 döndürürken hem kullanıcılara hem Google’a görülecek bir şey olmadığını söyler.

Bu sitede tespit mekanizmaları ve düzeltmeler için özel bir soft-404-errors makalesi vardır; burada tekrarlamayacağım. 200 tartışmasının özeti basittir: gerçekten yok olmuş bir sayfada 200 döndürmek soft 404 için zemin hazırlar. Çözüm, kodu gerçeğe uydurmaktır.

İlgili tuzak: taşıma başarısı uygulama başarısı değildir

API ve izleme çevrelerinde sık çıktığı için sınırlı bir parantez açalım: HTTP katmanı ile uygulama katmanı uyuşmayabilir. Bir API uç noktası gövdesinde JSON hata nesnesiyle 200 gönderebilir; bir sayfa, arka uç bağımlılığı sessizce çökmüş ve gerçek içerik yerine bozuk bir bölüm oluşturmuşken 200 gönderebilir. Durum satırı “delivered fine” (çeviri) “başarıyla teslim edildi” der — iddiası bundan ibarettir. Yükün gerçekten doğru olup olmadığı ayrı bir sorudur ve durum kodu yanıtlamaz. Uygulamacılar API’nin hatayı 200 içine sarmalamak yerine 200 dışı kodla mı bildirmesi gerektiği konusunda ayrılır; bu, her ekibin seçtiği bir sözleşmedir, HTTP kuralı değil. Bu sitenin SEO odağında bunun sayfa düzeyindeki karşılığı yukarıdaki soft 404’tür: yalnızca durum satırına güvenmeyin, gövdenin gerçekten ne içerdiğine bakın.

200, 204 ve 304’ü birbirine karıştırmayın

İnsanların karıştırdığı üç kod vardır; yalnızca biri “here’s your page” (çeviri) “işte sayfanız” başarısıdır:

204 gerçek bir başarı kodudur; ancak boş gövdesi tarayıcıya dizine ekleyecek hiçbir şey vermez. Bu nedenle bir sayfa URL’sinde soft 404 sınıfına girer. Bu ayrı bir makalenin konusudur; boş gövde durumunu normal bir 200 ile karıştırmayın. 304 ise aynı ailede bile değildir: koşullu bir isteğe (If-None-Match / If-Modified-Since) istemcinin önbellekteki kopyasının hâlâ güncel olduğunu bildirerek yanıt verir. Gövde taşımaz ve dizine ekleme hakkında hiçbir şey söylemez; 200’ün başka bir biçimi değil, tarama verimliliği mekanizmasıdır. “200 ile 304 aynı şey değil mi?” sorusu, önbellek iyileştirmesiyle başarı yanıtını birbirine karıştırır.

Googlebot’un gerçekten ne aldığını doğrulayın

Rakip makalelerin neredeyse tamamının atladığı bir boşluk var: aynı URL için farklı istek yapanlar farklı kodlar alabilir. Tarayıcınız temiz bir 200 görebilirken Googlebot başka bir yanıt alabilir. Bunun nedeni bazen kasıtlı cloaking’dir (Google’ın Arama Essentials kurallarında spam ihlali); daha sık olarak WAF/bot engelleme kuralları, coğrafi IP hedefleme, CDN uç mantığı veya botlarda hata veren bir A/B testi gibi yapılandırma hatalarıdır.

Bu nedenle “tarayıcımda 200 görüyorum” demek, “Google da 200 görüyor” demenin kanıtı değildir. Doğru tanı, Googlebot’un kendisinin aldığı yanıtı kontrol etmektir:

• GSC URL Inspection — Google’ın getirdiği durum kodunu ve oluşturulan içeriği görmek için Canlı Test’i çalıştırın; kendi makinenizin gördüğünü değil.
• Sunucu/CDN günlükleri — Her kullanıcı aracısının gerçekten aldığı kod için en güçlü kanıtı sağlar.

Terminalinizden yaptığınız düz curl -I yararlıdır, ancak Googlebot’tan farklı uç kurallara çarptırılabilecek başka bir istektir. Sonuçları veri noktası olarak görün; son söz olarak değil.

HTTP durum yanıtlarını nasıl kontrol eder ve izlersiniz

• Tarayıcı DevTools — Network sekmesinde yeniden yükleyin, belge isteğini seçin ve Status sütununu okuyun.
• Komut satırı — Tek isteğin başlıkları için curl -I https://example.com/page, yönlendirme zincirini izlemek için curl -IL kullanın.
• Google Search Console — URL Inspection raporu taranan durumu gösterir ve Canlı Test yapmanızı sağlar.
• Bing Webmaster Tools — URL Inspection aracı Bingbot’un aldığı yanıtı doğrulamanın Bing tarafındaki yoludur. (Bing, Google’ın yaptığı gibi durum kodlarının dizine eklemeyi nasıl etkilediğine dair ayrı bir rehber yayımlamıyor; bu nedenle Bing adına politika uydurmayın.)
• Tarayıcı araçları — Screaming Frog ve Ahrefs Site Audit, tüm sitedeki durum kodlarını toplu olarak gösterir; ücretsiz Ahrefs SEO Toolbar bulunduğunuz sayfanın kodunu gösterir.

“healthy” (çeviri) “Sağlıklı” görünüm şudur: önemli canonical URL’ler gerçek içerikle tutarlı biçimde 200 döndürür; gerçekten kaldırılmış veya taşınmış sayfalar yanıltıcı bir 200 yerine 404/410 ya da 301 döndürür.

Karar tek satırda

Kodu gerçekle eşleştirin. Dizinde olması isteniyor → anlamlı içerikle 200. Kalıcı olarak kaldırıldı → 404 veya 410 (404-not-found bölümüne bakın). Taşındı → 301. Başka bir URL’nin kopyası → 200 dışında bir kodu zorlamak yerine canonical etiketini tercih edilen sürüme yöneltin. 200, bunu gerçekten hak eden sayfalar için yeşil ışıktır; ne daha fazlası ne de daha azı.

AI özet

İleri Düzey sürümün kısa özeti:

• 200 OK standart 2xx başarı kodudur (RFC 9110 §15.3.1): sunucu isteği yerine getirir ve GET/HEAD için gövde kaynağı temsil eder. Varsayılan olarak sezgisel biçimde önbelleklenebilir. RFC, gövdeyi mutlak değil beklenen bir özellik olarak tanımlar; sıfır uzunluklu 200 teknik olarak geçerlidir, ancak dizine eklenmesini istediğiniz sayfanın gerçek bir gövdeye ihtiyacı vardır.
• Dizine ekleme için gerekli, ancak yeterli değildir. Google’ın kendi belgesi, dizin sistemlerinin “may index the content, but that’s not guaranteed.” (çeviri) “içeriği dizine ekleyebileceğini, ancak bunun garanti edilmediğini” söyler. Kalite, yinelenme, zayıf içerik ve noindex, 200’ün üzerine ayrıca değerlendirilir. Rakip sayfaların çoğu “200 = dizine eklendi” diyerek burada yanılır.
• Soft 404 tuzağı: hata veya boş içeriği saran bir 200, içerik katmanında algılanır ve Search Console’da soft 404 olarak bildirilir. Google’ın ifadesiyle, “if the content suggests an error… Search Console will show a soft 404 error.” (çeviri) “İçerik bir hataya işaret ediyorsa Search Console bir soft 404 hatası gösterir.” Gerçekten kaldırılmış bir sayfada 200 kullanmak bu sorunu doğurur. soft-404-errors makalesine bakın.
• Paralel bir tuzak: HTTP katmanıyla uygulama katmanı birbiriyle çelişebilir; 200, bir API hata yükünü veya sessizce bozulan arka uç bloğunu sarabilir. Durum satırı yalnızca aktarımın başarılı olduğunu söyler, yükün doğru olduğunu değil.
• 200, 204 ve 304: 200 = gerçek gövdeli başarı (dizine eklenmeye uygun); 204 = boş gövdeli başarı ve sayfa URL’lerinde soft 404 gibi ele alınır (204-no-content bölümüne bakın); 304 = koşullu isteğe yanıt veren önbellek sinyali, dizine ekleme kararı değil.
• Googlebot’un ne aldığını doğrulayın. Cloaking, bot engelleme, coğrafi kurallar veya CDN/WAF yapılandırması yüzünden farklı istekte bulunanlar aynı URL için farklı kodlar görebilir. “Tarayıcımda 200” ≠ “Google 200 görüyor.” Yalnızca tarayıcı veya curl yerine GSC URL Inspection Canlı Testi’ni ya da sunucu günlüklerini kullanın.
• Kodu gerçekle eşleştirin: istenen → gerçek içerikle 200; kaldırılan → 404/410; taşınan → 301; yinelenen → canonical etiketi. Patrick’in ifadesiyle, “200 OK – All good. Everything is successful.” (çeviri) “200 OK — Her şey yolunda. Her şey başarılı.” Bu, gerçekten orada olmayı hak eden bir sayfa içindir.

Resmî dokümantasyon

200’ün ne olduğu ve Google’ın onu nasıl ele aldığına dair birincil kaynaklar.

HTTP spesifikasyonu ve tarayıcı başvurusu

• RFC 9110 §15.3.1 — 200 OK — yetkili tanım: isteğin başarıyla tamamlanması, yönteme göre gövde anlamı ve sezgisel önbellekleme.
• MDN — 200 OK — sade açıklama, varsayılan önbelleklenebilirlik ve PUT/DELETE ayrıntısı (201/204 daha yaygındır).

Google Search Central

• HTTP durum kodları, ağ ve DNS hatalarının Google Arama’ya etkisi — 2xx işleme açıklaması (“may index the content, but that’s not guaranteed” (çeviri) “içeriği dizine ekleyebilir, ancak bu garanti değildir”) ve soft 404 bağlantısı.
• Soft 404 hataları — Sayfa dizine ekleme raporu — 200 yanıtının aslında hata/boş içerik sunduğunda neden sorun olduğunu ve kaldırılmış sayfa için başarı kodu döndürmenin neden kötü uygulama olduğunu açıklar.
• Cloaking — bir URL’nin kullanıcılara ve Googlebot’a neden farklı kod/içerik sunabileceğini ve sıralamayı yönlendirmek için bunun neden ihlal sayıldığını açıklar.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — Bingbot’un bir URL için aldığı HTTP yanıtını doğrulamanın Bing tarafındaki yoludur. (Bing tarafından yazılmış “how status codes affect indexing” (çeviri) “durum kodlarının dizine eklemeyi nasıl etkilediği” başlıklı ayrı bir belge yoktur.)

Kaynaktan alıntılar

Kayıtlara geçmiş ifadeler. Her bağlantı, kaynak sayfadaki alıntı bölümüne doğrudan gider.

HTTP spesifikasyonu

• “The 200 (OK) status code indicates that the request has succeeded.” (çeviri) “200 (OK) durum kodu, isteğin başarıyla tamamlandığını belirtir.” — RFC 9110, HTTP Semantics, §15.3.1. Bölümü okuyun

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (çeviri) “HTTP 200 OK başarı durum kodu, isteğin başarıyla tamamlandığını belirtir. 200 OK yanıtı varsayılan olarak önbelleğe alınabilir.” Alıntıya git

Google Search Central — 2xx / 200 işleme

• Google’ın yukarıdaki birebir kaynak açıklamasının Türkçe özeti: “Google, aldığı yanıtı ürüne özgü sonraki işleme aşamasına iletir; Google Search için bu aşama dizine ekleme hattıdır. Sistemler içeriği dizine alabilir, ancak bunu garanti etmez.” — Google’s HTTP status codes doc, 200 entry. Google’s status-code doc

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (çeviri) “İçerik Google Search açısından bir hataya, boş sayfaya veya hata mesajına işaret ediyorsa Search Console bir soft 404 hatası gösterir.” — aynı belgedeki soft 404 çapraz başvurusu. Google’ın durum kodları belgesi

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” — from my HTTP Status Codes guide on the Ahrefs blog. Jump to quote

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (çeviri) “Bu sınıftaki yanıtların çoğu sayfaların dizine eklenmesine izin verir. Ancak boş gövdeli yanıt soft 404 olarak ele alınır ve dizine eklenmez.” — aynı rehberde Google’ın 2xx ailesini nasıl ele aldığına ilişkin bölüm. Alıntıya git

200 OK Yanıtı — hızlı başvuru

Nedir?

200 ve karıştırılan kardeşleri

Bu URL hangi kodu döndürmeli?

• Dizinde olması istenen → gerçek, anlamlı içerikle 200.
• Tamamen kaldırılmış → 404 veya 410 (bkz. 404-not-found).
• Yeni bir URL’ye taşınmış → 301.
• Başka bir URL’nin yineleneni → 200’ü koruyun, tercih edilen sürüme canonical etiketi ekleyin.
• Kasıtlı olarak boş (API/beacon) → 204 (bkz. 204-no-content); asla sayfa için değil.

Hızlı bilgiler

• 200 bir sayfayı dizine eklemeye uygun kılar; onu dizine eklenmiş yapmaz. Google kalite, yinelenme, zayıf içerik ve noindex temelinde ayrıca karar verir.
• Gerçekte kaldırılmış/boş bir sayfadaki 200, Google’ın gözünde soft 404’tür.
• Farklı istek yapanlar bir URL için farklı kodlar görebilir. Yalnızca tarayıcıya veya curl’e değil, GSC URL Inspection ya da sunucu günlüklerine bakarak Googlebot’un aldığını doğrulayın.
• Kodları DevTools Network sekmesi, curl -I / curl -IL, GSC/Bing URL Inspection, Screaming Frog ve Ahrefs Site Audit/Toolbar ile kontrol edin.

200 OK hakkında yaygın mitler

“200 durum kodu, sayfanın dizine eklendiği anlamına gelir.” Yanlış. 200, sunucunun içeriği başarıyla döndürdüğü anlamına gelir; dizine ekleme, sonraki aşamada verilen ayrı bir karardır. Google’ın kendi belgesi, dizin sistemlerinin “may index the content, but that’s not guaranteed.” (çeviri) “içeriği dizine ekleyebileceğini, ancak bunun garanti edilmediğini” söyler. Google, 200 yanıtından sonra kaliteyi, yinelenmeyi, içeriğin zayıflığını ve noindex yönergesini de ayrıca değerlendirir.

“Search Console soft 404 gösteriyorsa sunucumda hata vardır.” Şart değil. Soft 404, sunucunuzun gönderdiği bir kod değildir; Google’ın 200 durumu ile hata ya da boş sayfa izlenimi veren içerik arasındaki uyumsuzluğa dayanarak uyguladığı etikettir. Sunucu yapılandırıldığı şeyi yapıp 200 gönderiyordur; sorun başlıkta değil içeriktedir.

“200 her zaman iyidir, nokta.” Her zaman değil. Silinmiş ürün, süresi dolmuş ilan veya boş arama sonuçları sayfası gibi 404 döndürmesi gereken bir URL’de 200 kullanmak doğrudan zararlıdır. Soft 404 işlemine yol açar ve sunacak hiçbir şeyi olmayan URL’nin yeniden taranmasıyla tarama kaynağını boşa harcayabilir.

“Tarayıcım 200 gösteriyor; o hâlde Google da kesinlikle 200 görür.” Garanti edilmez. Bot engelleme, cloaking, coğrafi IP kuralları ve CDN/WAF yapılandırması Googlebot’a insan tarayıcısının aldığından farklı bir yanıt sunabilir. URL Inspection veya sunucu günlükleriyle doğrulayın.

“200 ile 204 temelde aynıdır; ikisi de başarı demektir.” İkisi de 2xx’tir, ancak 204 tasarım gereği boş gövdeye sahiptir. Bu, API’ler ve işaretçiler için uygundur; dizine eklenmesini istediğiniz sayfa içinse yanlıştır. Sayfa URL’sindeki 204, soft 404 gibi ele alınır (204-no-content bölümüne bakın).

“200 ile 304 aynı fikir değil mi?” Hayır. 304 Not Modified, koşullu bir isteğe (If-None-Match / If-Modified-Since) yanıt verip istemciye önbellekteki kopyayı kullanmasını söyleyen bir önbellek mekanizmasıdır. Gövde taşımaz ve dizine ekleme kararı değildir; 200’den farklı bir kavramdır.

200 OK sayfası neden hâlâ başarısız olur

Search Console URL’yi soft 404 olarak bildiriyor

Belirti: URL 200 döndürüyor, ancak Sayfa Dizine Eklenme raporu onu soft 404 olarak gösteriyor.

Olası neden: Yanıt gövdesi boş, bozuk veya hata sayfası gibi görünüyor. Yaygın örnekler, yararlı ürün bilgisi kalmayan üretimden kaldırılmış ürün, aksi hâlde eksiksiz şablonun içindeki silinmiş makale ya da sıfır sonuçlu arama sayfasıdır.

Düzeltme: Yanıtı gerçeğe uydurun. Sayfa var olmalıysa anlamlı içeriği geri yükleyin; kaldırıldıysa 404 veya 410, taşındıysa 301 döndürün. URL Inspection Canlı Test’ini yeniden çalıştırın ve yanıtla oluşturulan içeriğin artık uyuştuğunu doğrulayın.

Tarayıcınız 200 alıyor, Googlebot almıyor

Belirti: DevTools veya curl 200 gösterirken Google URL’yi getiremiyor ya da dizine ekleyemiyor.

Olası neden: Bir CDN, WAF, coğrafi kural, bot kuralı veya deney Googlebot’a farklı yanıt sunuyor olabilir. Kendi isteğiniz Google’ın isteğinin kanıtı değildir.

Düzeltme: Normal bir istekle Googlebot kullanıcı aracısı kullanan isteği karşılaştırın; ardından URL Inspection ve sunucu/CDN günlüklerini kontrol edin. Uç kuralını düzeltin ve Canlı Test’in kullanıcıların aldığı aynı anlamlı gövdeyle 200 aldığını doğrulayın.

Sayfa 200 döndürüyor ama yine de dizinde değil

Belirti: Durum kodu sağlıklı, ancak URL hâlâ dizin dışında.

Olası neden: 200 yalnızca içeriği işleme için uygun kılar. Bir noindex, yinelenen/ canonical çakışması veya düşük değerli içerik onu hâlâ dışarıda tutabilir.

Düzeltme: Durum kodunu değiştirmeyi bırakın. Dizinleme yönergelerini, Google’ın seçtiği canonical’ı ve gerçek içeriği kontrol edin. Başarılı HTTP yanıtı, dizine ekleme kararı değildir.

Yanlış hikâye anlatan 200 yanıtları

Bunlar basitleştirilmiş örneklerdir. Durum satırı teknik olarak başarılıdır; ancak bu başarının dürüst olup olmadığını gövde belirler.

Boş ürün kabuğu: yanıltıcı 200

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

Ürün kalıcı olarak kaldırılmış ve yerine yenisi gelmemişse 404 veya 410 döndürün. Yararlı bir ürün sayfası hâlâ duruyorsa — teknik özellikler, alternatifler, destek veya stok bilgisi sunuyorsa — gerçek bir amacı olduğu için 200 yine uygun olabilir.

Silinmiş makalenin yerine yenisi varsa yönlendirme kullanın

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

“Makale silindi” diyen şablon bir 200 sayfası kullanıcıları ortada bırakır ve soft 404 sınıflandırmasına davetiye çıkarır. İlgili yeni içerik, sunucu tarafı 301 yönlendirmesinin hedefi olmalıdır.

Sitede sıfır sonuçlu arama: yararlı ya da boş

Sayfa, kullanıcıların aramayı yeniden yazmasına, kategorilere göz atmasına veya alternatifler bulmasına yardımcı oluyorsa 200 dürüst bir yanıt olabilir. Yalnızca “0 results” (çeviri) “0 sonuç” içeren ince bir sayfa, başarı koduna rağmen hata gibi görünür. Ayrım 200 sayısında değil, gövdenin yararlılığındadır.

Şüpheli 200 yanıtlarını sınıflandırma

URL, durum, başlık, canonical, dizine eklenebilirlik ve kısa gövde metni örneğini içeren bir tarama dışa aktarımını yapıştırın. Bu istem, HTTP başarısını içerik ve dizine ekleme sorunlarından ayırır.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Sayfaya güvenmek yerine yanıtı kontrol edin

curl ile yanıtı inceleyin

Bunları macOS, Linux veya WSL’de çalıştırın. İlk komut yanıt başlıklarını okur; ikinci komut gövdeyi de indirir, böylece 200 yanıtının gerçek içerik taşıdığını doğrulayabilirsiniz.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

200 durum satırını arayın, ardından page.html dosyasını açın. Başlıklar tek başına soft 404’ü ortaya çıkaramaz.

Normal istekle Googlebot kullanıcı aracısını karşılaştırın

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

Fark, CDN/WAF kurallarını ve günlükleri incelemek için bir nedendir; taklit edilmiş bir isteğin yanıtı Googlebot’un gerçekten bunu aldığına kanıt değildir. Gerçek getirmeyi URL Inspection’da doğrulayın.

Bir listedeki 200 dışı yanıtları kontrol edin

urls.txt içine satır başına bir URL yazın:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

Bu, belirgin durum uyuşmazlıklarını bulur. Bir 200 gövdesinin anlamlı olup olmadığına karar veremez; bu nedenle şüpheli şablonların ve soft 404 raporlarının peşinden ayrıca gidin.

200 yanıtlarını doğrulama araçları

Patrick’in ücretsiz aracı

• Bulk HTTP Status Code Checker — 500’e kadar URL yapıştırıp durum kodlarını, son hedefleri, yönlendirme zincirlerini ve gecikmeyi tek dışa aktarımda toplayın. Gerçekte 200 döndürmeyen URL’leri bulmak için kullanın; ardından gövdeyi ve soft hata raporlarını Search Console’da ayrıca inceleyin, çünkü durum denetleyicisi içerik kalitesine veya dizine eklenmeye karar veremez.

Arama motoru ve sunucu kanıtı

• Google Search Console URL Inspection — dizine eklenmiş sonucu canlı getirmeyle karşılaştırın ve Google’ın alabileceği oluşturulmuş içeriği inceleyin.
• Bing Webmaster Tools URL Inspection — Bingbot’un aldığı bildirilen yanıtı kontrol edin.
• Sunucu ve CDN günlükleri — gerçek tarayıcı isteklerinin aldığı durum kodunu doğrulayın; günlükler curl’de kullanıcı aracısı dizesini değiştirmekten daha güçlü kanıttır.
• Tarayıcı DevTools Network paneli — önünüzdeki tarayıcı oturumundaki belge isteğini, yanıt başlıklarını ve gövdeyi doğrulayın.

Kendinizi test edin: 200 OK

SEO açısından 200’ün ne anlama geldiğine dair beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü