304 Not Modified ve Last-Modified Nedir? Googlebot Taramasını Verimli Kılma Rehberi

Biz Talha Aslan ve ekibi olarak teknik SEO denetimlerinde bu konuya sık rastlıyoruz. Çoğu site sahibi 304 Not Modified yanıtını bir hata sanıyor. Oysa doğru kurulduğunda tam tersine çalışır: Googlebot değişmeyen sayfalar için tüm HTML'i indirmez, kazandığı zamanı yeni ya da güncel sayfalara ayırabilir. Ancak yanlış kurulduğunda da tehlikelidir, çünkü güncellediğiniz bir sayfa Google'ın gözünde eski haliyle kalabilir.

Bu rehberde koşullu istekleri, Last-Modified ve ETag başlıklarını, Google'ın bu başlıkları resmi belgelere göre nasıl kullandığını ve CDN ile önbellek katmanında neleri kontrol etmeniz gerektiğini adım adım anlatıyoruz. Kod bloğu vermiyoruz; amaç, geliştiricinizle ya da hosting ekibinizle aynı dili konuşabilmenizdir.

Koşullu istek (conditional request) tam olarak nasıl çalışır?

Koşullu istek, istemcinin "elimdeki kopya hâlâ geçerliyse bana içeriği yeniden gönderme" dediği istektir. İlk ziyarette sunucu sayfayı 200 OK ile gönderir ve yanına bir doğrulayıcı (validator) ekler. Bu doğrulayıcı ya bir tarih (Last-Modified) ya da içeriğe özgü bir etikettir (ETag).

Sonraki ziyarette istemci bu doğrulayıcıyı geri yollar. Sunucu karşılaştırma yapar ve iki sonuçtan birini seçer:

1. İçerik değişmemişse 304 Not Modified döner ve gövde göndermez.
2. İçerik değişmişse 200 OK ile yeni içeriği ve yeni doğrulayıcıyı gönderir.

Bu mekanizma yalnız Googlebot'a özgü değildir. Tarayıcılar da aynı yöntemi kullanır. Örneğin web.dev'in HTTP önbelleği rehberi, 304 yanıtında aktarılan verinin çok az olduğunu vurgular. Dolayısıyla doğru kurulan bir koşullu istek akışı hem kullanıcı deneyimine hem tarama verimliliğine katkı verir.

Burada kritik nokta şudur: karar sunucudadır. İstemci yalnız "elimde şu sürüm var" der. Sayfanın gerçekten değişip değişmediğini doğru bilmek ise tamamen sizin sisteminizin sorumluluğundadır.

Last-Modified ve If-Modified-Since başlıkları ne iş yapar?

Last-Modified, sunucunun yanıtla birlikte gönderdiği bir yanıt başlığıdır ve sayfanın en son ne zaman değiştiğini bir tarih olarak bildirir. If-Modified-Since ise istemcinin sonraki istekte gönderdiği istek başlığıdır. Yani ilki sunucudan gelir, ikincisi istemciden sunucuya gider.

Akış şöyle işler: Googlebot bir sayfayı ilk taradığında yanıtta Last-Modified değerini görür. Google'ın tarama hataları belgesi, tarayıcıların If-Modified-Since gönderdiğinde bu değerin, içeriğin son tarandığı tarih ve saat olduğunu belirtir. Sunucu bu tarihten sonra değişiklik yoksa 304 Not Modified ile cevap verebilir.

Tarih biçimi önemlidir. Google'ın tarayıcılara genel bakış belgesi, Last-Modified tarihinin HTTP standardına uygun biçimde yazılması gerektiğini söyler. Bu nedenle yerel saat dilimiyle, Türkçe ay adlarıyla ya da eksik biçimdeki tarihler sorun çıkarır. Standart biçim, gün adı, gün, ay kısaltması, yıl, saat ve GMT ifadesinden oluşur.

Ayrıca tarih "sayfanın anlamlı biçimde değiştiği an" olmalıdır. Her istekte o anın saatini basan bir sistem, Last-Modified başlığını anlamsız hale getirir. Çünkü sayfa her seferinde "yeni" gibi durur ve 304 hiç oluşmaz.

ETag ve If-None-Match neden Google'ın tercihidir?

