Eski başlık arama sonuçlarında görünüyorsa hangi önbellek katmanları?

Önce kaynağı ayırın: cache mi, dizindeki sürüm mü, title rewrite mı?

Başlık etiketini güncellediğiniz halde arama sonucunda eski sürüm görünüyorsa ilk hata, sorunu doğrudan CDN cache diye etiketlemektir. Teknik teşhiste üç ayrı ihtimali birbirinden koparmak gerekir: kullanıcının veya botun gördüğü HTML’nin eski olması, Google’ın dizinindeki kopyanın henüz güncellenmemesi ve Google’ın yeni HTML’yi görse bile başlığı farklı üretmesi. Bu ayrımı yapmadan purge atmak, tekrar tarama istemek veya canonical değiştirmek çoğu zaman yalnızca süre kaybettirir.

Google’ın Google Arama’daki Başlık Bağlantılarını Etkileme dokümanında da açıkça anlatıldığı gibi başlık bağlantıları yalnızca title etiketi ile oluşmaz; görünür başlık, bağlantı metni ve sorgu bağlamı da devreye girebilir. Dokümanın 18 Aralık 2025 vurgusu, yeniden işleme süresinin birkaç gün ile birkaç hafta arasında değişebildiğini özellikle hatırlatır. Bu yüzden kaynak kodda doğru title’ı görmek, tek başına SERP’te aynı metnin hemen görüneceği anlamına gelmez.

İlk kontrolde yalnızca title etiketine bakmayın. og:title, H1, breadcrumb metni, yapılandırılmış verideki başlık benzeri alanlar ve rendered HTML içindeki görünür başlık dili birbirini itiyorsa Google farklı bir title link seçebilir. Özellikle CMS eklentileri, tema katmanları veya A/B test araçları sunucuda bir title, istemci tarafında başka bir başlık üretebiliyor. Bu uyumsuzluk varsa sorun cache’den çok sunum mantığında olabilir.

• Canlı kaynak kodda yeni title var ama URL Denetleme dizindeki sürümde eski title görünüyorsa sorun büyük olasılıkla Google’ın elindeki kopyadadır.
• Canlı ve dizindeki sürüm aynı olduğu halde SERP farklıysa title rewrite veya canonical kümesi daha güçlü adaydır.
• Tarayıcı ve curl çıktısı farklıysa önce yerel cache, servis worker veya CDN katmanını dışlayın.

Hangi önbellek katmanları incelenmeli: tarayıcı, CDN, reverse proxy ve origin

Eski başlığın takıldığı katmanı bulmak için tarayıcı cache, paylaşımlı cache, CDN, reverse proxy ve origin zincirini ayrı okumak gerekir. En pratik yöntem, aynı URL’yi hem tarayıcıda hem de terminalden header düzeyinde incelemektir. Özellikle Cache-Control, Age, ETag ve Last-Modified kombinasyonu size eski HTML’nin nerede tutulduğunu söyler. Age değeri artıyorsa paylaşımlı bir cache katmanı devrededir; Age yok ama 304 dönüyorsa koşullu istek zinciri eski kopyayı yaşatıyor olabilir.

MDN HTTP caching rehberinin Temmuz 2026 güncel ayrımı burada kritik: no-cache kopyayı yasaklamaz, yeniden doğrulama ister; no-store ise yeni bir kopya saklanmamasını söyler ama istemcide var olan eski kopyayı sihirli biçimde temizlemez. Bu fark yanlış anlaşıldığında ekipler no-cache gördüğü için her şeyin güncel olduğunu sanıyor. Oysa Googlebot veya ara katman, ETag ya da Last-Modified ile 304 alıp önceki HTML’yi kullanmaya devam edebilir.

Reverse proxy ve origin tarafında da durum aynıdır. Uygulama sunucusu title’ı değiştirmiş olabilir, fakat Nginx, Varnish ya da host paneli üstündeki tam sayfa cache eski yanıtı vermeyi sürdürebilir. CDN purge başarılı görünse bile origin’den gelen ETag değişmemişse veya yanlış varyant purge edilmişse problem geri döner. Bu nedenle yalnızca panel ekranına değil, yanıt başlıklarının fiili sonucuna bakmak gerekir.

• Tarayıcı cache: Gizli pencerede ve hard refresh sonrası title aynı mı kontrol edin.
• CDN cache: Age, x-cache, cf-cache-status benzeri başlıklar eski nesnenin taşınmasını gösterir.
• Reverse proxy: Origin’e bypass ederek alınan yanıt ile standart istek farklı mı bakın.
• Origin: ETag ve Last-Modified gerçekten değişti mi, yoksa uygulama eski değeri mi döndürüyor kontrol edin.

Google tarafında hangi sürüm var: URL Denetleme, canlı URL ve dizindeki kopya

