直接答案：先找出页面停在哪个阶段
Shopify 页面没有出现在 Google，不能靠重复提交 sitemap 或反复点击“请求编入索引”解决。先用 Google Search Console 的 URL 检查工具确认页面处于“未发现、已发现未抓取、抓取失败、已抓取未编入索引、重复页被规范化，还是已索引但查询中不展示”的哪一类，再处理对应原因。
Google Search 包含发现、抓取、索引和结果展示等阶段。Google 的搜索工作原理明确说明，即使页面符合技术要求，Google 也不保证抓取、索引或展示。提交只能提供发现信号，不能变成收录承诺，更不能保证排名。
| 观察到的状态 | 核心问题 | 优先检查 | 不该做的事 |
|---|---|---|---|
| Google 不知道 URL | 发现不足 | 站内链接、sitemap、正确主域 | 每天重复提交同一 URL |
| 已发现但未抓取 | 抓取优先级或站点问题 | 服务器稳定性、重复 URL、整体质量 | 批量制造更多低价值页面 |
| 抓取失败 | 访问或响应错误 | HTTP 状态、登录、WAF、重定向、资源 | 只改标题而忽略错误响应 |
| 已抓取未索引 | 质量、重复或软 404 | 正文价值、模板重复、canonical、渲染 | 承诺“加速收录” |
| Google 选了另一 canonical | 规范化信号冲突 | canonical、重定向、内链、sitemap | 各处指定不同主 URL |
| 已索引但搜不到 | 相关性或展示问题 | URL 检查、Performance 数据、查询意图 | 用 site: 数量当完整索引报告 |
第一步：确认你检查的是精确 URL
先记录完整 URL，包括 https、主机名、语言目录、尾部斜杠和所有参数。www 与非 www、/en/ 与默认语言、产品主 URL 与集合上下文 URL，可能是不同地址。不要只搜索标题判断是否收录。Google 表示 site: 运算符受检索限制，适合辅助排查，但 URL 检查工具比搜索运算符更可靠。
在 Search Console 选择覆盖该 URL 的正确资源，然后检查：Google 报告的索引状态、上次抓取、允许抓取与允许索引、用户声明 canonical、Google 选择 canonical，以及已发现来源。再执行“测试实际网址”，区分 Google 上次抓取的版本与当前线上版本。测试通过只说明当前可访问，不说明 Google 已经索引。
如果团队还没有 Search Console 权限，先建立域名资源和负责人，不要用第三方“收录查询”代替一手诊断。需要整理技术 SEO 与内容结构时，可参考 WESWOO 的Shopify 独立站 SEO 实操清单和服务范围。
第二步：检查响应、访问与渲染
用未登录、无 Cookie 的浏览器和 HTTP 工具访问精确 URL。正式页面通常应直接返回 200，而不是先经历多次 301/302、返回 404/5xx，或以 200 包装“商品不存在”的软 404 内容。页面不能依赖后台登录、店铺密码或只对特定国家开放才能看到正文。
检查 HTML 中是否出现意外的 noindex。还要分清 robots.txt 与 noindex：robots.txt 主要控制抓取，并不是可靠的“禁止索引”方式；如果同时阻止抓取，Google 甚至可能无法看到页面里的 noindex。Google 的noindex 指南要求页面可被抓取，搜索引擎才能读取该指令。
随后查看 URL 检查的渲染截图和 HTML。商品名称、价格、库存、主要描述、集合说明和核心链接应当能被 Google 看到。不要把关键信息只放在图片、视频、需要点击后才请求的组件或被错误阻止的脚本中。Shopify 托管层通常已提供可抓取基础，但主题、应用、Markets 跳转和自定义 robots 仍可能改变最终响应。
第三步：让 canonical、重定向、内链与 sitemap 指向同一版本
canonical 是首选 URL 信号，不是强制命令。一个页面自引用 canonical，同时却被站内导航链接到带参数版本、在 sitemap 里列出另一版本、又通过重定向到第三个版本，会让规范化判断变得混乱。Google 的重复 URL 规范化说明建议不要在不同方法中指定不同 canonical。
对目标页面建立一张信号表：
- 页面最终返回 200，canonical 指向自身正式 URL；
- HTTP 与主域版本统一重定向到正式 URL；
- 导航、集合、相关文章和正文内链直接使用正式 URL；
- sitemap 只列出希望索引、可公开访问的 canonical URL；
- 多语言页面各自使用可索引 URL、自引用 canonical，并通过正确 hreflang 连接；
- 下架或合并页面有经过数据确认的去向，不把所有旧 URL 重定向到首页。
Shopify 会自动生成 sitemap，位置通常为域名根目录的 /sitemap.xml。官方的查找与提交 sitemap 指南同时说明，sitemap 可以帮助发现页面，但抓取与索引需要时间，Google 不保证时长。检查目标 URL 是否出现在正确市场或语言的 sitemap，且与页面 canonical 完全一致。
第四步：判断是不是发现和站内架构问题
一个只存在于 sitemap、没有任何正常页面链接到的 URL，搜索引擎和用户都会很难理解其重要性。让核心商品从集合和导航可达，让指南页从主题中心与相关商业页面可达，并使用描述目标内容的锚文本。避免用数百个标签页、筛选参数和近重复文章稀释抓取与内链信号。
新页面至少应从一个已被正常抓取的相关页面获得内链。批量站点更要区分“应该索引的主页面”和“用于筛选、搜索、排序或追踪的辅助 URL”。sitemap 不是内部信息架构的替代品；Google 的官方 sitemap 指南同样说明，它有助于发现，但不保证其中每个项目都会被抓取或索引。
WESWOO 现有项目案例和服务页可以作为商业意图路径；文章内链应真正帮助用户完成下一步，而不是为了数量在每段塞入链接。
第五步：排查低价值、重复与软 404 内容
技术全部通过，页面仍“已抓取但未编入索引”时，应审查页面本身。常见问题包括：直接复制供应商描述、变体或市场页面只有少量词语不同、大量文章回答同一问题、集合页只有商品网格、缺货页没有替代信息，以及标题很具体但正文只是空泛模板。
改写时先回答该页面的唯一意图，再补充规格、适用与不适用边界、原创图片或演示、交付与退换信息、证据来源及有用内链。不要仅把字数拉长，也不要自动生成数百个城市、国家或关键词替换页。对于近重复 URL，要结合 Search Console 查询、外链、成交与历史价值选择主页面；没有数据时不应批量删除、noindex 或 301。
Google 的官方入门检查把可访问性、外部与内部发现、文本内容和对用户有价值的高质量内容列为基础。它没有提供可保证收录的固定字数、关键词密度或提交次数。
第六步：提交一次，然后记录与观察
修复完成后，用实际网址测试确认 Googlebot 能看到预期状态、canonical 和正文。少量重要 URL 可以请求编入索引；大量 URL 用 sitemap。Google 的请求重新抓取说明明确表示，抓取可能需要几天到几周，重复请求不会让同一 URL 抓取得更快，提交也不保证进入结果。
记录修复日期、原状态、改动、实际网址测试结果和后续状态。用 Page indexing 报告观察页面组，用 URL 检查追踪少量代表页，用 Performance 报告判断已索引页面是否获得目标查询的展示。收录、排名与流量是三个不同结果，不能用一个指标代替另两个。
常见问题
提交 sitemap 后多久一定会收录？
没有确定时限，也不保证收录。sitemap 帮助 Google 发现重要 URL；页面仍需可抓取、可索引、有一致规范化信号并提供足够价值。
每天请求编入索引会更快吗？
不会。Google 明确表示，对同一 URL 重复请求不会让它抓取得更快。修复原因、提交一次并观察状态更有效。
robots.txt 允许抓取就一定能索引吗？
不一定。允许抓取只是前提之一，页面还可能有 noindex、错误 canonical、软 404、渲染、重复或质量问题。
site:域名 查不到就说明未收录吗？
不能这样判断。site: 结果不完整，也受检索限制。站点所有者应以 Search Console 的 URL 检查和 Page indexing 报告为主要依据。
改标题和 meta description 能解决未收录吗？
只有当问题确实是页面信息和质量不足时，它们才可能是改进的一部分。若页面返回错误、被 noindex、canonical 指向别处或无法发现，只改 metadata 不会解决根因。