Shopify 轉向 Headless 遷移：Next.js、Hydrogen 和 Remix 指南

在過去三年中，我已經遷移了十多個 Shopify 商店到 headless 架構。有些進行得很順利。也有幾個是噩夢。區別幾乎總是歸結於規劃 — 特別是團隊在寫第一行代碼之前是否理解他們真正要面對的問題。

本指南涵蓋了我希望在第一次 headless Shopify 遷移前有人告訴我的所有內容：選擇哪個前端框架、如何保留你的 SEO 排名、如何在切換期間實現零停機時間、實際成本是多少，以及基於商店複雜性的現實時間表。沒有空話。沒有「取決於」而不解釋取決於什麼。

目錄

• 為什麼要從 Shopify 遷移到 Headless？
• Headless Shopify 架構詳解
• 選擇前端框架：Next.js vs Hydrogen vs Remix
• 逐步遷移過程
• 遷移期間的 SEO 保護
• 零停機時間遷移策略
• 定價和時間表細目
• 常見遷移陷阱
• 何時 Headless 不是合適的選擇
• 常見問題

為什麼要從 Shopify 遷移到 Headless？

讓我們先把這個問題解決：標準 Shopify 對大多數商店都很有用。如果你的年銷售額低於 200 萬美元，而且你的主題滿足你的需求，你可能不需要 headless。說真的。我勸阻人們進行這次遷移的次數比我鼓勵他們進行遷移的次數還要多。

但有充分的理由轉向 headless：

• 性能上限：Liquid 主題有渲染瓶頸。即使使用 Online Store 2.0 和 Dawn，你也受限於 Shopify 的伺服器端渲染管道。Headless 商店一致地達到亞秒級 LCP 分數。
• 自定義體驗：產品配置器、AR 試穿、複雜過濾、個性化引擎 — 這些在 Liquid 中構建起來很困難。
• 多店面：一個後端支持你的 DTC 站點、批發門戶、行動應用程式和國際商店。
• 內容豐富的品牌：如果你的品牌嚴重依賴編輯內容、外觀書和故事敘述，將 headless CMS 與 Shopify 的商務引擎結合會為你提供兩者的最佳結合。
• 開發者體驗：你的團隊想要用 React/TypeScript 工作，而不是 Liquid。這比人們承認的更重要。

性能提升是真實且可衡量的。在 2025 年，Google 的 Core Web Vitals 直接影響你的搜尋排名。我遷移到 headless 的商店通常在 LCP 中看到 30-50% 的改進，在總阻止時間中看到 40-60% 的改進。這轉化為可衡量的轉換率改進 — Shopify 自己的數據表明頁面速度每提高 1%，轉換可能增加 0.7%。

Headless Shopify 架構詳解

當人們說「headless Shopify」時，他們的意思是將前端（客戶看到的）與後端（Shopify 的商務引擎）分離。你保留 Shopify 用於產品、庫存、訂單、結帳和支付。你構建一個通過 Storefront API 與 Shopify 通信的自定義前端。

以下是典型的架構：

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   自定義前端     │────▶│  Storefront API   │────▶│  Shopify 後端   │
│(Next.js/H2/Remix)│    │  (GraphQL)        │     │ (產品、購物車、  │
│                 │     │                  │     │   訂單等)       │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │
        ▼
┌─────────────────┐
│  Headless CMS    │
│(Sanity, Contentful,│
│   Storyblok)     │
└─────────────────┘

Shopify Plus 商家可以存取 Checkout Extensibility API，它允許你自定義結帳而無需重新導向到 Shopify 的託管結帳。對於非 Plus 商店，客戶仍然會被重新導向到 checkout.shopify.com 進行實際購買 — 老實說這不是一個可怕的體驗，但這確實是一個 UX 中斷。

Storefront API

所有內容都通過 Shopify 的 Storefront API 運行，這是一個 GraphQL 端點，處理：

• 產品查詢和集合
• 購物車管理（建立、更新、移除行項目）
• 客戶驗證
• 內容（元欄位、元物件）
• 商店本地化和貨幣

API 有速率限制 — 單個應用每秒 50 個成本點。在實踐中，如果你正確進行快取，這很少是個問題，但如果你沒有為它進行規劃，它可能在快閃銷售期間困擾你。

