Cloudflare Pages SEO 上線檢查｜Launch Checklist

這份 SOP 用在 Cloudflare Pages 網站正式上線前，確認搜尋引擎看到的是唯一、穩定、可索引的 canonical 網站版本。

適用情境

新網站準備從 preview / staging 切到正式網域。
WordPress、舊主機或舊 Pages 專案要搬到 Cloudflare Pages。
Google Search Console 顯示 sitemap could not fetch、Duplicate without user-selected canonical、Alternate page with proper canonical tag 或 soft 404。
網站同時存在 root domain、www、HTTP、HTTPS、Pages preview URL，多個版本可能被搜尋引擎看見。

最終目標

正式上線後，所有公開 URL 都應該收斂到同一個 canonical host，常見目標是 https://www.example.com。搜尋引擎、sitemap、robots.txt、canonical tag、Open Graph、JSON-LD 和 redirect 規則都必須指向同一個 host。

Checklist

上線前結果檢查

http://example.com 301 到 canonical HTTPS host。
https://example.com 301 到 canonical HTTPS host。
http://www.example.com 301 到 canonical HTTPS host。
https://www.example.com 回 200，且是正式內容。
robots.txt 指向 canonical sitemap。
sitemap.xml 是有效 XML，且 sitemap 內 URL 全部回 200。
canonical、og:url、JSON-LD url 使用同一個 host。
unknown URL 回真正的 404，不回 homepage 200。

必備前置資料

Cloudflare 帳號與該 zone 的 DNS / Rules 權限。
Cloudflare Pages 專案名稱、production branch、正式 custom domain。
決定好的 canonical host，例如 https://www.example.com。
Google Search Console 權限，最好能建立 Domain property。
本機可使用 curl、grep，必要時可用瀏覽器檢查 response header。
專案中的 sitemap、robots、SEO metadata 產生位置。

操作流程

1. 決定 canonical host

先決定唯一正式主機。OriginalPhase 專案預設建議使用 www：

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

決策完成後，不要在不同頁面混用 root / www。混用會讓 GSC 和搜尋引擎把同一內容視為多個 URL 版本。

2. 設定 root / www 301 redirect

在 Cloudflare 內設定 redirect rule，讓 root domain 永久轉址到 canonical www：

example.com/* → https://www.example.com/$1
狀態碼使用 301
保留 path 與 query string

如果 canonical host 決定不用 www，方向反過來即可，但全站所有 metadata 都要同步。

3. 設定 HTTP 到 HTTPS

在 Cloudflare SSL/TLS 設定中開啟 Always Use HTTPS，讓 HTTP request 自動 301 到 HTTPS。

先不要開 HSTS。HSTS 會讓瀏覽器記住 HTTPS 強制規則，初次上線或 redirect 還在調整時，太早開啟會增加 rollback 難度。等正式站穩定、憑證與 redirect 都確認後，再評估開啟。

4. 檢查 sitemap

確認 sitemap.xml 是有效 XML，並且所有 URL 都是 canonical host：

sitemap 不能混入 preview URL。
sitemap 不能混入 root domain，如果 canonical 是 www。
sitemap 內的每個 URL 都要回 200。
不要把 redirected URL 放進 sitemap。

5. 檢查 robots.txt

robots.txt 必須指向 canonical sitemap：

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

如果此文件站是內部使用，則應維持 noindex；但公開網站上線 SOP 的 robots 檢查仍應以公開站為準。

6. 統一 canonical / og:url / JSON-LD

每個頁面的這三者必須使用同一個 host：

<link rel="canonical" href="https://www.example.com/path/" />
<meta property="og:url" content="https://www.example.com/path/" />
JSON-LD 裡的 url、@id、mainEntityOfPage

不要出現 canonical 是 www、og:url 是 root domain、JSON-LD 是 preview URL 的混合狀態。

7. 建立 GSC property 並提交 sitemap

Google Search Console 建議建立：

Domain property：涵蓋 root、www、HTTP、HTTPS，適合看整體網域狀態。
URL-prefix property：針對 canonical host，例如 https://www.example.com/，適合提交 sitemap 與檢查正式版本。

sitemap 提交 canonical www 版本：

https://www.example.com/sitemap.xml

8. 確認 unknown URL 回真正 404

Cloudflare Pages 或 SPA fallback 設錯時，未知 URL 可能回 homepage 200。這會造成 soft 404、錯誤索引或 GSC 覆蓋率混亂。

未知 URL 應該：

HTTP status 是 404
頁面內容是清楚的 404
不要用 200 回首頁內容

驗證指令

部署後驗證

檢查 root / www / HTTP / HTTPS 收斂

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

預期結果：

非 canonical URL 回 301。
Location 指向 canonical HTTPS host。
canonical URL 回 200。

SEO 驗證

檢查 robots 與 sitemap

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

Sitemap 驗證

抽查 sitemap URL 是否回 200

curl -s https://www.example.com/sitemap.xml \
  | grep -o 'https://www.example.com[^<]*' \
  | head -20 \
  | while read url; do curl -o /dev/null -s -w "%{http_code} %{url_effective}\n" "$url"; done

Soft 404 驗證

確認 unknown URL 是真 404

curl -I https://www.example.com/this-page-should-not-exist-404-check

Agent Prompt 範例

Prompt

Cloudflare Pages SEO Launch Audit Agent

Any Agent

你是資深技術 SEO 與 Cloudflare Pages 上線檢查 Agent。請根據以下資料檢查網站是否可以正式提交到 Google Search Console。

輸入資料：

canonical host：
Cloudflare Pages production URL：
root domain：
www domain：
sitemap URL：
robots.txt URL：
需要抽查的頁面 URL：

請依序檢查：

canonical host 決策是否一致。
root / www 是否用 301 redirect 收斂。
HTTP 是否轉 HTTPS。
Cloudflare 是否開啟 Always Use HTTPS。
是否尚未開 HSTS，或若已開啟，列出風險。
sitemap 是否為有效 XML。
sitemap 內 URL 是否全部使用 canonical host 並回 200。
robots.txt 是否指向 canonical sitemap。
canonical、og:url、JSON-LD 是否使用同一 host。
GSC 應建立 Domain property 或 URL-prefix property，以及 sitemap 應提交哪個版本。
unknown URL 是否回真 404，而不是 homepage 200。

輸出格式：

結論：可以上線 / 需修正後再上線
Blocking issues
Non-blocking recommendations
驗證指令
修正建議
完成標準

常見錯誤

sitemap 提交 root，但 canonical 是 www

GSC 會看到 sitemap URL 和頁面 canonical 不一致。修正方式是重新產生 sitemap，全部使用 canonical host，並在 URL-prefix property 提交 canonical 版本。

開了 Always Use HTTPS，又另外寫了衝突 redirect

Cloudflare redirect rule、Pages redirect、framework redirect 如果互相指向不同 host，會造成 redirect loop。先畫出每一層規則，再保留一個最清楚的收斂方向。

太早開 HSTS

HSTS 適合穩定後加強安全性，不適合剛上線還在調整 redirect 時使用。若已開啟，先確認 max-age、includeSubDomains、preload 狀態，再評估如何安全調整。

unknown URL 回首頁 200

這通常是 SPA fallback 或 Pages _redirects 設定過度寬鬆。公開網站可以有漂亮 404 頁，但 status code 必須是 404。

canonical / og:url / JSON-LD host 不一致

社群分享、結構化資料與搜尋引擎 canonical 判斷會彼此矛盾。SEO metadata 應該共用同一個 site URL config，不要分散在多個檔案手寫。