Önbelleğe alınmış herkese açık bir sayfayı yenilemek için güncellenmiş belgeyi yayımlayın, belgeyi sunan paylaşılan önbelleği temizleyin ve sonucu Mac tarayıcınızda doğrulayın. Google hâlâ eski içeriği gösteriyorsa ayrıca yeniden tarama isteyin; tarayıcınızı yenilemek Google dizinini güncellemez.
Bu kılavuz, mevcut URL'deki güncellenmiş içeriğin okuyuculara ulaşmasını isteyen herkese açık bir belgeyi yöneten kişiler içindir. Masaüstü adımlarında macOS üzerinde Chrome kullanılır. Sürümleri iş akışı boyunca ayırt etmeyi kolaylaştırmak için “Revizyon A: daireler” ifadesinden “Revizyon B: daireler ve kareler” ifadesine geçen kurgusal bir “Kağıt Şekiller Kılavuzu” kullanılır.
Kaynağı düzenlemek neden önbelleğe alınmış her sayfayı yenilemez?
HTTP geçersizleştirme, depolanmış bir yanıtı kaldırır veya yeniden kullanılmadan önce doğrulama yapılmasını zorunlu kılar. RFC 9111, önbellekten geçen başarılı bir durum değiştirme isteğinden sonra önbelleğin hedef URI'yi geçersiz kılmasını şart koşar; ancak bunun kopyaları küresel olarak geçersiz kılmadığını açıkça belirtir. Bu nedenle bir yayımlama iş akışı, düzenleme isteğinin izlediği yolun dışındaki önbellekleri de hesaba katmalıdır. RFC 9111: Depolanmış Yanıtları Geçersiz Kılma.
Kağıt Şekiller Kılavuzu için düzenlemeden etkilenen çıktılara dair kısa bir kontrol listesi hazırlayın. Güncellenen metin bir koleksiyon sayfasında da görünüyorsa o sayfayı da ekleyin. Yalnızca kılavuz değişiyorsa listeyi o belgeyle sınırlayın. Bu bağımlılık kontrol listesi editoryal bir yardımcıdır: değiştirilen kaynaktan başlayın ve artık farklı bir şey göstermesi gereken yayımlanmış her belgeyi belirleyin.
Sonraki adımı seçmek için aşağıdaki sıralamayı kullanın. Her sonucu, tüm okuyucuların aynı yanıtı aldığının kanıtı olarak değil, bir tanılama ipucu olarak değerlendirin.
| Gözlem | Sonra neyi kontrol etmeli? |
|---|---|
| Yayımlama sistemi, yayımlanmış çıktıda hâlâ Revizyon A'yı gösteriyor | Revizyon B'nin başarıyla yayımlandığını veya yeniden oluşturulduğunu doğrulayın. |
| Yayımlanmış çıktı Revizyon B, ancak tarayıcı ağ yenilemesi Revizyon A'yı alıyor | Paylaşılan önbelleği veya sunucunun sunduğu belgeyi inceleyin. |
| Ağ yenilemesi Revizyon B'yi, sıradan yenileme ise Revizyon A'yı gösteriyor | Yerel tarayıcı önbelleğini ve yanıtın önbellekleme politikasını inceleyin. |
| Herkese açık sayfa Revizyon B'yi gösteriyor, ancak Google'ın dizine eklenmiş bilgileri eski | Search Console'un canlı testini kullanın, ardından dizine eklenmesini istemeyi değerlendirin. |
Google, son satırın ardındaki farkı açıklıyor: URL Denetleme'nin ilk raporu dizine eklenmiş sürümü tanımlarken canlı testi mevcut sayfayı getirir. Dolayısıyla eski bir dizin raporu, düzeltilmiş herkese açık belgeyle aynı anda bulunabilir. URL Denetleme aracı.
Önbelleği temizlemeden önce değiştirilen belgeyi yayımlayın
Önce herkese açık URL'yi ve beklenen değişikliği kaydedin. Bu kurgusal örnekte beklenen cümle “Revizyon B: daireler ve kareler.” şeklindedir. Belgeye zaten uygun olan, ayırt edici bir cümle kullanın; amaç, bir sekmenin ne zaman açıldığına bağlı kalmadan yeni çıktıyı tanımaktır.
Düzenlemeyi mevcut yayımlama sisteminiz üzerinden yayımlayın. Sistem kaynak dosyalardan belge oluşturuyorsa yayımlanan çıktıda güncellenmiş cümlenin bulunduğunu doğrulayın. Kaynak içeriği kaydetmek ve herkese açık belgeyi oluşturmak bu iş akışında ayrı kontrol noktalarıdır; platformunuzun belgelenmiş yayımlama sürecini izleyin.
Ardından, varsa paylaşılan önbelleği geçersiz kılın. Sıralama önemlidir: Örneğin Cloudflare, temizleme sonrasındaki isteklerin kaynaktan kaynağı getirdiğini ve CDN önbelleğine yeniden eklediğini belgeliyor. Kaynak sunucu hâlâ eski belgeyi sunarken önbelleği temizlemek, önbelleğin eski belgeyle yeniden doldurulmasına yol açabilir. Tek dosyaya göre temizleme.
Cloudflare için belgelenmiş bir kontrol paneli örneği
Herkese açık sayfanız Cloudflare önbelleğini kullanıyorsa, belgelenmiş tek dosya temizleme işlemi tarayıcı üzerinden izlenebilecek somut bir yol sunar:
- İlgili sitenin Cloudflare kontrol panelini açın ve
Configurationbölümüne gidin. Purge CachealtındaCustom Purgeseçeneğini belirleyin.Purge byaltındaURLseçeneğini belirleyin.- Etkilenen her belgenin herkese açık tam URL'sini girin.
- Girdileri gözden geçirin ve
Purgeseçeneğini belirleyin.
Bu etiketler ve adımlar Cloudflare'ın tek dosya temizleme talimatlarından alınmıştır.
Bir temizleme işlemini tekrarlamadan önce belgelenmiş sınırları kontrol edin. Bir yönlendirmeyi temizlemek yönlendirme yanıtını siler; içeriği yenilemek için hedef URL'yi temizleyin. Bazı özel önbellek anahtarları, URL kontrol paneli formu üzerinden temizlenemez; Cloudflare, alternatifler arasında önek veya etiket temizlemeyi belgeliyor. Tek dosya temizlemede joker karakterler de kabul edilmez. Temizleme sınırlamaları ve alternatifler.
Başka bir barındırma sağlayıcısı veya CDN kullanıyorsanız, o sağlayıcının belgelenmiş geçersiz kılma denetimini kullanın. Cloudflare süreci koşullu bir örnektir; tüm arayüzlerde geçerli değildir. Yayımlama hizmetiniz bir temizleme işlemi sunmuyorsa, bir temizleme URL'si uydurmak veya tarayıcıdaki bir düğmenin sunucularını kontrol ettiğini varsaymak yerine, belgelenmiş önbellek ömrünü ve yenileme davranışını inceleyin.
Mac'inizde herkese açık yanıtı doğrulayın
Sayfanın mevcut herkese açık URL'sini Chrome'da açın. DevTools'u açmak için Command–Option–I tuşlarına basın, ardından Network sekmesini seçin. Chrome bu Mac kısayolunu belgeler ve normal yenileme, zorla yenileme ve önbelleği boşaltarak yenileme seçeneklerini birbirinden ayırır. Chrome DevTools'u açma.
DevTools açıkken Network panelinde Disable cache seçeneğini belirleyin ve sayfayı yenileyin. Chrome, bu ayarın normal yenilemelerde kendi önbelleğinin kullanılmasını önlediğini belgeliyor. Kontrol boyunca DevTools'u açık tutun. Önbellekle veya önbellek olmadan yenileme.
Ağ listesinden ana belge isteğini seçin. Yanıt başlıklarını incelemek için Headers, döndürülen içeriği incelemek için Response sekmesini açın. Belgede beklenen Revizyon B cümlesini arayın. Chrome'un ağ öğreticisi, tek tek isteklerin, başlıkların ve yanıt içeriğinin nasıl inceleneceğini açıklar. Ağ etkinliğini inceleme.
Üç gözlemi kaydedin: istenen URL'yi, döndürülen belgede Revizyon B'nin bulunup bulunmadığını ve belgeyle birlikte sunulan önbellekleme başlıklarını. Böylece temizleme sonrasında yararlı bir karşılaştırma yapabilirsiniz. Kontrol panelindeki işlemin başarıyla tamamlanması bir kontrol noktasıdır; amaçlanan belgenin alınması ise okuyucunun anlık gereksinimini karşılayan kontrol noktasıdır.
Ardından Disable cache seçeneğini kapatıp sayfayı yeniden yenileyin. Sonucu ağ testiyle karşılaştırın. İki sonuç uyuşmuyorsa yanıt politikasını incelerken her iki gözlemi de saklayın. Aradaki farkı kaydetmeden tarayıcı önbelleğini tekrar tekrar temizlemek, nedeni belirlemeyi zorlaştırır.
WHATWG Fetch Standardı, tarayıcı getirme kiplerinin neden önemli olduğunu açıklar. reload kipi, ağ isteği sırasında tarayıcının HTTP önbelleğini atlar ve yanıtı temel alarak bu önbelleği günceller. no-cache kipi ise önbelleğe alınmış bir yanıt bulunduğunda koşullu istek yapar. Bunlar istek davranışlarıdır; dolayısıyla hiçbiri paylaşılan önbelleğe alınmış sayfaları küresel olarak temizlemez. Fetch Standardı: istek önbelleği kipleri.
Gelecekteki düzenlemelere uygun bir önbellekleme politikası seçin
Her kullanım öncesinde kontrol edilmesi gereken herkese açık bir belge için Cache-Control: no-cache yanıt yönergesini değerlendirin. Bu yönerge depolamaya izin verir, ancak yeniden kullanım öncesinde başarılı doğrulama gerektirir. Cache-Control: no-store ise depolamayı yasaklar. Bir yanıtın max-age değeri tazelik süresini belirtir; must-revalidate ise yanıt güncelliğini yitirdikten sonra geçerlidir. Bu yönergeler farklı gereksinimleri karşılar. RFC 9111: Yanıt Cache-Control yönergeleri.
Örnek olarak, Kağıt Şekiller Kılavuzu'nun ara sıra değiştiğini ve her ziyarette güncellemeleri kontrol etmenin kabul edilebilir olduğunu varsayalım. Barındırma yapılandırmasını yapan kişiyle yeniden doğrulama politikasını görüşmek makul olur. Ağ kontrolü olmadan yeniden kullanım tercih ediliyorsa, eski bir revizyonun ne kadar süre kabul edilebilir olduğuna uygun bir tazelik süresi seçin ve daha erken güncellemeler için belgelenmiş bir temizleme süreci bulundurun.
Yeni yayımlanan bir yanıttaki politika değişikliği, hâlâ eski ve taze bir yanıtı yeniden kullanan tarayıcıya sunucuyla iletişim kurmadan bildirim gönderemez. Bu nedenle geçiş sırasında mevcut önbelleğe alınmış kopyalar da hesaba katılmalıdır. Bu durum HTTP'nin tazelik ve yeniden kullanım kurallarından kaynaklanır; yeni bir başlık ayarının, mevcut kopyalar için açık bir planla birlikte uygulanmasının nedeni budur. RFC 9111: Önbelleklerden Yanıt Oluşturma.
Doğrulamanın revizyonu tanıdığından emin olun
ETag, doğrulama için bir gösterimi tanımlar. Last-Modified ise değiştirilme zamanını bildirir. Sunucudan, diğer kaynaklardan bir araya getirilen içerikteki ilgili değişiklikler dâhil olmak üzere yayımlanan gösterimi yansıtan doğrulayıcılar üretmesini isteyin. RFC 9110 her iki doğrulayıcıyı da açıklar ve bazı durumlarda varlık etiketlerinin gösterimleri değiştirilme tarihlerinden daha güvenilir biçimde ayırt edebildiğini belirtir. RFC 9110: Doğrulayıcı Alanları.
304 Not Modified yanıtı, alıcıya belgeyi yeniden aktarmak yerine geçerli, depolanmış bir gösterimi yeniden kullanmasını söyler. Depolanmış revizyon güncelse bu normaldir. İçerik değişikliğini doğrulamanıza rağmen Revizyon A'yı görmeye devam ederken bu sonucu alıyorsanız, sunucunun hangi gösterimi ve doğrulayıcıyı değerlendirdiğini araştırın. RFC 9110: 304 Not Modified.
Google'dan düzeltilmiş sayfayı yeniden ziyaret etmesini isteyin
Herkese açık belge sürekli olarak Revizyon B'yi sunduktan sonra, uygun Search Console mülkünde tam URL'sini inceleyin. Mevcut sayfayı incelemek için Test live URL seçeneğini belirleyin. Bu sonucu, daha eski bir taramayı açıklıyor olabilecek dizin raporuyla karşılaştırın. Canlı test mevcut sayfayı kontrol eder; Google dizininin güncellendiğini tek başına göstermez. URL Denetleme aracı.
Güncellenmiş tek bir sayfa için denetleme sonucunda Request indexing seçeneğini belirleyin. Search Console mülkünün sahibi veya tam yetkili kullanıcısı olmanız gerekir. Google, taramanın birkaç günden birkaç haftaya kadar sürebileceğini, tekrar tekrar istekte bulunmanın süreci hızlandırmayacağını ve tarama isteğinin sayfanın arama sonuçlarına eklenmesini garanti etmediğini belirtiyor. Google'dan URL'lerinizi yeniden taramasını isteme.
Güncellenmiş çok sayıda sayfa için Google bir site haritası göndermenizi öneriyor. <lastmod> değerlerini doğru tutun: Google, bu değerlerin telif hakkı tarihinin rutin olarak değiştirilmesi gibi durumları değil, ana içerik güncellemeleri gibi önemli değişiklikleri yansıtması gerektiğini belirtiyor. Site haritası, değişen belgeleri bildirmeye yardımcı olur; tarayıcı veya CDN kopyalarını temizlemez. Site Haritası Oluşturma ve Gönderme.
Küçük bir yayımlama kaydı tutarak işlemi tamamlayın: etkilenen URL'ler, beklenen revizyon cümlesi, yayımlanan çıktı kontrolü, paylaşılan önbellek işlemi ve tarayıcı doğrulama sonucu. Google'dan yeniden tarama isteğini ayrı olarak izleyin. Böylece ilk hedef, yani güncellenmiş herkese açık belgenin sunulması gözlemlenebilir kalırken eski sürümün hâlâ göründüğü her durum için bir sonraki adım da açıkça belirtilmiş olur.
Kaynaklar
- RFC 9111: HTTP Önbellekleme — IETF / RFC Editor.
- RFC 9110: HTTP Semantiği — IETF / RFC Editor.
- Fetch Standardı — WHATWG.
- Tek dosyaya göre temizleme — Cloudflare.
- Chrome DevTools'u açma — Google Chrome for Developers.
- Ağ etkinliğini inceleme — Google Chrome for Developers.
- URL Denetleme aracı — Google Search Console Help.
- Google'dan URL'lerinizi yeniden taramasını isteme — Google Search Central.
- Site Haritası Oluşturma ve Gönderme — Google Search Central.