2022 年初，一位客户来找我——中等规模的时尚品牌，每月约 4 万次有机会话，域名权重不错，在 Shopify 上运营了四年。他们聘请了一家开发机构用 Next.js 和 Shopify 的 Storefront API 重建整个网站。新网站看起来很漂亮。速度确实很快。但上线后的六周内，他们的有机流量下降了 38%。
关键要点：Headless Shopify 迁移和其他所有迁移一样保护排名——完整的重定向映射、字节相同的元数据传输，以及新构建上的 Core Web Vitals 预算。Headless Shopify migrations protect rankings the same way every migration does: full redirect map, byte-identical metadata transport, and a Core Web Vitals budget on the new build.
没有人做过重定向审计。网站地图坏了。规范标签指向了错误的环境。这是场灾难，在我们稳定局面之前，他们损失了大约 60,000 英镑的收入。
Headless 迁移看起来像是纯技术胜利——更快的渲染、解耦的前端、完全的设计自由——但如果你把 SEO 当作事后才考虑的东西，代价会很大。我在 Seahawk 做过 12,000 多个网站的工作，我看到这个模式重复出现了足够多次，所以我想把它都写下来。look like a pure technical win -- faster rendering, decoupled front-end, total design freedom -- but if you treat SEO as an afterthought, you'll pay for it. Badly. I've worked on 12,000+ sites at Seahawk and I've seen this pattern repeat itself enough times that I wanted to write it all down properly.
---
为什么无头 Shopify 首先会破坏 SEO
Shopify 的标准主题架构在你毫无察觉的情况下处理了大量的 SEO 工作。规范标签会自动生成。位于 /sitemap.xml 的 sitemap.xml 会自动维护。产品的结构化数据通过 Liquid 内置其中。分页使用 rel="next" 和 rel="prev" 约定，Shopify 在后台静默管理这些。/sitemap.xml is maintained automatically. Structured data for products comes baked in via Liquid. Pagination uses rel="next" and rel="prev" conventions that Shopify manages quietly in the background.
从你开始使用 headless 的那一刻起——通常是使用 Next.js、Nuxt、Remix 或 SvelteKit 这样的框架从 Shopify Storefront API 拉取数据——你就拥有了所有的一切。每条规范化链接。每个 hreflang。每个结构化数据块。每个重定向。这些不再免费提供了。Next.js, Nuxt, Remix, or SvelteKit pulling data from the Shopify Storefront API -- you own all of that. Every canonical. Every hreflang. Every structured data block. Every redirect. It doesn't come for free anymore.
关键是：大多数开发团队被聘用是因为他们擅长 React。而不是因为他们知道什么是分面导航爬取陷阱。
我经常看到的三种失败模式
- 测试环境 URL 泄露到生产索引中。开发团队在 staging.mybrand.com 或 Vercel 预览 URL 上构建，忘记了正确的 noindex 处理，Google 爬取了它，突然你的实时站点就有了与其竞争的重复内容。 The dev team builds on
staging.mybrand.comor a Vercel preview URL, forgets tonoindexit properly, Google crawls it, and suddenly you have duplicate content competing with your live site. - URL 重组期间的中断或缺失重定向。无头项目几乎总是涉及 URL 更改。/collections/mens-shirts 变成 /category/shirts 或更糟的情况。没有 301 重定向，每个入站链接和每个 Google 索引的 URL 都会返回 404。 Headless projects almost always involve URL changes.
/collections/mens-shirtsbecomes/category/shirtsor something worse. Without 301s in place, every inbound link and every Google-indexed URL returns a 404. - 客户端渲染破坏可爬取性。如果你的无头前端纯粹通过客户端渲染产品内容，而不使用 SSR 或 SSG，Googlebot 可能无法可靠地获取你的内容。Google 可以渲染 JavaScript，但它在第二波中处理，索引会有延迟。对于大型目录，这个延迟会让你付出代价。 If your headless front-end is rendering product content purely client-side without SSR or SSG, Googlebot may not be picking up your content reliably. Google can render JavaScript, but it's processed in a second wave and there's indexing lag. For large catalogues, that lag costs you.
---
你不能跳过的迁移前审计
我直言不讳：如果你上线前没有做过这件事，你就已经落后了。但现在开始永远不会太晚。
在单个DNS记录改变之前，我需要做好四件事。
1. 对现有 Shopify 网站进行完整抓取。使用 Screaming Frog（我在伦敦的专用机器上本地运行它——不是云爬取，而是本地，这样我可以捕获包括 JavaScript 渲染页面的所有内容）。导出每个 URL、状态码、标题标签、元描述、规范化链接和 H1。这是你的基线。这是你的前照片。 Use Screaming Frog (I run it locally here in London on a dedicated machine -- not cloud crawl, local, so I can catch everything including JavaScript-rendered pages). Export every URL, status code, title tag, meta description, canonical, and H1. This is your baseline. It's your before-photo.
2. 一份映射文档。每个旧URL→新URL的对应关系。不仅仅是分类和产品页面。博客文章。标签页面。大小指南页面。那个拥有47个来自2020年新闻提及的反向链接的/pages/about URL。所有具有爬取历史、反向链接或排名关键词的URL都需要列在这个电子表格中。 Every old URL → new URL. Not just category and product pages. Blog posts. Tag pages. Size guide pages. The /pages/about URL that has 47 backlinks from that press mention in 2020. Every URL that has crawl history, backlinks, or ranking keywords needs to be in this spreadsheet.
3. 来自Ahrefs或SEMrush的反向链接导出。筛选至少拥有一个引荐域的页面。这些是你最高优先级的重定向目标。错过一个拥有12个引荐域的页面的301重定向，你就白白丧失了有意义的链接权重。 Filter to pages with at least one referring domain. These are your highest-priority redirect targets. Miss a 301 on a page with 12 referring domains and you've just deleted a meaningful chunk of link equity.
4. 关键词排名快照。从 Google Search Console 导出你当前的排名——至少要导出按点击量排名前 200 的查询。你需要这个来对比迁移前后的情况。如果"mens linen trousers"在上线后从第 4 位跌到第 22 位，你需要能立即发现这一点。 Export your current rankings from Google Search Console -- at minimum, the top 200 queries by click volume. You need this so you can compare pre- and post-migration. If "mens linen trousers" drops from position 4 to position 22 after go-live, you need to be able to spot that immediately.
---
在Headless设置中实现重定向
这里涉及一些技术细节，但请继续跟上。
在标准 Shopify 设置中，你在 Shopify 管理员内管理重定向。在 headless 设置中，你的前端框架处理路由——这意味着重定向的位置取决于你的部署目标。
如果你使用 Vercel（大多数 Next.js headless Shopify 项目最终都会用到），你的重定向放在 vercel.json 的 redirects 数组中。它能够干净地处理 301 重定向，Vercel 的边缘网络在页面甚至还没渲染时就应用它们，这正是 SEO 所需要的——重定向发生在基础设施层，而不是在 JavaScript 中。vercel.json under the redirects array. It handles 301s cleanly and Vercel's edge network applies them before the page even renders, which is exactly what you want for SEO -- the redirect happens at the infrastructure layer, not in JavaScript.
如果你用的是 Netlify，思路一样——netlify.toml 或 _redirects 文件。Netlify, same idea -- netlify.toml or a _redirects file.
如果你自己托管在 AWS CloudFront 或自定义 Node 服务器这样的服务上，你需要在反向代理层实现重定向。别在 React router 里做。边缘级重定向才能干净地传递链接权重。
我总是这样做：每次实现重定向后，我会通过 httpstatus.io 做批量检查来验证链。301 → 301 → 200 这样的链是坏的。你想要的是 301 → 200。重定向链会损失链接权重，还会拖累速度。httpstatus.io to verify the chain. A 301 → 301 → 200 chain is bad. You want 301 → 200. Redirect chains bleed link equity and slow things down.
---
规范标签、结构化数据和团队容易忘记的那些东西
回到 2023 年，Seahawk 帮一个 DTC 护肤品牌迁移到了无头 Hydrogen 架构（Shopify 自家的 React 框架）。开发者在重定向上做得很扎实。但他们忘了一件事：Hydrogen 不会自动生成规范标签——你得在 <head> 里用 Hydrogen 的 SEO 组件手动设置。结果怎样？每个产品页面都在用查询字符串参数规范化到自己，因为购物车和筛选逻辑把参数写进了 URL。Google 看到了数百个近乎重复的产品页面。<head> using Hydrogen's SEO component. Result: every product page was canonicalising to itself with the query string parameters appended, because the cart and filter logic was writing params into the URL. Google was seeing hundreds of near-duplicate product pages.
发现问题后修复花了大约一天，但它造成的排名波动花了大约三周才平复。
上线前要手动检查的东西
- 产品页面上的规范标签指向干净的 URL（没有查询字符串，没有 UTM 参数）。
noindex 要放在你的预发布环境和任何 Vercel/Netlify 预览 URL 上——把这个加到你的部署检查清单里，而不是待办事项清单。is on your staging environment and any Vercel/Netlify preview URLs -- add this to your deployment checklist, not your to-do list.- 产品结构化数据（Schema.org Product 类型）在 <head> 中进行服务器端渲染，而不是通过客户端脚本在 hydration 后注入。Schema.org
Producttype) is being server-rendered in the<head>, not injected by a client-side script after hydration. - 你的 robots.txt 可在根域名处访问，且没有阻止 Googlebot 访问你的新 URL 模式。
robots.txtis reachable at the root domain and isn't blocking Googlebot from your new URL patterns. - XML 网站地图要反映新的 URL 结构——不是老的 Shopify 网站地图，也不是构建过程中的缓存版本。
---
Core Web Vitals：双刃剑
大多数代理在推销无头架构时都会这么说："这能改善你的 Core Web Vitals。"他们没说错——潜在上是这样。一个精心构建的 Next.js 前端，配上图片优化、边缘缓存和适当的代码分割，确实能在三个 Core Web Vitals 指标上全部达到绿色。potentially. A well-built Next.js front-end with image optimisation, edge caching, and proper code splitting can genuinely hit green across all three Core Web Vitals metrics.
但我见过一些 headless 迁移反而使 CWV 恶化。特别是 LCP（最大内容绘制）和 CLS（累积布局移位）。worse. Specifically LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift).
当首图或首屏产品图没有被正确预加载时，LCP 就会变差。在无头架构中，你的图片管道是你自己的责任。你不再依赖 Shopify 的 CDN——你需要确保你的框架在首图上使用优先级标记（在 Next.js 中，那就是 <Image> 上的 priority 属性），并且你通过 Cloudflare 或 Fastly 这样的 CDN 提供正确尺寸的图片。priority flags on hero images (in Next.js, that's the priority prop on <Image>) and that you're serving correctly sized images via a CDN like Cloudflare or Fastly.
当字体或动态内容（特别是购物车抽屉状态、促销横幅或筛选芯片）在 hydration 期间引起布局移位时，CLS 会恶化。Shopify 主题开箱即用地处理得相当不错。你的自定义 headless 前端则不会，除非有人专门为此设计。
用 PageSpeed Insights 在预发布 URL 上测试，上线前就要测，不是上线后。如果网站在预发布环境里停留足够长的时间，就用 Chrome UX Report 的字段数据。一定要在移动设备上检查——那才是 Google 用来排名的数据。PageSpeed Insights on your staging URL before go-live, not after. Use field data from Chrome UX Report if the site has been in staging long enough to accumulate it. And check on mobile -- that's the data Google actually uses for ranking.
---
爬虫预算和大型目录
如果你的产品 URL 少于 5,000 个，爬虫预算可能不是主要关注点。但如果你要迁移一个有 50,000+ SKU、多面导航、多币种/地区变体，还有一个回溯到 2015 年的博客的目录——你就得考虑这个问题。
Headless 设置通常会创建比它们所替换的 Shopify 设置更多的 URL。以前在 Shopify 中通过 AJAX 处理且带有 noindex 的分面过滤器，如果没有人仔细考虑 URL 参数处理，现在会获得自己的服务器渲染路由。突然之间，Googlebot 试图爬取一个 200,000 URL 的网站，而你之前只有 30,000 个。more URLs than the Shopify setup they're replacing. Faceted filters that were previously handled via AJAX with noindex in Shopify now get their own server-rendered routes if someone hasn't thought carefully about URL parameter handling. Suddenly Googlebot is trying to crawl a 200,000-URL site when you had 30,000 before.
保持你的 robots.txt 简洁。禁止抓取不代表独特、可排名内容的过滤 URL 模式。在过滤页面上用 rel="canonical" 指向根分类。不要为每个分面组合创建单独的服务端路由——那样只会导致混乱和爬虫浪费。robots.txt tight. Disallow crawling of filtered URL patterns that don't represent unique, rankable content. Use rel="canonical" on filtered pages to point back to the root category. And don't create individual server-side routes for every facet combination -- that way lies madness and crawl waste.
---
迁移后监控（人们在第二周后停止做的事）
迁移上线，客户签署，大家庆祝。然后一个月没人查看 Search Console。别这样做。
在头三个月内至少每周导出一次 GSC 数据。跟踪展示次数、点击次数、平均排名和索引覆盖率。注意索引下降——如果你的索引页面数突然从 8,000 掉到 4,200，说明出了问题，你需要在 Google 认定这些页面永久消失前找到它。
我还在站点地图 URL 本身（yourdomain.com/sitemap.xml）上设置了正常运行时间监控（我使用 Better Uptime）。如果在部署期间它开始返回 500 错误，你需要立即知道，而不是三天后才在排名下滑时才发现。yourdomain.com/sitemap.xml. If it starts returning a 500 during a deployment, you want to know immediately, not three days later when you notice rankings sliding.
还有一件事：上线后，在搜索控制台中重新提交你的网站地图。这看起来很明显，但我见过它被遗忘的次数比我想承认的还要多。
---
常见问题
无头架构总是会先伤害SEO吗？
不总是会，但在前四到八周内几乎总会出现一些排名波动，因为 Google 会重新抓取并重新索引新的设置。如果你的重定向没问题、规范标签正确且结构化数据完整，通常会稳定下来，甚至经常改善。危险在于迁移仓促的时候——那时短期波动会变成长期损失。
我能使用 Shopify 的 Hydrogen 框架并维持良好的 SEO 吗？
可以。Hydrogen 默认使用服务器端渲染，这是 SEO 的正确基础。不足之处在于细节——规范标签管理、站点地图生成和结构化数据。Shopify 在 Hydrogen 的组件库中提供了 SEO 实用工具，但不是魔法。你仍然需要有人理解它在做什么以及为什么要这样做。
迁移问题后排名需要多长时间才能恢复？
说实话？取决于严重程度。少数几个页面上缺失重定向可能在你修复后的几周内自行纠正。整个网站的规范标签错误或整个域名上的意外 noindex 可能需要两到四个月才能恢复，有时竞争激烈的词汇需要更长时间。你越早发现和修复它，恢复就越快。noindex on your entire domain can take two to four months to recover from, sometimes longer for highly competitive terms. The sooner you catch and fix it, the shorter the recovery.
从 SEO 的角度单独来看，无头架构值得吗？
不值得。如果迁移正确，无头架构对性能、灵活性和前端开发者体验是值得的。SEO 是一个中立因素。不要让代理商通过强调 SEO 优势来推销无头架构——同样的性能收益通常可以通过优化良好的 Shopify 2.0 主题和稳定的 CDN 设置以更低的成本实现。if you migrate correctly. Don't let an agency sell you headless by leading with SEO benefits -- the same performance gains can often be achieved with a well-optimised Shopify 2.0 theme and a solid CDN setup, at a fraction of the cost.
---
迁移不是发布。它们是信任的转移——从一个 Google 熟悉的旧环境转移到一个陌生的新环境。把每个技术细节都当作很重要的事情对待，因为对你的自然搜索渠道来说，确实如此。