Shopify SEO 做不到的那几件事：托管平台替你定的五层

搜 Shopify SEO 的人想拿到的多半是一份优化清单。这一章讲的是清单里那些你根本做不到的条目：托管平台把网站分成五层，完全交给你的只有一层，一半开放的两层，剩下两层你永远拿不到。分清哪层是哪层就是这件事的全部功夫 —— 它决定一个变通方案够不够得着问题，也决定你会不会花一周去改一个平台从来就没打算给你的东西。换平台放在最后一节，是故意的。

读这一章之前

这一章讲改不动的部分。能改的那部分在 网站防火墙挡住的那些爬虫：诊断顺序，以及各家平台确实开放了哪一层。如果你眼下的问题是某个爬虫被拒绝，先看那一篇 —— 这类问题四分之三是能修的。

先定一个词：本章说的托管平台指一切你控制不了服务器进程的地方 —— 建站工具、独立站商城、托管 CMS、静态托管。分界线不是开源还是闭源，是你能不能往请求链路里放任意一段代码。

Shopify SEO 也好，别家也好，问的都是这五层

所有以「平台不让我改」开头的抱怨，最后都落在这五层里的一层。中间一列是托管平台通常给你的权限，同一条建议在这家能做、在那家做不了，原因全在这一列。

做任何方案之前，先从上往下读一遍这张表。落在前两行的活一定能上线；依赖最后一行的活根本做不了，再聪明也换不过来。

第一层：不是你写的那个文件

多数托管平台替你生成 robots.txt。做得好的给的是钩子，不是文本框。Shopify 的官方文档就是这个形状：robots.txt.liquid 模板「isn't included in any themes by default」，要自己在 Templates 文件夹里新建；文档建议优先用它提供的 Liquid 对象而不是纯文本，因为默认规则「updated regularly to ensure that SEO best practices are always applied」。

这一句就是全部取舍。把生成的文件整个换成自己写的纯文本，等于把平台那天的默认值冻住，从此维护责任归你。用钩子扩展，就能继续跟着更新，代价是删不掉厂商认定属于最佳实践的那条规则。

完全没有钩子时的替代做法：用页面级指令。meta name="robots" 能表达 robots.txt 本来就表达不了的收录决定 —— 一个被 Disallow 的页面仍然可能因为外部链接被收录。页面级指令做不到的是阻止抓取，所以目标是省带宽时它帮不上忙。

第二层：边缘那一下决定

这一层最常被误以为自己有，实际最常没有。一个有名字的爬虫到底会不会被交付，是在你的应用前面、由你没写过的规则决定的；各家在默认值和可否覆盖上差别很大。

两份文档正好划出这个范围。Cloudflare 把 AI Crawl Control 写成「Available on all plans」，并且可以「Set allow or block rules for individual crawlers」—— 按爬虫逐个控制，不用升级套餐。Vercel 那套针对 AI 爬虫的托管规则集是「inactive by default」，只有 log 和 deny 两档，名单由 Vercel 维护而不是你。

替代做法：在你控制不了的那家前面，再套一家你控制得了的。这招管用，代价却很容易被漏掉。Vercel 明写它的 bot protection「doesn't work when a reverse proxy (e.g. Cloudflare, Azure, or other CDNs) is placed in front of your Vercel deployment」。叠加买到的是外层控制，同时关掉了内层原本在做的一部分事。先想清楚你要的到底是哪一个。

前面再套一家，不等于多一份控制。它只是把决定权挪了个地方，顺手关掉了里面那家原本在做的事。

第三层：响应头

响应头是平台态度最不容商量的一层，而恰好也是最没人用的一层。我们自己那份 27 个首页的普查里，发 X-Robots-Tag 的正好只有 1 个，20 个既不发这个响应头也不发 meta robots，数字在 谁在用 X-Robots-Tag 里。新鲜度那两个头也一样：同一批 27 个里有 13 个既不发 last-modified 也不发 ETag，也就是说对其中一半的站根本发不出条件请求。

这个读数其实让人松一口气。平台不让你设这些，你和大多数站在同一条船上，而且那条船上有比你大得多的站。这一层被锁住，损失的是一项优化，不是一项能力。

