我在过去三年内已将十多家 Shopify 商店迁移到无头架构。有些进展顺利。少数几个是噩梦。区别几乎总是归结为规划——特别是团队在编写第一行代码前是否真正理解了他们所要面对的问题。

本指南涵盖了我希望在第一次无头 Shopify 迁移前有人告诉我的一切：选择哪个前端框架、如何保留你的 SEO 排名、如何在切换过程中实现零停机时间、实际成本是多少，以及基于商店复杂度的现实时间表。没有含糊其辞。没有"取决于"而不解释取决于什么。

目录

Shopify 无头迁移指南：Next.js、Hydrogen & Remix

为什么从 Shopify 迁移到无头

让我们先说清楚：标准 Shopify 对大多数商店都很好用。如果你的年销售额低于 200 万美元，你的主题满足你的需求，你可能不需要无头。说真的。我劝阻迁移的次数比劝说的次数更多。

但迁移到无头有合理的理由：

  • 性能瓶颈：Liquid 主题有渲染瓶颈。即使使用 Online Store 2.0 和 Dawn，你也受到 Shopify 服务器端渲染管道的限制。无头商店通常实现低于 1 秒的 LCP 分数。
  • 自定义体验：产品配置器、AR 试穿、复杂过滤、个性化引擎——这些在 Liquid 中很难实现。
  • 多店面：一个后端支持你的 DTC 网站、批发门户、移动应用和国际商店。
  • 内容丰富的品牌：如果你的品牌依赖于大量编辑内容、lookbooks 和叙事，将无头 CMS 与 Shopify 的商务引擎结合使用可以兼得两者之长。
  • 开发体验：你的团队想要在 React/TypeScript 中工作，而不是 Liquid。这比人们承认的更重要。

性能提升是真实且可衡量的。在 2025 年，Google 的 Core Web Vitals 直接影响你的搜索排名。我迁移到无头的商店通常看到 LCP 改进 30-50%，总阻塞时间改进 40-60%。这转化为可衡量的转化率改进——Shopify 自己的数据表明页面速度提高 1% 可能会将转化提高多达 0.7%。

无头 Shopify 架构详解

当人们说"无头 Shopify"时，他们的意思是将前端（客户看到的）与后端（Shopify 的商务引擎）解耦。你保留 Shopify 用于产品、库存、订单、结账和支付。你构建一个通过 Storefront API 与 Shopify 通信的自定义前端。

这是典型的架构：

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   自定义前端     │────▶│  Storefront API   │────▶│  Shopify 后端    │
│(Next.js/H2/Remix)│   │  (GraphQL)        │     │(产品、购物车、   │
│                 │     │                  │     │   订单等)       │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │
        ▼
┌─────────────────┐
│   无头 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 等无头 CMS 配对。生态系统巨大，招聘更容易，App Router 提供了不可思议的灵活性。

缺点？你必须自己连接 Shopify 集成。没有官方的 Next.js Shopify SDK（尽管 @shopify/hydrogen-react 等社区包提供购物车钩子和实用程序）。你会花更多时间在样板上。

我们在 Social Animal 构建了许多带有 Next.js 的无头 Shopify 商店——这是电商项目最常请求的堆栈。

Hydrogen：Shopify 自己的框架

Hydrogen 是 Shopify 官方的无头框架，构建在 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。

如果你想使用 React Router 7 而不使用 Hydrogen 的 Shopify 特定抽象，你可以。你会获得相同的加载程序/操作模式、相同的流 SSR 和对 Shopify 集成的完全控制。如果你已经是 Remix 团队并且想要最大的灵活性，这就有意义了。

我的推荐

对于内容丰富的品牌和复杂页面布局：Next.js + 无头 CMS。对于想要最快进入生产路径的直接面向消费者的简单商店：Oxygen 上的 Hydrogen。对于已投资于 Remix 生态系统的团队：带 Hydrogen UI 组件的 React Router 7。

