Untuk memperbarui halaman publik yang tersimpan di cache, publikasikan dokumen yang telah diperbarui, hapus cache bersama yang menyajikannya, lalu verifikasi hasilnya di browser Mac Anda. Jika Google masih menampilkan konten lama, minta perayapan ulang secara terpisah; menyegarkan browser tidak memperbarui indeks Google.

Panduan ini ditujukan bagi seseorang yang mengelola dokumen publik dan perlu memastikan pembaca menerima konten revisinya di URL yang sudah ada. Langkah desktop menggunakan Chrome di macOS. Contoh sintetis “Panduan Bentuk Kertas,” yang berubah dari “Revisi A: lingkaran” menjadi “Revisi B: lingkaran dan persegi,” memberikan cara sederhana untuk membedakan versi selama seluruh alur kerja.

Mengapa mengedit sumber tidak menyegarkan setiap halaman yang tersimpan di cache?

Invalidasi HTTP menghapus respons yang tersimpan atau mewajibkan validasi sebelum respons digunakan kembali. RFC 9111 mewajibkan cache menginvalidasi URI target setelah permintaan yang berhasil dan mengubah status melewati cache tersebut, tetapi secara eksplisit menyatakan bahwa ini tidak menginvalidasi salinan secara global. Karena itu, alur kerja publikasi perlu memperhitungkan cache di luar jalur permintaan pengeditan. RFC 9111: Menginvalidasi Respons Tersimpan.

Untuk Panduan Bentuk Kertas, buat daftar periksa singkat tentang keluaran yang terdampak oleh pengeditan. Jika teks yang direvisi juga muncul di halaman koleksi, sertakan halaman tersebut. Jika hanya panduan yang berubah, batasi daftar periksa pada dokumen itu. Daftar dependensi ini merupakan bantuan editorial: mulai dari sumber yang berubah dan identifikasi setiap dokumen terbitan yang kini seharusnya menampilkan sesuatu yang berbeda.

Gunakan urutan berikut untuk menentukan tindakan selanjutnya. Perlakukan setiap hasil sebagai petunjuk diagnostik, bukan bukti bahwa setiap pembaca menerima respons yang sama.

Yang Anda amati Hal berikutnya yang perlu diperiksa
Sistem publikasi masih menampilkan Revisi A dalam keluaran terbitannya Pastikan Revisi B berhasil dipublikasikan atau dibangun ulang.
Keluaran terbitan adalah Revisi B, tetapi pemuatan ulang jaringan di browser menerima Revisi A Selidiki cache bersama atau dokumen yang disajikan oleh host.
Pemuatan ulang jaringan menampilkan Revisi B, sedangkan pemuatan ulang biasa menampilkan Revisi A Selidiki cache lokal browser dan kebijakan caching respons.
Halaman publik menampilkan Revisi B, tetapi informasi yang diindeks Google masih lama Gunakan pengujian langsung Search Console, lalu pertimbangkan untuk meminta pengindeksan.

Google menjelaskan perbedaan yang mendasari baris terakhir: laporan awal Inspeksi URL menjelaskan versi yang diindeks, sedangkan pengujian langsung mengambil halaman saat ini. Karena itu, laporan indeks lama dapat muncul bersamaan dengan dokumen publik yang sudah diperbaiki. Alat Inspeksi URL.

Publikasikan dokumen yang diubah sebelum menghapus cache-nya

Pertama, catat URL publik yang tepat dan perubahan yang diharapkan. Untuk contoh sintetis ini, kalimat yang diharapkan adalah “Revisi B: lingkaran dan persegi.” Gunakan kalimat khas yang memang sesuai untuk dokumen tersebut; tujuannya adalah mengenali keluaran baru tanpa bergantung pada kapan tab dibuka.

Publikasikan perubahan melalui sistem publikasi yang sudah Anda gunakan. Jika sistem tersebut membangun dokumen dari berkas sumber, pastikan keluarannya yang terbit menyertakan kalimat revisi. Menyimpan konten sumber dan menghasilkan dokumen publik merupakan dua titik pemeriksaan yang terpisah dalam alur kerja ini; ikuti prosedur publikasi yang didokumentasikan untuk platform Anda.

Kemudian invalidasi cache bersama, jika ada. Urutannya penting: misalnya, Cloudflare mendokumentasikan bahwa permintaan setelah penghapusan cache mengambil sumber daya dari origin dan menambahkannya kembali ke cache CDN. Menghapus cache saat origin masih menyajikan dokumen lama dapat mengisi ulang cache dengan dokumen lama tersebut. Hapus cache per satu file.

