新网站上线后，想让 Google 发现并收录，最稳妥的路线不是找“快速提交接口”，而是完成五件事：验证 Search Console、提交干净的站点地图、确保页面可抓取可索引、准备有实际价值的核心内容、用合理内链和外部入口帮助 Google 发现。Google 官方说明，URL 检查工具适合少量 URL 请求重新抓取；大量 URL 应提交站点地图。抓取可能需要几天到几周，提交不保证立即收录。参见 Ask Google to recrawl your URLs。
第一步：先在 Search Console 验证站点
Search Console 是新站与 Google 搜索沟通的基础工具。验证后，你可以查看页面索引状态、提交站点地图、使用 URL 检查工具、监控抓取和搜索表现。对于新站，建议优先验证域名属性；如果暂时无法修改 DNS，也可以验证 URL 前缀属性，但要注意 http/https、www/非 www 是不同前缀。
验证完成后，不要急着提交所有 URL。先检查站点是否已经确定规范版本：HTTPS 是否全站生效，www 与非 www 是否有明确跳转，站点地图里的 URL 是否与 canonical 一致。新站早期如果多个版本同时暴露，Google 可能需要更长时间判断哪个才是规范 URL。
第二步：提交一份只包含重要规范 URL 的站点地图
站点地图的作用是告诉搜索引擎哪些页面、图片、视频或文件是站点认为重要的资源，以及它们之间和更新时间的相关信息。Google 官方同时说明，站点地图有助于发现 URL，但不保证所有 URL 都会被抓取和索引。参见 Learn about sitemaps。
新站的 sitemap 不需要追求数量，重点是干净：
- 只放返回 200、允许索引、canonical 指向自己的 URL。
- 不要放搜索结果页、标签参数页、测试页、登录页、购物车页、noindex 页面。
<lastmod>只在页面有实质更新时改变，不要每天批量刷新制造“新鲜”。- 站点地图文件本身可访问，并在 Search Console 中提交；也可以在 robots.txt 中声明 sitemap 地址。
如果你使用 WordPress，常见 SEO 插件通常能生成 sitemap；如果是定制站点，应让程序自动输出规范 URL，而不是手工维护一份很快过期的 XML。
第三步：排除抓取和索引障碍
新站最常见的问题并不是 Google 不知道你上线了，而是 Googlebot 访问后发现页面不能处理。上线当天建议逐项检查：
| 检查项 | 为什么重要 | 怎么处理 |
|---|---|---|
| HTTP 状态码 | 2xx 才会把内容送往后续处理；4xx 表示不存在；5xx 会影响抓取稳定性 | 重要页面返回 200，删除页返回 404/410，减少链式跳转 |
| robots.txt | 误写 Disallow: / 会阻止抓取 | 上线前移除测试期封禁规则，确保 CSS/JS 可抓取 |
| noindex | 页面即使能抓取，也可能被明确要求不索引 | 检查 head 和 X-Robots-Tag，移除误加 noindex |
| canonical | Google 可能选择 canonical 指向的页面，而不是当前 URL | 每个重要页面使用自引用或正确规范 URL |
| 移动端渲染 | Google 主要按移动端内容理解页面 | 移动版不要缺少正文、链接、图片 alt 或结构化信息 |
Google 对 HTTP 状态码的处理有专门文档：2xx 不保证索引，4xx URL 不会被索引，5xx 会让抓取放慢并可能影响已索引 URL。上线前用这一规则检查整站，比反复提交 URL 更有价值。参见 How HTTP status codes affect Google's crawlers。
第四步：用 URL 检查工具处理少量关键页面
新站可以优先检查首页、核心服务页、重要分类页和几篇代表性文章。Search Console 的 URL 检查工具可以查看 Google 索引中的版本状态；官方 API 文档也说明，URL Inspection API 用来查看 URL 在 Google 索引中的状态，目前不是用来测试实时页面可索引性的通用抓取器。参见 URL Inspection API: index.inspect。
手动请求编入索引适合少量 URL。不要把它当成批量发布流程，也不要每天重复提交同一个地址。提交后记录检查结果：Google 选择的规范 URL、是否允许抓取、是否允许索引、上次抓取时间和页面抓取结果。发现问题后先修页面，再请求重新抓取。
第五步：准备足够支撑搜索意图的核心内容
新网站不需要一上线就发布大量文章，但需要让 Google 和用户看出站点的主题、服务范围和内容质量。Google 的有用内容指南建议，内容应主要为人而创建，提供原创信息、完整说明、可靠来源和能帮助读者达成目标的答案；不要为了搜索流量批量生成薄内容，也不要按传言追求固定字数。参见 Creating helpful, reliable, people-first content。
更适合新站的内容组合是：
- 核心服务页：清楚说明你提供什么、适合谁、流程、交付边界和下一步咨询方式。
- 基础知识页：回答目标客户会反复搜索的问题，例如概念、判断标准、成本、流程和风险。
- 专题或分类页：把同一主题下的文章组织起来，形成可抓取的内链结构。
- 案例或示例：在有真实材料时展示方法和结果；没有材料时不要编造客户、比例或截图。
如果你正在建设面向 Google 搜索的中文或外贸站点，可以先参考光算的 Google SEO 服务 页面，理解服务页如何承接用户问题；内容选题阶段可延伸阅读 什么是搜索意图。
不要把 Indexing API 用在普通新站文章上
很多新站教程会建议“部署 Indexing API 批量推送文章”。这并不符合 Google 官方边界。Indexing API 只适用于包含 JobPosting 的招聘页，或 VideoObject 中嵌入 BroadcastEvent 的直播活动页；普通博客、企业新闻、产品页和服务页不属于通用适用范围。参见 Indexing API Quickstart。
对于一般新站，正确组合是 Search Console、站点地图、内部链接、可抓取页面和有用内容。只有当你的站点确实发布招聘信息或直播活动，并按官方结构化数据要求实现页面时，才应评估 Indexing API。
新站内链：让重要页面从首页几步内可达
Google 通过链接发现网页。新站外部链接少，更要把内部链接做清楚。首页导航应指向核心栏目和服务页；分类页应能列出重要文章；文章正文应自然链接到相关解释、服务页或下一步阅读。不要只把文章放进 sitemap，却没有任何站内入口。
一个可用的早期结构是：
- 首页链接到主要服务页和文章分类页。
- 服务页链接到能解释客户疑问的文章。
- 文章之间按同一主题互相引用，不做无关互链。
- 每篇文章回到对应服务或专题页，帮助读者继续行动。
如果涉及站内抓取排查，Screaming Frog 等工具可以模拟爬虫视角查看孤立页面、404、重复标题和 canonical 问题。本站的 Screaming Frog 使用文章 可以作为入门参考。
上线后的监控节奏
新站上线后，建议每周固定查看：
- Search Console 的页面索引报告：哪些 URL 已索引、哪些被排除、原因是什么。
- 站点地图报告：Google 是否成功读取，发现的 URL 是否符合预期。
- 服务器日志：Googlebot 是否访问核心路径，是否遇到大量 4xx/5xx。
- 搜索效果报告：是否开始出现曝光，哪些查询与页面匹配或不匹配。
- 内容队列：哪些页面回答不足、重复、过时或缺少内链。
不要把“未收录”一律理解为提交失败。新站被发现后，Google 仍会判断内容质量、重复性、站点信号和抓取优先级。技术无误但迟迟未索引时，优先检查页面是否真的值得被单独索引：是否有独立信息、是否解决明确问题、是否只是改写已有页面、是否缺少站内入口。
新网站让 Google 发现的简明流程
- 确定 HTTPS、www/非 www、canonical 和站点地图 URL。
- 验证 Search Console，并提交 sitemap。
- 检查首页、服务页、分类页和代表性文章的状态码、robots、noindex、canonical。
- 用 URL 检查工具请求少量关键页面重新抓取。
- 从首页、导航、分类、相关文章建立自然内链。
- 持续发布有明确搜索意图和业务承接的内容，而不是批量薄文。
- 用 Search Console 与日志监控进展，按问题类型修复，而不是反复提交同一 URL。
新站收录没有固定天数承诺。能控制的是：页面让 Google 看得到、读得懂、判断出价值，并且通过站点地图和链接持续获得发现入口。把这些基础做好，比任何“快速收录技巧”都更可靠。