Shopify 改到 Headless，怎麼保住網址與流量

Shopify 改成 Headless 時，最容易被低估的不是新前端，而是舊網址。

設計、效能、結帳體驗都很重要，但上線當天真正會讓 SEO、廣告與營收出問題的，通常是這幾種連結突然失效：

• Google 已經收錄的商品頁
• 分類頁與活動頁
• EDM、LINE、Meta 廣告、KOL 貼文裡的商品連結
• 聯盟行銷與合作夥伴連結
• 帶有 utm_source、utm_campaign、coupon 或 referral 參數的網址

如果你正在做 Shopify 網址搬家，請把轉址層當成正式上線項目，而不是 DNS 切完之後才補的清理工作。

Shopify 搬到 Headless 為什麼容易壞網址

Shopify 原本的 URL 結構很固定：

• /products/{handle}
• /collections/{handle}
• /pages/{handle}

改成 Next.js、Hydrogen 或自建 Headless 架構後，團隊常會順手把路徑改短，或依新的資訊架構重新整理：

• /shop/{handle}
• /c/{handle}
• /{handle}

新結構可能更乾淨。但對搬站來說，問題不是新網址好不好看，而是舊網址還活在很多地方。

一個舊商品網址可能同時存在於 Google 搜尋結果、品牌 EDM、LINE 官方帳號圖文、Facebook 廣告、開箱文、QR Code、客服回覆模板，以及消費者自己的書籤裡。你不處理它，它就會變成 404。

[!WARNING] 不要等到 DNS cutover 才開始補轉址。轉址對照表應該在 staging 就完成匯入、抽查與批次爬行。

先定義搬站風險

沒有轉址對照表的 Headless 搬站，通常會遇到三個問題。

1. 商品與分類頁變成 404

Googlebot 和真實消費者都可能打到舊的 /products/... 或 /collections/...。如果沒有對應的新目的地，這些請求就會失敗。

2. 舊連結的價值被浪費

反向連結、站內連結、搜尋結果、合作頁面都需要清楚指到新的最佳目的地。不是每個舊網址都值得保留，但高價值 URL 不應該被丟到首頁或直接放任失效。

3. 活動歸因斷掉

搬站 QA 很容易只看「頁面有沒有到」，卻忘了 utm_、coupon、affiliate、referral 這些參數。如果轉址把 query string 洗掉，廣告與 EDM 報表會看起來像突然失真。

第 1 步：匯出舊 Shopify URL

不要靠記憶做轉址。

先從 Shopify 拿一份基礎清單，再用 SEO、分析與行銷資料補齊真正有流量的網址。

從 Shopify Admin 匯出商品

到 Products > Export 匯出全部商品。CSV 裡通常會有 Handle 欄位。

Handle,Title,Variant Price
cool-tshirt,Cool T-Shirt,29.99
blue-jeans,Blue Jeans,49.99

你可以用 handle 建出舊商品頁：

/products/cool-tshirt
/products/blue-jeans

解析 sitemap.xml

如果要包含商品、分類、頁面與 blog，請解析 Shopify 的 sitemap.xml。

# 安裝 sitemap parser
npm install -g sitemap-to-csv
 
# 抓取並轉成 CSV
sitemap-to-csv https://store.example/sitemap.xml > urls.csv

補上搜尋與活動資料

Shopify 不會知道所有重要網址。請另外匯出：

• Google Search Console 有曝光或點擊的頁面
• GA4、warehouse 或 BI 裡的 landing page 報表
• 仍在投放的廣告 URL
• EDM、CRM、簡訊、LINE 官方帳號裡的連結
• 聯盟行銷、KOL、合作夥伴頁面
• 客服常用連結與舊活動頁

這些網址要標出優先順序。高流量、高營收、高風險的 URL 先處理，不要把時間平均分給所有舊頁。

第 2 步：設計轉址對照表

你不一定要為每個網址手寫一條規則。Shopify 原本的結構很規律，很多情況可以用 pattern rule 處理，再用一對一規則處理例外。

情境 A：只改前綴

• 舊網址：https://shop.example/products/blue-jeans
• 新網址：https://shop.example/shop/blue-jeans

UrlEdge 規則可以像這樣：

• Source: ^/products/(.*)$
• Destination: /shop/$1
• Type: 301

情境 B：移除商品前綴

• 舊網址：https://shop.example/products/blue-jeans
• 新網址：https://shop.example/blue-jeans

UrlEdge 規則：

• Source: ^/products/(.*)$
• Destination: /$1
• Type: 301