Search Console tarafında sorulması gereken temel soru şudur: Google şu anda hangi HTML’yi biliyor? URL Denetleme Aracı bu ayrımı yapmanızı sağlar, çünkü canlı test ile dizindeki sürüm aynı şey değildir. Google Search Console Yardımı da bu iki görünümün farklı olabileceğini net biçimde söyler. Teknik olarak canlı test anlık erişimi temsil eder; dizindeki sürüm ise Google’ın daha önce işleyip tuttuğu kopyadır.

Pratik akışta önce canlı testi çalıştırın ve yeni title’ın orada görünüp görünmediğini teyit edin. Ardından dizindeki sürümü kontrol edin. Canlı testte yeni, dizinde eski başlık varsa yeniden tarama ve yeniden işleme bekleniyordur. Canlı testte de eski görünüyorsa hâlâ yayın veya cache katmanındasınız. Bu ayrım, yanlış kişiyi suçlamayı önler: Search Console sorunu değilse CDN ekibine, CDN sorunu değilse içerik ekibine dönersiniz.

Yeniden dizine ekleme isteği süreci hızlandırabilir ama garanti vermez. Google’ın Eski İçeriği Yenileme aracı ve URL Denetleme yardımı birlikte okunduğunda, görünürlük güncellemesinin tarama sıklığına, işlem kuyruğuna ve canonical seçim sinyallerine bağlı değişebildiği görülür. Bu aşamada XML sitemap içindeki lastmod değerinin güncel olması, Crawl Stats raporunda bot hareketinin görülmesi ve başlık değişiminin tek URL ile sınırlı mı yoksa şablon çapında mı olduğunu anlamak operasyonu netleştirir.

Canonical, yönlendirme ve varyant URL’ler eski başlığı nasıl yaşatır?

Canlı sayfada doğru title görünse bile Google başka bir temsilci URL seçiyorsa arama sonucunda beklemediğiniz başlık çıkabilir. Özellikle http/https, www/non-www, parametreli sürümler, mobil varyantlar ve eski AMP kopyaları aynı içeriğin kümelenmesine yol açar. Google’ın 10 Temmuz 2026 güncellemesi taşıyan What is canonicalization dokümanı, canonical seçiminin tek sinyalle değil birden çok işaretle yapıldığını vurgular. Canonical etiketi doğru olsa bile iç linkleme, yönlendirme ve sitemap başka şey söylüyorsa farklı URL öne çıkabilir.

Bu yüzden yalnızca rel=canonical satırına bakmak yeterli değildir. 301 yönlendirme zinciri uzunsa, bir varyant noindex ise, robots.txt render dosyalarını engelliyorsa veya JavaScript başlığı geç enjekte ediyorsa yeni başlığın yeniden işlenmesi gecikebilir. Googlebot koşullu istekler ve render kısıtları yüzünden beklediğiniz title’ı görmeyebilir; Troubleshoot Google Search crawling errors dokümanı tarama erişimi ve sunucu yanıtları tarafını bu nedenle ayrı ele alır.

• http ve https sürümleri aynı başlığı mı, farklı başlığı mı döndürüyor kontrol edin.
• www ve non-www arasında tek adımlı yönlendirme olduğundan emin olun.
• Parametreli URL’lerde eski title şablonu kalmışsa temsilci seçim bozulabilir.
• Mobil şablon, SSR çıktısı veya rendered HTML masaüstüyle aynı title’ı veriyor mu doğrulayın.
• robots.txt, noindex ve render engelleri yeni başlığın görülmesini geciktirebilir.

72 saatlik vaka günlüğü: canlı HTML, purge log ve GSC ekranları ne söyledi?

Yakın dönem teknik teşhis günlüklerimizden birinde aynı URL’deki title güncellemesi yayına alındıktan sonra arama sonucunda eski başlık 72 saat daha görünmeye devam etti. İlk saatte kaynak kod ve rendered HTML kontrolünde yeni başlık doğru görünüyordu. İkinci saatte CDN purge log’u başarılıydı. Buna rağmen ekip SERP ekran görüntülerinde eski başlığı görmeye devam ettiği için sorun ilk bakışta Google gecikmesi gibi okundu.

Zaman çizelgesini yan yana koyunca tablo değişti. 18. saatte URL Denetleme canlı testi yeni title’ı gösterdi, fakat dizindeki sürüm hâlâ eskiydi. 26. saatte curl ile alınan bazı varyant isteklerde eski ETag’nin dönmeye devam ettiği fark edildi; kök sorun, bir parametreli sürümün reverse proxy katmanında purge dışında kalmasıydı. 41. saatte canonical zinciri düzeltildi, ETag yenilendi ve sonrasında dizinlenmiş sürüm de güncellenmeye başladı. 72. saatte SERP yeni başlığa geçti.

