电商 SEO 的一个核心判断是：这个搜索需求应该落到商品页、集合页、博客文章还是教程？很多店铺把所有关键词都塞进商品页，结果页面承诺混乱；也有店铺把集合页写成博客，结果买家找不到商品。页面类型本身就是搜索意图决策。
Google 的 Product structured data 指南强调 Product markup 应该聚焦在具体商品页面，而不是泛泛的分类或 listing 页面。Merchant listing 相关资格也更贴近可购买商品页面。集合页、博客和教程仍然重要，但它们的任务不同：集合页帮助选择，博客帮助教育，教程帮助建立判断，商品页帮助成交。
页面类型是意图决策
先看 query pattern。用户搜具体型号、品牌+产品名、颜色尺码或“buy [exact product]”，通常应该落到商品页。用户搜“best waterproof dog leash”“men linen shirts for summer”这类比较和筛选需求，集合页或 buying guide 更合适。用户搜“how to choose”“what is”“vs”时，博客或教程可能先承接，再内链到商品和集合。
不要把所有关键词都压到一个页面。商品页承担具体购买，集合页承担选择路径，博客承担解释和比较，教程承担方法学习。页面角色越清楚，内链越容易设计，搜索系统也更容易理解你的网站结构。
什么时候商品页应该承接 query
商品页适合承接明确购买意图：用户知道要买哪个产品或变体，只需要确认价格、库存、配送、退换、评价、规格和风险逆转。商品页的标题、H1、Product/Offer structured data、图片、价格和库存必须围绕这一个商品事实展开。
如果 query 很宽，比如“best travel water bottle”，单个商品页通常不应该硬抢。它可以通过内链接受集合页或博客的推荐流量，但不要把商品页写成大百科。商品页越具体，转化和结构化数据越清楚。
什么时候集合页应该承接 query
集合页适合承接类别、场景、筛选和比较意图。用户还没决定具体商品，但知道方向，比如“waterproof dog leashes”“travel mugs for commuters”。集合页应该提供清楚的筛选、商品排序、简短类别说明、FAQ 和到核心商品页的内链。
集合页的问题是容易变薄。只有一堆商品卡，没有说明、筛选逻辑、FAQ、内部链接和可索引文本，搜索系统很难理解它为什么值得排名。集合页不需要写成博客，但要解释如何选择、哪些属性重要、哪些商品适合什么场景。
博客和 buying guide 的支持角色
博客或 buying guide 适合承接信息型和比较型搜索：怎么选、有哪些风险、A 和 B 区别、适合谁、不适合谁。它们的目标不是直接替代商品页，而是帮助用户完成判断，然后通过语义内链进入集合页或商品页。
教程则更适合方法层，比如 SEO、Feed、广告、GA4、定价这类经营任务。Ecomwith 的博客应该作为场景入口，把复杂问题连接到教程、工具和答案库，而不是复制教程正文。
内链路由例子
如果 query 是“GTIN missing in Google Merchant Center”，博客可以解释问题，内链到 GTIN 答案、Feed QA 文章和商品数据教程；如果 query 是“best bundle for skincare routine”，集合页可以承接选择，博客解释 bundle 决策，商品页承接具体套装。内链应该顺着用户判断，而不是只做“相关文章”。
孤立商品页也要修。没有集合页、博客、FAQ 或答案页指向的商品页，很难获得内部信号。用集合页聚合类别，用博客解释选择标准，用商品页完成购买，用答案页处理单点问题，这才是电商 SEO 的路由系统。
搜索意图路由表
| query pattern | 最佳页面类型 | 支持页面 | schema 注意 |
|---|---|---|---|
| 具体产品名/型号 | 商品页 | 集合页、FAQ、评测 | Product/Offer 应匹配可见商品 |
| 类别+用途 | 集合页 | 博客 buying guide、商品页 | 不要把集合页伪装成单品 Product |
| how to choose / vs | 博客或购买指南 | 集合页、商品页、答案页 | Article/BlogPosting + 可见 FAQ |
| 经营方法问题 | 教程或答案页 | 博客场景入口、工具 | LearningResource/FAQ 按可见内容 |
把这篇文章变成可复用的运营闭环
不要把这篇文章当成一次性阅读材料。围绕 页面类型是意图决策 / 什么时候商品页应该承接 query / 什么时候集合页应该承接 query 这些判断点，给团队留下一个能重复执行的小闭环：什么时候检查、谁负责、证据放在哪里、什么情况暂停发布、什么情况继续推进。最后产出的不应该只是“看过了”，而应该是一条带日期、带负责人、带结论的运营记录。
搜索意图路由表 里的 具体产品名/型号 / 类别+用途 / how to choose / vs 可以当成最低证据集合。只要其中一项无法验证，就先把页面、广告、Feed、事件或政策标成未放行，并写清楚缺的是什么证据。这样做不是为了让流程变慢，而是为了避免电商团队最常见的误判：指标动了，大家开始反应，但没人知道当时的店铺、追踪、内容和 offer 是否真的处在可判断状态。
执行完这张清单以后，再进入文中链接到的 Ecomwith 工具、教程或答案页。本文先帮你做第一层判断；后续页面负责计算、审计、记录或修复具体问题。这样，读者能顺着一个清楚的操作路径继续行动，搜索系统也更容易理解页面之间的关系。