網站改版SEO指南：舊網址、內容與搜尋流量如何妥善交接

網站改版SEO的第一個警號：舊頁突然找不到

假設一間公司推出新版網站，老客戶收藏的舊服務頁卻打開了「找不到頁面」，搜尋結果仍顯示舊網址。網站改版SEO的工作，應在新版上線前便處理這種情況：保留舊頁清單、決定每頁的新位置、設定合適轉址，並驗證搜尋者抵達後仍能找到對應內容。這是假設情境，並非 Black Media 的客戶事故。

改版通常同時牽涉版面、內容、程式、網址和寄存；其中哪些真的改變，會決定需要做甚麼。若只是換主機而對外網址不變，不能直接套用更換網址的操作。若網址與頁面內容都重整，則需要更仔細的舊新對照。Google 的網站搬遷指引亦將網址變更和單純更換寄存分開處理。

把改版當成時間線較容易管理：在設計新頁前，先按網站製作流程保存現況；在測試環境核實內容與轉址；正式切換時確認真實回應；上線後持續觀察。老闆不必自行編寫伺服器規則，卻要知道哪些頁面承接查詢與銷售，哪些舊內容不可隨意刪除，以及誰有權批准新頁不再提供某項資訊。

改版前：盤點所有值得交接的舊網址

從網站地圖、報告與現有內容交叉查找

若舊系統有分頁、搜尋參數或多語言版本，不必把每個無意義組合都列成獨立工作，但要找出有獨立內容價值的網址。可以抽查不同頁面類型的例子，了解模板是否產生多條近似網址，再由技術人員決定如何整理。這比只複製導航首頁下幾個可見連結，更接近真正需要轉移的網站範圍。

舊網址清單不只靠導航選單。可以從現有網站地圖、內容管理系統、搜尋報告、伺服器紀錄及曾在宣傳物使用的連結取得。某些舊頁早已不在選單，卻仍被外部網站引用或供客戶收藏。盤點時記下網址、頁面任務、主要內容、是否仍可用，以及查找到它的來源。

Search Console 可提供搜尋曝光與點擊線索，但不能當成所有舊頁的完整名冊。先找出核心服務頁、產品頁、重要文章、下載文件及表格完成頁，再逐步補上其餘項目。若網站很大，應讓技術人員用合適工具匯出與核對，避免單靠人手逐頁複製造成遺漏。

保留版面之外，也保留頁面原本的任務

同一條網址可能承載多年累積的業務說明。除了存頁面文字，還應記下訪客到此通常想完成甚麼、舊頁有哪些重要內連與行動入口。新設計如果只留下視覺效果，卻把服務限制、下載資料或查詢途徑移走，轉址成功也未必能滿足原有訪客。

若網站有不同語言版本，對照表應把每個版本的內容責任分開。英文頁可能並非中文頁逐字翻譯，不能只按網址語言字尾自動設定轉址。請熟悉該語言與服務內容的人確認替代頁，避免訪客由舊英文說明被帶到只含中文或不同服務的目的地。

舊頁相片、附件及 PDF 亦可能被直接搜尋或分享。決定移除時先查它們的用途、替代檔案及新的連結位置。若文件因內容過時不應再公開，可說明適當的新資訊入口；不要把所有檔案請求悄悄丟到首頁，令使用者以為自己找錯地方。

盤點不是為了永久保留每段舊文字。已經不提供的服務可以淘汰，重複文章可以合併；但決定應由懂業務的人確認，再由技術人員安排合適回應。若只按「新版版面放不下」便刪去內容，可能連同客戶需要的證據和搜尋入口一起刪走。

改版前：先決定一對一、合併及移除的對照

舊頁有明確新版本，轉向最相關的新頁

例如原本介紹某項服務的舊頁，在新版有同一服務的新頁，便為它建立明確對照。若網址永久改變，通常可用永久轉址向使用者與搜尋系統交代去向；部署方式由技術人員按實際系統處理。轉往內容相符的新頁，比一律送到首頁更符合訪客原本期待。

如果舊頁原來回答「如何準備網站資料」，新版把這部分改成下載清單，而另一頁是一般公司介紹，應確認哪個才是真正替代內容。先作內容判斷再寫轉址規則，不能只見網址包含相同字詞便當作相等。轉址是流量路徑的交接，目的地仍要承接原本問題。

多頁合併，要先確認重要資訊是否真的保留

幾篇內容薄弱或彼此重複的文章，可以考慮合併為一篇較完整的指南。製作方應將原文的重要問題逐項對照到新頁段落，由內容負責人核實沒有把仍適用的細節刪掉。合併後再決定舊網址如何指向新頁，避免只是把多個不同問題一概導向一份根本沒有答案的短文。

