204 İçerik Yok

HTTP 204'ün ne anlama geldiği, Google'ın 204 yanıtlarını neden yumuşak hata sayfalarına benzer şekilde ele aldığı, 204'ün ne zaman meşru olarak kullanıldığı (API'ler, beacon'lar) ve web sayfaları için ne sunulması gerektiği.

İlk yayın tarihi: 27 Haz 2026 · Son güncelleme: 6 Ağu 2026 · Advanced
Diller
Bu sayfada 1 kanıt sinyali

HTTP 204 No Content, bilerek boş bir gövde döndüren bir 2xx başarı kodudur — hata değildir, bir URL'nin var olup olmadığıyla ilgisi yoktur ve spesifikasyonda sabit bir yöntem kümesiyle sınırlı değildir. REST API DELETE/PUT çağrıları ve analiz beacon'ları (sendBeacon, GA4'ün Measurement Protocol'ü) için doğru yanıttır; ancak API tasarımcıları ona ne sıklıkla başvurulacağı konusunda hemfikir değildir. SEO açısından dar sonuç şudur: Google'ın kendi dokümanına göre 204, işleyebileceği içerik sunmaz; bu nedenle sıralanmasını istediğiniz bir sayfa bu yanıttan dizine eklenmez. Pratikte bunlar Search Console'da çoğu zaman soft 404 olarak görünür; ancak Google bu özel etiketi veya kaldırılma takvimini garanti etmez. 204, API ve beacon uç noktaları için doğru, sıralanması amaçlanan her şey için yanlıştır. Bir sayfa gerçekten ortadan kalktıysa 404 veya 410 kullanın; taşındıysa 301 kullanın; içerik olması gerekiyorsa gerçek gövdeli 200 yerine 204 gönderen sunucuyu/CDN'yi düzeltin.

TL;DR — 204, boş gövdeyi tasarım gereği döndüren, spesifikasyona uygun bir 2xx başarı kodudur (RFC 9110 §15.3.5); gövde boş olmak zorundadır (ne Content-Length ne de 0 dahil) ve tarayıcılar içerik gönderen bir 204’ü reddedebilir. Bu bir hata değildir ve varlık hakkında hiçbir şey söylemez; RFC onu sabit bir yöntem listesiyle sınırlamaz. Meşru kullanımlar neredeyse tamamen belge olmayan yanıtlardır: REST API DELETE/PUT ve analiz beacon’ları (sendBeacon(), GA4’ün Measurement Protocol’ü). Ancak API tasarımcıları API’lerin buna ne sıklıkla başvurması gerektiği konusunda hemfikir değildir. SEO sonucu dar kapsamlıdır: Google’ın durum kodu tablosu 204 için “Google wasn’t able to receive any content and therefore can’t process it” (çeviri) “Google herhangi bir içerik alamadı ve bu nedenle işleyemiyor” der; yani sıralanmasını istediğiniz bir sayfa bu yanıttan dizine eklenmez. Pratikte bunlar Search Console’da çoğu zaman soft 404 olarak işaretlenir; ancak Google bu özel etiketi veya kaldırılma takvimini garanti etmez. Yanlışlıkla sayfa düzeyinde oluşan 204’ü, amaca göre gerçek bir 200’ü geri getirerek veya 404/410/301 kullanarak düzeltin.

Spesifikasyonda 204 ne demek

RFC 9110 nettir: 204, “sunucu isteği başarıyla yerine getirmiştir ve yanıt yük gövdesinde gönderilecek ek içerik yoktur” anlamına gelir. Bu bir başarı kodudur; 200 OK ile aynı 2xx ailesindedir, ancak kasıtlı fark gövde olmamasıdır.

Evidence for this claim RFC 9110 defines 204 No Content as a successful response with no additional content to send and says it is terminated by the header section because it cannot contain content. Scope: HTTP semantics for 204 responses. Confidence: high · Verified: IETF: RFC 9110 §15.3.5 — 204 No Content

