XML 站点地图是一种发现和库存提示：它告诉搜索引擎您认为重要的首选 URL 和文件。 robots.txt 是一种访问协议：它告诉合规的爬虫它们可能请求哪些 URL 路径。既不保证索引或排名，也不保护私人信息。
发现：站点地图加上可爬行的链接。抓取访问：robots.txt。索引排除：可抓取的 noindex 或真正的删除响应。重复合并：规范或重定向。保密性：认证和授权。
五个控件不可互换
| 所需的结果 | 初级控制 | 成功的证据 | 请勿替代 |
|---|---|---|---|
| 帮助搜索引擎发现首选 URL | 可抓取的内部链接和干净的站点地图 | URL 已链接、列出且可获取 | 重复的 URL 检查请求 |
| 防止合规机器人请求路径 | 该爬网程序和主机的 robots.txt 规则 | 规则与测试的 URL 匹配 | noindex，仍然允许爬行 |
| 将可访问的页面排除在 Google 搜索之外 | 机器人元或 X-Robots-Tag noindex | Google 可以获取并读取该指令 | robots.txt 禁止 |
| 永久删除已停用的公共 URL | 404/410 或 301/308 为真正的替代品 | 最终 HTTP 响应与决策匹配 | 仅从站点地图中删除它 |
| 合并等效的重复 URL | 一致的规范信号或永久重定向 | 首选 URL 用于跨链接和站点地图 | robots.txt 阻止重复项 |
| 保护私人或机密内容 | 身份验证和服务器端授权 | 未经授权的请求无法检索它 | robots.txt、noindex 或未链接的 URL |
网站需要站点地图吗？
谷歌表示，当每个重要页面都可以通过普通链接访问时，大约 500 个页面或更少的小型网站可能不需要站点地图。但这并不意味着站点地图对小型企业毫无用处：它们在发布、迁移、多语言扩展和库存监控期间仍然有价值。
站点地图补充了站点架构；它不修复孤立页面。使用 网站架构指南 和 内部链接指南 创建真正的发现路径。
| 情况 | 站点地图值 | 更重要的伴侣 |
|---|---|---|
| 新域名，外部链接很少 | 高：暴露首选发布库存 | 来自主页、中心和相关外部配置文件的链接 |
| 小型、全面链接的服务站点 | 对发现有用但不是必需的 | 清晰的导航和直接的内部链接 |
| 大型电子商务、出版或市场网站 | 高：分区较大且不断变化的库存 | 分面导航控制、日志和稳定的 URL 规则 |
| 多语言网站 | 当选择 Sitemap hreflang 实现时高 | 自规范区域设置 URL 和相互替代 |
| 以图像、视频或新闻为主导的网站 | 当专门文件难以发现时高 | 无障碍媒体、有效的登陆页面和特定功能的要求 |
| 网站迁移 | 高：呈现最终的首选 URL 集 | 一对一重定向、保留内容和生产抓取 QA |
选择可维护的站点地图格式
| 格式 | 很合身 | 能力和限制 |
|---|---|---|
| XML URL 集 | 大多数网站和 CMS 平台 | 支持本地化、图像、视频和新闻数据的 URL、lastmod 和 Google 扩展 |
| 站点地图索引 | 多个 XML 文件或大量库存 | 参考子站点地图；它包含站点地图位置，而不是页面 URL |
| RSS 或 Atom | 拥有可靠提要的出版商 | 对于最近的 URL 很有用；不取代完整的历史库存 |
| 文本站点地图 | 简单的仅页面库存 | 每行一个绝对 URL；没有lastmod或扩展 |
| HTML 站点地图 | 人工导航和可达性 | 普通网页，不能替代符合协议的站点地图提交 |
从规范库存构建站点地图
最安全的生成器从发布页面的相同事实来源开始。仅当 URL 的预期状态是公开、可索引和规范时，才会进入站点地图。自动抓取生成的列表可以保留参数重复、重定向或旧的暂存路由等错误。
Google 尝试抓取所提供的确切绝对网址。保持协议、主机名、路径大小写、尾部斜杠策略和区域设置路径与最终的 Canonical 一致。
- 绝对、完全限定的生产 HTTPS URL。
- 具有正确主机名、路径和区域设置的首选 Canonical 版本。
- 预计返回 HTTP 200 和有意义的可见内容。
- 已被 robots.txt 允许，且不受登录保护。
- 没有机器人元或 X-Robots-Tag noindex。
- 不是重复的参数、排序、过滤器、会话或跟踪变体。
- 可通过至少一个有用的可爬网内部链接进行访问。
- 适合用户从搜索结果中登陆。
- 包含在正确的子站点地图中一次。
- 当其发布或索引决策发生变化时自动删除。
排除讲述不同索引故事的 URL
| URL状态 | 网站地图处理 | 正确的技术处理 |
|---|---|---|
| 301/308 永久重定向 | 排除来源；仅列出最终首选 URL | 旧 URL 直接重定向到最接近的等效 URL |
| 302/307临时重定向 | Usually exclude temporary source from a preferred inventory | 确认哪个 URL 应保留索引 |
| 404/410 已停用 URL | 排除 | 保留真实删除回复并修复内链 |
| 5xx 或持续超时 | 不要呈现为健康库存 | 修复服务器或应用程序原因 |
| 无索引页 | 排除 | 保持可抓取，直到 Google 可以处理该指令 |
| 规范重复 | 排除重复项；包括首选代表 | 对齐内部链接、hreflang 和 Canonical |
| 内部搜索或弱过滤页面 | 排除 | 根据价值和规模使用经过深思熟虑的索引/抓取规则 |
| 暂存、预览、管理或帐户 URL | 排除 | 通过访问控制保护私有环境和会话 |
尊重协议限制和文件范围
单个 Sitemap 的大小限制为 50,000 个 URL 或 50 MB 未压缩大小。站点地图索引最多可以引用 50,000 个站点地图文件，并且受到相同的未压缩大小限制。压缩减少了传输大小，而不是未压缩的协议限制。
使用 UTF-8、实体转义 XML 值并将 Sitemap 文件保存在稳定的公共 URL 中。除非通过 Search Console 提交，否则站点地图通常会影响其父目录的后代；将其托管在站点根目录可以避免意外的范围限制。
| 协议项 | 要求 | 审核检查 |
|---|---|---|
| 网址设置 | 最多 50,000 个 URL 和 50 MB 未压缩 | 释放前对条目和未压缩字节进行计数 |
| 站点地图索引 | 最多 50,000 个子站点地图和 50 MB 未压缩 | 子位置解析并包含预期的主机清单 |
| 编码 | 具有有效 XML 和转义实体的 UTF-8 | 解析器接受 & 符号、非拉丁路径和命名空间 |
| 地点 | 有效范围内稳定可访问的URL | 根目录放置或经过验证的跨站点提交是故意的 |
| 页面网址 | 完全限定的绝对 URL | 无相对路径、开发主机或混合协议 |
| 订购 | 无排名意义 | 不要浪费精力按假定的重要性进行排序 |
分区子站点地图用于诊断，而不是装饰
将一个小清单分成数百个文件会产生维护噪音。当群组具有不同的模板、所有者、更新模式或风险时进行分区，以便 Search Console 过滤显示可操作的群组。
SEOWithJack 目前使用一个根站点地图索引，该索引引用帖子、页面和类别子站点地图。帖子站点地图包括英文、马来文和简体中文文章 URL，而 robots.txt 文件则指向一个根索引。该模式足够简单以供审核，并且足够具体以隔离内容类型。
| 可能的子站点地图 | 有用的时候 | 创建它的理由很糟糕 |
|---|---|---|
| 帖子或文章 | 编辑 URL 共享发布和刷新规则 | 无论工作流程如何，每个月都需要一个永久文件 |
| 页面或服务 | 商业/静态模板需要单独监控 | 他们只是 URL 数量较少 |
| 产品或类别 | 不同的模板和规范风险需要队列 | 要求更高的优先权 |
| 区域设置 | 团队或平台独立维护语言 | 避免实现正确的 hreflang 关系 |
| 图片、视频或新闻 | 适用专门的 Google 扩展和验证 | 该网站恰好包含一张普通图像 |
| 遗留迁移队列 | 记录了对移动 URL 的临时监控 | 重定向旧 URL 作为首选页面 |
使用lastmod作为事实变更记录
谷歌表示可能会使用 <最后修改> 当值一致且可验证准确时，用于爬网计划。它应该反映页面的最后一次重大更改，而不是站点地图生成时间、部署时间戳或版权年份。
谷歌忽略 <优先级> 和 <更改频率>。未经身份验证的 Sitemap Ping 端点也已弃用并返回 404；保持稳定的站点地图网址并使用 Search Console、robots.txt 或 Search Console API。
| 改变 | 更新最新版本吗？ | 原因 |
|---|---|---|
| 用新证据重写主要指南 | 是的 | 页面发生了有意义的变化 |
| 添加或更正重要的结构化数据 | 是的 | Google 将结构化数据视为潜在重要数据 |
| 更改重要的内部链接或导航上下文 | 当页面内容充足时通常是的 | 发现和页面关系已更改 |
| 修复一个拼写错误或压缩同一张图像 | 通常没有 | 页面用途和信息没有发生重大变化 |
| 仅更新页脚、版权年份或全局 CSS | 每个内容 URL 都不是 | 共享的外观构建不是内容刷新 |
| 使用今天的日期重新发布未更改的文本 | 否 | 它会产生不准确的信号和误导性的新鲜度 |
| 聚合器页面自动更改 | 只有当系统能够计算出真实有意义的更新时 | 如果置信度较低，则省略 Lastmod |
对齐站点地图、状态、规范和索引规则
| 信号 | 首选可索引 URL | 已停用的网址 | 重复的网址 | 私人网址 |
|---|---|---|---|---|
| HTTP响应 | 200 | 404/410 或相关 301/308 | 200或根据产品需求重定向 | 401/403 或经过身份验证的访问 |
| 机器人.txt | 允许抓取 | 通常不需要特殊规则 | 当 Google 必须读取 Canonical/noindex 时允许 | 不是安全控制 |
| 机器人元/标题 | 允许索引 | 真正去除不需要 | 仅当需要排除时才使用 noindex | 不是安全控制 |
| 规范的 | 自引用首选 URL | 删除回复后无任何回复 | 适当时指向同等代表 | 不依赖 |
| 内部链接 | 直接使用首选 URL | 删除或更新 | 首选有代表性的 URL | 仅限内部授权经验 |
| 网站地图 | 包括 | 排除 | 排除非首选重复项 | 排除 |
多语言站点地图和 hreflang 规则
XML 是 Google 支持的三种等效的 hreflang 实现方法之一。如果您选择它，每个本地化 URL 都会收到自己的 <网址> 条目，并且每个条目都通过相同的方式列出自身以及所有其他替代项 xhtml:链接 注释。
不要使用 hreflang 来修复围绕未翻译的主要内容的翻译导航。每个区域设置 URL 都应该是真实的、可索引的本地化页面，具有自规范且受支持的语言或语言区域代码。回顾 多语言 SEO 指南 以获得完整的决策模型。
- 每个可索引语言 URL 都有自己的站点地图 URL 条目。
- 每个条目都会列出自己和所有其他替代项。
- 不同版本之间的备用集是相互的且相同的。
- 所有 href 值都是绝对生产 URL。
- 每个替代解析为 HTTP 200 和该区域设置中的自规范。
- 语言代码使用支持的 ISO 语言值和可选区域值。
- x-default is used only for the deliberate fallback destination.
- 重定向、无索引、阻止或未翻译的变体不会被声明为有效的替代。
- 相同的映射与 HTML 或 HTTP 标头 hreflang 并不矛盾。
仅在解决发现问题时才使用专门的站点地图扩展
| 扩展 | 有用于 | 释放门 |
|---|---|---|
| 图片 | Google 可能无法发现的重要图像，包括一些 JavaScript 到达的资产 | 图片URL可抓取；使用当前支持的图像标签 |
| 视频 | 以视频为主要内容且媒体详细信息有助于发现的页面 | 登陆页面、缩略图、播放器/内容 URL 和必填字段均可访问 |
| 新闻 | 具有当前文章库存的合格新闻发布商 | 遵循当前的 Google 新闻站点地图要求和新鲜度窗口 |
| xhtml hreflang | 当选择 Sitemap 注释方法时的本地化变体 | 每个版本都列出了完整的相互语言环境集 |
| 组合扩展 | 一个页面合法地符合多种类型 | 声明每个名称空间一次并验证组合的 XML |
| 无 | 普通页面已经可以在 HTML 中发现 | 不要仅为外观添加不受支持的元数据 |
提交位置，而不是文件内容
Search Console 提交会告知 Google 托管站点地图所在的位置；它不会将 XML 上传到 Google。该文件必须保持公开且可获取。成功提交意味着 Google 可以处理该文件，而不是对列出的每个 URL 进行爬网、索引或排名。
| 发现或提交方式 | 使用案例 | 重要限制 |
|---|---|---|
| Search Console 站点地图报告 | 手动提交加上获取和解析反馈 | 需要所有者许可并显示提交的财产文件 |
| robots.txt 站点地图行 | 爬虫可发现的持久公开声明 | 使用完全限定的绝对 URL；它不保证处理 |
| 搜索控制台 API | 对许多经过验证的属性进行程序化管理 | 自动化仍然需要验证和所有权 |
| RSS/Atom 与 WebSub | 广播最近的发布更改 | Feed 是最近的库存，不一定是完整的站点地图 |
| 已弃用的 Ping 端点 | 请勿使用 | 谷歌返回404并且没有获得任何有用的信号 |
阅读正确级别的 Search Console 报告
使用站点地图报告来确认获取历史记录和解析错误。使用按“所有提交的页面”或特定站点地图筛选的页面索引报告来了解该群组的索引状态。对代表性 URL 使用 URL 检查，而不是从一页推断出整个站点。
提交的 URL 和索引的 URL 之间的差距不会自动导致错误。重定向、重复、无索引页面和删除不应进入干净的站点地图；有效页面可能仍需要质量调查、规范选择或处理。
| 问题 | 最好的证据 | 不做结论 |
|---|---|---|
| Google 可以获取并解析该文件吗？ | 站点地图报告状态、上次读取和错误 | 成功意味着每个 URL 都被索引 |
| 哪个提交的群组未编入索引？ | 按站点地图过滤的页面索引报告 | 每个未索引的 URL 都是一个缺陷 |
| Google 对一个网址了解多少？ | URL 检查索引数据和实时测试 | 实时测试意味着 URL 已进入索引 |
| 发电输出在技术上是否清洁？ | 独立的XML解析加上URL库存抓取 | 有效的 XML 意味着 URL 决策是正确的 |
| 变化是否改善了发现？ | 可比较的爬网/索引群组和服务器日志 | 提交时间戳导致排名提升 |
robots.txt 范围从确切的主机根开始
文件必须以小写形式提供 /robots.txt 在顶层。其规则仅适用于相同的协议、主机名和端口。上的一个文件 https://example.com 不控制 http://example.com, https://www.example.com、另一个子域或非标准端口。
确保每个生产主机名都是有意的。翻译后的子文件夹共享其主机的 robots 文件；翻译后的子域需要有自己的子域。 CDN 或应用程序应返回纯 UTF-8 文本，而不是登录页面、HTML 错误模板或重定向链。
| robots.txt 位置 | 控制 | 不控制 |
|---|---|---|
| https://example.com/robots.txt | example.com 上标准端口的 HTTPS URL | HTTP、www、子域或自定义端口 |
| https://www.example.com/robots.txt | 仅 www HTTPS 主机 | Apex example.com 或 shop.example.com |
| https://shop.example.com/robots.txt | 仅商店 HTTPS 子域 | 主网站或其他子域 |
| https://example.com/folder/robots.txt | 没有任何机器人根策略 | /文件夹/下的URL |
| https://example.com:8443/robots.txt | 仅该主机、协议和端口 | 标准 HTTPS 端口 |
了解组、匹配和支持的字段
| 元素 | 谷歌行为 | 审计风险 |
|---|---|---|
| 用户代理 | 开始一个团体； Google 选择最具体的匹配标记并合并重复的匹配组 | A generic group is assumed to override a more specific bot group |
| 不允许 | 阻止路径与规则匹配的爬网请求 | 宽泛的前缀无意中涵盖了有用的 URL |
| 允许 | 允许更广泛的禁止范围内的例外 | The exception is shorter than the competing blocking rule |
| 最长的匹配 | 最具体的匹配路径获胜；允许赢得相同长度的平局 | Reviewers read top-to-bottom as if first rule always wins |
| 路径套管 | 规则区分大小写 | 实时 URL 使用不同的大小写 |
| 通配符 | Google 在路径规则中支持 * 和结束锚 $ | 正则表达式假设产生更宽或更窄的匹配 |
| 网站地图 | 绝对位置；不绑定到用户代理组 | 相对 URL 或错误的协议/主机名 |
| 不支持的线路 | 谷歌忽略他们 | 抓取延迟或特定于插件的指令被假定为通用的 |
从表达策略的最小的 robots.txt 开始
如果所有公共内容都可以被爬网，则不存在的文件或空的适用“禁止”已经意味着允许爬网。 允许：/ 通常是不必要的。仅针对爬网访问被故意限制的 URL 模式添加规则，然后测试代表性的允许和阻止的 URL。
一个简单的服务站点可能会使用一个 用户代理：* 组，阻止内部搜索结果路径并列出一个绝对站点地图索引。在这些路由不再存在后，它不应复制旧的 WordPress 管理规则，也不应阻止渲染公共页面所需的 CSS、JavaScript 或图像。
- 每个 Disallow 都有记录的爬网管理目的。
- 规则与确切的生产案例、斜杠和参数模式匹配。
- 更具体的允许例外在最长匹配规则下起作用。
- 渲染所需的公共页面、CSS、JavaScript、图像或 API 不会被意外阻止。
- 没有规则被用作安全、Canonical 或 noindex 的替代品。
- 特定的爬网程序组基于该爬网程序已发布的文档。
- Sitemap 行使用最终的绝对生产 URL。
- 暂存规则无法静默复制到生产环境中。
了解 robots.txt 响应失败如何改变抓取
robots.txt 是运营基础设施。 Google 通常会将其缓存长达 24 小时，有时刷新失败时会缓存更长时间。因此，更改可能需要一段时间才能传播，并且中断可能会影响多个页面。
| robots.txt 响应 | 谷歌记录的治疗方法 | 运营响应 |
|---|---|---|
| 2xx | 处理收到的有效规则 | 确认内容类型、编码和预期规则 |
| 3xx | 遵循至少五个重定向；除此之外，将其视为 404 | 尽可能直接在规范主机根目录下提供服务 |
| 4xx，429 除外 | 就好像 robots.txt 不存在一样，因此不适用抓取限制 | 不要使用 401/403 来限制爬行 |
| 429 | 与普通 4xx 分开处理 | 研究容量和速率限制配置 |
| 5xx | 最初停止爬行12小时；重试时可能会使用最后一个好的版本 | 将其视为紧急的主机可靠性问题 |
| DNS/网络故障 | 视为服务器错误 | 修复可用性、TLS、DNS 或边缘行为 |
| 文件大于 500 KiB | limit之后的内容被忽略 | 整合规则并重组 URL 模式 |
| 缓存旧版本 | 故障期间可能持续约 24 小时或更长时间 | 允许传播时间并验证服务器交付 |
robots.txt 无法删除或保护内容
| 需要 | 正确方法 | 为什么 robots.txt 失败 |
|---|---|---|
| 从 Google 中删除可访问的 HTML 页面 | 可爬行元机器人 noindex | 被阻止的爬虫无法读取页面级规则 |
| 删除可访问的 PDF 或其他非 HTML 文件 | 可抓取的 X-Robots-Tag noindex 响应标头 | HTML 元不可用并且块隐藏了标头 |
| 在准备永久处理时紧急隐藏结果 | Search Console 删除以及持久的 noindex/删除/身份验证 | 单独的机器人更改既不能立即删除索引，也不能持久删除索引 |
| 保护客户、暂存或机密数据 | 身份验证、授权和网络控制 | robots.txt 是公开的、建议性的并公开命名路径 |
| 淘汰内容且不进行替代 | 404 或 410 以及从链接/站点地图中删除 | 禁止使 URL 及其外部引用无法解析 |
| 永久移动内容 | 301/308 到最接近的等效值 | 禁止阻止移动的正常处理 |
| 合并重复的 URL | 规范信号或永久重定向 | 阻止阻止 Google 读取规范内容信号 |
为 WordPress、静态站点和应用程序生成不同的内容
| 平台 | 推荐的事实来源 | 释放风险 |
|---|---|---|
| WordPress 核心 | 在合适的情况下发布公共内容和本机站点地图系统 | SEO 插件、缓存或多语言插件创建第二个冲突索引 |
| 带有 SEO 插件的 WordPress | 使用最终 Canonical 设置精心选择的站点地图提供商 | 提交本机和插件清单而不进行比较 |
| 静态站点生成器 | 构建公共可索引路线的清单 | 每个构建都会更改lastmod或包含生成的重定向和实用程序页面 |
| 无头内容管理系统 | 已发布的记录与路线、区域设置和规范状态相结合 | 未发布或孤立的记录泄漏到生成的 XML 中 |
| 电子商务/应用 | 产品/类别可用性和指数决策服务 | 方面、会话、排序参数和软删除记录扩大了库存 |
| 多主机 | 仅在有意情况下才对每台主机清单进行验证的交叉提交 | 假设一个 robots 文件控制每个子域 |
保护 WordPress 到静态的迁移
- 导出旧的站点地图库存、公共爬行、Canonicals、hreflang 和索引指令。
- 将每个旧 URL 映射到未更改的路由、真正的等效重定向或合理的 404/410。
- 继续在身份验证后进行暂存，并将其主机名从生产站点地图中排除。
- 从最终发布的路线清单生成新的站点地图，而不是盲目抓取。
- 按内容类型和区域设置比较新旧首选库存。
- 删除重定向、无索引页面、错误、搜索结果和非规范变体。
- 验证 XML、子索引、URL 限制、响应代码和生产主机名。
- 在同一版本中发布重定向、页面、站点地图和 robots.txt。
- 确认生产 robots.txt 没有继承站点范围的登台禁止。
- 启动后抓取每个旧 URL 和每个新站点地图 URL。
- 在生产版 Search Console 属性中提交稳定的 Sitemap 索引。
- 监控提交的群组、选定的 Canonicals、服务器错误和有机登陆页面。
按正确的顺序诊断症状
| 症状 | 可能层 | 收集的第一个证据 |
|---|---|---|
| 站点地图“无法获取” | 访问、DNS、重定向、内容类型或属性范围 | 直接 HTTP 响应和站点地图报告详细信息 |
| XML 解析错误 | 编码、转义、命名空间或格式错误的标记 | 原始响应和 XML 验证器位置 |
| 提交的网址被 robots.txt 阻止 | 库存和抓取策略冲突 | 精确的站点地图条目加上匹配的机器人规则 |
| 提交的 URL 标记为 noindex | 发布/索引决策冲突 | 渲染/头部响应和生成器资格逻辑 |
| 提交的 URL 是重定向 | 旧的或错误的 Canonical 库存 | 重定向目的地和路线清单 |
| Google 选择了不同的 Canonical | 重复或不一致的信号 | 页面对、内部链接、Canonicals、hreflang 和站点地图 |
| 站点地图中缺少重要 URL | 生成器、发布状态或分区错误 | 源记录和子站点地图分配 |
| 大量无法解释的未提交 URL 集 | 方面、参数、旧路线或爬虫陷阱 | 页面索引过滤器、抓取导出和服务器日志 |
| robots.txt 已更改，但测试看起来很旧 | 缓存或边缘交付 | 响应标头、主机变体和已用缓存时间 |
| 提交后流量发生变化 | 不能证明站点地图因果关系 | 查询、页面、发布、需求和 SERP 群组 |
运行释放门，而不是目视抽查
- robots.txt 和每个 Sitemap 在生产主机上返回 HTTP 200。
- 文件采用 UTF-8 和 XML 解析，并使用每个声明的命名空间。
- 站点地图索引子位置是绝对的、唯一的且可获取的。
- 每个列出的页面都有 200 个、可索引、规范且内部链接。
- 未列出重定向、4xx、5xx、登录、暂存或非规范 URL。
- 使用 Sitemap hreflang 时，语言环境集群是完整且互惠的。
- lastmod 被省略或与有意义的源代码控制更改相关联。
- 机器人规则通过代表允许、阻止和例外情况。
- 所需的渲染资源仍可抓取。
- 站点地图索引使用其确切的绝对 URL 声明一次。
- 旧的 WordPress URL 根据批准的重定向映射进行解析。
- Search Console 可以获取站点地图，并且同类群组监控拥有所有者。
常见的站点地图和 robots.txt 误区
- “站点地图中的每个 URL 都会被索引。”这是一个提示，而不是保证。
- “站点地图取代了内部链接。”孤立页面仍然是一个导航和架构问题。
- “优先级 1.0 使页面排名更高。”谷歌忽略优先级。
- “changefreq=每日强制每日爬行。”谷歌忽略changefreq。
- “全新的 Lastmod 保证了今天的重新爬行。”它仅在准确且不设定截止日期时才有用。
- “旧的 Ping URL 可以加快提交速度。” Google 已弃用它并返回 404。
- “robots.txt 从搜索中删除页面。”被阻止的 URL 可能仍会在没有获取内容的情况下被编入索引。
- “禁止保护机密路径。”该文件是公开的，不提供任何授权。
- “阻止无索引页面以获得额外的确定性。”阻止可能会阻止 Google 读取 noindex。
- “一个 robots.txt 控制 www、子域和 HTTP。”规则的范围为协议、主机名和端口。
- “更多禁止规则可以节省每个小网站的抓取预算。”不必要的复杂性可能会造成更大的失败。
- “成功提交 Search Console 证明 SEO 已完成。”它证明文件处理，而不是页面质量或排名。
常见问题
每个网站都需要 XML 站点地图吗？
不会。谷歌表示，一个小型的、全面链接的网站可能会在没有链接的情况下被发现。干净的站点地图对于发布、迁移、多语言库存、专业媒体和监控仍然有用。
站点地图是否保证抓取或索引？
不，提交只是一个提示。该 URL 仍然必须是可访问的、可索引的、规范的、有用的并由 Google 系统选择。
站点地图中是否应该包含重定向网址或 noindex 网址？
否。首选的可索引库存应排除重定向、删除、无索引页面和非规范重复项。
一个站点地图可以包含多少个网址？
最多 50,000 个 URL 或 50 MB 未压缩，以先达到的限制为准。较大的库存应使用子站点地图和站点地图索引。
我应该在每个 URL 上使用 lastmod 吗？
仅当系统能够提供最后一次重要页面更改的一致准确的日期时。当置信度较低时省略它是可以接受的。
Priority 和 ChangeFreq 对 Google 有帮助吗？
不。Google 声明它会忽略这两个字段。
robots.txt 中是否也应该阻止 noindex URL？
不可以。Google 必须能够抓取 URL 才能读取其元机器人或 X-Robots-Tag noindex 指令。
robots.txt 可以保护临时网站吗？
不可以。使用身份验证或网络访问控制。公共 Disallow 文件是建议性的，可以公开其命名的路径。
robots.txt 和站点地图应托管在哪里？
robots.txt 必须位于确切的主机根目录下。根级站点地图提供了简单的站点范围；然后可以在 robots.txt 和 Search Console 中声明其绝对位置。
我应该如何监控站点地图性能？
检查站点地图报告中的获取和解析，按提交的站点地图过滤页面索引报告，检查代表性 URL 并按有意义的群组比较索引结果。
官方参考资料
- Google：构建并提交站点地图
- Google：站点地图概述
- Sitemaps.org 协议
- Google Search Console：站点地图报告
- Google Search Console：页面索引报告
- 谷歌：robots.txt 简介
- Google：创建并提交 robots.txt 文件
- 谷歌：谷歌如何解释robots.txt
- IETF RFC 9309：机器人排除协议
- Google：使用 noindex 块索引
- Google 机器人元规范
- Google：本地化页面版本和 hreflang
- 谷歌：合并站点地图扩展
- 谷歌：图像站点地图
- Google：站点地图 ping 端点弃用和 Lastmod
分享实时站点地图索引、robots.txt、Search Console 状态和受影响的网址模式。 Jack 可以将生成的清单与 Canonicals、响应、区域设置路由和迁移重定向进行比较。