ETag, sunucunun bir içeriğin belirli sürümüne verdiği benzersiz etikettir. Genelde içeriğin bir özeti (hash) gibi çalışır. İstemci sonraki istekte bu etiketi If-None-Match başlığıyla geri gönderir. Etiket aynıysa sunucu 304 Not Modified döner; farklıysa yeni içeriği yollar.

Google bu konuda açık bir tercih belirtir. Aynı Google tarayıcıları belgesine göre yanıtta hem ETag hem Last-Modified varsa Google'ın tarayıcıları ETag değerini kullanır. Üstelik Google, önbellek tercihini belirtmek için Last-Modified yerine ETag kullanmayı önerir. Gerekçe basittir: ETag, tarih biçimlendirme sorunlarıyla uğraşmanızı gerektirmez.

Peki Last-Modified tamamen gereksiz mi? Hayır. Bazı istemciler ve ara katmanlar yalnız tarihe bakar. Bu yüzden pratikte iki başlığı birlikte, tutarlı biçimde göndermek en sağlam yoldur. Biz denetimlerde önce ETag'in istikrarlı olup olmadığına, sonra Last-Modified tarihinin gerçek değişiklikle örtüşüp örtüşmediğine bakıyoruz.

Google aynı belgede Cache-Control başlığındaki max-age alanını da zorunlu olmamakla birlikte değerlendirebileceğinizi söyler. Bu değer, tarayıcıların bir adresi ne zaman yeniden taramak isteyebileceğine yardımcı olur. Öte yandan Google, bunların dışındaki HTTP önbellek yönergelerini desteklemediğini de belirtir.

Google 304 Not Modified yanıtını nasıl yorumlar?

Google'ın HTTP durum kodları belgesi bu soruyu net yanıtlar. 304 aldığında Google'ın tarayıcıları, bir sonraki işleme sistemine içeriğin son taramadakiyle aynı olduğunu bildirir. Dizin tarafında ise belge, işleme hattının adres için sinyalleri yeniden hesaplayabileceğini, bunun dışında durum kodunun dizine etkisi olmadığını söyler.

Bu cümlenin pratik anlamı önemlidir. 304 Not Modified yanıtı:

• Sayfayı dizinden çıkarmaz.
• Sıralamayı tek başına yükseltmez ya da düşürmez.
• Google'ın daha önce sakladığı kopyanın kullanılmasını sağlar.
• Sunucunuzun gövde üretme ve gönderme maliyetini azaltır.

Yani 304 bir sıralama sinyali değil, bir verimlilik mekanizmasıdır. Kimse size "304 kurarsanız üst sıraya çıkarsınız" diyemez; biz de demiyoruz. Ancak taranması gereken çok sayıda sayfanız varsa, değişmeyen sayfalara harcanan kaynağı azaltmak dolaylı olarak önemli sayfaların daha düzenli taranmasına yardım edebilir.

Tersi de doğrudur: içerik değiştiği halde 304 dönerseniz Google eski kopyayı kullanmaya devam eder. Bu yüzden 304 kurgusunun doğruluğu, varlığından daha önemlidir.

Googlebot her istekte koşullu başlık gönderir mi?

Hayır, göndermez. Google'ın tarama hatalarını giderme belgesi, tarayıcıların bu başlıkları her tarama denemesinde eklemediğini, bunun isteğin amacına bağlı olduğunu açıklar. Belge ayrıca AdsBot'un bu başlıkları gönderme olasılığının daha yüksek olduğunu not eder.

Aynı belgede dikkat çekici bir bilgi daha vardır. Sunucu, istek bu başlıkları içermese bile, içerik Googlebot'un son ziyaretinden beri değişmediyse herhangi bir Googlebot isteğine gövdesiz bir 304 yanıtı gönderebilir. Ancak bunu yapabilmek için sunucunuzun Googlebot'un son ziyaretini doğru bilmesi gerekir; bu da çoğu sitede ek bir mantık ister.

Ayrıca her Google tarayıcısı önbelleği aynı biçimde kullanmaz. Google'ın belgesi, Googlebot'un Google Arama için adresleri yeniden tararken önbelleği desteklediğini, Storebot-Google'ın ise yalnız belirli koşullarda desteklediğini belirtir. Dolayısıyla loglarda bazı Google isteklerinin hep 200 aldığını görmeniz tek başına bir arıza işareti değildir.