Üç operasyonel ayrıntı önemlidir. Birincisi, gövdenin gerçekten boş olması gerekir: MDN, “must not include any content or the Content-Length header (browsers may reject responses that include content).” (çeviri) “204’ün herhangi bir içerik veya Content-Length başlığı içermemesi gerektiğini (tarayıcılar içerik içeren yanıtları reddedebilir)” belirtir. Bu gevşek bir gelenek değil, gerçek bir yasaktır — RFC 9110 §8.6, Content-Length başlığını 204’te tamamen yasaklar; dolayısıyla “emin olmak için Content-Length: 0 gönderin” önerisi de uyumlu değildir. Yanıt, nokta atışıyla başlık bölümünde sona erer. İkincisi, 204’ün taşıdığı ETag veya Last-Modified gibi başlıklar gönderilen bir gövdeyi değil, işleminiz tamamlandıktan sonraki seçili temsili açıklar. Üçüncüsü, bazı 204’lerde ETag görülür (MDN’nin örneği kaynağı yerinde güncelleyen bir PUT’tur), ancak RFC her 204’te bulunmasını gerektirmez; bunu kesin kabul etmeyin. Yöntem veya açık cache-control başlıkları aksini söylemediği sürece 204, varsayılan olarak sezgisel biçimde önbelleğe alınabilir.

En önemlisi, 204’ün bir URL’nin var olup olmadığıyla hiçbir ilgisi yoktur. Çalışan bir API uç noktası sonsuza kadar doğru biçimde 204 döndürebilir. Fark, yokluğu ifade eden 404 (bulunamadı) veya 410 (gitti) ile 204 arasındadır: 204, bilerek yük taşımayan başarılı bir istekle ilgilidir.

Google 204’ü nasıl ele alır

SEO hikâyesinin tamamı budur ve satıcı bloglarının kalıp ifadelerinden daha dardır. Google içeriği dizine ekler. 204’ün içeriği yoktur. Google’ın kendi durum kodu dokümanı 204’ü sınırları belirli bir ifadeyle ayrıca ele alır: genel 2xx kuralı “Google içeriği işlenmek üzere değerlendirir” derken, 204’e ayrılan satır “Google wasn’t able to receive any content and therefore can’t process it.” (çeviri) “Google herhangi bir içerik alamadı ve bu nedenle işleyemiyor” der.

Evidence for this claim Google says it treats a 204 response as though the URL returned a soft 404. Scope: Google Search indexing behavior for URLs returning HTTP 204. Confidence: high · Verified: Google: HTTP status codes and Search

Gerçek sınır budur; neyi vaat edip etmediği konusunda kesin olmak gerekir. Aynı sayfadaki genel 2xx yönlendirmesi, boş veya hata benzeri içeriğin soft 404 olarak raporlanabileceğini söyler; ancak 204 satırı her 204’ün bu özel Search Console etiketine gireceğini garanti etmez ve Google bir kaldırılma takvimi yayımlamaz. Kesin olan şudur: bir içerik URL’sindeki 204, Google’ın dizine ekleme hattına çalışacağı hiçbir şey vermez; bu nedenle URL’nin bu yanıttan dizine eklenmeyeceğini söylemek makul bir çıkarımdır. Bunu “site genelinde sıralama kaybı garantisi” veya “otomatik tarama bütçesi kurtarma” iddialarına genişletmem; Google’ın dokümantasyonu bu vaatlerin hiçbirini yapmaz. Pratikte Search Console bunları çoğu zaman soft 404 olarak gösterir — gözlemleyip yazdığım örüntü budur; ancak rapor etiketini ve zamanlamasını belgelenmiş garanti değil, gözlemlenen davranış olarak değerlendirin.

Kendi yazılarımda savunduğum tutum budur. Ahrefs blogundaki HTTP Durum Kodları ve SEO Etkileri rehberimde, Google’ın 2xx yanıtlarını nasıl ele aldığı bölümünde bunu doğrudan şöyle yazdım: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (çeviri) “2xx yanıtlarının çoğu sayfaların dizine eklenmesine izin verir. Ancak içeriksiz yanıtlar soft hata olarak ele alınır ve dizine eklenmez.”. Pratik okuma olarak bunun arkasındayım; Google’ın kendi dokümanındaki daha kesin ve güncel ifade yukarıdaki “içeriği alamaz veya işleyemez” çerçevesidir ve tam resmî sınır için işaret edeceğim nokta da budur.