合併決定要顧及內容所有者。假設兩個部門各有一頁服務，但實際交付與聯絡窗口不同，僅因主題相近就合成一頁，可能令查詢送錯部門。先問兩頁的決策任務是否相同、誰負責更新及能否保持清楚聯絡路徑。若合併只減少頁數，卻增加客戶理解成本，便應保留分頁並改善相互連結。

若合併涉及不同服務，先看讀者是否能在單頁內找到自己那項。如果需要大量無關背景才能到達答案，強行合併未必合適。可按關鍵字研究與頁面任務的分組方法評估：兩頁原本是否服務同一個主要需要，或只是同時含有某個常見詞。

沒有合理替代內容，應明確處理

過時活動頁若已沒有可用的相近資訊，不必硬把它轉去首頁。按實際情況提供清楚說明或正確的不存在狀態，讓使用者知道原內容已取消。若仍有相關但不同的服務，亦可在清楚的說明中引導，而非用轉址讓人誤以為兩件事完全一樣。

改版中：讓測試站只供相關人員核對

開發環境與正式網站要清楚區分

改版測試用的「不收錄」處理也要有移除責任人。在上線檢查表新增一格，列出哪些限制只適用於測試站、正式站應輸出甚麼。某些網站複製整套設定到正式環境後才發現頁面不可被搜尋，問題未必出在文章寫法。將測試與正式設定分開紀錄，能在切換當日迅速核對差異。

測試站可能使用尚未核實的內容與虛構資料，應由技術人員控制存取並安排避免被搜尋收錄的做法。實際措施需按環境決定，不能只在頁面角落寫「測試」便以為安全。更重要的是，上線時要確保正式頁沒有沿用測試環境的封鎖設定，以免新版明明可打開，搜尋系統卻無法收錄。

如果測試站需要商戶外勤同事試用，可給受控帳戶與必要範圍，不要為了方便一時公開整套管理後台。測試結束後，清理不再需要的帳戶及內容。關於帳戶與可下載資料的檢查，可參考網站保安檢查的基本工作；這些保安事項與搜尋搬遷各有目的，應由相應負責人配合。

先用真實內容測版面，避免上線才發現頁面缺口

以有代表性的長短內容、不同圖片與表格核對新版頁面。若舊站用一頁解答常見客戶問題，新版不要只以幾句佔位文字驗收。內容人員可將盤點表與新版逐頁對照，核實標題、限制、相片來源及聯絡入口仍然準確；技術人員則檢查標題與網址由哪個模板輸出。

在網站改版設計與開發討論中，應讓「內容變得好讀」與「原有答案仍存在」同時成為目標。有時為了手機版縮短首頁文字是合理的，但被移走的關鍵資訊需要有新的合適位置。版面決定應與搜尋任務和客戶操作一起核對，而非只在最後加幾個關鍵字。

改版中：核對每頁的搜尋訊號與內部路徑

標題、摘要與主要內容互相支持

編輯團隊可在每個頁面模板抽樣檢查，避免所有服務頁都輸出同一個主標題或摘要。若新 CMS 的欄位名稱與舊系統不同，先核對資料匯入後是否放到正確位置；已有文字並不等於前台會顯示。這項測試可用幾個不同類型頁面完成，不必把所有欄位逐字人工重打。

新版 SEO 標題要反映頁面真正回答的問題，不能把舊站最受歡迎的字詞一律貼到新頁。摘要可清楚說明頁面用途，但實際搜尋結果的展示由搜尋系統決定。商戶應檢查新服務名稱、地域與限制是否準確，讓技術人員核對模板有否輸出預期欄位。

一篇改版指南不能替代整套 SEO 工作。若需要先釐清哪些頁面應公開、內容是否能被理解，可參考公司網站的 SEO 基本檢查次序。改版項目在這些基礎上再加舊新交接；即使新版內容更好，舊入口處理錯誤仍會妨礙使用者。

canonical、索引狀態及網站地圖要對得上新版

技術人員應核對正式頁的 canonical 提示是否指向預期版本、需收錄的頁面沒有不小心被設定為不收錄，以及網站地圖列出的是否新版有效網址。canonical 是一項訊號，不是用來遮蓋錯誤轉址的工具。若模板在測試時輸出測試站域名，上線前尤其要逐類頁面檢查。