Contoh dasbor Cloudflare yang terdokumentasi

Jika halaman publik Anda menggunakan caching Cloudflare, penghapusan cache satu file yang terdokumentasi menyediakan langkah konkret melalui browser:

  1. Buka dasbor Cloudflare untuk situs terkait, lalu buka Configuration.
  2. Di bawah Purge Cache, pilih Custom Purge.
  3. Di bawah Purge by, pilih URL.
  4. Masukkan URL publik yang tepat untuk setiap dokumen yang terdampak.
  5. Tinjau entri, lalu pilih Purge.

Label dan langkah ini berasal dari petunjuk penghapusan cache satu file Cloudflare.

Periksa batasan yang terdokumentasi sebelum mengulangi penghapusan cache. Menghapus cache redirect akan menghapus respons redirect, jadi hapus cache URL tujuan untuk memperbarui kontennya. Beberapa kunci cache khusus tidak dapat dihapus melalui formulir dasbor URL; Cloudflare mendokumentasikan penghapusan berdasarkan awalan atau tag sebagai beberapa alternatif. Penghapusan cache satu file juga tidak menerima wildcard. Batasan dan alternatif penghapusan cache.

Jika Anda menggunakan host atau CDN lain, gunakan kontrol invalidasi yang didokumentasikan oleh penyedia tersebut. Prosedur Cloudflare ini adalah contoh bersyarat, bukan antarmuka universal. Jika layanan publikasi Anda tidak menyediakan operasi penghapusan cache, periksa masa berlaku cache dan perilaku penyegaran yang didokumentasikan, alih-alih mengarang URL penghapusan cache atau berasumsi bahwa tombol di browser mengendalikan servernya.

Verifikasi respons publik di Mac Anda

Buka URL publik halaman yang sudah ada di Chrome. Tekan Command–Option–I untuk membuka DevTools, lalu pilih Network. Chrome mendokumentasikan pintasan Mac ini dan membedakan pemuatan ulang normal, pemuatan ulang paksa, serta pemuatan ulang yang mengosongkan cache. Buka Chrome DevTools.

Dengan DevTools terbuka, pilih Disable cache di panel Network, lalu muat ulang halaman. Chrome mendokumentasikan bahwa setelan ini membuat pemuatan ulang normal menghindari cache-nya. Biarkan DevTools tetap terbuka selama pemeriksaan. Muat ulang dengan atau tanpa cache.

Pilih permintaan dokumen utama dalam daftar jaringan. Buka Headers untuk memeriksa header respons dan Response untuk meninjau konten yang dikembalikan. Cari kalimat Revisi B yang diharapkan dalam dokumen tersebut. Tutorial jaringan Chrome menjelaskan cara memeriksa permintaan, header, dan konten respons satu per satu. Periksa aktivitas jaringan.

Catat tiga hal: URL yang diminta, apakah dokumen yang dikembalikan memuat Revisi B, dan header caching yang menyertainya. Ini memberi Anda perbandingan yang berguna setelah cache dihapus. Operasi dasbor yang berhasil merupakan satu titik pemeriksaan; menerima dokumen yang dimaksud adalah titik pemeriksaan yang menjawab kebutuhan langsung pembaca.

Lalu nonaktifkan Disable cache dan muat ulang lagi. Bandingkan hasilnya dengan pengujian jaringan. Jika keduanya berbeda, simpan kedua pengamatan saat meninjau kebijakan respons. Mengosongkan browser berulang kali tanpa mencatat perbedaannya membuat penyebabnya lebih sulit diketahui.

Fetch Standard WHATWG menjelaskan mengapa mode pengambilan browser berpengaruh. Mode reload melewati cache HTTP browser dalam perjalanan ke jaringan dan memperbarui cache tersebut dari respons. Mode no-cache membuat permintaan bersyarat ketika respons yang tersimpan di cache tersedia. Ini adalah perilaku permintaan, sehingga keduanya bukan penghapusan global halaman yang tersimpan di cache bersama. Fetch Standard: mode cache permintaan.

Pilih kebijakan caching yang sesuai untuk perubahan mendatang