Soft 404’lerin taranmaya devam ettiği ve tarama bütçesini boşa harcadığı belgelenmiştir; ancak bu, 204’e özgü bir vaat değil, Google’ın genel soft 404 yönlendirmesidir. 204 kullanmak tarama kaynaklarını otomatik olarak serbest bırakmaz veya başka yere yönlendirmez; Google’ın kendi açıklamasına göre kaynak tahsisi hangi durum kodunun dışlamayı tetiklediğine değil, sunum sınırlarına, site kalitesine ve envantere bağlıdır. Güvenli çıkarım şudur: yanlışlıkla oluşan 204’ü, belirli bir tarama bütçesi karşılığı hakkınız olduğu için değil, sayfanın dizine eklenmesini engellediği için düzeltin.

Evidence for this claim Using 204 does not automatically free crawl budget or redirect crawl resources; the official Google 204 guidance establishes only that no content can be processed. Scope: web crawling and indexing Confidence: high · Verified: How HTTP status codes affect Google's crawlers

204 ve karıştırıldığı kodlar

KodGövdeAnlamıDoğru kullanım
200 (gerçek içerik)DoluBaşarı, işte sayfaDizine eklenmesini istediğiniz sayfa
200 (boş / “bulunamadı” metni)Boş veya hata metniBaşarı iddiası var, gerçek içerik yok — soft 404Hiçbiri; düzeltilmesi gereken bir hatadır
204Tasarım gereği boşBaşarı, bilerek gövde yokAPI’ler, beacon’lar — asla sayfa URL’si değil
404HerhangiBulunamadıYerine yenisi olmayan sayfa
410HerhangiGitti (kalıcı)Bilerek ve kalıcı olarak kaldırılmış sayfa
301Kalıcı olarak taşındıYeni bir URL’ye taşınan sayfa

Tuzak şudur: 204, boş-200, 404 ve 410, kullanılabilir içerik olmadığında GSC’de hepsi “soft 404” olarak sonuçlanabilir; ancak spesifikasyona uygun bir istemciye çok farklı amaçlar bildirirler. 410, “bu vardı ve kalıcı olarak gitti” sinyalidir; 204 hiçbir zaman bu anlam için tasarlanmamıştır ve sayfa URL’lerinde bulunmamalıdır.

204 ne zaman tam olarak doğrudur (hata değildir)

Meşru 204’lerin neredeyse tamamı belge olmayan yanıtlardır:

  • REST API DELETE / PUT. Bir istemci bir kaynağı sildiğinde veya yerinde güncellediğinde ve döndürülecek anlamlı bir şey olmadığında 204, deyimleşmiş yanıttır; RFC 9110’un önerdiği kalıp da budur.
  • Analiz ve izleme beacon’ları. navigator.sendBeacon() etrafında kurulan W3C Beacon spesifikasyonu, beacon uç noktalarının 204 ile yanıt vermesini bekler. Google Analytics 4’ün Measurement Protocol uç noktası, kabul ettiği istekler için 204 döndürür. Dikkat edilmesi gereken nokta: GA4 hatalı veya geçersiz yükler için bile 204 döndürür; dolayısıyla buradaki 204 yalnızca uç noktanın erişilebilir olduğunu ve yapısal olarak yanıt verdiğini doğrular, isteğinizin gerçekten işlendiğini değil. Beacon’ın 204’ünü başarı kanıtı olarak okumayın.
  • “Sayfadan ayrılmadan kaydet” kullanıcı deneyimi. Durumu yerinde kaydeden ve kullanıcıyı mevcut sayfada bırakan bir PUT için MDN’nin kendi çerçevesi, 204 ile “the client doesn’t need to navigate away from its current page.” (çeviri) “istemcinin mevcut sayfasından ayrılması gerekmediği” yönündedir.

Ana fikir şudur: Bunlar hiç kimsenin dizine eklememesi gereken URL’lerdir; bu yüzden 204 doğru ve beklenen yanıttır. Sorun yalnızca sıralanması gereken bir belge URL’sinde 204 bulunmasıdır.