Kısacası amacınız "her Googlebot isteği 304 alsın" olmamalı. Amacınız, koşullu istek geldiğinde sunucunun doğru kararı vermesidir.

Tarama verimliliği açısından 304 Not Modified neden önemlidir?

Google'ın tarama bütçesi yönetimi rehberi, verimlilik önerileri arasında HTTP önbelleğini kullanmayı ve 304 durum kodunu desteklemeyi açıkça sayar. Rehbere göre bir sayfa Google'ın son taramasından beri değişmediyse 304 kodu, Google'a önbellekteki sürümü yeniden kullanmasını söyler.

Aynı rehber, tarama kapasitesinin sunucu sağlığıyla ilişkili olduğunu da anlatır. Yanıt süreleri istikrarlı kaldığında ya da iyileştiğinde sınır artabilir. Bu nedenle gövdesiz, hızlı 304 yanıtları sunucu yükünü azaltarak dolaylı bir katkı sunar. Sunucu hızının ayrıntıları için TTFB ve sunucu yanıt süresi yazımıza göz atabilirsiniz.

Tarama bütçesi kavramının kendisini burada tekrar anlatmıyoruz; hangi sitelerin bu konuyla gerçekten ilgilenmesi gerektiğini tarama bütçesi rehberimizde ayrıntılı ele aldık. Tarama sıklığı aniden düştüyse olası nedenleri de Googlebot neden daha az tarar yazımızda topladık.

Bu tür teknik ayarların sitenizde doğru çalışıp çalışmadığını tek seferlik bir kontrolle anlamak zordur. SEO danışmanlığı hizmetimizde sunucu yanıtlarını, logları ve Search Console verisini birlikte izliyor, sorunu sitenizde biz çözüp takip ediyoruz.

Hangi siteler 304 Not Modified desteğine öncelik vermeli?

Her site için aynı aciliyet yoktur. Google'ın tarama bütçesi rehberi, kendini kabaca şu sitelere yönelik tanımlar: çok sayıda benzersiz sayfası olup içeriği orta sıklıkta değişen büyük siteler, içeriği çok hızlı değişen orta ve büyük siteler ve Search Console'da birçok adresi "Bulundu, şu anda dizine eklenmedi" (Discovered, currently not indexed) durumunda görünen siteler.

Bu son durum için ayrı bir rehberimiz var: Discovered currently not indexed yazımız bu durumun ne anlama geldiğini anlatıyor. Saha tecrübemize göre 304 desteğinden en çok fayda gören site tipleri şunlardır:

• Binlerce ürün ve kategori sayfası olan e-ticaret siteleri.
• Arşivi büyük, eski yazıları nadiren değişen haber ve içerik siteleri.
• Filtre ve listeleme sayfaları üreten ilan ve katalog siteleri.
• Paylaşımlı ya da sınırlı kaynaklı sunucuda çalışan orta ölçekli siteler.

Öte yandan birkaç düzine sayfalık bir kurumsal sitede 304 kurulumu bir öncelik değildir. Böyle bir sitede önce içerik, iç linkleme ve indekslenme sorunlarını çözmek daha fazla getiri sağlar. Yine de altyapınız bu desteği varsayılan olarak sunuyorsa kapatmanız için de bir neden yoktur.

200 OK, 304 Not Modified ve diğer yanıtlar arasındaki fark nedir?

Aşağıdaki tablo, Google'ın HTTP durum kodları belgesindeki açıklamaları ve tarama açısından pratik sonuçları özetler. Tablo bir sıralama rehberi değildir; her kodun Google'a ne söylediğini gösterir.

Tablodaki en önemli ayrım şudur: 304 bir başarı yanıtı gibi davranır ama içerik göndermez. 5xx ise taramayı yavaşlatır. Bu nedenle önbellek katmanında yaşanan bir arıza, 304 yerine 5xx döndürmeye başlarsa tarama verimliliği bir anda tersine döner. Sunucu hatalarının ayrıntısını aynı Google belgesinde bulabilirsiniz.

