ckgrowthmarketing-fallback-featured-image

網站改版 SEO Checklist：轉 CMS、改網址或改網域前後要做甚麼？

/ CK Insight, SEO / By

網站改版最重要的SEO原則，其實不是「所有東西都要保留」，而是：不要為改動而改動。

如果新CMS、網址架構或網域能解決真正的業務、內容或技術問題，改動可以有價值；但若只是覺得舊網址不夠漂亮，或者想趁改版一次過更換domain、CMS、URL和版面，風險通常會大幅增加。

SEO亦不應到launch前才加入。當新URL、刪頁名單和網站架構已經落實，很多高風險決定已難以逆轉。較穩妥的次序是：先分辨改動類型，保留舊站baseline，建立新舊URL mapping及rollback plan，再在staging、launch day和上線後分階段驗證。

Google同樣建議，轉網域、換CMS和更新版面等重大改動應盡量逐項處理，避免一次改變太多因素；網站搬遷期間亦可能出現短期搜尋波動，不能保證流量或排名完全不變。Google網站搬遷指引

甚麼改動才算website migration？

Website migration不一定等於轉domain。只要改動可能影響Google如何爬取、理解、索引或顯示頁面，便需要做相應SEO檢查。

改動類型一般風險最需要留意
只換視覺設計，URL及內容不變低至中rendered content、heading、internal links、mobile、tracking
轉CMS或framework，URL不變中status code、canonical、robots/noindex、HTML內容、schema、analytics
改URL結構、合併或刪除內容高URL inventory、mapping、redirect、internal links、sitemap、orphan pages
轉domain、合併網站或轉subdomain高property驗證、permanent redirect、canonical、Change of Address、monitoring
只轉hosting或server中度營運風險DNS、TTL、server capacity、verification、logs、crawl blocks
同時改domain、CMS、URL和設計很高分拆改動、rollback、清晰owner及分階段驗證

表中的風險只是起點。同樣是轉CMS，一個只有數十頁的企業網站與一個有多年新聞archive的媒體網站，URL數量、template種類和回溯redirect需要可以相差很遠。

只換設計、不改URL也會出問題嗎？

會。新template可能意外移除文字內容、H1、internal links、canonical、schema或tracking；JavaScript rendering方式亦可能令Google看到的內容與用戶不同。

所以「URL沒變」只代表少了一類redirect風險，不代表不用QA。

Google說「逐項改」，是否代表每條URL都要分批搬？

兩件事不要混為一談。

Google建議盡量不要同時改domain、CMS及layout，是為了減少變數。至於已經準備好的一次URL migration，Google對中小型網站反而建議把URL一併搬遷；大型網站則可按section分階段處理，方便監察和修正。Google網站搬遷指引

立項階段：先決定甚麼不應該改

網站改版會自然吸引很多「順便」要求：順便改URL、順便刪舊文章、順便換domain、順便重寫所有title。每一項看似合理，合在一起卻令問題難以追查。

項目開始時應該先建立兩張清單：

  1. 必須改動：有清楚業務、技術、安全、品牌或用戶需要支持。
  2. 暫時保持不變：不是今次改版目標，或沒有足夠證據支持。

例如，轉CMS是因為舊系統停止支援，不代表現有URL結構亦一定要重寫。如果URL沒有實際問題，保留它通常可以少一層migration風險。

建立改版前baseline

Baseline不是為了保證改版後維持某個百分比，而是讓團隊知道改了甚麼、異常由何時開始。

至少記錄：

  • Search Console的主要queries、click、impression及landing pages
  • GA4的organic landing pages、key events及重要conversion paths
  • 目前可索引URL、sitemap、status codes及canonical
  • 帶來流量、backlink、查詢或收入的重要頁面
  • 主要表格、電話、WhatsApp、login、購買或訂閱流程
  • 舊站crawl及關鍵template樣本

沒有baseline，上線後即使流量變動，團隊亦很難分辨是季節、演算法、tracking失靈，還是migration造成。

URL inventory不能只靠SEO或Tech單方面完成