# 示例：使用變體獲取產品
query ProductQuery($handle: String!) {
  product(handle: $handle) {
    id
    title
    descriptionHtml
    priceRange {
      minVariantPrice {
        amount
        currencyCode
      }
    }
    variants(first: 100) {
      edges {
        node {
          id
          title
          availableForSale
          price {
            amount
          }
          selectedOptions {
            name
            value
          }
        }
      }
    }
    images(first: 10) {
      edges {
        node {
          url
          altText
          width
          height
        }
      }
    }
  }
}

選擇前端框架：Next.js vs Hydrogen vs Remix

這是大多數團隊卡住的地方。以下是我使用所有三個框架構建生產商店後的誠實看法。

特性	Next.js 15	Hydrogen 2024.10+	Remix (Shopify)
框架成熟度	非常成熟，龐大的生態系統	成熟中，Shopify 特定	成熟（合併到 React Router 7）
Shopify 整合	通過 Storefront API 手動	第一方，內建鉤子	通過 Hydrogen UI 很好
託管	Vercel、Netlify、自託管	Oxygen (Shopify) 或自託管	任何地方，但針對 Oxygen 優化
學習曲線	中等	中等-高	中等
社區/招聘	龐大	小但不斷增長	中等
SSR/SSG 靈活性	優秀 (App Router)	SSR 焦點（流）	SSR 焦點（加載器）
快取控制	ISR、按需重新驗證	Oxygen 子請求快取	標準 HTTP 快取
最適合	有 React 經驗的團隊、複雜內容需求	Shopify 原生團隊、簡單到中等商店	想要 Shopify 推薦路徑的團隊

Next.js：安全的選擇

Next.js 是我對大多數團隊的推薦，特別是如果你將 Shopify 與 Sanity 或 Contentful 等 headless CMS 配對。生態系統非常龐大，招聘更容易，使用 App Router 的伺服器元件你會獲得難以置信的靈活性。

缺點呢？你必須自己連接 Shopify 整合。沒有針對 Next.js 的官方 Shopify SDK（雖然 @shopify/hydrogen-react 等社區套件為你提供購物車鉤子和實用程式）。你會花更多時間在樣板上。

我們在 Social Animal 構建了很多 headless Shopify 商店，使用 Next.js — 它是我們最受歡迎的電子商務專案堆棧。

Hydrogen：Shopify 自己的框架

Hydrogen 是 Shopify 的官方 headless 框架，構建在 Remix 之上（現在是 React Router 7）。它配有產品、購物車和 SEO 的預構建元件 — 加上與 Oxygen（Shopify 的邊緣託管平台）的緊密整合。

吸引力很明顯：更少的樣板、Shopify 優化的快取和一個在 Oxygen 上恰好有效的部署故事。2024.10 版本帶來了重大改進，包括更好的 TypeScript 支持和購物車操作的樂觀 UI 更新。

缺點呢？社區較小，當你卡住時資源較少，你在某種程度上被鎖定在 Shopify 的生態系統中。如果你曾經想要交換商務後端，你需要重寫的代碼比使用 Next.js 要多得多。

Remix / React Router 7

這是令人困惑的部分：Remix 已合併到 React Router 7 中。Hydrogen 構建在 Remix 之上。所以在大多數情況下，「用於 Shopify 的 Remix」實際上意味著 Hydrogen。

如果你想在沒有 Hydrogen 的 Shopify 特定抽象的情況下使用 React Router 7，你可以。你會得到相同的加載器/操作模式、相同的流式 SSR 和對你的 Shopify 整合的完全控制。如果你已經是 Remix 團隊並希望最大程度的靈活性，這很有意義。

我的建議

對於內容豐富、佈局複雜的品牌：Next.js + headless CMS。對於想要最快生產路徑的簡單 DTC 商店：Oxygen 上的 Hydrogen。對於已投資於 Remix 生態系統的團隊：帶有 Hydrogen UI 元件的 React Router 7。

逐步遷移過程

以下是我對每次遷移遵循的過程。它很無聊。它有效。

第 1 階段：審計和規劃（2-3 週）

