若要重新整理快取的公開頁面，請發布更新後的文件、清除任何提供該頁面的共用快取，並在 Mac 瀏覽器中確認結果。如果 Google 仍顯示舊內容，請另外要求重新檢索；重新整理瀏覽器不會更新 Google 的索引。

本指南適用於維護公開文件，且需要讀者透過原有網址取得修訂內容的人。桌面操作步驟使用 macOS 上的 Chrome。本文以虛構的「Paper Shapes Guide」為例，將內容從「Revision A: circles」改為「Revision B: circles and squares」，讓你在整個流程中能輕易分辨不同版本。

為什麼編輯來源不會重新整理所有快取頁面？

HTTP 失效處理會移除已儲存的回應，或要求在再次使用前先進行驗證。RFC 9111 規定，快取收到成功且會變更狀態的請求並將其轉送後，必須使目標 URI 失效；但也明確指出，這不會讓全網的副本都失效。因此，發布流程需要考量編輯請求所經路徑之外的快取。RFC 9111：使已儲存的回應失效。

以 Paper Shapes Guide 為例，請列出受編輯影響的輸出項目。如果修訂文字也出現在彙整頁面，請將該頁面列入。如果只變更指南，清單就只列該文件。這份相依項目清單是編輯上的輔助工具：從變更的來源開始，找出每份現在應該有所不同的已發布文件。

請依照下列順序選擇下一個動作。將每項結果視為診斷線索，而非所有讀者都會收到相同回應的證明。

觀察到的情況 下一步檢查項目
發布系統的已發布輸出仍顯示 Revision A 確認 Revision B 已成功發布或重新建置。
已發布輸出是 Revision B，但瀏覽器透過網路重新載入收到 Revision A 調查共用快取，或主機提供的文件。
網路重新載入顯示 Revision B，但一般重新載入顯示 Revision A 調查本機瀏覽器快取與回應的快取政策。
公開頁面顯示 Revision B，但 Google 的索引資訊仍是舊內容 使用 Search Console 的即時測試，然後考慮要求建立索引。

Google 說明了最後一列背後的差異：URL Inspection 的初始報告描述的是已建立索引的版本，而即時測試會擷取目前的頁面。因此，索引報告仍舊過時時，公開文件可能已經修正。URL Inspection 工具。

清除快取前先發布變更後的文件

首先，記下確切的公開網址與預期的變更。以本文的虛構範例來說，預期句子是「Revision B: circles and squares」。請使用適合文件內容且易於辨識的句子；這樣就能辨認新的輸出，而不必根據分頁開啟的時間來判斷。

透過現有的發布系統發布編輯內容。如果該系統會從來源檔案建置文件，請確認已發布的輸出包含修訂後的句子。在此流程中，儲存來源內容與產生公開文件是兩個不同的檢查點；請依照平台記載的發布程序操作。

接著，如果有共用快取，請使其失效。操作順序很重要：例如，Cloudflare 記載，清除快取後的請求會從來源伺服器擷取資源，並將其重新加入 CDN 快取。如果來源伺服器仍提供舊文件時就清除快取，舊文件可能會再次填入快取。清除單一檔案的快取。

Cloudflare 的已記載控制面板操作範例

如果公開頁面使用 Cloudflare 快取，其已記載的單一檔案清除方式提供了一個具體的瀏覽器操作流程：

  1. 開啟相關網站的 Cloudflare 控制面板，前往 Configuration。
  2. 在 Purge Cache 下，選取 Custom Purge。
  3. 在 Purge by 下，選擇 URL。
  4. 輸入每份受影響文件的確切公開網址。
  5. 檢查所列項目，然後選取 Purge。

這些標籤與步驟出自 Cloudflare 的單一檔案清除快取說明。

再次清除前，請先確認文件所列的限制。清除重新導向會移除重新導向回應，因此若要重新整理目的地的內容，請清除目的地網址。有些自訂快取金鑰無法透過網址控制面板表單清除；Cloudflare 記載的替代方法包括依前綴或標籤清除。單一檔案清除也不接受萬用字元。清除快取的限制與替代方法。

如果你使用其他主機或 CDN，請使用該供應商所記載的失效處理控制項。Cloudflare 的程序是有條件適用的範例，並非通用介面。如果你的發布服務沒有提供清除快取功能，請查閱其記載的快取存留時間與重新整理行為，而不要自行編造清除網址，或假設瀏覽器中的按鈕可以控制服務的伺服器。

在 Mac 上確認公開回應

在 Chrome 中開啟頁面現有的公開網址。按下 Command–Option–I 開啟 DevTools，然後選取 Network。Chrome 記載了這個 Mac 快速鍵，並區分一般重新載入、強制重新載入，以及清空快取後重新載入。開啟 Chrome DevTools。

