公司網站改版檢查清單：舊網址、SEO、內容與帳號交接怎麼做

一、 網站改版先確認什麼？先保住能用的內容與聯絡流程

**網站改版不只是換版面，而是把既有內容、網址、帳號與營運流程接到新版本。**對中小企業而言，最需要避免的是新網站上線了，舊文章卻找不到、客戶無法聯絡、公司也沒有後台權限。

建議先完成三份文件：保留與調整清單、舊新網址對照表、交付驗收清單，再確認誰負責切換、誰判斷能否上線。本文提供的是可與廠商共同核對的工作方法，不是保證排名不變的方案。

閱讀指引： 本篇適合已經有官網、準備改版或換製作廠商的企業。若還在規劃需求與比較報價，先看網站設計與委外規劃指南；若尚未決定架站方式，可參考網站架設與上線準備指南。

二、 先分清楚改版範圍，哪些東西真的要換？

先寫下目前的問題，例如手機導覽不好用、服務資訊過時、內容難更新，或訪客找不到聯絡方式。每一項改動都應對應問題與驗收方式，不必為了「全新」而把原本有效的內容全部刪掉。

若範圍允許，可把換網域、換系統與大幅調整內容分階段安排，讓發生問題時較容易定位。Google 也提醒，重大網站變動可能造成暫時的搜尋排名波動，無法承諾完全沒有影響。Google：網站搬遷指南

三、 改版前先盤點，不要等舊站關掉才找資料

請公司窗口與製作團隊共同留存下列資料，指定保存位置、負責人及版本日期：

• 頁面與檔案： 服務頁、文章、作品、圖片、影片與下載文件，標示保留、更新、合併或移除。
• 重要入口： 廣告到達頁、社群與 LINE 介紹連結、名片或型錄上的網址，以及客戶經常使用的頁面。
• 內容權利： 確認照片、字型、文案及設計素材能否延續使用，不把舊站上看得到當作一定有授權。
• 搜尋基準： 從 Search Console 留存適當期間的查詢、頁面曝光與點擊，另記主要頁面的索引狀態。
• 營運基準： 從 GA4 記錄入口頁、來源與已驗證的聯絡事件，對照實際詢問紀錄；比較時盡量使用相近天數與星期組合，並註記活動與季節差異。
• 可還原備份： 備份網站檔案、適用的資料庫與必要設定，並確認真的能在測試環境還原。備份檔不應放在可公開下載的網址。

如果舊站沒有安裝分析工具，請明確標示「無歷史資料」，從現在建立基準；不能用新站資料倒推或補出不存在的成效。

四、 換廠商前，先把公司能管理的權限交接清楚

交接不等於把一張帳密表寄給新廠商。應使用公司可持續管理的帳戶，依需要邀請協作者，確認權限與復原方式；公開表單或一般聊天訊息不適合傳送密碼、金鑰與完整備份。

不要假設委外就一定會取得所有原始碼，也不要把尚未取得的權限列為已完成。先寫進交付範圍，再由公司人員實際登入確認。可使用網站交付與權限驗收表記錄歸屬、收到的項目與測試結果；交接完成後，再依分工移除不再需要的存取權限。

五、 舊網址怎麼處理？先做對照表，再決定轉址

最小可用的對照表至少包含「舊網址、新網址或處理結果、負責人、測試結果」。以下路徑只是示意，不是淞間現有網頁：

例如 /service-old/ 改為 /services/brand/，應測試舊網址是否直接到新版服務頁，而不是先經過已停用網址。永久搬遷優先使用 301／308；canonical 是標準網址訊號，不會替使用者執行跳轉，不能代替轉址。Google：重新導向、標準網址設定

真正不存在的內容回傳 404／410 是正常處理，不需要把所有錯誤頁都導回首頁；重點是不要誤刪仍應存在的重要頁面。Google：HTTP 狀態碼

轉址不是上線當天測完就能刪掉。Google 建議盡可能長期保留，通常至少一年；若舊連結仍被使用，還應評估繼續保留。因此需要預留舊網域續費與轉址服務，不一定要維持整套舊網站。Google：搬遷後保留轉址

六、 測試站與正式站的搜尋設定，要分開檢查

6.1 測試站：先限制存取，不把未完成內容當正式頁面

未公開內容宜使用登入或其他存取限制保護。若測試頁必須公開供審查，可設定 noindex，但它不是保密機制。只在 robots.txt 禁止抓取，不能可靠地阻止網址出現在搜尋結果；若同時阻擋抓取，搜尋引擎也可能讀不到頁面的 noindex。Google：使用 noindex 排除索引

