一份能执行的 Shopify SEO 清单，先解决页面归属。每组搜索需求和用户任务都要有一个主承接页，它可能是商品页、集合页、指南、政策页、工具或主题入口。技术设置、结构化数据、商品 Feed 和内链都为这个主页面服务。页面职责还没弄清楚，就先批量改全站 title，通常只是把原来的混乱改得更整齐。
执行顺序建议固定下来：先确认抓取和索引状态，再把搜索意图映射到页面类型，修正商品事实，补强集合页与商品页，接上支持文章，最后一起看查询表现和经营结果。Shopify 会处理部分技术默认项，但导航、重定向、内容质量、数据一致性和页面承诺仍由商家负责。
这份清单适合周期复盘，不是只在上线前跑一次。先选有代表性的 URL，修一类问题，验证结果，再扩大范围。它肯定比装一个应用、半天改几百个字段慢，但能留下真正可信的证据。
1. 建立抓取和索引基线
先确认规范域名和语言规则。主域名、HTTPS、www 或非 www、语言路径都要有唯一方向，每个公开 URL 应一次跳转到最终地址。浏览器里返回 200 的页面，仍可能输出错误 canonical，继续被其他变体访问，或者把多个语言 URL 暴露给搜索系统。
Shopify 默认生成 sitemap.xml 和 robots.txt。把正确 sitemap 提交到 Search Console，读取状态和发现 URL 数量。Sitemap 成功不等于所有页面已收录，它只证明 Google 能读取文件。Page indexing、URL Inspection、渲染 HTML、canonical 选择和搜索表现分别回答不同问题。
先看 Page indexing 原因，再判断未收录总数。Page with redirect、正确 canonical 的替代页、noindex 和私有页面被阻挡，很多是预期状态。404、Soft 404、5xx、错误 canonical，以及重要页面长期处于 crawled but not indexed，需要逐个看样本 URL。每个样本标记为预期排除、有等价替代、需要修复，或确实应该消失。
重要修复要有 URL 台账，至少记录旧 URL、目标 canonical、状态码、redirect、canonical 标签、sitemap、内链、最近抓取时间和负责人。有等价内容时做一次永久重定向。没有等价页面时，真实 404 或 410 可能更准确。把所有失效链接都扔到首页，反而容易被判成 Soft 404。
2. 把搜索意图放到正确 Shopify 页面
商品页、集合页、Page、博客和政策页承担不同任务。商品页解释一个可销售 item 及其变体，集合页帮助用户在一个品类或使用场景里做选择，Page 适合常青购买指南、服务说明和主题入口，博客解决聚焦问题和变化中的运营场景，政策页负责交易规则。一张页面可以承接一组相关查询，但必须有一个主要读者任务。
建立 query-to-page map。每个查询组写清读者任务、当前排名 URL、主承接 URL、支持页面、购买阶段和冲突页面。两张页面承诺相同，就判断应该扩充其中一张、重定向、重新定位，还是按不同场景保留。不要因为关键词顺序稍有不同就再建一篇文章。
宽泛类目查询通常适合集合页或购买入口。具体型号、尺寸、材质或兼容性查询，只有在商品和搜索需求足够时，才适合商品页或可索引筛选集合。How-to 和诊断问题适合指南或教程。价格、配送、退换和兼容问题往往既要补商品页事实，也需要一张支持答案页。
页面职责确定后再写 title 和 H1。title 是搜索结果承诺，H1 是用户进入页面后看到的主题。两者可以有轻微差别，但必须服务同一任务。meta description 用清楚的产品、受众、限制或结果帮助用户判断相关性，不是装下所有关键词的地方。
3. 优化文案前先审计商品身份
商品 SEO 依赖准确商品数据。检查 title、vendor 或 brand、product type、category、变体选项、SKU、Barcode 或 GTIN、price、compare-at price、availability、图片、配送、退换和材质。商品页、Shopify 变体、结构化数据和渠道 Feed 必须描述同一个 Offer。
GTIN 要单独检查，因为数字结构正确，也可能属于其他商品。Shopify 把标识放在变体 Barcode 字段，SKU 是另一套内部字段。制造商或品牌方已经分配时使用真实值，测试值不能进入商业 Feed。商品没有 GTIN 时，按当前渠道规则填写 brand、MPN 和 identifier_exists，不要自己编数字。
变体必须按变体级复核。不同颜色和尺码可能有各自的 GTIN、图片、库存和默认落地状态。批量编辑时把同一个 GTIN、SKU 或图片复制给所有行，表格看起来一致，商品身份却可能全部错位。
字段责任也要分开。商品团队负责可见事实和变体结构，品牌或验证过的供应商记录负责标识分配，运营负责库存和履约，主题把这些字段写进页面和结构化数据，Feed 集成再转换成渠道格式。同一个事实手工录入三遍，后面一定会漂移。
4. 集合页要真正帮助用户选择
Shopify 非品牌商业搜索里，集合页往往是最重要的承接页。集合页不能只有商品网格。它要说明适合谁、主要选择标准、关键差异、使用场景、限制，以及用户比较商品时应该看什么。
开头要有用，也不能长到把商品压到很下面。主题支持时，可以在网格周围或下方补对比表、材质或适配说明、尺寸指引、短 FAQ、子类入口、购买指南，以及需要特别解释的商品。不要写只会重复类目词，却不改变选择的段落。
Faceted navigation 需要明确索引政策。筛选会产生很多 URL，大多数组合不应该成为公开落地页。根据搜索需求、商品数量、独特价值和库存稳定性维护候选清单，其他筛选继续给用户使用，但不要制造无限抓取空间。
分页和无限加载要保留可抓取链接。Google 说明，它通常不会主动提交站内搜索表单来发现商品。重要商品要通过导航、集合链接、sitemap 或其他受支持路径被发现。只有搜索才能找到的商品，很容易成为站内孤立 URL。
5. 商品页围绕购买问题补内容
商品描述要回答影响购买和正确使用的问题：产品是什么、适合谁、重要规格、包装包含什么、兼容性、护理、配送、退换和限制。能提供证据时，用测量尺寸、材质规格、真实评价、说明书或明确保修。不要拿 premium、best、适合所有人替代证据。
长内容用标题拆开。商品名放一个主 H1，H2 可以解释优势、规格、适配、使用、护理、配送、FAQ 或对比，具体按产品决定。模板提供稳定模块，但不要强迫每个商品套上同样的卖点。
图片需要合适文件名、准确 alt、正确尺寸和压缩交付。alt 描述用户看见的商品或动作，不重复标题，也不堆关键词。变体图片同样要准确，页面选中一种颜色却展示另一种颜色，用户信任和商品数据都会出问题。
商品页内链应该解决下一问。尺寸、材质、兼容、集合、护理教程和政策，都可以在确实帮助购买时链接。不要每个商品下面都挂一套通用相关文章。少一些，但更贴合当前决策的链接更容易维护。
6. 用可见内容核对结构化数据
很多 Shopify 主题会输出 Product 和 Offer，应用也可能再加一份 graph。要看实际渲染 JSON-LD，不要假设默认一定正确。逐项对照 name、URL、image、SKU、GTIN、brand、price、currency、availability、condition、review、shipping 和 return。
多个 Product graph 不一定直接导致失败，互相冲突才麻烦。一份 graph 还写旧价格，另一份写新价格；评论应用按父商品输出评分，页面却是具体变体；手写 SEO 代码里的库存早已过期。字段责任要收拢，避免主题和应用争夺同一个事实。
FAQPage 只能对应页面真实可见的问题。Review 和 AggregateRating 必须来自符合规则的真实评价。Merchant listing markup 用在用户能购买的商品页，Product snippet 对应另一类页面场景。Schema 应由可见页面职责决定，不要追求验证器里类型越多越好。
先测试少量代表页面，再看上线后的 enhancements 和 URL Inspection。本地 validator 通过，能证明语法和部分规则，不能证明 Google 已抓到新版本、选择了正确 canonical，或一定展示 rich result。
7. 把内链设计成页面系统
Google 会用页面之间的链接关系理解站点结构和相对重要性。菜单连接重点集合和 Page，集合连接商品与子分类，商品页连接对应指南和集合，指南再把用户送到完成任务的商业或运营页面。
锚文字要描述目标。Shopify 也建议菜单和内链文字能说明链接内容。比较保温旅行水瓶比了解更多更清楚。表达可以自然变化，但必须和目标页及当前段落有关。
站内已经有足够且不重复的内容，才建设主题路径。主题 Hub 负责解释边界、组织子问题并链接到真实页面，支持文章解决更窄的任务，并返回主题入口。不要发布一张塞满未来 URL 的 Hub，也不要让几篇文章反复写同一段宽泛介绍。
每类页面负责一个读者任务，并把用户送到下一项有用决策。
审计时同时看出链和入链。一篇写得很好的文章，如果没有任何重点页面指向它，仍然很弱。高价值商品只藏在搜索和筛选后面，也很难被理解。每张目标页记录导航、集合、指南、答案、Breadcrumb 和外链入口，只在用户路径真实存在时补链接。
8. 博客要支持商品和经营判断
博客数量不是 SEO 策略。新文章要解决独立读者任务，补强现有主题，并连接真实商品或工具。编辑队列除了新文章，还应该有 refresh、merge、retire 和短答案补充。很多店在增加 URL 前，更应该先把已有页面修好。
用 Search Console query 和 page 找有曝光但点击弱、接近首页、排名 URL 冲突，或者没有合适承接页的问题。再用 GA4 和 Shopify 看用户有没有进入下一步。查询有曝光不代表商业价值合适，低流量页面也可能承担信任、合规或高价值购买决策。
每篇文章开头给直接答案，说明边界，提供实际案例，任务需要时加入表格或清单，对平台变化声明引用当前官方来源，再把用户送到相关页面。作者和更新时间要可见。平台变化后更新链接和截图，不要只是为了放年份就修改稳定 URL。
日更需要质量控制。保留一张批准后的队列，每个意图只有一个主页面，发布前检查来源和链接，只有真正需要深度的长文才执行字数下限，发布后读取公开页面。日更不等于每个题目都值得三千词。既然编辑政策要求长文，新增长度必须来自判断、案例、证据和例外，不能重复定义。
9. 把 Search Console 问题转成页面决策
索引原因是工作队列，不是评分。Page with redirect 可能正常，Alternate page with proper canonical 可能正常，账号、购物车、搜索、筛选和后台页面被 noindex 或 robots 阻挡也可能正确。必须先看样本 URL。
404 样本要判断有没有等价替代。有同一用户任务和内容时，做一次永久重定向。没有等价页面时保留真实 not found 或 gone。删除旧内链和 sitemap 条目，并检查双斜杠、旧语言路径、旧教程 handle、删除商品链接、占位文件，以及脚本或模板生成的异常 URL。
Crawled but not indexed 要看内容和页面职责。页面是否过薄、重复、过期、孤立，或者同一查询已有更强 URL。任务独立就补强，已有页面能完整承接就合并或退役。反复点击 Request indexing 不能修复薄弱和重复内容。
Discovered but not indexed 可能来自抓取优先级、新提交 URL、内链弱或一次增加太多内容。先确认 sitemap 和内链入口，再给正常抓取时间。重点 URL 要单独跟踪，经营目标是重要页面进入索引，不是所有技术上可访问的 URL 都被收录。
10. 用 30 天节奏执行 Shopify SEO
| 周次 | 主要动作 | 证据 | 暂停条件 |
|---|---|---|---|
| 第 1 周 | canonical、redirect、sitemap、索引样本和页面职责图 | 状态码、渲染 canonical、Search Console 样本 | 目标身份或替代关系不清楚 |
| 第 2 周 | 商品与集合事实、结构化数据和变体抽样 | Shopify 导出、页面、Feed 行、Product markup | 字段来源责任人无法确认 |
| 第 3 周 | 内链、主题路径、title、H1 和内容 refresh | 可抓取链接、URL map、聚焦页面 diff | 新页面与既有主 URL 重叠 |
| 第 4 周 | 公开 readback 和第一轮复盘 | Search Console query/page、索引、GA4 next path、Shopify 结果 | 数据质量不足以判断 |
每轮只改能追踪的范围。一次改几百张页面的 title、正文、导航、schema、redirect 和商品数据，下次报表只会告诉你发生了变化，却解释不了原因。先选样本，记录 baseline，修改一类页面，验证公开结果，模式稳定后再扩大。
保留三个观察窗口。7 天适合看状态码、抓取发现、坏链和明显技术回归，28 天给普通 query 和 landing page 变化更合理的时间，60 天再看辅助转化、客服、退货和收入。季节、促销、迁移和其他并行活动可能需要更长对比。
11. Shopify SEO 最终清单
- 确认唯一 canonical host、语言规则和跳转路径。
- 读取 sitemap 和 Page indexing，不把每个排除都当错误。
- 每个 query group 指定一个主页面并记录冲突。
- 审计商品身份、变体、SKU、GTIN、brand、MPN、价格和库存。
- 给集合页补真正帮助选择的内容。
- 让重点商品通过可抓取链接被发现。
- 对照 Product 结构化数据、页面和渠道 Feed。
- 只使用可见 FAQ 和真实评价数据。
- 用已经公开且不重复的支持页建设主题路径。
- 先 refresh 强 URL，再创建近似新页面。
- 逐 URL 处理 404、Soft 404 和 canonical 冲突。
- 把 Search Console、GA4 和 Shopify 经营结果一起看。
- 记录 baseline、owner、change、expected signal 和复查日期。
当团队能给每个重点查询组说清主页面、来源字段、内链路径、当前搜索信号和下一项经营动作，这轮清单才算完成。更多插件和更多文章都替代不了页面责任。
12. 小团队应该先做什么
小团队不要从 Search Console 所有问题同时开工。先保护收入和商品身份，修购买页故障、重要 URL 的错误 canonical、5xx、商品数据冲突，以及把用户带到失效页面的内链。然后处理有曝光但 CTR 弱、接近首页、或者缺少决策内容的商业集合页。
Backlog 分两张表。Protection 处理可能损失流量、信任、商品资格和订单的问题，Growth 处理新页面、深度指南、集合模块和实验。风险明确时，Protection 可以打断节奏，Growth 留在批准队列里，避免每出现一个新关键词就推翻整个页面系统。
每周只选一个页面家族和一个可测结果。商品页本周检查变体身份和 Product markup，集合页本周检查商品可抓取和选择指导，博客则 refresh 一张已有曝光的页面，并补一篇支持文章。范围收窄后，代码审阅、内容审阅、公开 QA 和 Search Console 复盘都会清楚很多。
不要在 commit 结束任务。读取公开页面，检查 canonical 和结构化数据，走一遍内链，确认 sitemap 或 content index，并记录 release revision。Search Console 可能几天或几周后才反映变化，所以部署证明和搜索结果证明必须分开，后者另设复查日期。