Shopify 无头迁移指南：Next.js、Hydrogen & Remix - 架构

迁移流程逐步说明

这是我对每次迁移遵循的流程。很无聊。能用。

阶段 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 主题包括基本的结构化数据。当你进入无头时，你负责自己实现。最低限度：

  • Product 架构，带有 offers、aggregateRating
  • BreadcrumbList 用于导航
  • Organization 用于你的品牌
  • WebSite 带 SearchAction 用于 sitelinks 搜索
  • FAQPage 如果适用

元标签和规范

每个页面都需要适当的 <title>、<meta description>、规范 URL 和 Open Graph 标签。在 Next.js 中，使用 Metadata 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 站点地图

从 Shopify 数据动态生成你的站点地图。包括产品、集合和 CMS 页面。迁移后立即将其提交给 Google Search Console。

迁移前的 SEO 检查清单

  • 完整的 URL 映射文档
  • 已配置和测试的 301 重定向
  • 已实现并验证的结构化数据
  • 从 Shopify SEO 字段提取元标签
  • 动态生成的 XML 站点地图
  • 正确配置的 robots.txt
  • Google Search Console 已通知域名更改（如果适用）
  • 内部链接已更新到新 URL 结构
  • 保留 Shopify 的图像 alt 文本

零停机时间迁移策略

零停机时间不是魔法。这是 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 Middleware）
  2. 逐页路由流量——从低风险页面开始，如 /about
  3. 在 2-4 周内逐步将页面移动到新前端
  4. 在移动下一批之前监控每个页面的性能
  5. 产品和集合页面最后进行（最高收入风险）

这种方法增加了复杂性，但让你在影响整个商店之前发现问题。

// Vercel Edge Middleware 示例用于渐进式迁移
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/月（无头推荐）
  • 托管：$20-500/月（Vercel Pro 是 $20/用户，Oxygen 包含在 Shopify 中）
  • 无头 CMS：$0-500/月（Sanity、Contentful、Storyblok 都有免费层）
  • 搜索：$0-500/月（如果使用 Algolia 或类似）
  • 维护：每年预算初始构建成本的 10-15%

对于探索无头 Shopify 迁移对其特定情况成本的团队，我们在这里分解我们的定价方法。我们也很乐意在快速通话中确定范围。

常见迁移陷阱

1. 低估购物车

购物车看起来很简单，直到你考虑：折扣代码、自动折扣、礼品卡、行项目属性、购物车便笺、估计运费、税费计算和购物车级元字段。为购物车功能预算两倍你认为需要的时间。

2. 忘记应用程序

你依赖的 Shopify 应用生态系统？大多数应用都会将 JavaScript 注入你的 Liquid 主题。进入无头意味着你需要基于 API 的替代品或评论、愿望清单、忠诚计划等的自定义实现。

3. 结账自定义

不使用 Shopify Plus（$2,300/月），你无法自定义结账体验。客户将被重定向到 Shopify 的托管结账，这造成了视觉脱节。Plus 商户可以使用 Checkout Extensibility，但它仍然比完全自定义结账更受限制。

4. 不进行早期性能测试

Storefront API 增加了延迟。如果你进行 8 个 API 调用来渲染产品页面，你会感到它。积极缓存，使用 GraphQL 片段最小化过度获取，并在适当的地方实现流 SSR。

5. 忽视内容团队

你的营销团队在 Shopify 的管理员中管理内容。现在他们需要无头 CMS。预算时间进行培训和构建实际令人愉快的内容编辑体验。这就是无头 CMS 开发专业知识真正发挥作用的地方。

何时无头不是正确的选择

我会直言不讳：无头 Shopify 不适合所有人。在以下情况下不要迁移：

  • 你的商店年销售额低于 100 万美元，并且没有复杂的自定义需求
  • 你没有预算用于持续开发和维护
  • 你的团队没有 React 开发人员（或预算聘用/合同他们）
  • 你对当前主题的性能和功能很满意
  • 你主要寻求"酷技术"故事而不是解决真实业务问题