Sitenizin 304 Not Modified döndürüp döndürmediğini nasıl test edersiniz?

Teste başlamadan önce bir şeyi netleştirelim: amacınız tek bir sayfanın değil, şablonların davranışını görmektir. Ana sayfa, kategori, ürün ya da yazı ve statik dosya gibi her şablondan en az bir adres seçin. Ardından şu adımları izleyin:

1. Tarayıcınızın geliştirici araçlarında ağ (Network) sekmesini açın ve önbelleği devre dışı bırakma seçeneğinin kapalı olduğundan emin olun.
2. Sayfayı ilk kez yükleyin ve belge yanıtında ETag ile Last-Modified başlıklarının olup olmadığını not edin.
3. Sayfayı normal biçimde yenileyin; belge isteğinin durum sütununda 304 görüp görmediğinize bakın.
4. İçerikte küçük bir değişiklik yapın ve yeniden yenileyin; bu kez 200 ve yeni bir ETag görmelisiniz.
5. Aynı testi bir komut satırı HTTP istemcisiyle, ETag değerini If-None-Match başlığına koyarak tekrarlayın.

Dördüncü adım en çok atlanan adımdır. Ancak asıl tehlikeyi o yakalar: içerik değiştiği halde 304 dönen bir sistem, Google'a eski sürümü kullanmaya devam etmesini söyler. Örnek senaryo olarak example.com/urun-a sayfasında fiyatı değiştirip 304 alıyorsanız, sorun önbellek katmanındadır.

Search Console Tarama istatistikleri raporunda 304'ü nerede görürsünüz?

Search Console'da bu bilgi Ayarlar bölümündeki Tarama istatistikleri (Crawl stats) raporunda yer alır. Google'ın yardım sayfasına göre rapor, yanıtları türlerine göre gruplar ve tüm tarama yanıtları içindeki yüzde olarak gösterir. Burada "Not modified (304)" satırı, sayfanın son tarama isteğinden beri değişmediğini ifade eder.

Raporda bakmanızı önerdiğimiz başka alanlar da var:

• Tarama amacı: Keşif (Discovery) yeni adresleri, Yenileme (Refresh) bilinen sayfaların yeniden taranmasını gösterir.
• Ortalama yanıt süresi: Seçilen dönemde sitenizden alınan tüm kaynakların ortalama süresidir.
• Ana makine durumu (Host status): Google'ın sitenizde erişilebilirlik sorunu yaşayıp yaşamadığını gösterir.
• Dosya türü ve Googlebot türü kırılımları: Hangi kaynakların ne kadar tarandığını ayırmanıza yardım eder.

Yorum yaparken dikkatli olun. Yenileme amaçlı taramaların çok olduğu bir sitede 304 oranının sıfıra yakın görünmesi, koşullu istek desteğinin hiç çalışmadığına işaret edebilir. Öte yandan bu oran için Google'ın açıkladığı bir hedef değer yoktur; o yüzden "şu yüzdeye ulaşın" gibi bir eşik vermiyoruz. Asıl değerli olan, değişiklikten önceki ve sonraki dönemi aynı raporda karşılaştırmaktır.

Sunucu loglarında 304 Not Modified satırlarını nasıl okursunuz?

Search Console size özet bir görünüm sunar. Sunucu logları ise her isteği tek tek gösterir. Bu yüzden 304 kurgusunu doğrulamanın en sağlam yolu loglardır. Log analizinin genel yöntemini SEO için sunucu log analizi rehberimizde anlattık; burada yalnız 304'e özgü noktalara değiniyoruz.

Loglarda şu soruları sorun:

1. Googlebot olarak görünen istekler gerçekten Google'dan mı geliyor? Google'ın önerdiği ters DNS doğrulamasını atlamayın.
2. Hangi şablonlar hiç 304 almıyor? Örneğin yazılar 304 alırken ürün sayfaları hep 200 alıyorsa şablon farkı vardır.
3. 304 alan adreslerde gövde boyutu gerçekten sıfıra yakın mı?
4. Bir sayfayı güncellediğiniz gün, o adres için ilk Googlebot isteği 200 almış mı?