內部連結改向新版時，先處理導覽、服務頁及高使用率文章。若新頁原本是用另一個名稱上線，錨點文字也應隨內容修訂，讓讀者知道前往的是甚麼。不要只做機械字串替換，因為有些舊頁已合併或停止提供服務。對有明確替代內容的連結，可直接指向最終頁，減少繞經舊入口。

網站地圖可協助搜尋系統發現新網址，卻不能替代轉址與站內導航。搜尋者沿舊連結而來時，要靠對應處理抵達相關頁；在站內瀏覽時，選單與正文連結亦應直接指向新版網址。若所有內連仍先經舊網址轉一次，使用者雖未必立即察覺，維護及排查會更複雜。

結構化資料只標示真實可見的內容

若舊站使用與頁面內容相符的結構化資料，改版時應核對新模板是否保留必要資訊，以及標記是否仍與訪客看到的內容一致。不要為了保留某種展示而填入新版沒有的資料。具體類型和驗證方式要按頁面用途及官方要求核實，不能把所有舊標記原封複製到新頁。

上線當日：用小批關鍵頁試切換

先確定操作時間與回復條件

切換時還要明確記錄內容凍結的安排。若商戶在舊站繼續更新產品，新站同時準備上線，必須知道哪些資料需要再同步一次，誰確認最後版本。否則兩邊畫面各自看似正常，正式站卻漏掉切換前收到的查詢或近期資料。具體同步方法要按系統架構訂立。

選擇能讓技術與業務負責人同時核對的時段，並備好需要的權限與聯絡方法。若網站交易繁忙或依賴其他系統，上線時間還要配合營運。切換前先記下舊站可用狀態與資料時間點，明確寫出甚麼異常需暫停或回退。不要把「新版大致打得開」視為可以忽略所有差異的理由。

Google 建議可行時把大幅變動拆成較易管理的步驟；實際做法需看網站規模。若同時換域名、後台、版面、內容及寄存，事故時很難立即判斷是哪一項造成問題。公司可以與寄存服務負責人及技術方討論是否分階段交接，並為每一步保留核對資料。

抽查要涵蓋多種網址狀態

可從對照表抽出不同處理類型的樣本，讓業務和技術各做一次：一條舊網址對新服務頁、一組合併頁、一條沒有替代內容的舊入口，以及一份被直接分享的文件。若其中一類全部出錯，先停下來查規則，不要只修補被看見的個別網址。分類抽查能較快發現整個模板或設定的共同問題。

切換後至少抽查核心服務頁、仍有用途的舊網址、合併頁、應取消的頁面、表格及直接分享的附件。單看首頁容易漏掉深層連結。對每個測試記錄起始網址、經過的轉址、最後頁面及是否找到原本需要的資訊；只寫「正常」不足以發現舊頁全部跑到首頁的錯誤。

永久轉址通常應直接到最後相關新頁，避免多重跳轉或錯誤循環。測試應同時看手機和電腦，亦可用已保存的舊宣傳連結驗證。不要只在登入管理員的瀏覽器測試，因為公開訪客可能看到不同內容或權限回應。

使用者功能與搜尋配置分別驗收

功能驗收要看查詢、搜尋、登入及電郵通知；搜尋配置則核對轉址、索引狀態、canonical 與網站地圖。兩份清單可共享網址，卻應各由合適人員負責。如果表格提交失敗，修好 SEO 標題不能令客戶完成查詢；相反，表格可用也不能證明舊搜尋入口已妥善處理。

• 一位業務人員核實新版仍能回答核心客戶問題。
• 一位技術人員核對回應狀態、轉址及正式頁設定。
• 指定協調人收集問題、優先次序與是否啟用回復方案。

若公司仍沿用舊域名，記得在新站完成上線後核對域名續期與管理帳戶是否仍由現任人員掌握。改版本身不用強制轉移域名，但控制權若在舊供應商手中，日後再調整網站設定便可能受阻。這屬交接責任的一部分，可和網址對照表一併確認。

上線後：留意資料變化，不用單一日期定成敗

核對舊入口的實際抵達情況

上線初期要留意哪些舊網址仍有人使用、是否出現大量找不到頁面，以及新頁有沒有出現非預期的存取問題。將錯誤網址回填對照表，追查是盤點遺漏、轉址配置失效，還是內容本來已取消。修正時留下變更紀錄，避免多人各自修改規則而產生新的轉址鏈。

記錄變化時，將改版日附近的廣告、活動或季節因素一併寫在觀察表。否則若網站恰好遇上假期需求改變，團隊容易把全部升跌歸因於轉址。反過來，某些深層頁出現大量錯誤，亦不能用「市場淡季」一筆帶過。先有頁面級別的技術證據，再談整體表現，較能找出可修正的問題。

