URL 遷移後，使用一份舊網址到新網址的對照表，更新公開連結、正規網址宣告、重新導向和網站地圖項目。這份 Mac 桌面工作流程說明如何讓這些變更保持一致，並驗證發布結果。

此處的任務是將一小組公開 HTML 文件移至同一網站上的新路徑。所有範例網址和頁面名稱都是虛構的。若要完成整個工作流程，您需要存取發布系統、其重新導向設定，以及相關的 Search Console 資源。

遷移後哪些項目應保持一致？

對每份移動的文件，選定一個最終目的地。您管理的連結應直接指向該處，目的地應宣告自身為正規網址，而目前的網站地圖應列出該網址。舊網址應重新導向至該處。Google 將重新導向和正規網址註記視為強烈的正規化訊號，而納入網站地圖則是較弱的訊號。這些方法可以相互強化，但最終仍由 Google 選擇正規網址。Google 的正規化指南。

這些機制各有不同用途。重新導向負責處理對舊網址的請求。公開連結決定讀者接下來前往何處。正規網址宣告指出文件的偏好網址；WHATWG 將這個意義定義於 canonical 連結類型中。網站地圖則提供偏好網址清單，供搜尋引擎探索。更新其中一項不會修改其他項目。WHATWG HTML 標準：canonical 連結類型、Google 的網站地圖指南。

將這份一致性表作為實用的驗收檢查。這是根據文件整理出的工作流程，不是 Google 的評分系統。

項目 虛構的 Colors 文件預期結果
舊網址 https://example.com/notes/colors.html 永久重新導向至目的地
目的地 https://example.com/library/colors/ 提供 Colors 文件
導覽和文件連結 直接指向 https://example.com/library/colors/
目的地正規網址 指向 https://example.com/library/colors/
目前的網站地圖項目 列出 https://example.com/library/colors/

先建立一份對照表，再逐一變更設定

在 Mac 上開啟試算表或純文字編輯器，將每個舊網址與預定目的地並列記錄。Google 建議將舊網址到新網址的對照表列為網站搬遷準備工作之一。保留原始清單的副本，這樣替換網站地圖項目時，就不會遺失仍需設定重新導向的網址紀錄。Google 的網站搬遷指南。

文件 舊路徑 最終路徑
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

對每一列，記錄需要在哪些地方變更：頁面編輯器、共用導覽、正規網址設定、重新導向設定和網站地圖產生器。另加欄位，分別檢查公開回應和 Search Console 檢查結果。這會將含糊的「更新網址」指示轉化為一組數量明確的編輯與觀察項目。

接受對照結果前，先檢查目的地內容。如果兩份舊文件已整合成一份實用文件，兩者都可以重新導向至該處。避免將無關文件導向通用首頁；Google 警告，不相關的重新導向可能會被視為軟性 404。Google 的重新導向對應建議。

更新公開連結並檢查相對路徑

在發布編輯器中，使用對照表更新導覽、文件索引、相關文件連結和文章內的連結。如果系統會根據頁面記錄產生導覽，請修改底層記錄或範本，而不是一再修正產生的內容。儲存前檢查每項替換，尤其要留意舊路徑是否也出現在說明範例中。

即使連結文字維持不變，路徑變更也可能改變相對連結的目的地。WHATWG URL 標準規定，相對參照會根據基礎 URL 解析。以下示例假設文件沒有明確覆寫基礎 URL。WHATWG URL 標準。

文件 URL 連結值 解析後的目的地
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

這些虛構的解析結果是使用 JavaScript 的 URL API 檢查的。未變更的 palette.html 值現在會指向 Colors 目錄內，因此只在其他地方成功替換文字，無法發現這個問題。對這一小組文件而言，使用預定的根相對路徑可明確指定目的地。如果要遷移至不同主機，請使用正確的絕對網址，或確認每個根相對連結仍會指向預定的主機。

在 Mac 瀏覽器中開啟已發布的 Colors 文件，然後點選其中的 Palette 連結。確認顯示的文件和最終網址。對共用導覽和任何章節連結重複此檢查。如果連結使用 #swatches，請確認目的地仍包含相應的章節識別碼；僅憑路徑對照表無法確認這一點。

在來源設定正規網址和永久重新導向

對每份新的 HTML 文件，將正規網址設為最終絕對網址。Google 建議使用絕對正規網址，並接受文件 head 中的 HTML 正規網址元素。如果發布系統有正規網址欄位，請在該處輸入網址，並檢查產生的內容。Google 的正規網址實作說明。

Colors 頁面的下列內容是要放入現有文件 head 中的中繼資料片段，不是完整的 HTML 頁面：

<link rel="canonical" href="https://example.com/library/colors/">

檢查主機是否也透過 HTTP Link 回應標頭傳送正規網址。Google 支援這兩種方法，但建議擇一使用，因為同時維護兩者可能導致目的地互相衝突。修正產生該值的範本或設定，避免下次發布時又恢復舊網址。Google 的正規化方法。