我曾參與信報的URL改動，包括把www1、www2整合至www，亦參與過am730的CMS migration。這些經驗令我特別重視一點：migration所需的URL inventory，不應由SEO憑crawl結果自行估算，也不能只拿CMS匯出清單便當作完整答案。

Tech team掌握CMS、database、routing rules及動態URL等系統資料，負責匯出底層清單及落實redirect；SEO則結合sitemap、網站crawl、Search Console、analytics及backlink資料，補回系統清單未必涵蓋的舊URL和重要頁面，再制定保留、合併、redirect或移除的規則，並在staging及上線後驗證結果。Content及Marketing則需要確認頁面是否仍有業務或編輯價值。

所以URL inventory應該是一份由各方共同維護的working document：Tech確保系統資料和實作完整，SEO處理搜尋風險與mapping邏輯，Content及Marketing負責頁面決策，而不是把全部責任推給其中一方。

工作建議主要ownerSEO參與方式
從CMS、database及系統匯出全部URLTech team指定必要欄位及資料來源
整理sitemap、crawl、analytics及Search Console URLSEO／Marketing找出流量、索引及重要頁面
決定頁面保留、合併、刪除或改寫Content／Marketing評估搜尋意圖及organic風險
建立redirect規則及部署Tech team審核mapping邏輯及抽查結果
Staging crawl與technical QASEO＋Tech分清rule、implementation及修正owner
Business journey及表格驗收Marketing／Product核對organic landing及conversion tracking
最後go/no-go決定Project owner彙總P0風險，不代替業務簽署

URL清單不應只來自sitemap。Google建議亦包括CMS、analytics、server logs及有內外部連結的重要URL，因為sitemap未必保留所有舊頁。Google URL mapping指引

如何建立新舊URL mapping？

URL mapping最少應有以下欄位：

欄位用途
Old URL改版前完整網址
Current status/indexability原本是否200、redirect、noindex或已失效
New URL最相關的新目的地
Action保留、301/308、合併、404/410或待定
Page type/template方便按規則測試
Business/SEO priority標示高流量、高查詢或重要功能頁
Redirect rule owner負責實作的tech owner
QA status未測試、通過、錯誤及修正狀態

不要把所有舊頁redirect去首頁

舊頁應redirect至內容最相關的新頁。把大量不相關URL全部導向首頁，可能令用戶困惑，Google亦可能把它當作soft 404。Google網站搬遷指引

如果舊內容已沒有替代頁、沒有合理用戶用途，也不是每一頁都必須硬找一個目的地。應按內容、流量、backlink及業務價值決定保留、合併或正式移除。

HTTP、HTTPS、www及non-www應合回一個版本

同一網站可能同時透過以下版本被存取：

  • http://example.com
  • http://www.example.com
  • https://example.com
  • https://www.example.com

實務上應選定一個指定canonical host，讓其他版本redirect至它，並令canonical、internal links、sitemap及hreflang使用同一版本。Google亦建議，網站可由多個URL存取時，選定preferred destination並把其他版本redirect過去。Google Redirects指引

我亦處理過這類HTTP／HTTPS及www／non-www整合。關鍵不是哪一個版本看起來較專業，而是全站訊號要一致，避免部分template、sitemap或舊link仍然指向另一版本。

Google的canonicalization文件亦指出，HTTP與HTTPS、redirect、sitemap及rel="canonical"都是系統選擇canonical URL時考慮的訊號。Google canonicalization說明

URL有「/」與沒有「/」是否一樣？

除了根目錄外，以下兩個path可以是不同URL：

  • https://example.com/service
  • https://example.com/service/

Google會分開處理有trailing slash與沒有trailing slash的URL。網站可以選擇其中一種，但要保持一致：preferred版本返回200，另一版本redirect過去；internal links、canonical及sitemap亦應指向同一版本。Google trailing slash說明

Migration時最常見的問題不是「選錯有slash或沒slash」，而是新CMS改了規則，令兩個版本都返回200、canonical互相衝突，或者產生多一層redirect chain。

Staging上線前SEO Checklist