如果發現新版某些類型頁完全不見於觀察資料，先核對它們是否可被抓取、是否回應正確狀態，以及是否仍由站內頁面連結。不要直接複製大量相似文章試圖補回曝光。先修可證實的技術或內容缺口，再評估是否需要重寫，避免讓原本可修正的搬遷問題變成更多重複頁。

外部搜尋結果更新需時，不宜因翌日仍看到舊標題就判定失敗。可以用 Search Console 觀察頁面收錄與搜尋表現，並記錄改版日期、主要改動及查到的問題。數據變化可能受季節與其他推廣影響，應結合實際頁面檢查，不以單一數值判斷全部原因。

與業務查詢一起看內容是否仍有用

若新頁已能被找到，但客戶反覆詢問舊頁曾有的規格或限制，就應回到內容對照表核查。某些問題不是搜尋引擎故障，而是改版時遺漏了關鍵說明。客服與銷售的具體問題可協助修正內容，比單純追看流量線圖更能指出網站是否繼續服務原有客戶。

若公司同步安排網上廣告推廣，也應核對廣告到達頁與表格是否仍可用。這涉及付費流量的實際去向，不能等自然搜尋資料逐步反映才發現舊廣告連結已失效。把不同來源的連結一併抽查，能減少改版後營運中斷。

落手前，先決定哪些舊內容應被保留

若舊站由多人更新，請為每組內容指定核對者：服務細節由業務確認，程式功能由技術確認，圖片和下載資料由內容負責人確認。每組都標出尚待批准的變更。這能避免新版製作人員在缺少背景時猜測哪些說法已失效，也減少改版當日才發現沒有任何人願意簽收內容的情況。

真正難的往往不是寫轉址規則，而是決定舊頁對讀者還有甚麼價值。若公司能在畫新版之前確認重要頁面、替代位置與資料負責人，技術方便可根據清楚對照實作。若改版後才回頭找舊網址，原本可保存的內容、檔案與連結可能已難以整理。

上線後遇到客戶提供一條尚未記錄的舊連結，不要只回覆對方新的首頁位置。先問他原本想取得甚麼資訊，再確認有沒有真正的替代頁；如果有，就補回對照和轉址。客戶的實際使用方式能協助優先排序，亦可提醒團隊某些不在主選單的舊頁仍有價值。

工作完成後，亦要把轉址規則的維護責任交給現任網站管理者。日後改服務名稱或再換系統，若沒有人知道這批舊網址仍在使用，可能再次斷開多年累積的入口。可以把重要對照與測試方法寫入網站文件；日常新增頁面時同樣注意是否移走任何原本可用的網址。

請用一份表同時記下舊網址、新網址、決定理由、負責人和驗證結果；每次正式修改都更新該表。上線後查到新的舊連結，再補上處理與測試。這是一份持續使用的交接文件，不是簽約時才看的附件，能協助業務與技術團隊對同一個問題說清楚。

常見問題

所有舊頁都需要轉去新版首頁嗎？

不應一律這樣做。舊服務頁如有對應的新服務頁，應讓使用者抵達相關內容；幾頁合併時，要先核對新頁真的承接原本問題。沒有適當替代內容的頁面，應按實際狀況作清楚處理。全部轉去首頁通常不能讓訪客完成原來要做的事。

網址不變，只改版面，還要做對照嗎？

若對外網址完全不變，無須假設每頁都要轉址，但仍應核對內容、內連、標題、可收錄狀態及重要功能。改版可能讓某些舊頁實際被刪或改成另一用途，盤點表仍可幫你發現差異。若連寄存也更換，則另需核對基礎環境與 DNS 切換。

改版後搜尋流量短期波動是否一定出錯？

不一定。搜尋系統重新抓取及處理新頁需要時間，業務本身亦可能有季節變化。先查核心頁面是否可開啟、舊址能否抵達適當新頁、設定有沒有誤封鎖，再結合搜尋報告觀察。若某組重要頁明顯失去入口，應作具體排查，不應只說等一等便會好。

只換網站寄存，也照這份轉址流程做嗎？

不必機械套用。若網址與內容不變，重點是新環境能否正常提供原有頁面、程式與資料，以及切換後的存取表現。涉及伺服器搬遷的資料同步與回復安排，應另作計劃；如果同時改網址，才需要在同一項目內加入對照與轉址檢查。

如果公司打算改版，可先保存現有網站地圖與重要舊網址，再帶上哪些服務會保留或合併的初步決定，向 Black Media 討論網站改版與交接安排。先有可核對的對照，設計、內容與搜尋工作才不會各走各路。