GEO-017·第 02 期·战略与市场·17 / 132
自建站、Shopify、Amazon：三种载体的 GEO 可访问性
同一款商品在自建站、Shopify 与 Amazon 上，能改的层完全不同。本文用一张控制权对照表，拆开三种载体对 AI 抓取、渲染与引用的实际影响，给出按载体分配目标的做法，并指出哪些层根本不在卖家手里，避免把一份 GEO 清单复制三遍。
本期主线先被看见：抓取、渲染与 AI 爬虫可访问性
一家做宠物饮水机的品牌，美国站同时跑 Shopify 独立站和 Amazon。季度会上运营总监问了一个问题：Amazon 上我们的评分比对手高，销量也比对手多，为什么同事在 ChatGPT 里问“猫咪不爱喝水，买哪种饮水机”，答案里只出现对手的独立站？技术负责人说 robots.txt 早就放行了，运营说五点描述写满了。三个人说的都对，错的是把两个载体当成了一套动作。
三种载体的差别不在流量大小，而在你能改到第几层：自建站能改到根，Shopify 改到主题为止，Amazon 只能改输入；GEO 的目标必须按载体分别设定。
先问能改什么，再问该做什么
GEO 的动作清单有十几条，但每一条都依赖一个前提：那一层归你管。自建站上，robots、状态码、模板渲染、结构化数据、访问日志都在你手里；Shopify 上，你能改主题和商品数据，改不了托管侧的结账，也拿不到原始访问日志；Amazon 上，你只能改后台字段、图片、价格库存和参与评论，页面怎么渲染、能不能被抓，由平台决定。
| 层 | 自建站 | Shopify | Amazon |
|---|---|---|---|
| 爬虫与 robots | 完全自主，可分组放行、限速 | 可编辑，默认段由平台生成 | 无入口 |
| 模板与渲染 | 自主决定服务端或客户端渲染 | 主题可改；app 注入的区块常在浏览器里生成 | 平台模板 |
| 结构化数据 | 可加任意 schema | 由主题或 app 注入，注意重复 | 无入口 |
| 价格与库存 | 自建 feed 与接口 | 后台与 app | 后台字段与 feed |
| 访问日志 | 原始日志齐全 | 以平台报表为主 | 以后台报表为主 |
| 结账与售后 | 自控 | 托管结账 | 全托管 |
这张表不比好坏：可改的层多，不等于值得投；决定顺序的是“哪一层出问题你能自己验证”。自建站的价值是可以取证：改完 robots 能看日志，改完模板能用无 JS 抓取复现，加完 schema 能对页面。Amazon 的价值是离成交最近，代价是所有动作都停在输入层——你能把属性写全，但改不了页面如何被读取。
载体选择本身是个战略问题。战略与市场这条线要回答的是先做哪个市场、用哪种载体承接，而答案取决于你愿意为“可验证”付多少工程成本。
平台内 AI 与站外助手，读的不是同一份东西
在 Amazon 上问“买哪个”，购物助手读的是 listing 属性、评论、问答、价格库存和履约表现。这些恰好是卖家能改的输入，所以平台内的 GEO 动作很具体：把关键属性写进能被整句摘出的地方，把使用场景写进问答，把退货原因压下去。它不依赖 schema，也不要求你懂爬虫。
站外助手是另一条路。它读公开网页和第三方语料，Amazon 的商品页对它开放到什么程度由平台决定，卖家没有开关。所以“让 ChatGPT 引用我的 Amazon 页面”通常不是一个可执行的目标，而“让 ChatGPT 引用我的独立站对比页”是。
反过来看，Shopify 和自建站能被站外抓到，但抓到的可能是个空壳。评价、常见问题、规格表如果由 app 在浏览器里注入，无 JS 抓取只剩标题和价格。这类问题分不清是允许、渲染还是解析造成的，先做一次完整的 AI 抓取审计比继续加内容有用。站外助手还会看 Reddit、评测站和媒体，这部分不由你的站点决定，得先做第三方语料审计。
一个判断：同一个 SKU 在两个入口里的证据源不同，动作就不能共用。站内靠字段和评论，站外靠可抓取的页面和站外提及；把两者混在一张任务表里，执行的人会不断返工。
多载体并行的真实成本是一致性
多载体的难点通常不是人力，最常见的损耗是同一款商品在三处说法不一致：标题主干不同，型号写法不同，容量单位不同，价格一个含税一个不含税，赠品和保修各写一套。AI 要把这些记录合并成一个商品实体，名称与属性冲突会降低它的确认度，结果是每个载体都被单独看见，却没有一个被当成同一个品牌。
所以并行的第一步不是分工，是共享一份事实底稿：品牌与系列名、型号、关键属性、价格口径、保修与退货规则。三个载体只做表达差异，不做事实差异。冲突的优先级高于新增内容：先对齐容量和型号，再谈场景页。
载体差异也应该被用来分工，而不是被抹平。自建站适合放对比、场景和品类解释，因为这类页面需要长文本和可抓取的结构；Shopify 适合把商品页的渲染与结构化数据修干净，并让分类与筛选路径能被爬虫走通；Amazon 适合把属性、问答和评论做厚，接受它不被站外引用。
五步做法
| 步骤 | 做什么 | 谁来做 | 怎么算过 |
|---|---|---|---|
| 1 分组 | 按 SKU 组拆开，标出买家主要在站内还是站外提问 | 运营 | 每组一行，写清主入口 |
| 2 定目标 | 每个载体只定一个 GEO 目标：自建站=被站外引用，Shopify=可抓可渲染可解析，Amazon=输入完整 | 增长负责人 | 每个载体一句可验收的话 |
| 3 对底稿 | 统一名称、型号、属性、价格口径、保修 | 品牌与运营 | 跨载体抽查十个 SKU，冲突为零 |
| 4 划边界 | 不可改的层不写进 KPI | 负责人 | KPI 表里没有“让平台页面被站外引用” |
| 5 分开复测 | 站外问题集与站内问题集分别记录 | 增长 | 两组各有前后对比 |
第 2 步最容易做成形式。判断标准很朴素：这个目标失败了，你能不能自己查出原因。查不出原因的，就不该定。
示例：一次分载体的排查
示例：某宠物饮水机品牌（假设场景，不含真实品牌与数据），Shopify 独立站加 Amazon 美国站。排查发现两件事：独立站的评分、滤芯更换周期和常见故障都由评价 app 在浏览器里注入，无 JS 抓取只拿到标题和价格；Amazon listing 属性齐全，但站外助手读不到平台页面。
改法分三处。独立站把评分、滤芯周期、噪音与清洗方式写成服务端输出的文本块，补 Product schema，并把“多猫家庭”“出差三天”“租房不能打孔”做成独立的场景页。Amazon 侧只补后台属性和问答，不再指望被站外引用。第三处是底稿：两个载体的型号、容量、保修期改成同一套说法。
验收也分开：站外用同一批问题复测，看引用来源里是否出现独立站域名；站内看问答覆盖和退货原因分布。抓取有没有恢复，用服务器日志确认，厂商报表会漏掉一部分请求。
边界：这套对照什么时候不适用
第一，纯平台卖家。对照表里只有一行可用，先做 listing、问答和评论；为 GEO 仓促建站是另一笔账，通常不划算。
第二，托管平台的政策会变。robots 默认段、结账流程、可插脚本的位置都可能调整，把某条限制写成永久 SOP，半年后就会挡住自己。
第三，品类决策本来就发生在平台内。低价标品、比价驱动的品类，站外引用对成交的影响很小，优先做平台输入。
第四，一个载体都还没跑通。三个一起改，通常三个都改不动，先选一个把取证链走通。
第五，市场不同，载体优先级要重排：平台集中度高的市场，自建站的话语权更低，那一行要换成当地平台的做法。
这个月先做一件事：把在售 SKU 按载体分三列，每列选五个，做一次三十分钟的取证——自建站用 curl 关掉 JS 抓一个商品页，Shopify 用无痕窗口关掉 JS 看主题实际输出，Amazon 把五个 ASIN 的后台属性完整率对一遍。三列结果贴在一页纸上，这个季度只修最漏的那一列。