替代做法：收录与摘要规则，用 head 里的 meta 标签能在 HTML 页面上做同样的事。对没有 HTML 的文件 —— PDF、图片、数据导出 —— 没有替代，这是老实话。如果你的生意确实依赖控制某份 PDF 怎么被收录，而平台又不给你发响应头，那这一条需求就是没被满足。

第四层：你永远拿不到的那份日志

原始请求日志重建不出来。本章其他每一项都有变通，只有这一项没有。没有它，你说不出哪个爬虫来过、来了多少次、要了什么、拿到了什么。

替代做法更弱，弱在哪儿你得心里有数。你可以按固定周期从外面测 —— 用每个 UA 请求自己的页面，记状态码和字节数，每周一次 —— 再去看搜索侧的覆盖率与效果报告。两边合起来，你得到的是推断出来的到访和观察到的结果。缺的是中间那一段：失败的请求，以及从不表明身份的客户端。

我们发的每一篇实测都被同一个缺口塑造，所以每一篇写的都是样本量和日期，而不是「一段时间里的行为」。你也被锁在日志外面的话，结论就照这个写法写，别让一次每周快照被人引用成趋势。

第五层：包着你文字的那层模板

正文哪儿都是你的。听起来像安慰奖，其实是这张表里最大的杠杆 —— 决定一个页面能不能被摘走的东西全在正文里：对得上真实问句的小标题、标题下那段自包含的答案、能上表就不写成四句话。

托管平台真正咬人的地方是 head。有的给你一个自由注入槽，有的只给几个命名字段。属于后者的话，第一个牺牲的就是结构化数据，因为它需要一个 script 元素，而你可能根本没地方放。

替代做法：先查平台是不是已经在输出结构化数据，再决定要不要自己加。不少建站工具和商城系统本来就在输出，第二块和第一块打架，比两块都没有更糟。平台什么都不输出、也不给你槽位，那才是真缺口 —— 而它影响的结果范围比多数人以为的要窄，这正是不该让它单独推动一次迁站的理由。

交付物：十五分钟给自己的平台打分

填一次，留着。它能终结那个反复出现的争论 —— 这件事到底值不值得试 —— 而且在你换平台之前一直有效。

凡是填「不能」的那一行，都是要绕着设计的约束，不是要去硬碰的缺陷。把它们写下来的意义在于：下个季度一定有人提一个正好依赖其中某一条的方案，这张表一分钟就能答完，否则要花一周才发现。

什么时候该认赔换平台，什么时候不该

迁站的贵法不体现在报价单上：每一个 URL、每一条内链、每一块结构化数据，外加一段数字和过去谁都对不上的恢复期。值得做的情形是，某个被关掉的层挡住了你赚钱的主路径；不值得的情形是，为了一个缺失的功能点。

判断这个约束是真约束还是只是烦人，看三条：它挡的是收入路径而不是一个指标；替代做法你已经做过并且量出来不够用；同一个约束从不同方向撞上来超过两次。三条凑不齐，老实的做法通常是把这条约束写进平台记分卡，然后继续干活。

不构成理由的有三种：一条没有流量挂在后面的 SEO 清单项、一个你设完一次再也不会看的响应头、以及一份写给你没在用的技术栈的建议。把「被关掉的那一层怎么绕」变成一件可重复的例行工作、而不是一次次的现场研究，正是 QueryWin 在建的东西。

常见问题

Shopify SEO 到底能做到什么程度？

最要紧的那一层完全能做：小标题、答案、页面结构哪儿都能改，而它们决定页面能不能被摘走。受限的是响应头、边缘规则和日志，损失的是优化项，不是竞争资格。

托管平台上能改 robots.txt 吗？

有时候能，而且经常只给模板钩子不给文本框。Shopify 就是要你自己新建一个 robots.txt.liquid 模板，并且建议在生成的规则上扩展而不是整个替换。

平台不让加结构化数据怎么办？

先查它已经在输出什么，重复一块比没有更糟。确实什么都不输出、也没有注入槽，那就当成真缺口记下来，和别的事一起权衡，别让它单独决定一次迁站。

没有服务器日志，怎么知道爬虫来没来？

按固定周期从外面测，再配上搜索后台的报告。你拿到的是推断出来的到访而不是观察到的到访，所以每个数字都要写清样本量和日期，永远别把一次快照说成趋势。