Büyük log dosyalarını elle taramak zahmetlidir. Bu nedenle ilk elemeyi log analizi aracımızla yapıp durum kodlarına göre dağılımı görebilirsiniz. Ardından şüpheli şablonları tek tek inceleyin. Böylece "site genelinde 304 var" yanılgısı yerine, hangi sayfa grubunda çalıştığını kanıtla görürsünüz.

Yanlış Last-Modified değeri hangi sorunlara yol açar?

Last-Modified değerini yanlış üretmenin iki tipik biçimi vardır ve ikisi de farklı zarar verir. Birincisi, tarihin her istekte "şimdi" olmasıdır. Bu durumda sayfa her seferinde yeni gibi durur, koşullu istek hiçbir zaman 304 ile sonuçlanmaz ve verimlilik kazancı tamamen kaybolur.

İkincisi daha sinsidir: tarihin hiç değişmemesi. Örneğin bir şablon, sayfanın ilk oluşturulma tarihini Last-Modified olarak basıyor olabilir. Bu durumda içerik güncellense bile sunucu "değişmedi" diyebilir ve 304 dönebilir. Sonuç olarak Google güncel fiyatı, yeni bölümü ya da düzelttiğiniz bilgiyi görmeyebilir.

Üçüncü bir sorun da bileşen değişiklikleridir. Bir ürün sayfasının ana metni değişmese bile stok durumu, fiyat ya da yorum sayısı değişebilir. Eğer Last-Modified yalnız ana metnin tarihine bakıyorsa, sayfanın kullanıcıya görünen hali değiştiği halde sistem bunu fark etmez.

Bu yüzden önerimiz şudur: Last-Modified, sayfanın HTML çıktısını etkileyen tüm anlamlı verilerin en son değiştiği anı yansıtsın. Telif yılı ya da rastgele bir öneri kutusu gibi önemsiz parçalar ise bu tarihi tetiklemesin.

Dinamik sayfalarda doğru ETag nasıl üretirsiniz?

ETag üretmenin en sağlam kavramsal yolu, sayfanın anlamlı içeriğinden bir özet çıkarmaktır. İçerik aynıysa özet aynı, içerik değiştiyse özet farklı olur. Böylece etiket, sayfanın gerçek durumunu yansıtır. Ancak dinamik sitelerde bu basit fikir birkaç yerde aksar.

Sık gördüğümüz bozulma noktaları şunlardır:

• Her yanıtta değişen bir parça (oturum belirteci, zaman damgası, rastgele kimlik) özetin içine giriyor ve ETag her seferinde farklı çıkıyor.
• Birden fazla sunucunun arkasında, her sunucu aynı dosya için farklı ETag üretiyor; istemci hangi sunucuya düşerse farklı etiket görüyor.
• Sıkıştırma katmanı, sıkıştırma uygulanan ve uygulanmayan sürüme aynı güçlü ETag'i veriyor ya da etiketi tamamen siliyor.
• Kişiselleştirilmiş içerik, giriş yapmış ve yapmamış kullanıcılara aynı etiketle sunuluyor.

HTTP standardı "zayıf" (weak) ve "güçlü" (strong) ETag ayrımı yapar. Zayıf etiket, anlamca eşdeğer sürümleri aynı sayar; güçlü etiket ise bayt düzeyinde aynılık bekler. Hangisini seçeceğiniz altyapınıza bağlıdır. Önemli olan, aynı içeriğin her sunucuda ve her istekte aynı etiketi almasıdır.

CDN ve önbellek katmanı 304 Not Modified akışını nasıl etkiler?

Bir CDN ya da ters vekil sunucu (reverse proxy) kullanıyorsanız, Googlebot'un konuştuğu taraf çoğu zaman sizin kaynak sunucunuz değil, bu ara katmandır. Dolayısıyla 304 kararını kimin verdiğini bilmeniz gerekir. Bazen CDN kendi kopyasına bakarak 304 döner, bazen isteği kaynağa iletir.

Burada üç olası durum vardır. Birincisi, CDN kaynaktaki ETag ve Last-Modified değerlerini olduğu gibi aktarır; bu ideal durumdur. İkincisi, CDN bu başlıkları siler ya da kendi değerleriyle değiştirir; o zaman kaynak tarafındaki emeğiniz boşa gider. Üçüncüsü, CDN eski bir kopyayı uzun süre tutar ve içerik değiştiği halde 304 döner.