1. 爬取現有站點 — 使用 Screaming Frog 或 Sitebulb 來編目每個 URL、重新導向、正規化標籤和結構化數據塊。匯出此內容。你稍後會需要它。
2. 記錄所有整合 — Klaviyo、Yotpo 評論、忠誠度計劃、訂閱應用（Recharge、Loop）、支付閘道。每一個。
3. 對映 URL 結構 — 你的新 URL 是否與舊 URL 相符？Shopify 使用 /products/product-handle 和 /collections/collection-handle。如果你改變這些，你需要重新導向。
4. 確定自定義功能 — 除了標準的瀏覽和購買之外的任何內容。禮品卡、套件組合、批發定價、多貨幣、B2B。
5. 選擇你的堆棧 — 前端框架、CMS、託管、CDN。

第 2 階段：構建前端（6-12 週）

這是實際開發發生的地方。關鍵領域：

• 產品頁面，具有變體選擇、圖像庫、評論整合
• 集合頁面，具有過濾、排序、分頁
• 購物車，具有即時庫存檢查和追加銷售
• 搜尋 — Shopify 的預測搜尋 API 或第三方如 Algolia
• 客戶帳戶 — 登入、訂單歷史、地址管理
• CMS 驅動的頁面 — 首頁、關於、登陸頁面
• 結帳重新導向 — 處理到 Shopify 結帳的交接

// 示例：使用 ISR 的 Next.js 產品頁面
import { getProduct } from '@/lib/shopify'
import { ProductDetails } from '@/components/product-details'

export async function generateStaticParams() {
  const products = await getAllProductHandles()
  return products.map((handle) => ({ handle }))
}

export default async function ProductPage({ 
  params 
}: { 
  params: { handle: string } 
}) {
  const product = await getProduct(params.handle)
  
  if (!product) notFound()

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(generateProductJsonLd(product)),
        }}
      />
      <ProductDetails product={product} />
    </>
  )
}

export const revalidate = 60 // ISR：每 60 秒重新驗證一次

第 3 階段：整合和 QA（2-4 週）

連接所有第三方服務。測試所有內容。我的意思是所有內容：

• 通過所有支付方式下達測試訂單
• 測試折扣代碼、禮品卡、自動折扣
• 驗證分析追蹤（GA4、Meta Pixel、TikTok Pixel）
• 在預期流量下對 Storefront API 呼叫進行負載測試
• 在實際設備上測試，而不僅僅是 Chrome DevTools

第 4 階段：切換（1-2 天）

實際開關。有關零停機時間部分的更多信息，請見下文。

遷移期間的 SEO 保護

這是遷移出錯的地方。我見過商店因為有人忘記了 URL 重新導向而損失 40% 的有機流量。不要成為那個團隊。

URL 對映

在寫一行重新導向規則之前，請建立一個完整的 URL 對映文檔。舊站點上的每個 URL 都需要一個新站點上的目標。

舊的：/collections/summer-2024
新的：/collections/summer-2024  ← 相同？很好，不需要重新導向。

舊的：/blogs/news/our-story
新的：/journal/our-story  ← 不同？需要 301 重新導向。

舊的：/pages/about-us
新的：/about  ← 不同？需要 301 重新導向。

結構化數據

Shopify 主題包含基本的結構化數據。當你轉向 headless 時，你有責任自己實現它。至少：

• Product 架構，具有 offers、aggregateRating
• BreadcrumbList 用於導航
• Organization 用於你的品牌
• WebSite，具有 SearchAction 用於 sitelinks 搜尋
• FAQPage（如適用）

元標籤和正規化

每個頁面都需要適當的 <title>、<meta description>、正規化 URL 和 Open Graph 標籤。在 Next.js 中，使用元數據 API：

export async function generateMetadata({ params }): Promise<Metadata> {
  const product = await getProduct(params.handle)
  
  return {
    title: product.seo.title || product.title,
    description: product.seo.description || product.description,
    openGraph: {
      images: [product.featuredImage?.url],
    },
    alternates: {
      canonical: `https://yourstore.com/products/${params.handle}`,
    },
  }
}

XML Sitemap

從 Shopify 的數據動態生成你的 sitemap。包括產品、集合和 CMS 頁面。遷移後立即將其提交到 Google Search Console。

遷移前 SEO 檢查清單

• 完整的 URL 對映文檔
• 已配置並測試的 301 重新導向
• 在每個頁面類型上實現的結構化數據
• 從 Shopify SEO 欄位提取的元標籤
• 動態生成的 XML sitemap
• robots.txt 配置正確
• Google Search Console 已通知域更改（如適用）
• 內部連結已更新為新 URL 結構
• 保留了來自 Shopify 的圖像替代文本

零停機時間遷移策略