在 DevTools 開啟時，於 Network 面板選取 Disable cache，然後重新載入頁面。Chrome 說明，此設定會讓一般重新載入避開瀏覽器快取。檢查期間請保持 DevTools 開啟。使用或不使用快取重新載入。

在網路清單中選取主要文件請求。開啟 Headers 檢查回應標頭，並開啟 Response 檢視傳回的內容。在該文件中尋找預期的 Revision B 句子。Chrome 的網路教學說明如何檢查個別請求、標頭與回應內容。檢查網路活動。

記錄三項觀察結果：要求的網址、傳回的文件是否包含 Revision B，以及隨附的快取標頭。清除快取後，你可以用這些資訊進行比較。控制面板操作成功是一個檢查點；收到預期的文件，才是能確認讀者當下需求已獲滿足的檢查點。

接著關閉 Disable cache，再重新載入一次。將結果與網路測試進行比較。如果兩者不一致，檢視回應政策時請保留兩項觀察結果。反覆清除瀏覽器卻不記錄差異，會讓原因更難查明。

WHATWG Fetch Standard 說明了瀏覽器擷取模式的重要性。其 reload 模式會在連線至網路時略過瀏覽器 HTTP 快取，並根據回應更新該快取。其 no-cache 模式則會在快取中有回應時送出條件式請求。這些都是請求行為，因此兩者都不會清除共用快取頁面的所有副本。Fetch Standard：請求快取模式。

選擇符合未來編輯需求的快取政策

若公開文件應在每次重用前先檢查，請考慮使用回應指令 Cache-Control: no-cache。此指令允許儲存，但要求在重用前成功驗證。Cache-Control: no-store 則禁止儲存。回應中的 max-age 用來指定新鮮度存留時間；must-revalidate 則在回應變成過時後生效。這些指令適用於不同需求。RFC 9111：回應 Cache-Control 指令。

舉例來說，假設 Paper Shapes Guide 偶爾會更新，而且每次造訪時檢查更新都可以接受。重新驗證是適合與主機設定人員討論的政策。如果你希望在不進行網路檢查的情況下重用內容，請選擇符合舊版本可接受存留時間的新鮮度期限，並保留一套記載清楚的清除程序，以便處理較早發生的更新。

變更新發布回應的政策，無法在瀏覽器仍重用尚新鮮的舊回應時通知它，因為此時瀏覽器尚未連線至伺服器。因此，轉換期間仍須考量既有的快取副本。這符合 HTTP 的新鮮度與重用規則，也是新增標頭設定時應同時規劃如何處理既有副本的原因。RFC 9111：從快取建構回應。

確認驗證能辨識版本

ETag 會識別用於驗證的表示形式。Last-Modified 則提供其修改時間。請讓伺服器產生能反映已發布表示形式的驗證器，包括由其他來源組合而成的內容中，相關部分的變更。RFC 9110 說明了這兩種驗證器，並解釋實體標籤在某些情況下能比修改日期更可靠地區分表示形式。RFC 9110：驗證器欄位。

304 Not Modified 回應會告知接收端重用有效的已儲存表示形式，而非再次傳送文件。若已儲存的版本仍是最新版本，這種回應很正常。如果確認內容已變更後仍收到此回應，且畫面仍顯示 Revision A，請調查伺服器評估的是哪個表示形式與驗證器。RFC 9110：304 Not Modified。

請 Google 重新檢視修正後的頁面

公開文件穩定提供 Revision B 後，請在適當的 Search Console 資源中檢查其完整網址。選取 Test live URL 檢查目前頁面。將結果與可能描述較早一次檢索的索引報告進行比較。即時測試會檢查目前頁面，但本身無法證明 Google 的索引已更新。URL Inspection 工具。

若是單一更新頁面，請在其檢查結果中選取 Request indexing。你必須是 Search Console 資源的擁有者或完整使用者。Google 表示，檢索可能需要幾天到幾週；重複提出要求不會加快檢索速度，要求檢索也不保證頁面會出現在搜尋結果中。要求 Google 重新檢索你的網址。

若有許多更新頁面，Google 建議提交網站地圖。請確保其中的 <lastmod> 值正確：Google 表示，這些值應反映主要內容更新等重大變更，而非版權日期的例行變更。網站地圖有助於通知搜尋引擎哪些文件已變更，但不會清除瀏覽器或 CDN 中的副本。建立並提交網站地圖。

最後，建立一份簡要的發布紀錄：受影響的網址、預期的版本句子、已發布輸出檢查結果、共用快取處理方式，以及瀏覽器驗證結果。另行追蹤任何要求 Google 重新檢索的事項。這樣就能確認最直接的目標——提供修訂後的公開文件——同時清楚列出仍出現舊版本時的下一步。

資料來源