一个客户在 2022 年初找到我，是一个中等规模的时尚品牌，每月约 40,000 次有机会话，域名权威性不错，已在 Shopify 上运营了四年。他们聘请了一家开发机构用 Next.js 和 Shopify 的 Storefront API 重建了整个网站。新网站看起来很棒。速度确实很快。但上线后的六周内，他们的有机流量下降了 38%。
关键要点：Headless Shopify 迁移和其他所有迁移一样保护排名——完整的重定向映射、字节相同的元数据传输，以及新构建上的 Core Web Vitals 预算。
没有人做过重定向审计。网站地图坏了。规范标签指向了错误的环境。这是场灾难，在我们稳定局面之前，他们损失了大约 60,000 英镑的收入。
无头迁移是那些看起来像纯粹技术优势的项目之一，更快的渲染、解耦的前端、完全的设计自由，但如果你把 SEO 当作事后的想法，代价会很大。非常大。我在 Seahawk 服务过 12,000 多个网站，这种模式重复出现的次数足够多了，我想把它好好整理下来。
---
为什么无头 Shopify 首先会破坏 SEO
Shopify 的标准主题架构在你毫无察觉的情况下处理了大量的 SEO 工作。规范标签会自动生成。位于 /sitemap.xml 的 sitemap.xml 会自动维护。产品的结构化数据通过 Liquid 内置其中。分页使用 rel="next" 和 rel="prev" 约定，Shopify 在后台静默管理这些。
一旦你采用无头架构，通常是使用 Next.js、Nuxt、Remix 或 SvelteKit 这样的框架从 Shopify Storefront API 拉取数据，你就拥有了所有这些内容的控制权。每个规范化 URL、每个 hreflang、每个结构化数据块、每个重定向。这些不再是免费得到的。
关键是：大多数开发团队被聘用是因为他们擅长 React。而不是因为他们知道什么是分面导航爬取陷阱。
我经常看到的三种失败模式
- 测试环境 URL 泄露到生产索引中。开发团队在 staging.mybrand.com 或 Vercel 预览 URL 上构建，忘记了正确的 noindex 处理，Google 爬取了它，突然你的实时站点就有了与其竞争的重复内容。
- URL 重组期间的中断或缺失重定向。无头项目几乎总是涉及 URL 更改。/collections/mens-shirts 变成 /category/shirts 或更糟的情况。没有 301 重定向，每个入站链接和每个 Google 索引的 URL 都会返回 404。
- 客户端渲染破坏可爬取性。如果你的无头前端纯粹通过客户端渲染产品内容，而不使用 SSR 或 SSG，Googlebot 可能无法可靠地获取你的内容。Google 可以渲染 JavaScript，但它在第二波中处理，索引会有延迟。对于大型目录，这个延迟会让你付出代价。
---
你不能跳过的迁移前审计
我直言不讳：如果你上线前没有做过这件事，你就已经落后了。但现在开始永远不会太晚。
在单个DNS记录改变之前，我需要做好四件事。
1. 对现有 Shopify 网站进行完整爬取。使用 Screaming Frog（我在伦敦本地的专用机器上运行它，不是云爬取，是本地爬取，这样我可以抓取包括 JavaScript 渲染的页面在内的所有内容）。导出每个 URL、状态代码、标题标签、元描述、规范化 URL 和 H1。这是你的基线。这是你的"前"照片。
2. 一份映射文档。每个旧URL→新URL的对应关系。不仅仅是分类和产品页面。博客文章。标签页面。大小指南页面。那个拥有47个来自2020年新闻提及的反向链接的/pages/about URL。所有具有爬取历史、反向链接或排名关键词的URL都需要列在这个电子表格中。
3. 来自Ahrefs或SEMrush的反向链接导出。筛选至少拥有一个引荐域的页面。这些是你最高优先级的重定向目标。错过一个拥有12个引荐域的页面的301重定向，你就白白丧失了有意义的链接权重。
4. 关键词排名快照。从 Google Search Console 导出你当前的排名，至少是点击量排名前 200 的查询。你需要这个来对比迁移前后的数据。如果"男士亚麻裤"在上线后从第 4 位下降到第 22 位，你需要能够立即发现这一点。
---
在Headless设置中实现重定向
这里涉及一些技术细节，但请继续跟上。
在标准的 Shopify 设置中，你在 Shopify 管理后台管理重定向。在无头设置中，你的前端框架处理路由，这意味着重定向的位置取决于你的部署目标。
如果你使用 Vercel（大多数 Next.js 无头 Shopify 项目最终都会用到），你的重定向进入 vercel.json 中的 redirects 数组。它可以干净地处理 301 重定向，Vercel 的边缘网络在页面渲染之前应用它们，这正是 SEO 所需的，重定向发生在基础设施层，而不是在 JavaScript 中。
如果你使用 Netlify，想法是一样的，netlify.toml 或 _redirects 文件。
如果你自己托管在 AWS CloudFront 或自定义 Node 服务器这样的服务上，你需要在反向代理层实现重定向。别在 React router 里做。边缘级重定向才能干净地传递链接权重。
我总是这样做：每次实现重定向后，我会通过 httpstatus.io 做批量检查来验证链。301 → 301 → 200 这样的链是坏的。你想要的是 301 → 200。重定向链会损失链接权重，还会拖累速度。
---
规范标签、结构化数据和团队容易忘记的那些东西
回到2023年，Seahawk帮助一个DTC护肤品牌迁移到了无头Hydrogen架构（Shopify自有的React框架）。开发团队在重定向上做得很扎实。但他们忘记了一件事：Hydrogen不会自动生成canonical标签，你必须在<head>中使用Hydrogen的SEO组件手动设置。结果是：每个产品页面都在对自己进行规范化，并且附带了查询字符串参数，因为购物车和筛选逻辑在URL中写入了参数。Google看到了数百个几乎重复的产品页面。
发现问题后修复花了大约一天，但它造成的排名波动花了大约三周才平复。
上线前要手动检查的东西
- 产品页面上的规范标签指向干净的 URL（没有查询字符串，没有 UTM 参数）。
- noindex应该在你的预发布环境和任何Vercel/Netlify预览URL上启用，把这个加到你的部署检查清单里，而不是待办事项清单。
- 产品结构化数据（Schema.org Product 类型）在 <head> 中进行服务器端渲染，而不是通过客户端脚本在 hydration 后注入。
- 你的 robots.txt 可在根域名处访问，且没有阻止 Googlebot 访问你的新 URL 模式。
- XML网站地图应该反映新的URL结构，而不是旧的Shopify网站地图，也不是来自你构建过程中的缓存版本。
---
Core Web Vitals：双刃剑
大多数代理商在推销无头架构时会说："它能改善你的Core Web Vitals。"他们说的没错，理论上是这样。一个构建良好的Next.js前端，配合图像优化、边缘缓存和合适的代码分割，确实可能在三个Core Web Vitals指标上都达到绿色。
但我见过一些 headless 迁移反而使 CWV 恶化。特别是 LCP（最大内容绘制）和 CLS（累积布局移位）。
当hero图像或折叠线上的产品图像没有被正确预加载时，LCP会恶化。在无头架构中，你的图像管道完全由你自己负责。你不再依赖Shopify的CDN，你需要确保你的框架在hero图像上使用优先级标志（在Next.js中，那是<Image>上的priority属性），并且你通过Cloudflare或Fastly这样的CDN提供正确尺寸的图像。
当字体或动态内容（特别是购物车抽屉状态、促销横幅或筛选芯片）在 hydration 期间引起布局移位时，CLS 会恶化。Shopify 主题开箱即用地处理得相当不错。你的自定义 headless 前端则不会，除非有人专门为此设计。
在上线前用PageSpeed Insights在你的预发布URL上测试，不要等上线后再测。如果网站在预发布环境中存在的时间足够长能累积数据，就使用Chrome UX Report的实地数据。并且检查移动设备，那才是Google实际用于排名的数据。
---
爬虫预算和大型目录
如果你的产品URL少于5,000个，爬虫预算可能不是你主要关心的。但如果你在迁移一个包含50,000多个SKU的目录、有分面导航、多个货币/地区变体，以及追溯到2015年的博客，你需要考虑这个问题。
Headless 设置通常会创建比它们所替换的 Shopify 设置更多的 URL。以前在 Shopify 中通过 AJAX 处理且带有 noindex 的分面过滤器，如果没有人仔细考虑 URL 参数处理，现在会获得自己的服务器渲染路由。突然之间，Googlebot 试图爬取一个 200,000 URL 的网站，而你之前只有 30,000 个。
保持你的robots.txt精简。禁止爬取不代表独特、可排名内容的过滤URL模式。在过滤页面上使用rel="canonical"指向根分类。不要为每个分面组合创建单独的服务端路由，那样会导致混乱和爬虫浪费。
---
迁移后监控（人们在第二周后停止做的事）
迁移上线，客户签署，大家庆祝。然后一个月没人查看 Search Console。别这样做。
在前三个月至少设置一个GSC数据的周度导出。追踪展示次数、点击数、平均位置和索引覆盖情况。留意索引下降，如果你的索引页面数突然从8,000降到4,200，说明有问题，你需要在Google判定这些页面已永久消失之前找到它。
我也在网站地图URL本身上设置了一个正常运行时间监控器（我用Better Uptime），yourdomain.com/sitemap.xml。如果它在部署过程中开始返回500错误，你会立即知道，而不是三天后才注意到排名下滑。
还有一件事：上线后，在搜索控制台中重新提交你的网站地图。这看起来很明显，但我见过它被遗忘的次数比我想承认的还要多。
---
常见问题
无头架构总是会先伤害SEO吗？
不一定，但在前四到八周内几乎总会出现一些排名波动，因为Google会重新爬取和重新索引新的设置。如果你的重定向设置得当、规范标签正确、结构化数据完整，通常会稳定下来，而且往往会有所改善。危险在于迁移仓促时，短期波动就会转变为长期损失。
我能使用 Shopify 的 Hydrogen 框架并维持良好的 SEO 吗？
是的。Hydrogen默认使用服务器端渲染，这是SEO的正确基础。不足之处在于细节——规范管理、网站地图生成和结构化数据。Shopify确实在Hydrogen的组件库中提供了SEO工具，但这不是魔法。你仍然需要有人理解它在做什么以及为什么这样做。
迁移问题后排名需要多长时间才能恢复？
说实话？取决于严重程度。少数几个页面上缺失重定向可能在你修复后的几周内自行纠正。整个网站的规范标签错误或整个域名上的意外 noindex 可能需要两到四个月才能恢复，有时竞争激烈的词汇需要更长时间。你越早发现和修复它，恢复就越快。
从 SEO 的角度单独来看，无头架构值得吗？
不是。Headless架构值得采用，因为它能带来性能、灵活性和前端开发体验上的优势。如果你正确迁移，SEO是一个中立因素。别让代理商以SEO优势为首要卖点来推销headless架构，相同的性能提升往往可以通过优化得当的Shopify 2.0主题和可靠的CDN设置来实现，成本仅为前者的一小部分。
---
迁移不是发布。迁移是信任的转移，从Google熟悉的旧环境转向它不熟悉的新环境。像对待关键事项一样对待每一个技术细节，因为对你的自然搜索流量而言，它确实很重要。