İlgili bir ayrıntı: RFC 9110, 204’ü özellikle DELETE/PUT/beacon’larla sınırlamaz; bunlar yalnızca yaygın kalıplardır. Spesifikasyonun tanımı yönteme bağlı değildir; asıl önemli olan yöntemin kendi sözleşmesi ve bir temsil döndürmenin yararlı olup olmadığıdır. Bu iki yönlüdür. GET isteğinin 204 döndürmesi protokol açısından yasaldır — Stack Overflow’da uygulayıcılar bunu yıllardır tartışıyor — ancak dizine eklenebilir bir sayfa için gerçek soru “204 ile GET’e izin var mı?” değil, “bulunabilir olmak için bu URL’nin Google’a bir temsil sunması gerekiyor mu?” sorusudur; sıralanmasını istediğiniz bir sayfa için yanıt her zaman evettir. Dolayısıyla SEO kuralı hangi HTTP yönteminin kullanıldığıyla değil, URL’nin bir belge olarak tasarlanıp tasarlanmadığıyla ilgilidir.

“204, API yanıtları için her zaman doğrudur” fikrinin API tasarımcıları arasında bile evrensel olarak kabul edilmediğini bilmekte fayda var. Postman’ın kendi yazısı, döndürülecek hiçbir şey olmayan işlemler için 204’ü varsayılan seçenek olarak listeler; Brandur Leach ise boş bir başarı yanıtının, başarılı bir yazma işleminden sonra bile geri gönderilecek bir temsil (güncellenmiş durum, oluşturulan bir kimlik veya hesaplanan bir alan) bekleyen API istemcilerine biraz zarar verebileceğini savunur. Bu, HTTP doğruluğu değil, geliştirici ergonomisiyle ilgili meşru bir API tasarımı tercihidir; 204 her iki durumda da spesifikasyona uygundur ve bu makalenin SEO sorusundan ayrıdır. API yazılarında bazen yapılan bir hata da “güvenli olmak” için 204’e Content-Length: 0 göndermektir. Bunu yapmayın — RFC 9110 §8.6, yalnızca sıfırdan büyük olanı değil, 204 yanıtındaki Content-Length’i tamamen yasaklar.

Yanlışlıkla oluşan sayfa düzeyi 204’ü teşhis etme ve düzeltme

Bir tarayıcı (Screaming Frog, Ahrefs Site Audit) veya günlükleriniz içeriği olması gereken bir sayfada 204 gösteriyorsa:

  1. Googlebot’un gerçekte ne aldığını doğrulayın. Yalnızca tarayıcınızın gördüğüne değil, Google’ın aldığı duruma ve oluşturulmuş içeriğe bakmak için Search Console’da URL Denetimi’ni kullanın. Bir CDN, edge worker, WAF veya uygulama rotası, size normal görünürken botlara ya da belirli koşullarda 204 döndürebilir (başınıza gelebilecek başıboş bir 403 ile aynı “tarayıcımda iyi görünüyor” örüntüsü).
  2. Ardından amaca göre düzeltin:
    • Sayfa içerikle var olmalı → 204 üreten sunucu/CDN/uygulama mantığını bulun ve gerçek gövdeyle düzgün bir 200 döndürün.
    • Sayfa yerine yenisi olmadan gitti404 veya 410 döndürün.
    • Sayfa taşındı → yeni URL’ye 301 yönlendirin.
  3. İzleyin. GSC Sayfa Dizine Ekleme raporunda soft 404 kayıtlarını takip edin, günlüklerdeki tarama durum kodlarına göz atın ve bir şablondaki yanlışlıkla oluşan 204’ün bütün bir bölümü sessizce dizinden çıkarmaması için tarayıcınızı 204’leri işaretleyecek şekilde ayarlayın.

Akılda tutulacak zihinsel model şudur: 204 “kötü” değildir. API ve beacon uç noktaları için doğru, belgeler için yanlış olan hassas bir araçtır. Arıza modu yalnızca onu yanlış yerde kullanmaktır. 403, 404, 410 ve soft 404 gibi kardeşlerinin bu kararda kendi yerleri vardır; 204’ün yeri sayfanın dışıdır.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.