零停機時間不是魔法。這是 DNS 管理和準備。

藍綠部署方法

1. 在暫存域上構建和部署新站點（例如 new.yourstore.com）
2. 同時運行兩個站點至少一周，徹底測試新站點
3. 配置你的 CDN/DNS 支持即時切換（Cloudflare、Vercel 或 Netlify 都支持這一點）
4. 切換 DNS 指向新前端 — TTL 應提前設置為 60 秒
5. 監控所有內容：錯誤率、404、轉換率、Core Web Vitals

代理方法（更安全）

對於月銷售額超過 100 萬美元的商店，我更喜歡基於代理的遷移：

1. 在舊站點和新站點前面放置反向代理（Cloudflare Workers、Vercel Edge 中間件）
2. 逐頁路由流量 — 從低風險頁面開始，如 /about
3. 在 2-4 週內逐步將頁面移動到新前端
4. 在移動下一批之前監控每個頁面的效能
5. 產品和集合頁面最後進行（最高收入風險）

這種方法增加了複雜性，但讓你在問題影響整個商店之前發現問題。

// Vercel Edge 中間件示例，用於漸進式遷移
import { NextResponse } from 'next/server'

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl
  
  // 已遷移到新前端的頁面
  const migratedPaths = ['/about', '/contact', '/journal']
  
  if (migratedPaths.some(path => pathname.startsWith(path))) {
    return NextResponse.next() // 從新前端提供
  }
  
  // 一切都代理到舊 Shopify 商店
  return NextResponse.rewrite(
    new URL(pathname, 'https://old-store.myshopify.com')
  )
}

定價和時間表細目

讓我們談論真實數字。這些基於我在 2025 年看到的專案，從簡單的 DTC 商店到複雜的多市場運營。

商店複雜性	時間表	代理成本	自由職業者成本
簡單（< 50 個產品、基本頁面、標準結帳）	8-12 週	$40,000 - $75,000	$20,000 - $40,000
中等（50-500 個產品、CMS、訂閱、多貨幣）	12-20 週	$75,000 - $150,000	$40,000 - $80,000
複雜（500+ 個產品、B2B+DTC、自定義結帳、多個整合）	20-32 週	$150,000 - $300,000+	$80,000 - $150,000

持續成本

別忘了經常性費用：

• Shopify Plus：$2,300/月（headless 推薦）
• 託管：$20-500/月（Vercel Pro 是 $20/用戶，Oxygen 包含在 Shopify 中）
• Headless CMS：$0-500/月（Sanity、Contentful、Storyblok 都有免費層級）
• 搜尋：$0-500/月（如果使用 Algolia 或類似的）
• 維護：預算初始構建成本的年度 10-15%

對於探索 headless Shopify 遷移將對其特定情況成本的團隊，我們在這裡詳細說明我們的定價方法。我們很樂意通過快速通話為事情評估範圍。

常見遷移陷阱

1. 低估購物車

購物車似乎很簡單，直到你考慮到：折扣代碼、自動折扣、禮品卡、行項目屬性、購物車備註、估計運費、稅務計算和購物車級別元欄位。為購物車功能預算兩倍的時間。

2. 忘記應用程式

Shopify 應用程式生態系統你依賴嗎？大多數應用程式將 JavaScript 注入到你的 Liquid 主題中。轉向 headless 意味著你需要基於 API 的替代方案或自定義實現評論、願望清單、忠誠度計劃等。

3. 結帳自定義

沒有 Shopify Plus（$2,300/月），你無法自定義結帳體驗。客戶將被重新導向到 Shopify 的託管結帳，這會造成視覺斷開。Plus 商家可以使用 Checkout Extensibility，但仍然比完全自定義結帳受到更多限制。

4. 不早期進行性能測試

Storefront API 增加了延遲。如果你正在進行 8 個 API 呼叫來呈現產品頁面，你會感受到它。積極快取、使用 GraphQL 片段來最小化過度獲取，並在可能的地方實現流式 SSR。

5. 忽略內容團隊

你的行銷團隊在 Shopify 的管理員中管理內容。現在他們需要一個 headless CMS。預算時間用於培訓和構建一個實際上很愉快使用的內容編輯體驗。這是headless CMS 開發專業知識真正重要的地方。

何時 Headless 不是合適的選擇

我會直言不諱：headless Shopify 不適合所有人。如果以下情況不要遷移：