6.2 正式站：檢查希望被搜尋找到的頁面

• 可存取： 希望公開索引的頁面不能殘留測試用登入限制、誤設的 noindex 或爬蟲封鎖；私人頁面則保留原本的限制。
• 標題與內容： 頁面主題、標題、描述及主要資訊相符，不能只搬到空白版型。
• 標準網址： canonical 指向正確的正式版本，不是測試網域、舊網址或全部指向首頁。
• 站內連結： 導覽、文章與案例直接連到有效目的頁；舊圖片與文件的連結也要處理。
• 網站地圖： sitemap 列入希望被索引的正式網址，不把測試頁、轉址頁及刪除頁當成有效內容提交。提交不等於保證收錄。
• 結構化資料： 公司、文章、日期、圖片及網址與畫面一致，不添加不存在的評價或成果。Google：結構化資料規範

保留原本 Search Console 驗證所需的紀錄或檔案。若真的更換網域或子網域，再評估網址變更工具；只換版面、同網域路徑、HTTP 改 HTTPS，或同網域的 www／非 www 切換，並不是都要使用這個工具。Google：網址變更工具

七、 功能與 GA4 怎麼驗收？看結果，不只看按鈕存在

7.1 從客戶會走的路徑測試

使用手機與桌機走一次「找到服務 → 查看案例 → 聯絡公司」；再用鍵盤確認選單、連結與表單可操作。至少檢查：

• 電話、信箱及 LINE 目的地是否正確，點擊後能否開啟對應服務。
• 有啟用的表單是否能成功送出、寄達指定信箱，以及失敗時有沒有清楚提示；只顯示「已送出」不等於真的收到。
• 若暫停表單，應有可用的替代聯絡方式，不能保留看似能送出卻沒有作用的按鈕。
• 圖片、下載、網站搜尋、手機選單、回上一頁與輪播等實際有使用的功能是否正常。
• Cookie 選擇與分析啟停是否符合網站公布的做法，拒絕或撤回後也要測試。

7.2 GA4：網站有觸發，還要確認後台收到

同一個官網改版時，先確認是否延用原有 GA4 資源與串流，以利前後比較；若有分開管理需求，再規劃新的設定。不要未經盤點就新增一套追蹤，同時留下舊標記。

測試時記錄時間、頁面與操作，核對正確評估 ID、頁面瀏覽及必要事件是否只在預期時觸發。可先用即時報表確認入帳；需要查看事件參數時，依 Google 說明啟用偵錯模式並查看 DebugView。受到同意選擇或隱私控制限制時，也可能看不到事件。Google：DebugView 事件偵錯

例如自訂 contact_click 可用來記錄聯絡意圖，但 LINE 點擊不等於加入好友、電話點擊不等於接通、信箱點擊不等於寄出郵件。只有經過核對、符合業務目標的事件，才考慮標記為重要事件；實際詢問與成交仍要另外確認。Google：重要事件

有啟用表單的網站，可以用 form_start 記錄開始操作，把 generate_lead 留給確實已產生的需求。實作時應由後端確認接收後才記錄成功，並處理連點、重試或重新整理的重複情況；不能按下按鈕就算名單，也不能把姓名、Email、電話及需求全文送進分析事件。Google：建議事件、避免傳送個資

驗收紀錄可分成「網站有發出事件」、「測試資源已收到」、「正式資源已核對」三個狀態。沒有權限查看正式 GA4 時，保留待確認項目，不能以程式存在或網路請求送出代替後台驗證。

八、 上線當天，由誰決定切換與復原？

把「可以上線」變成明確決策，而不是只靠一則口頭通知。以下是建議的協作順序，實際時間與分工應寫進專案安排：

1. 確認上線版本： 公司窗口核對服務資訊與聯絡方式，製作團隊列出仍未處理的項目與風險。
2. 保留復原條件： 確認備份、舊設定、部署版本及復原負責人。若有訂單、預約或會員等持續寫入資料，先安排同步或暫停寫入策略，避免切回舊版時遺失新資料。
3. 安排切換： 由具權限的人部署或調整 DNS；如果只更新程式與內容、不需要換主機，就不必為改版而更動 DNS。
4. 核對郵件服務： 若更換 DNS 管理服務，檢查郵件所需的 MX 與相關驗證紀錄，不能只搬網站紀錄而讓公司信箱停收。Cloudflare：郵件 DNS 紀錄
5. 正式網址再測一次： HTTPS、重點舊網址、服務與聯絡流程、分析事件都以正式環境驗證，不以測試站通過代替。
6. 決定維持或復原： 若核心聯絡、交易或重要入口失效，由約定窗口依風險處理。回復舊版本前，也要確認期間新增資料不會遺失。