將舊網址設定為透過伺服器端永久重新導向前往目的地。RFC 9110 將 301 和 308 定義為永久重新導向，並說明目的地會放在 Location 標頭中。兩者的差異包括請求方法的處理方式：308 會保留方法，而 301 則允許沿用傳統的 POST 轉 GET 行為。對一般文件擷取而言，Google 將兩者都視為永久重新導向訊號。RFC 9110：HTTP 語意、Google 的重新導向說明。

實際設定方式取決於您的主機或發布系統。僅靠瀏覽器編輯無法建立 HTTP 回應規則。如果平台無法設定伺服器端重新導向，請依照其文件設定主機，或請主機服務業者實作這份對照表。Google 說明，無法使用伺服器端重新導向時，可將即時 meta refresh 作為替代方式；只有在其他方式都無法使用時，才建議使用 JavaScript 重新導向。單靠正規網址宣告不會將訪客帶往新網址。Google 支援的重新導向方式。

根據相同的目的地重新產生網站地圖

更新網站地圖的來源，然後重新產生。若只手動修正產生後的檔案，下次建置時很容易遺失這些修改。這次遷移的目前網站地圖應包含最終的 Colors、Palette 和 Shapes 網址，而不是舊路徑。

Google 要求網站地圖使用完整限定的絕對網址和 UTF-8 編碼。如果只需要列出網頁，也支援文字格式的網站地圖：每行一個網址，不加標題或說明。包含這三個虛構頁面的完整範例如下：

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Google 的網站地圖格式與要求。

如果網站已產生 XML 網站地圖，請保留這種支援的格式並更新網址項目。若提供 lastmod，請填入準確的修改日期；Google 表示，這個值應反映頁面的重大更新。不要只是為了讓網站地圖看起來較新，就自動替換所有日期。Google 的 XML 網站地圖指南。

從 Mac 驗證公開結果

請檢查部署後的輸出，因為編輯器預覽無法確認公開網址的 HTTP 回應。在 Mac 上開啟終端機。以下診斷命令使用虛構網址：執行前，請換成自己對照表中相應的公開網址。這些範例不代表任何實際遷移結果。

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

第一個命令會顯示初始回應標頭，但不跟隨重新導向。第二個命令會跟隨重新導向，並回報最終狀態、網址和重新導向次數。第三個命令會擷取目的地標記語法供檢查。這些選項記載於 curl 手冊。

對於一般的網址對應頁面，預期初始回應為 301 或 308，且 Location 指向預定目的地；接著最終網址會成功提供文件。檢查傳回的標記語法中是否有正規網址。也請在瀏覽器中閱讀文件：HTTP 成功回應本身無法證明收到的是正確內容。Google 建議直接重新導向至最終目的地，避免建立重新導向鏈。RFC 9110：狀態碼、Google 的網站搬遷指南。

某列檢查失敗時，請依照以下診斷順序處理，讓修正對應到可觀察的輸出。

觀察結果 下一步
舊網址重新導向至非預期頁面 修正該對照或重新導向規則
重新導向後又導向另一個網址 將舊網址直接指向最終目的地
正確頁面使用舊正規網址 修正其中繼資料來源並重新發布
導覽仍前往舊路徑 更新來源連結或共用範本
網站地圖仍列出舊路徑 修正產生器輸入並重新產生
終端機回報逾時 解決連線問題後重做檢查，並將測試記錄為未完成

提交網站地圖，並區分即時檢查與索引狀態

在 Search Console 中，選取涵蓋新網址的資源，並使用 Sitemaps 報告提交公開網站地圖網址。Google 說明，這份報告可用於提交，也會顯示處理錯誤。提交是協助搜尋引擎探索的提示，並不保證會建立索引。Google 的網站地圖提交說明。

在 Search Console 的檢查列中輸入新文件的完整網址，檢查該文件。使用即時測試調查目前的可存取性和潛在索引資格。若要查看 Google 選擇的正規網址，請使用已建立索引的結果及其中的 Google-selected canonical 欄位。即時測試無法預測正規網址的選擇結果。Search Console 網址檢查工具。

此範例是在同一主機內變更路徑，因此不適用 Change of Address 工具。Google 指引進行路徑遷移的發布者設定重新導向並更新網站地圖。此工具適用於網域或子網域遷移，且須在網站搬遷完成並設定重新導向後使用。Search Console 網址變更工具。

保留對照表作為維護紀錄。只有在公開重新導向、目的地內容、連結、正規網址和網站地圖都一致後，才將該列標記為完成；另外記錄 Google 後續的索引觀察結果。盡可能長期保留重新導向；Google 的一般遷移指南建議至少保留一年，並在未來編輯文件時繼續使用最終網址。Google 的遷移指南。

來源