• 你的商店年銷售額低於 100 萬美元，並且你沒有複雜的自定義需求
• 你沒有預算用於持續開發和維護
• 你的團隊沒有 React 開發人員（或預算僱用/合約他們）
• 你對當前主題的效能和功能感到滿意
• 你主要是在尋求「酷技術」故事而不是解決實際業務問題

Shopify 的 Online Store 2.0 與優化良好的主題可以在 Lighthouse 上獲得 90+ 分。有時正確的答案是優化你已擁有的東西，而不是從頭開始重建。

如果你不確定，請考慮從混合方法開始：保留你的 Shopify 主題，但將特定的高影響力頁面（如你的首頁或登陸頁面）構建為 headless。你可以在現有主題旁邊使用 Shopify 的 Storefront API。這允許你在提交完整遷移之前證明價值。

常見問題

從 Shopify 遷移到 headless 需要多長時間？ 對於典型的中等複雜性商店，預期從啟動到啟動需要 12-20 週。擁有較少產品和基本功能的簡單商店可以在 8-12 週內發運。具有自定義結帳和廣泛整合的複雜多市場商店通常需要 20-32 週。審計和規劃階段本身應該是 2-3 週 — 不要跳過它。

遷移到 headless Shopify 時我會失去 SEO 排名嗎？ 如果做得正確，不會。關鍵是：保留相同的 URL 結構（或設置適當的 301 重新導向）、在每個頁面類型上實現結構化數據、保留元標籤和正規化 URL，並立即將更新的 sitemap 提交到 Google Search Console。我通常在遷移後看到 1-2 週的排名波動，然後在 Google 識別更好的 Core Web Vitals 分數後改進。

headless 我需要 Shopify Plus 嗎？ 從技術上講，沒有。Storefront API 在所有 Shopify 計劃上都可用。但是，Shopify Plus 為你提供 Checkout Extensibility（自定義結帳體驗）、更高的 API 速率限制和對 Oxygen 託管的存取。對於認真的 headless 專案，Plus 在 $2,300/月時幾乎總是值得的。

Hydrogen 和使用 Next.js 和 Shopify 之間的區別是什麼？ Hydrogen 是 Shopify 的官方 headless 框架，構建在 Remix/React Router 7 之上。它包含 Shopify 特定的元件、鉤子和實用程式，以及針對 Oxygen 的優化部署。Next.js 要求你自己構建 Shopify 整合，但為你提供更大的生態系統、更多的託管選項和對複雜內容架構的更好支持。大多數代理（包括我們的）根據特定的專案要求對此有強烈的看法。

我可以通過零停機時間遷移到 headless Shopify 嗎？ 是的，使用藍綠部署（DNS 切換）或漸進式基於代理的遷移。藍綠方法通過 DNS 一次性切換所有流量，而代理方法在數週內逐步遷移頁面。兩者都有效。代理方法對高收入商店更安全，但增加了複雜性。

headless Shopify 遷移成本是多少？ 代理成本通常從簡單商店的 $40,000 到複雜多市場運營的 $300,000+ 不等。自由職業者費率大致是代理成本的 50-60%，但可能伴隨較少的專案管理結構和較少的專家。持續成本包括 Shopify Plus（$2,300/月）、託管（$20-500/月）、CMS（$0-500/月）和維護（構建成本的年度 10-15%）。

我應該使用 Astro 而不是 Next.js 或 Hydrogen 進行 headless Shopify 嗎？ Astro 對於內容豐富的站點是一個很好的選擇，具有交互性孤島，我們已經構建了幾個由 Astro 驅動的店面。它非常適合目錄風格的商店，其中大多數頁面是靜態的，你只需要 React（或 Svelte、Vue）來處理購物車等互動元件。但是，對於具有繁重客戶端互動的商店 — 即時庫存、複雜過濾、即時搜尋 — Next.js 或 Hydrogen 的完整 React 執行時通常是更好的選擇。

遷移到 headless 後我的 Shopify 應用會發生什麼？ 大多數注入前端代碼的 Shopify 應用程式（彈出窗口、小工具、評論顯示）不會立即工作。你需要直接使用應用程式的 API、找到一個 headless 相容的替代方案，或構建自定義實現。僅在後端運作的應用程式（庫存管理、運費、ERP 整合）通常無需更改即可繼續工作。始終在規劃階段審計你的應用堆棧。