Crawl與index控制

  • [ ] Staging受密碼或存取權限保護，避免測試內容被公開索引
  • [ ] Production launch時會移除臨時noindex、robots block或存取限制
  • [ ] 重要template可正常返回200及render主要內容
  • [ ] 404頁真正返回404，而不是200 soft 404

URL、redirect與canonical

  • [ ] 舊新URL mapping已完成並有tech owner
  • [ ] Permanent URL change使用server-side 301或308
  • [ ] Redirect直接到最終目的地，避免不必要的chain
  • [ ] 沒有把大量不相關舊頁redirect至首頁
  • [ ] 新頁canonical指向正確final URL
  • [ ] HTTP/HTTPS、www/non-www及slash規則一致

Google建議在永久更改URL時盡量使用server-side permanent redirect，例如301或308；temporary redirect則有不同用途，不應只因設定方便而混用。Google Redirects指引

Content及metadata

  • [ ] 重要頁面的主要內容沒有在新template遺失
  • [ ] Title、H1、meta description及robots設定已比較
  • [ ] 圖片、影片、PDF及其他可索引資產納入搬遷考慮
  • [ ] Internal links已指向新URL，不靠redirect長期接駁
  • [ ] Canonical、hreflang及structured data使用final URLs

如需檢查robots、sitemap、canonical、redirect和JavaScript等基本項目，可配合CK Growth的技術SEO完整教學。本篇重點則是改版過程的先後次序與責任。

Conversion及analytics

  • [ ] GA4及其他必要tags在新template正常觸發
  • [ ] Form成功及失敗狀態均有測試
  • [ ] 電話、電郵及WhatsApp連結正常
  • [ ] Cookie consent未意外阻止必要measurement
  • [ ] Thank-you page及key events沒有漏記或重複
  • [ ] 重要business journey在mobile及desktop均完成測試

Launch day Checklist

上線前

  • [ ] 完整backup及rollback方法已確認
  • [ ] Release內容、時間、owner及聯絡方法已記錄
  • [ ] P0問題有明確go/no-go準則
  • [ ] DNS、hosting、certificate及server capacity已確認
  • [ ] 舊domain、舊hosting及Search Console存取仍然保留

如果只更換hosting而URL不變，Google建議可預先降低DNS TTL、確保Search Console verification在新環境仍有效，並在切換後監察新舊server logs及crawl狀態。Google轉hosting指引

上線一刻

  • [ ] 啟用redirect規則
  • [ ] 移除production的臨時crawl/index blocks
  • [ ] 更新canonical、hreflang、internal links及sitemap
  • [ ] 驗證首頁、主要category、服務頁及高價值舊URL
  • [ ] 確認GA4、表格、電話及WhatsApp流程
  • [ ] 在Search Console提交新sitemap
  • [ ] Domain migration按適用情況使用Change of Address

HTTP轉HTTPS不需要使用Change of Address；真正轉往另一domain時，則需要確認舊站各相關property及variant的驗證與申請要求。Google網站搬遷指引

上線後24小時、7日及30日要看甚麼？

以下是操作檢查點，不是排名恢復保證。

首24小時：找P0故障

  • 全站或主要section是否被noindex或robots封鎖
  • 重要舊URL是否404、redirect錯頁或出現loop
  • 新站是否大量5xx或server反應異常
  • Canonical是否錯指staging、舊domain或另一語言版本
  • Sitemap及重要URL能否由Google存取
  • Form、電話、WhatsApp及tracking是否正常

首7日：比較crawl與index變化

  • Crawl新站並與baseline比較
  • 查看Search Console的indexing及crawl errors
  • 按重要page template抽查URL Inspection
  • 觀察舊URL流量下降與新URL承接情況
  • 檢查redirect chain、orphan page及錯誤internal links
  • 比較organic landing pages和key events有沒有異常斷層

首30日及之後：看趨勢，不急於宣判

  • 比較相同queries由舊URL轉到新URL的impression及click
  • 監察重要頁面的index、canonical及landing-page表現
  • 保留release log，分辨後續修正和原始migration影響
  • 檢查外部重要link、profile及campaign URL是否可更新
  • 確認舊domain、certificate或hosting不會過早失效