Bu vaka bize şunu net biçimde gösterdi: sorun yalnızca “Google geç güncelledi” değildi. Canlı HTML, purge kaydı ve GSC ekranı aynı zaman çizelgesinde okunmadığında cache sorunu ile title rewrite kararı birbirine karışıyor. Eğer canlı test yeni, dizin eski ve canonical temizse beklemek mantıklıdır. Ama bazı varyantlarda eski ETag veya yanlış temsilci URL görünüyorsa beklemek yerine teknik katmanı düzeltmek gerekir.

Adım Adım Eski SERP Başlığının Takıldığı Katmanı Teşhis Etme

Bu akış, eski başlık problemini en az yanlış hamleyle ayırmak için kullanılabilir. Amaç her adımda tek bir soruya cevap vermektir: yeni başlık gerçekten yayında mı, cache zinciri temiz mi, Google hangi sürümü tutuyor ve hangi URL’yi temsilci seçiyor?

1. Canlı sayfada title değişimini doğrula. Kaynak kodu ve rendered HTML’yi ayrı kontrol edin. Title, og:title ve H1 arasında uyumsuzluk varsa bunu not alın. Eğer istemci tarafında sonradan yazılan bir başlık varsa Googlebot’un gördüğü çıktı ile editörün gördüğü çıktı aynı olmayabilir.
2. Header düzeyinde cache zincirini kontrol et. curl ile Cache-Control, Age, ETag ve Last-Modified başlıklarını alın. Tarayıcıda yeni görünen ama terminalde eski dönen bir cevap, yerel görüntüyle gerçek sunum katmanının karıştığını gösterir. Aynı anda CDN paneli değil, fiili HTTP yanıtı karar vermelidir.
3. URL Denetleme ile iki sürümü karşılaştır. Canlı testte yeni title, dizindeki sürümde eski title görünüyorsa sorun Google’ın elindeki kopyadadır. Her iki tarafta da yeni title varsa ama SERP farklıysa title rewrite veya canonical ihtimali güçlenir.
4. Canonical ve varyant URL’leri denetle. http/https, www, mobil, parametreli ve eski kampanya URL’lerini kontrol edin. Yanlış canonical, eksik yönlendirme veya parametreli varyantlar, Google’ın başka başlığı temsilci olarak göstermesine neden olabilir.
5. Purge, yeniden tarama ve izlemeyi tamamla. Gerekli purge işlemini doğrulayıp yeniden dizine ekleme isteği gönderin. Ardından değişimi ekran görüntüsüyle değil, düzenli SERP ve tarama takibiyle izleyin; aksi halde geçici veri merkezi farklarını gerçek sorun sanabilirsiniz.

Ekip içi eğitim için Search Central’ın resmi URL Denetleme anlatımlarını referans almak da yararlıdır; asıl kritik nokta ise bu adımları aynı sıra ile uygulamaktır. Sıra bozulduğunda bir önceki katmandaki hata sonraki katmanda semptom gibi görünür.

Düzeltme akışı ve SEOYEN ile kalıcı izleme

Kalıcı çözüm için önerdiğimiz sıra nettir: önce canlı HTML, sonra header zinciri, ardından URL Denetleme karşılaştırması, sonra canonical ve varyant URL kontrolü, en sonda yeniden tarama isteği. Bu sıra sayesinde “önce purge, sonra bakarız” yaklaşımı yerine kanıt temelli ilerlersiniz. Özellikle birden fazla şablonda başlık güncellemesi yapıyorsanız kontrol listesini standartlaştırmak, aynı hatanın tekrarını ciddi biçimde azaltır.

İzleme tarafında iş yalnızca bir defalık teşhisle bitmez. Teknik sorunların yayılımını görmek için site sağlığı denetimi faydalıdır; hangi URL varyantlarının tutarsız başlık, canonical veya tarama problemi ürettiğini toplu görmenizi sağlar. Başlığın SERP’e ne zaman yansıdığını operasyonel olarak takip etmek için de sıralama takibi kritik olur. SEOYEN bu iki akışı tek platformda, Türkçe arayüz ve yerel Türkçe destekle birleştirdiği için ekip içi devir teslim daha hızlı yapılabilir.

Ahrefs ve SEMrush benzeri araçlar veri görünürlüğü sunar; ancak Türkiye pazarında günlük teknik operasyonu tek yerde toplamak isteyen ekipler için SEOYEN’in yerel kullanım akışı daha pratiktir. Bu farkı ayrıntılı görmek isterseniz Ahrefs karşılaştırması ve SEMrush karşılaştırması sayfaları bağlam sağlar. Planlama tarafında da sabit rakama bağlı kalmadan güncel fiyatlandırma üzerinden ilerlemek, içerik ve operasyon kararlarını daha temiz tutar.

Sıkça Sorulan Sorular