一句話總結：搜尋引擎「認網址、不認內容」。單純更新內容，千萬別動網址；真要保留多版本，用版本目錄加 canonical；真要搬家改網址，才動 301。三種情況做法完全不同，別搞混。
先記住一句話：Google 認網址，不認內容
網址（URL）對 Google 來說就像地址。你動一個字，它就當成一個全新的地址，你累積在舊網址上的排名和權重，全部要重新計算。
這就是為什麼「內容更新」這件事，處理不好會出事。你以為只是改個內容，Google 卻可能當成一頁全新的、沒有任何信任基礎的頁面。
情境一：單純把舊文章更新、重寫（最常見）
產品規格、API 文件、活動資訊，這些內容本來就要隨時間更新。這種情況的鐵則只有一句：別改網址。
直接在原本的網址上修內容、補最新數據、優化排版。改完之後，到 Google Search Console 把這頁重新提交索引，讓 Google 知道你更新了。
這樣做，累積的權重原封不動留在原地，還吃到「內容變新鮮」的好處，穩賺不賠。
情境二：舊版本要保留、又要有最新版（版本控管）
有些情況，舊版本不能砍，讀者可能還要看 v1、v2。例如你有一頁 https://example.com/conference，公司同仁每次活動都直接覆蓋上去，這是不好的做法：舊版本使用者找不到，Google 也被搞混。
這時候用 John Mueller 給的三招：
- 穩定的主網址：主要版本的 URL 保持不動，方便 Google 辨識。
- 版本目錄：用 /v1/、/v2/、/v3/ 區分不同版本，讀者要哪一版自己找得到。
- Canonical 標籤：把舊版本用 canonical 指向最新版，避免重複內容、引導搜尋引擎。像這樣：
- /api-doc/v1/ 的 canonical 指向 /api-doc/v3/
- /api-doc/v2/ 的 canonical 指向 /api-doc/v3/
- /api-doc/v3/ 自我參照（canonical 指向自己）
好處是既改善使用者體驗，又建立清楚的網址結構，讓內容更容易被使用者和爬蟲找到。
情境三：真的要改網址、搬家、換 CMS（最危險）
如果你不是更新內容，而是要動網址本身，那風險等級直接跳到最高。做錯會是「SEO 核彈級災難」，累積多年的自然流量可能一夕暴跌。原則：
- 能不改 URL 就千萬別改，能用 URL Rewrite 保留原結構就保留。
- 一定要 301 永久轉址：舊網址 1 對 1 精準 301 到新網址。301 能傳遞絕大部分的權重與信任。別用 302 暫時轉址或 JS 轉址，那傳不了權重，甚至會被當作弊。
- 分步進行，別一次全改：切勿同時改網址、導航和內容。先把網址和搬家做完，等 Google 完全吸收、排名恢復（通常要 1 到 3 個月），再去動導航或內容。
- 保留舊網域、監控索引：指向舊網域的外連沒辦法全部更新，長期保留能繼續傳權重；同時在 GSC 用「網站改版工具」告知 Google，盯著索引量和抓取有沒有異常。
最後一句話
搞清楚你現在是哪一種：只是更新內容，就別碰網址；要留多版本，用版本目錄加 canonical；要搬家，才動 301 而且要分步做。記住那句話，Google 認的是網址。地址別亂搬，權重才留得住。
要深入了解 SEO，請參考我們的詳細指南：SEO 是什麼？就是一套方法，向 Google 證明：我的內容，就是這個問題的最好答案。
幾個容易被忽略的實務重點
- 301 會傳遞大部分權重，這是搬家能保命的關鍵；canonical 則是「權重集中提示」，使用者不跳轉、但告訴 Google 把排名算在標準網址上。
- 伺服器搬家（換 IP/主機）的無縫 SOP：提前 24 小時把 DNS 的 TTL 縮短到幾分鐘 → 新機上傳完整備份並測試 → 改 DNS 指向新 IP、舊機同時保留 2 到 3 天 → 確認蜘蛛已轉到新 IP 後才關舊機、把 TTL 改回。
- 實際案例：新浪微博、京東、優酷、土豆、1 號店都順利改過域名，很多知名部落格也是靠 301 成功改域名。所以改版不是不能做，是要照規矩做。
延伸閱讀
舊文章要定期改版，別發完就放著爛
Google 有「實用內容」的評估，會獎勵真正幫到人的內容、壓低過時灌水的。所以你的舊文不是發完就沒事：定期回頭看排名掉的、資訊過時的，把它更新：補新資料、砍廢話、加實例、更新年份。改版時沿用原網址（別另開新頁），讓累積的權重接著長。一篇持續更新的老文，往往比一直發新文還划算。