Üçüncü durum en riskli olanıdır. Örnek senaryo: example.com'da bir kampanya sayfasını güncellediniz, ama CDN önbelleğini temizlemediniz. Googlebot koşullu istek gönderir, CDN eski ETag ile eşleşme bulur ve 304 döner. Google eski kopyayı kullanmaya devam eder.

Ters vekil önbelleği kuruyorsanız, temel yapılandırma mantığını Varnish Cache rehberimizde bulabilirsiniz. Hangi araç olursa olsun kural aynıdır: içerik değiştiğinde ilgili önbellek kaydını geçersiz kılmak, yayın sürecinizin ayrılmaz bir adımı olmalıdır.

CDN ve önbellek yapılandırması için kontrol listesi nedir?

Aşağıdaki listeyi, yeni bir CDN kurulumunda ya da önbellek eklentisi değişikliğinde ekibinizle birlikte adım adım işaretleyin. Her maddeyi bir test cümlesi olarak yazdık; "evet" diyemediğiniz madde, incelemeniz gereken yerdir.

1. HTML yanıtlarında ETag ya da Last-Modified başlığı var mı?
2. CDN bu başlıkları kaynaktan olduğu gibi aktarıyor mu?
3. Aynı adres, farklı uç noktalardan (edge) aynı ETag ile mi dönüyor?
4. İçerik güncellenince ilgili önbellek kaydı otomatik olarak temizleniyor mu?
5. Güncellemeden sonraki ilk koşullu istek 200 ve yeni ETag alıyor mu?
6. Kişiselleştirilmiş ya da oturuma bağlı sayfalar önbellekten genel kullanıcılara sunulmuyor mu?
7. Hata sayfaları (404, 5xx) yanlışlıkla 200 ya da 304 olarak önbelleğe girmiyor mu?
8. Cache-Control değerlerini sayfa türüne göre ayrı ayrı ve bilinçli seçtiniz mi?
9. Statik dosyalar (CSS, JavaScript, görseller) için sürümleme yapıyor musunuz?
10. Değişiklikten sonra Tarama istatistikleri raporunda yanıt dağılımını izliyor musunuz?

Bu listeyi bir kez doldurmak yetmez. Özellikle tema, eklenti ya da CDN ayarı değiştiğinde yeniden kontrol etmenizi öneriyoruz. Çünkü 304 davranışı çoğu zaman siz fark etmeden, başka bir değişikliğin yan etkisi olarak bozulabiliyor.

WordPress ve hazır altyapılarda nelere dikkat etmelisiniz?

WordPress, hazır e-ticaret altyapıları ve site kurucularında 304 davranışını çoğu zaman siz değil, sunucu yazılımı, önbellek eklentisi ve CDN birlikte belirler. Web.dev'in rehberi de bazı web sunucularının bu başlıkları varsayılan olarak ayarladığını, bazılarının ise yapılandırma olmadan göndermediğini belirtir.

WordPress tarafında sık karşılaştığımız durumlar şunlardır. Sayfa önbelleği eklentisi statik HTML üretir ve sunucu bu dosyalar için başlıkları otomatik ekler. Ancak eklenti devre dışı kalınca dinamik PHP yanıtları genelde ETag içermez. Ayrıca bazı güvenlik ya da performans eklentileri başlıkları yeniden yazar.

Hazır altyapılarda ise sunucu ayarına erişiminiz sınırlı olabilir. Bu durumda yapabileceğiniz en iyi şey, yukarıdaki test adımlarıyla mevcut davranışı ölçmek ve gerekiyorsa altyapı sağlayıcısının destek ekibine somut örnekle başvurmaktır. Yani "304 çalışmıyor" demek yerine, adresi, başlıkları ve beklenen davranışı birlikte iletin.

Not: Biz hosting firması değiliz ve sunucu işletmiyoruz. Ancak SEO danışmanlığı kapsamında hosting ekibinize ya da geliştiricinize ileteceğiniz teknik bulguları net biçimde hazırlıyor, uygulandıktan sonra sonucu birlikte doğruluyoruz.

