Skip to content
OriginalPhase Ops Handbook

WordPress / GoDaddy 搬站｜Cloudflare Pages Migration

這份 SOP 用在 WordPress / GoDaddy 舊站搬到 Cloudflare Pages 時，保住既有 SEO 訊號，避免 canonical 混亂、redirect loop、soft 404 或 GSC property 提交錯版本。

適用情境

  • 舊站在 WordPress、GoDaddy Website Builder、cPanel 或其他傳統主機。
  • 新站改由 Astro / Nuxt / static site 部署到 Cloudflare Pages。
  • 希望保留既有 URL、搜尋排名、分享連結與 GSC 歷史資料。

最終目標

  • 正式站只有一個 canonical host，例如 https://www.example.com。
  • root / www / HTTP / HTTPS 全部收斂到正確版本。
  • 舊 URL 若路徑不變，直接回 200，不額外 redirect。
  • 不存在的 URL 回真 404，不回 homepage 200。
  • sitemap、robots、canonical、og:url 全部指向 canonical host。

前置資料

  • 舊站完整 URL 清單，可從 WordPress export、sitemap、GSC、Analytics 或 crawl 工具取得。
  • 新站預計 canonical host，例如 https://www.example.com。
  • Cloudflare DNS / Rules / Pages 權限。
  • Google Search Console Domain property 與 canonical URL-prefix property 權限。

操作流程

1. 決定 canonical host

先決定正式版本是 root 還是 www。OriginalPhase 專案預設建議使用 www：

  • canonical：https://www.example.com
  • root：https://example.com 只做 301 到 www
  • Pages preview domain：只用於驗收，不進 sitemap，不提交 GSC

決策完成後，所有 metadata、sitemap、redirect、GSC sitemap 提交都要跟著同一個 host。

2. 設定 root / www DNS

在 Cloudflare Pages custom domains 綁定正式 host。若 canonical 是 www：

  • www CNAME 應直接指向 Pages project 提供的目標，例如 project-name.pages.dev。
  • 不要讓 www CNAME 指向 root domain，這很容易造成 root → www，www 又回 root 的 redirect loop。
  • root domain 可以透過 Cloudflare redirect rule 301 到 https://www.example.com/$1。

3. 保留舊 URL

如果舊 URL path 不變，例如 /about/ 新站也有 /about/，不需要新增 redirect。讓它直接回 200 才是最乾淨的狀態。

只有 path 改變時才建立 301 map：

  • /old-service/ → /services/
  • /blog/old-post/ → /articles/old-post/

不要把全部舊 URL 都 redirect 到首頁，這會造成 soft-404 與使用者體驗問題。

4. 檢查 SEO metadata

上線前逐頁抽查：

  • <link rel="canonical"> 使用 canonical host。
  • og:url 使用 canonical host。
  • sitemap 內只出現 canonical host。
  • robots.txt 的 Sitemap 指向 canonical sitemap。
  • 不要混入 Pages preview URL、root / www 混用或舊主機 URL。

5. 設定 GSC property

  • Domain property：用來看整個網域，包含 root、www、HTTP、HTTPS。
  • URL-prefix property：用來提交 canonical host 版本，例如 https://www.example.com/。

正式 sitemap 請提交 canonical host 版本，不要提交 root 版本或 preview domain。

6. 確認 unknown URL 是真 404

搬站後最常見的坑是 SPA fallback 或 Pages route 設定讓所有未知 URL 都回 homepage 200。未知 URL 應該回：

  • HTTP status 404
  • 清楚的 404 頁面內容
  • 不要回首頁 HTML

若內容已永久刪除且沒有替代頁，使用 404 或 410；若有明確替代頁，才使用 301。

驗證指令

DNS 與 redirect 驗證

檢查 root / www 收斂

Expected: 非 canonical 回 301，canonical 回 200

Terminal window
curl -I https://example.com/
curl -I https://www.example.com/
curl -I http://example.com/
curl -I http://www.example.com/

SEO metadata 驗證

檢查 sitemap 與 robots

Expected: sitemap 是 XML，URL 全部使用 canonical host

Terminal window
curl -s https://www.example.com/robots.txt
curl -s https://www.example.com/sitemap.xml | head

Soft 404 驗證

確認 unknown URL 是真 404

Expected: HTTP status 應為 404

Terminal window
curl -I https://www.example.com/this-url-should-not-exist

Agent Prompt

Prompt

SEO Migration Audit

搬站前後稽核 Codex

請針對這個 WordPress / GoDaddy → Cloudflare Pages 搬站專案做 SEO Migration Audit。

限制：

  • 請先 audit，不要一開始直接修改程式。
  • 請檢查 canonical host、root / www redirect、sitemap、robots.txt、canonical tag、og:url、GSC property 規劃與 unknown URL status。
  • 如果舊 URL path 沒變，請不要建議不必要的 redirect。
  • 如果 unknown URL 回 200 homepage HTML，請標成 P0 風險。

輸出格式：

  1. Canonical host 決策是否一致
  2. DNS / redirect 風險
  3. Sitemap / robots / metadata 檢查
  4. GSC property 建議
  5. 需要修復的項目，依 P0 / P1 / P2 排序
  6. 驗證指令

常見錯誤

  • www CNAME 指向 root，root 又 301 到 www，造成 redirect loop。
  • sitemap 提交 root host，但 canonical 寫 www。
  • 舊 URL 已存在於新站，卻又額外 301 到自己或首頁。
  • unknown URL 回首頁 200，被 Google 判成 soft-404 或 duplicate URL。

完成標準

Checklist

搬站完成前檢查

P0

  • canonical host 已決定並全站一致。
  • www CNAME 直接指向 Pages project。
  • root / HTTP / 非 canonical host 都 301 到 canonical host。
  • sitemap、robots、canonical、og:url 都使用 canonical host。
  • 舊 URL 不變時直接回 200。
  • unknown URL 回真 404。
  • GSC 已建立 Domain property 與 canonical URL-prefix property。