Google指出，中小型網站的大部分頁面搬遷可能需要數星期，大型網站更久；其間搜尋可見度可能暫時波動。實際時間受URL數量、server速度和改動類型影響，不能套用單一恢復期。Google網站搬遷指引

時間不足時，先修P0、P1還是P2？

以下優先次序是按技術及商業風險整理的框架，不代表每個網站的工作量相同。

P0：阻止launch或需要即時rollback

  • 全站／重要section無法crawl或index
  • 大量重要舊URL沒有正確redirect
  • 新站大量5xx、redirect loop或錯誤canonical
  • 主要內容在rendered HTML消失
  • 表格、付款、login、電話或WhatsApp等重要流程失效
  • Analytics完全中斷，無法判斷上線影響

P1：應盡快修正

  • 高價值頁面遺失內容、internal links或metadata
  • Hreflang、schema、sitemap或canonical局部錯誤
  • Redirect chain、orphan pages及重要404
  • Mobile或速度問題明顯影響重要template

P2：可排入後續優化

  • 低影響頁面的meta description微調
  • 不影響主要journey的次要broken links
  • 新增非必要schema或額外內容改善

如果launch前時間不足，至少要讓project owner清楚知道哪些P0未解決，以及繼續上線的業務風險。Checklist的作用不是把所有項目變成同一優先級。

Redirect應保留多久？

Google建議網站搬遷的redirect盡量保留，通常至少一年，讓系統有時間重新爬取及轉移舊URL訊號；從用戶角度，亦可考慮保留更長時間。Google網站搬遷指引

這不代表網站可以永遠依賴redirect chain。自己的internal links、sitemap、canonical及高流量外部連結仍應逐步更新至final URL。

何時值得在改版前做一次性SEO Audit？

以下情況特別值得在架構及URL正式落實前檢查：

  • 會更改URL、domain、subdomain或CMS
  • 會合併大量內容、刪除archive或重整分類
  • 現有網站已有穩定organic traffic、backlink或查詢頁面
  • Web agency未提供完整URL mapping及post-launch monitoring
  • Marketing與tech對redirect、canonical或launch風險理解不同
  • 改版後已出現索引、流量或conversion異常

一次性SEO Audit可以協助界定風險、整理規則和排定修正次序，但是否包括完整URL mapping、developer implementation、launch support及上線後monitoring，必須在scope內寫清楚。

最重要仍然是：不要為改動而改動。先問清楚改動解決甚麼問題，再決定是否值得承擔migration風險。

如你的網站準備轉CMS、改URL或domain，可以在開發規格及redirect邏輯仍可調整時，聯絡CK Growth Marketing查詢一次性SEO Audit。

常見問題

1. 只換網站設計、不改URL，也需要做migration SEO嗎？

需要按風險做檢查，但未必需要完整URL migration流程。重點是比較新舊template的內容、metadata、canonical、internal links、rendering、mobile及tracking，確認沒有因換版而意外改變搜尋及conversion訊號。

2. 改網址一定要用301 redirect嗎？

如果URL永久搬到另一個相關URL，Google建議盡量使用server-side permanent redirect，例如301或308。若只是短期轉向，才考慮temporary redirect。實際設定方式取決於CMS及server環境。

3. 轉domain後Search Console要做甚麼？

確認新舊domain及相關variant已驗證，提交新sitemap，測試redirect，並按Google要求使用Change of Address。HTTP轉HTTPS則不需要使用Change of Address。

4. URL有「/」與沒有「/」會否影響SEO？

除根目錄外，它們可以被視為不同URL。重點不是必須選哪一種，而是選定preferred版本，並保持redirect、canonical、internal links及sitemap一致，避免兩個版本同時返回相同內容的200頁面。

5. 網站改版後流量下跌是否正常？

短期波動可以發生，但不能把所有下跌都當成正常。先檢查P0問題，包括crawl/index blocks、錯誤redirect、canonical、內容遺失、server errors及tracking中斷，再觀察新舊URL的query、click和landing-page趨勢。

Related Posts

Scroll to Top