Sitemap lastmod ile Last-Modified başlığını nasıl uyumlu tutarsınız?

Site haritasındaki lastmod etiketi ile HTTP Last-Modified başlığı farklı yerlerde yaşar ama aynı soruya cevap verir: bu sayfa en son ne zaman anlamlı biçimde değişti? Google'ın site haritası belgesi, lastmod değerini tutarlı ve doğrulanabilir biçimde doğruysa kullandığını söyler. Örnek olarak da değeri sayfanın son değişikliğiyle karşılaştırmayı verir.

Bu iki değer birbirini tutmazsa ne olur? Örneğin site haritası bir sayfanın dün güncellendiğini söylerken sunucu Last-Modified başlığında aylar önceki bir tarihi gösteriyorsa, sinyaller çelişir. Bu çelişki, Google'ın lastmod değerine güvenmemesine yol açabilir.

Önerimiz basittir: iki değeri de tek bir kaynaktan, yani içeriğin "son anlamlı değişiklik" alanından üretin. Lastmod etiketinin doğru kullanımını sitemap lastmod rehberimizde, site haritasının temel yapısını ise site haritası nedir ve nasıl oluşturulur yazımızda ayrıntılı anlattık. Böylece Google hem site haritasında hem HTTP yanıtında aynı hikâyeyi görür.

Hangi hatalar 304 kurgusunu tehlikeli hale getirir?

304 Not Modified desteğini kurarken en çok zarar veren hatalar, verimlilik kazancını değil içerik doğruluğunu bozan hatalardır. Denetimlerde en sık gördüğümüz riskli durumları şöyle sıralayabiliriz:

• İçerik değiştiği halde 304 dönmesi; Google eski sürümü kullanmaya devam eder.
• Bakım ya da hata durumunda sunucunun gövdesiz 304 döndürmesi; sorunu gizler.
• Yönlendirme yapılan adreslerde eski ETag ile 304 dönmesi; Google yeni hedefi göremez.
• Noindex ya da canonical değişikliği yapılan sayfaların önbellekte eski başlıklarla kalması.
• Mobil ve masaüstü için farklı HTML sunan sitelerde iki sürüme aynı etiketin verilmesi.

Bu hataların ortak noktası şudur: sistem "değişmedi" derken gerçekte bir şey değişmiştir. Bu nedenle 304 kurgusunu test ederken yalnız "304 geliyor mu" diye değil, "değiştiğinde 200 geliyor mu" diye de bakın. İkinci soru, birincisinden daha önemlidir.

Özellikle büyük bir şablon değişikliği, alan adı taşıma ya da yeni tema yayını öncesinde önbelleği bilinçli olarak temizlemek ve ilk taramaları loglardan izlemek güvenli bir alışkanlıktır.

Bu işi ne zaman bir SEO ekibine devretmelisiniz?

Koşullu istekler kâğıt üzerinde basit duruyor. Ancak gerçek sitelerde kaynak sunucu, önbellek eklentisi, CDN, yük dengeleyici ve içerik yönetim sistemi aynı anda devreye girer. Sorunun hangi katmanda olduğunu bulmak, çoğu zaman log, başlık ve Search Console verisini birlikte okumayı gerektirir.

Şu durumlardan biri sizin için geçerliyse destek almanızı öneriyoruz:

• Binlerce sayfanız var ve Googlebot önemli sayfalara geç uğruyor.
• Google, güncellediğiniz içeriği uzun süre eski haliyle gösteriyor.
• Tarama istatistiklerinde sunucu hataları ya da yüksek yanıt süreleri dikkat çekiyor.
• Yeni bir CDN ya da önbellek katmanına geçmeyi planlıyorsunuz.

Biz bu tür teknik tarama sorunlarını sitenizde tespit ediyor, geliştirici ekibinize net uygulama adımları veriyor ve sonucu düzenli olarak takip ediyoruz. Sıralama garantisi vermiyoruz; ancak Google'ın resmi belgelerine dayanan, ölçülebilir bir iyileştirme süreci kuruyoruz. Sitenize özel bir teklif almak için SEO danışmanlığı sayfamızdan bize ulaşabilirsiniz.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.