[!TIP] 如果你把商品放到 root level，要先確認新 router 不會跟 /about、/contact、/cart、分類 slug 或活動頁互相撞到。

情境 C：保留活動參數

很多活動連結會在外面活很久。

https://shop.example/products/blue-jeans?utm_source=newsletter&utm_campaign=spring

轉址後應該到：

https://shop.example/shop/blue-jeans?utm_source=newsletter&utm_campaign=spring

如果 query parameters 被刪掉，你的 crawler 可能看不出問題，因為頁面仍然會到。但廣告、EDM、KOL 與會員活動的歸因會安靜地壞掉。

第 3 步：把例外先想清楚

Shopify 搬到 Headless 後，通常不是所有舊頁都能直接套 wildcard。

你至少要先決定這些情況：

• 已下架商品要導到替代商品、分類頁、品牌故事頁，還是 410？
• 合併後的 collection 要導到哪個新分類？
• 舊活動頁還有沒有搜尋或廣告流量？
• 商品 handle 改名時，要不要保留舊 slug？
• 多語系或多市場店面是否要保留地區路徑？

不要把所有例外都丟到首頁。對使用者來說，首頁通常不是「最接近」的目的地；對 SEO 和分析來說，它也會讓你失去判斷問題的能力。

第 4 步：在 Edge 層執行轉址

你可以把轉址寫進 headless app，例如 next.config.js 或 Middleware。但對大型搬站來說，把轉址綁在前端部署裡通常不理想。

比較乾淨的做法，是把轉址放在專門的 Edge routing layer：

• 大量規則不會塞進前端程式碼
• SEO 或行銷可以先匯入 CSV 讓工程審核
• DNS 切換前可以用 staging hostname 驗證
• 上線後修例外不必重新部署 storefront
• 舊商品頁與活動頁能直接在靠近訪客的節點回應

UrlEdge 可以匯入 CSV，也可以直接定義 Regex 規則。

{
  "rules": [
    {
      "source": "^/products/(.*)",
      "destination": "/shop/$1",
      "type": 301
    },
    {
      "source": "^/pages/contact-us",
      "destination": "/contact",
      "type": 301
    }
  ]
}

第 5 步：上線前驗證

Shopify 網址搬家不能只測首頁。

在正式切 DNS 前，請用舊 URL inventory 去打新的轉址層。

先測 staging domain

把 staging hostname 指到 UrlEdge，先測高價值 URL：

• 熱門商品頁
• 熱門分類頁
• 目前投放中的活動頁
• 有自然流量的 blog 或內容頁
• 帶 UTM、coupon、affiliate 參數的網址

用 curl 看狀態碼與 Location

curl -I https://staging.shop.example/products/old-product
 
# 預期輸出：
# HTTP/2 301
# location: /shop/old-product
# x-urledge-rule: regex-product-match

如果要看完整 hop，改用：

curl -IL https://staging.shop.example/products/old-product

你要看到的是一個乾淨的 301，而不是 HTTP -> HTTPS -> www -> old path -> final path 這種多段轉址鏈。

批次爬行舊網址

用 Screaming Frog 或類似 crawler，把舊 URL 清單整批丟進 staging。請特別看：

• 404
• 302 被誤用在永久搬家
• 多段轉址鏈
• 轉址迴圈
• query string 被移除
• 目的地不是最佳對應頁

如果你需要更完整的上線流程，可以搭配 網站搬家轉址檢查清單 一起跑。

上線日要看什麼

DNS 切換後，至少前 7 到 14 天要盯住這些訊號：

• 舊商品與分類頁的請求量
• 新站 404
• 高價值轉址規則的命中次數
• 廣告與 EDM landing page 報表
• Search Console 的索引與錯誤變化
• 客服是否收到找不到商品或訂單頁的回報

如果你在 UrlEdge 裡管理轉址，可以用 analytics、轉址檢查工具 與 壞連結監控 協助看規則是否真的按預期運作。

結論

Headless Shopify 搬站其實有兩次上線：一次是新 storefront，一次是讓舊流量安全抵達新站的轉址層。

真正穩的做法不是等 404 出現再補，而是提前完成：

• 商品頁、分類頁、活動頁與內容頁盤點
• 高價值 URL 的轉址對照表
• UTM 與活動參數保留
• CSV 或 Regex 批次規則
• staging 驗證與上線日監控

如果你準備把 Shopify 網址搬到 Headless 架構，先在 UrlEdge 建立轉址對照表，再讓新店面接正式流量。建立免費帳號 後可以先匯入第一批 URL 做驗證。