带有良好优化主题的 Shopify Online Store 2.0 可以在 Lighthouse 上得分 90+。有时候正确的答案是优化你已有的东西，而不是从头重建。

如果你在犹豫，考虑从混合方法开始：保留你的 Shopify 主题，但构建特定的高影响页面（如你的主页或登陆页面）作为无头。你可以在现有主题旁边使用 Shopify 的 Storefront API。这让你在完全提交迁移之前证明价值。

常见问题

从 Shopify 迁移到无头需要多长时间？ 对于典型的中等复杂度商店，预期从启动到发布需要 12-20 周。产品数量较少和功能基本的简单商店可以在 8-12 周内发布。具有自定义结账和广泛集成的复杂多市场商店通常需要 20-32 周。审计和规划阶段本身应该是 2-3 周——不要跳过它。

迁移到无头 Shopify 时会失去 SEO 排名吗？ 如果做得正确，则不会。关键是：维护相同的 URL 结构（或设置适当的 301 重定向）、在每个页面类型上实现结构化数据、保留元标签和规范 URL，并在启动后立即将更新的站点地图提交给 Google Search Console。我通常在迁移后看到 1-2 周的排名波动，然后在 Google 识别出更好的 Core Web Vitals 分数后改进。

我需要 Shopify Plus 来进行无头吗？ 从技术上讲，没有。Storefront API 在所有 Shopify 计划上都可用。但是，Shopify Plus 为你提供 Checkout Extensibility（自定义结账体验）、更高的 API 速率限制和对 Oxygen 托管的访问。对于认真的无头项目，Plus 每月 $2,300 几乎总是值得的。

Hydrogen 和使用 Next.js 与 Shopify 之间的区别是什么？ Hydrogen 是 Shopify 官方无头框架，构建在 Remix/React Router 7 上。它包括 Shopify 特定的组件、钩子和实用程序开箱即用，加上在 Oxygen 上的优化部署。Next.js 要求你自己构建 Shopify 集成，但给你一个更大的生态系统、更多托管选项和对复杂内容架构更好的支持。大多数代理机构，包括我们的，在这里有强烈的看法，基于具体的项目要求。

我可以使用零停机时间迁移到无头 Shopify 吗？ 是的，使用蓝绿部署（DNS 切换）或渐进式基于代理的迁移。蓝绿方法通过 DNS 一次性切换所有流量，而代理方法在数周内逐步迁移页面。两者都有效。代理方法对高收入商店更安全，但增加了复杂性。

无头 Shopify 迁移成本是多少？ 代理成本通常从简单商店的 $40,000 到复杂多市场操作的 $300,000+ 不等。自由职业者费率大约是代理成本的 50-60%，但可能缺少项目管理结构和较少的专家。持续成本包括 Shopify Plus（$2,300/月）、托管（$20-500/月）、CMS（$0-500/月）和维护（年度构建成本的 10-15%）。

我应该为无头 Shopify 使用 Astro 而不是 Next.js 或 Hydrogen 吗？ Astro 是内容丰富网站的绝佳选择，具有交互性岛屿，我们已经构建了几个 Astro 驱动的店面。它适用于目录式商店，其中大多数页面是静态的，你只需要为购物车等交互式组件使用 React（或 Svelte、Vue）。但是，对于具有大量客户端交互的商店——实时库存、复杂过滤、即时搜索——Next.js 或 Hydrogen 的完整 React 运行时通常是更好的选择。

迁移到无头后我的 Shopify 应用程序会发生什么？ 大多数注入前端代码的 Shopify 应用（弹出窗口、小部件、评论显示）开箱即用不起作用。你需要直接使用应用的 API、找到无头兼容的替代品或构建自定义实现。仅在后端操作的应用（库存管理、运费、ERP 集成）通常不经更改继续工作。始终在规划阶段审计你的应用堆栈。