Untuk dokumen publik yang sebaiknya diperiksa sebelum digunakan kembali, pertimbangkan direktif respons Cache-Control: no-cache. Direktif ini mengizinkan penyimpanan, tetapi mewajibkan validasi yang berhasil sebelum digunakan kembali. Cache-Control: no-store melarang penyimpanan. max-age pada respons menentukan masa berlaku kesegarannya; must-revalidate berlaku setelah respons menjadi kedaluwarsa. Direktif-direktif ini memenuhi kebutuhan yang berbeda. RFC 9111: Direktif Cache-Control Respons.

Sebagai contoh keputusan, anggap Panduan Bentuk Kertas sesekali berubah dan memeriksa pembaruan setiap kali dikunjungi dapat diterima. Validasi ulang adalah kebijakan yang wajar untuk dibahas dengan orang yang mengonfigurasi host. Jika penggunaan ulang tanpa pemeriksaan jaringan lebih diutamakan, pilih masa berlaku kesegaran yang sesuai dengan berapa lama revisi lama masih dapat diterima, dan siapkan prosedur penghapusan cache yang terdokumentasi untuk pembaruan lebih awal.

Mengubah kebijakan pada respons yang baru diterbitkan tidak dapat memberi tahu browser yang masih menggunakan ulang respons lama yang masih segar tanpa menghubungi server. Karena itu, salinan yang sudah tersimpan di cache tetap menjadi bagian dari proses transisi. Hal ini mengikuti aturan HTTP tentang kesegaran dan penggunaan ulang; itulah sebabnya setelan header baru perlu disertai rencana yang jelas untuk salinan yang sudah ada. RFC 9111: Membentuk Respons dari Cache.

Pastikan validasi mengenali revisi

ETag mengidentifikasi representasi untuk validasi. Last-Modified mencantumkan waktu modifikasinya. Minta server membuat validator yang mencerminkan representasi terbitan, termasuk perubahan terkait pada konten yang dirangkai dari sumber lain. RFC 9110 menjelaskan kedua validator dan menerangkan bahwa dalam beberapa situasi, tag entitas dapat membedakan representasi dengan lebih andal daripada tanggal modifikasi. RFC 9110: Field Validator.

Respons 304 Not Modified memberi tahu penerima untuk menggunakan kembali representasi tersimpan yang masih valid, alih-alih mentransfer dokumen lagi. Ini normal ketika revisi yang tersimpan masih terkini. Jika Anda menerima hasil tersebut tetapi masih melihat Revisi A setelah perubahan konten dikonfirmasi, selidiki representasi dan validator mana yang dievaluasi server. RFC 9110: 304 Not Modified.

Minta Google meninjau kembali halaman yang sudah diperbaiki

Setelah dokumen publik secara konsisten menyajikan Revisi B, periksa URL lengkapnya di properti Search Console yang sesuai. Pilih Test live URL untuk memeriksa halaman saat ini. Bandingkan hasilnya dengan laporan indeks, yang mungkin menjelaskan perayapan sebelumnya. Pengujian langsung memeriksa halaman saat ini; pengujian itu sendiri tidak memastikan bahwa indeks Google telah diperbarui. Alat Inspeksi URL.

Untuk satu halaman yang diperbarui, pilih Request indexing pada hasil inspeksinya. Anda harus menjadi pemilik atau pengguna penuh properti Search Console tersebut. Google menyatakan bahwa perayapan dapat memerlukan waktu beberapa hari hingga beberapa minggu, permintaan berulang tidak mempercepatnya, dan permintaan perayapan tidak menjamin halaman akan disertakan dalam hasil penelusuran. Minta Google merayapi ulang URL Anda.

Untuk banyak halaman yang diperbarui, Google merekomendasikan pengiriman sitemap. Pastikan nilai <lastmod> akurat: Google menyatakan bahwa nilai tersebut harus mencerminkan perubahan signifikan, seperti pembaruan pada konten utama, bukan perubahan rutin pada tanggal hak cipta. Sitemap membantu menyampaikan dokumen yang berubah; sitemap tidak menghapus salinan di browser atau CDN. Buat dan Kirim Sitemap.

Akhiri dengan catatan publikasi singkat: URL yang terdampak, kalimat revisi yang diharapkan, pemeriksaan keluaran terbitan, tindakan pada cache bersama, dan hasil verifikasi browser. Catat permintaan perayapan ulang Google secara terpisah. Dengan begitu, tujuan langsung—menyajikan dokumen publik yang telah direvisi—dapat diamati, sementara langkah selanjutnya tetap jelas jika versi lama masih muncul.

Sumber