僅更換主機而網址不變時，要觀察新舊主機的流量與錯誤，確認切換完成再停用舊主機；若舊網域仍負責轉址，則須另外保留這項服務。Google：更換網站主機

九、 上線後追蹤什麼？把追蹤故障與實際流量分開

以下是可依人力調整的檢查節奏，不是搜尋引擎的處理時程或排名承諾：

新舊比較時，註記改版日期、事件命名、同意機制及廣告活動的變更。若 GA4 數字突然下降但實際詢問沒有變，先檢查追蹤；若重要頁面回傳錯誤，就應先修復，不要只等待搜尋排名恢復。

十、 給公司窗口的上線確認清單

建議把以下項目複製到專案文件，每一項加上「負責人、完成日期、證據連結、待處理事項」。其中不適用的項目要註明原因，而不是直接略過。

• 範圍： 改版要解決的問題及本次不處理的範圍，雙方已確認。
• 內容： 應保留的文章、案例、圖片與下載文件已逐項核對。
• 網址： 舊新網址對照表完成，永久轉址與真正刪除的頁面處理正確。
• 搜尋： 正式頁面的索引限制、canonical、sitemap 與結構化資料已檢查。
• 功能： 手機、桌機、選單、搜尋與聯絡流程有實際測試紀錄。
• 分析： GA4 正確資源已收到預期資料，無重複安裝；事件的業務意義有說明。
• 權限： 公司能管理網域、主機、後台及分析工具，第三方授權範圍已說清楚。
• 營運： 若涉及 DNS 或系統搬遷，郵件與持續寫入資料的處理已確認。
• 復原： 有可用備份、切換紀錄、復原方案與負責窗口。
• 後續： 舊網址轉址維持方式、續費、維護範圍與問題回報管道已交付；可用網站維護項目清單分開確認主機、更新、備份與內容修改的責任。

十一、 網站改版常見問題

11.1 網站改版一定會掉排名嗎？

不一定，但重大變動可能有波動。能做的是保留有價值的資訊、正確處理網址與搜尋存取，並在上線後追蹤；不能用「有做轉址」保證排名完全不變，也不能把每次下降都歸因於改版。

11.2 換網站公司，一定要換網域或 GA4 嗎？

不必。合作廠商、網站系統、公司網域及分析資源是不同的事情。先確認原帳戶與權限能否交接、現有設定是否適合，再決定要更換哪些項目。

11.3 所有舊頁面都轉到首頁，會比較安全嗎？

不會。使用者原本找的是某項服務或文章，首頁通常無法替代。應依內容相關性處理；沒有適合替代內容的永久刪除頁面，可正確回應 404 或 410。

11.4 新網站看起來正常，就可以把舊主機取消嗎？

先確認流量切換、備份、必要資料與郵件都已交接，再區分「不再使用的舊主機」和「仍需運作的轉址服務」。看到新版首頁，不能代表所有舊網址都已處理完成。

11.5 公司需要先準備哪些資料，才能討論改版？

先提供現有官網網址、最想改善的問題、要保留的內容、預期功能、可配合的窗口與時程限制即可。帳戶權限盤點可在確認合作方式後進行，不需要先傳密碼。

十二、 官方參考資料

本文相關技術規則於 2026 年 10 月 27 日核對；實作仍應依網站系統、合約與官方最新文件調整。

• Google 搜尋中心：網站搬遷與網址變更
• Google 搜尋中心：重新導向與標準網址
• Google 搜尋中心：使用 noindex 排除索引
• Google Search Console：網址變更工具
• Google Analytics：DebugView
• Google Analytics：重要事件
• Google Analytics：generate_lead 等建議事件
• Google Analytics：避免傳送個人識別資訊

十三、 結語：驗收的是新網站能否接續營運，不只是新畫面

一份好的改版計畫，應讓公司知道哪些內容會保留、網址如何接續、權限由誰管理，以及出問題時誰來處理。先把這些寫清楚，報價與時程才有共同基準。

可先閱讀網站設計指南的報價與驗收規劃，再參考淞間的官方網站建置服務與作品集及案例說明，討論適合的改版範圍。

準備整理舊官網？可透過 LINE 與淞間討論，提供現有網址與希望改善的問題，先釐清內容、功能與交接需求。