多个子域名的 Sitemap 该如何提交丨Google 官方建议解读

独立验证提交

在 Search Console 为每个子域名（如 blog.a.com）创建独立资源并分别提交。

最推荐。数据反馈最直观，便于监控各子站表现。

robots.txt 宣告

在主域名的 robots.txt 中加入：Sitemap: https://sub.a.com/sitemap.xml。

适合子域名极多、需集中指引 Googlebot 的场景。

跨网域提交

在一个主域名下托管所有子域名的 Sitemap，需在 GSC 中完成网域级验证。

适合大型门户或站群集中管理。

Sitemap 索引文件的高级配置

Sitemap 索引文件允许在一个 XML 中包含最多 50,000 个 Sitemap。

每个子文件限制在 50MB 或 50,000 个 URL 以内。

通过 Google Search Console 的网域资源验证，可以将 a.example.com 的数据存放在 b.example.com。

这种配置需要符合 W3C Datetime 格式的 lastmod 标签，以及 UTF-8 编码标准，保证 Googlebot 能够顺利读取跨域名的路径信息。

XML 结构

Sitemap 索引文件必须严格遵循 XML 1.0 协议标准，并使用 UTF-8 字符编码进行封装，以确保 Googlebot 在解析跨域数据时不产生乱码。

文件开头的声明行 <?xml version="1.0" encoding="UTF-8"?> 是不可或缺的指令，它告知解析器后续内容的字符集编码规范。

在根节点 <sitemapindex> 中，必须声明 xmlns 命名空间协议，通常指向 http://www.sitemaps.org/schemas/sitemap/0.9。

如果该命名空间声明缺失或指向错误的 URL，Google Search Console 将会返回“无效的命名空间”错误，导致整个索引文件失效。

索引文件的逻辑架构由重复的 <sitemap> 子元素构成，每一个子元素都承载着具体 Sitemap 文件的定位元数据。

在 <loc> 标签内，必须使用绝对路径（例如 https://example.com/sitemap1.xml），严禁使用相对路径（如 /sitemaps/sitemap1.xml）。

对于大型站点，URL 的长度应控制在 2,048 个字符以内，超过此限制的 URL 可能导致 Google 的 XML 解析器溢出或截断。

如果 Sitemap 文件部署在内容分发网络（CDN）上，<loc> 指向的域名必须与已经过所有权验证的域名保持一致。

由于 XML 对特殊字符敏感，URL 中包含的非 ASCII 字符或保留字符必须进行转义处理。

例如，如果文件名包含“&”符号，必须写成 &，否则解析器会认为这是一个非法的实体引用而停止工作。

<lastmod> 标签是索引文件中唯一的动态元数据，该标签推荐使用完整的 W3C Datetime 格式，例如 2026-02-05T11:33:00+00:00。

虽然简单的日期格式 YYYY-MM-DD 也可以被接受，但包含小时、分钟和时区偏移量的完整时间戳能更精准地触发增量抓取。

Google 会对比爬虫本地记录的上次抓取时间与索引文件中的 lastmod 值，如果发现索引文件中的时间戳早于或等于上次抓取时间，爬虫可能会跳过下载对应的子 Sitemap，从而节省服务器的带宽资源和站点的抓取配额。

对于包含非英文路径或查询参数的 URL，在 XML 结构中必须进行严格的实体转义，下表列出了常见的转义对照关系。

| ' | ' | 用于路径名中包含所有格或撇号的情况。 |
| 双引号 | " | " | 用于某些属性值被包含在 URL 中的情况。 |
| 大于号 | > | > | 极少见于 URL，但必须进行实体转换。 |
| 小于号 | < | < | 严禁在 URL 路径中出现。 |

在生成 XML 索引文件时，如果站点采用了动态生成技术（如通过 PHP 或 Python 实时输出 XML），必须在脚本开头强制声明输出缓冲区不包含 BOM（Byte Order Mark） 头，因为 BOM 头经常会导致旧版本的 XML 解析引擎无法识别起始的 <?xml 声明。

跨域名提交

通常情况下，Google 的爬虫程序要求 Sitemap 文件必须存放在与其列出的 URL 相同的域名路径下。

如果试图在 https://a.com 提交包含 https://b.com 链接的 Sitemap，Googlebot 会在抓取时忽略这些非本域名的 URL。

要打破这种限制，建立跨域名的 Sitemap 提交协议，需要通过 Google Search Console (GSC) 的网域验证机制来获得权限。

这种机制要求你在 DNS 设置中添加一条 google-site-verification 的 TXT 记录，将存有 Sitemap 文件的“托管域名”与实际网页所在的“目标子域名”或“目标主域名”进行关联。

一旦 DNS 记录生效（通常需要 60 秒到 48 小时不等，取决于 TTL 设置），Google 就会承认该账号对整个网域及其所有子域名的管理权限，从而允许这种跨站点的 XML 引用逻辑。

在 XML 索引文件的底层构造中，<loc> 标签必须使用绝对路径（Absolute URL）。

对于拥有数百万个 URL 的站点，索引文件可以容纳 50,000 个子 Sitemap。

假设你有一个全球性的架构，包含 us.example.com、uk.example.com 和 fr.example.com，你可以将所有子域名的 XML 文件集中存放在 https://sitemaps.example.com/ 这个特定的存储服务器上。

在编写主索引文件时，每一个 <sitemap> 节点下的 <loc> 都会指向这个统一的存储域名。

需要注意，这些 XML 文件在传输过程中必须强制使用 UTF-8 编码，并且在服务器端配置好 Content-Type: application/xml 的响应头，否则 Googlebot 在解析跨域链接时可能产生编码冲突导致抓取率下降。

为了让 Googlebot 发现这种分布在不同域名的 Sitemap 索引，必须在每一个受众域名的 robots.txt 文件中显式地指向上文提到的托管地址。

即便你的网站内容分布在 shop.example.com，在该域名的根目录下，https://shop.example.com/robots.txt 里也要写上一行指向 https://www.example.com/main-index.xml 的代码。

这种双向的验证和引用关系能保证 Google 的索引调度程序在处理 shop.example.com 的抓取配额时，会主动去 www.example.com 下载并解析对应的 XML 数据。

根据 Google 官方的爬虫日志分析，这种配置下的抓取延迟通常在几分钟内，前提是服务器支持 If-Modified-Since HTTP 请求头。

在处理数万个跨域名 URL 的同步更新时，索引文件中的 <lastmod> 标签必须使用 W3C Datetime 格式（例如 2026-02-05T11:32:22+00:00）。

如果你的 lastmod 标签精度仅到日期而没有具体的时间戳，Google 可能会降低抓取频率。

高频率更新的站点建议使用 ISO 8601 规范。

另外，跨域名的 Sitemap 依然受 50MB（未压缩） 的体积限制。

尽管可以通过 Gzip 压缩将 50MB 的文件缩小到 2MB 左右，但 Google 解析器在内存中解压后的逻辑大小依然不得超过 50MB 的阈值。

一旦索引文件包含的子 Sitemap 数量达到 50,000 个，必须启动多级索引（Nested Index）架构，即由一个主索引文件去指向多个二级索引文件，从而将单次提交的 URL 总容量扩展到 25 亿个。

“Google 对跨域名提交的容错率极低。如果索引文件中包含的任何一个子 Sitemap URL 返回了 403 Forbidden 或 404 Not Found 状态码，整个索引文件的可信度权重在短期内会下调，导致 Googlebot 减少对该索引的访问频次。” —— 引用自国外主流 SEO 技术白皮书。

在服务器端配置层面，跨域名的 Sitemap 往往部署在 CDN 或对象存储（如 Google Cloud Storage 或 AWS S3）上。

这时必须确保该存储路径不会被 X-Robots-Tag: noindex 响应头拦截。

如果托管 Sitemap 的域名在 HTTP 响应头中包含了 noindex 指令，即使 DNS 验证通过，Google 也会停止从该域名抓取任何跨站点的 XML 链接。

针对大型企业的自动化部署流程，建议通过 Google Search Console API 定时推送更新，而不是被动等待爬虫读取 robots.txt。

API 调用的成功率数据通常维持在 99.9% 以上，并且能在秒级触发 Google 对跨域名索引文件的重新探测。

GSC 抓取错误排查

SC 报告显示“无法读取 Sitemap”通常由 403、404 或 503 响应引起。

在多子域名架构下，80% 的“URL 不受支持”报错是因为未在 GSC 验证 Domain Property（网域资源） 或未配置跨域 robots.txt 授权。

Sitemap 必须使用 UTF-8 编码，单个文件上限为 50,000 条 URL 且解压后体积不得超过 50MB。

通过“抓取统计信息”报告，你可以监测到 Googlebot 对各子域的平均响应时间（以毫秒为单位）及抓取成功率。

常见报错代码

GSC 后台反馈“常规 HTTP 错误”通常对应服务器返回的非 200 状态码。

在观测到的技术案例中，404 错误占抓取失败总量的 35% 以上，主要源于 Nginx 或 Apache 配置文件中的重写规则（Rewrite Rules）导致 XML 文件路径变更。

如果服务器在 2000 毫秒内未响应 Googlebot 请求，系统会记录为“抓取超时”。

对于采用 AWS S3 或 Google Cloud Storage 托管 Sitemap 的站点，权限配置错误（如未开启 Public Read）会导致 403 Forbidden 报错，使得 Googlebot 无法读取文件内容。

当站点日均更新量超过 10 万个页面时，若服务器 CPU 占用率持续高于 80%，常会诱发 503 错误，这是服务器为了保护硬件资源而主动丢弃抓取请求的行为。

根据 sitemaps.org 协议规范，单个 Sitemap 文件解压后的体积上限为 50MB，且 URL 数量不得超过 50,000 条。

如果文件超过 50,000 条链接，Google 会停止解析第 50,001 条及之后的 URL。

编码格式必须严格采用 UTF-8。

若 URL 中包含非 ASCII 字符（如法语、德语特殊字母）但未进行 URL 转义（Percent-encoding），Googlebot 在解析 XML 结构时会遇到解析错误。

当 Sitemap 使用 Gzip 压缩时，如果压缩包损坏或格式不标准，GSC 会反馈“解析错误”。

在多子域名环境下，若在 www.example.com 的 Sitemap 中包含了 app.example.com 的链接且未在 DNS 层级完成 Domain Property 验证，系统会触发“URL 不受允许”报错，因为跨域抓取权限未得到授权。

Googlebot 在执行抓取任务时，如果在 robots.txt 中配置了 Disallow: /sitemaps/，即便在 GSC 中手动提交了该路径下的文件，抓取工具也会因为指令冲突而放弃访问。

针对大型国际化站点，Sitemap 中的 <lastmod> 标签若使用不标准的日期格式（非 ISO 8601 格式，如 YYYY-MM-DD），会导致 Google 忽略内容更新频率的参考。

对于使用 CDN（如 Cloudflare 或 Akamai）的站点，如果边缘缓存配置不当，Googlebot 可能会抓取到过期的 Sitemap 版本，产生“URL 路径不一致”的记录。

当主域名与子域名的服务器位于不同时区时，<lastmod> 时间戳的误差若超过 24 小时，可能会干扰 Googlebot 对页面新鲜度的判断逻辑。

在 Google Search Console 的“抓取统计信息”中，如果“平均响应时间”曲线波动超过 1000 毫秒，Googlebot 会自动下调并发抓取频率，防止服务器崩溃。

当后端数据库在生成站点地图时出现死锁（Deadlock），服务器可能返回 200 状态码但内容为空，这种“静默失败”会导致 GSC 显示“解析成功”但“检测到的网址数为 0”。

使用分布式存储方案时，如果各节点同步延迟超过 60 秒，Googlebot 在不同 IP 节点抓取到的 Sitemap 内容不一致，会诱发“索引不匹配”的异常标记。

你在检查 GSC 报错时，可以查看“抓取统计信息”中的“按响应”分布图。

如果“确定 (200)”的比例低于 95%，说明服务器环境存在严重配置偏差。

数据分析

GSC 中的“抓取统计信息”报告提供过去 90 天内 Googlebot 访问站点的底层记录，在多子域名环境下，Googlebot 会根据各子域的服务器承载能力独立分配抓取配额。

平均响应时间是衡量服务器效率的首要指标，理想数值应保持在 200 毫秒至 600 毫秒之间。

如果该数值持续超过 1000 毫秒，Googlebot 会显著降低抓取频率，导致新发布的 Sitemap 链接长时间处于待处理状态。

抓取请求总数反映了 Google 对站点的关注度，通常大型电商或新闻站点的日均抓取请求量可达数万次。

通过分析“按响应”分布图，可以识别出服务器在处理大规模并发请求时的稳定性。

若“确定 (200)”请求占比低于 95%，则表明站点存在严重的链接失效或服务器配置偏差。

在分析“按用途”分布时，对于频繁产出新内容的子域，发现请求的占比应维持在 30% 以上，这表明 Googlebot 正在通过提交的 Sitemap 路径积极检索新 URL。

如果刷新请求占比长期处于 90% 以上，说明 Google 将大部分配额浪费在了旧页面的重复检查上，这通常是由于页面 <lastmod> 标签设置不当或内容更新过于频繁却无实质变化导致。

在多语言或跨国站点中，Googlebot 可能会从分布在全球的不同 IP 段（如美国、欧洲、亚太区节点）发起请求，检查不同地区的 CDN 边缘节点响应速度。

若某地区的“平均响应时间”曲线出现孤立峰值，说明该区域的服务器集群或节点分发策略存在延迟。

随着 Mobile-first Indexing 的全面实施，智能手机版 Googlebot 的请求量通常占总请求量的 80% 到 90%。

如果桌面版抓取量异常升高，可能预示着站点的移动端适配代码存在解析障碍，或者特定的移动端 URL 被 robots.txt 误拦截。

图片抓取工具 (Googlebot-Image) 和 视频抓取工具 的请求量与多媒体资源的收录量成正比。

在优化多子域名 Sitemap 时，需观察 XML 文件本身是否被频繁抓取。

通常 Sitemap 文件的抓取状态码应为 200 或 304（未修改），若频繁出现 404 或解析错误，说明自动化生成脚本在特定子域下运行不稳定。

针对抓取数据的波动，需要结合服务器日志进行交叉验证。

当 GSC 显示“抓取请求总量”下降时，应检查“主机状态”报告中的 DNS 查找、服务器连接和 robots.txt 提取是否正常。

这三项基础指标必须保持绿色勾选状态。

Google Search Console API 批量提交

使用 Google Search Console API v3 的 sitemaps.submit 接口可实现自动化操作。

API 每日限额通常为每个项目 100,000 次请求，单个用户每秒限额约 20 次。

针对 500 个子域名，脚本调用可在 10 秒内完成，比手动操作节省约 95% 耗时。

调用需通过 OAuth 2.0 或 Service Account 鉴权，成功后返回 HTTP 204 状态码。

鉴权与 API 配置

进入 Google Cloud Console ，在项目仪表板中，找到 API 和服务库，搜索并启用 Google Search Console API。

目前使用的版本是 v3，它通过 RESTful 架构提供服务。

在凭据管理页面，选择创建 服务账号 (Service Account) 而不是 OAuth 2.0 客户端 ID，因为服务账号适用于服务器到服务器的通信，不需要人工干预登录流程。

系统会生成一个唯一的电子邮件地址，格式通常为 [email protected] 或 [email protected]。

在创建服务账号的过程中，必须生成并下载一份 JSON 格式的私钥文件。

这份文件包含了 private_key、client_email 和 token_uri 等敏感信息。

私钥仅在创建时可下载一次，若丢失则需重新生成。

为了确保安全性，建议将此文件存储在环境变量或加密的机密管理器中，避免将其上传到公开的代码仓库。

该私钥用于构造签名请求，通过 google-auth 库自动完成 JWT（JSON Web Token）的交换，从而获取有效期为 3600 秒 的访问令牌（Access Token）。

完成 Google Cloud 侧的配置后，进入 GSC 的“设置”菜单，选择“用户和权限”，点击“添加用户”，输入上述服务账号邮箱。

对于需要批量处理多个子域名的架构，通过在域名注册商（如 Cloudflare 或 Namecheap）的 DNS 设置中添加一条 TXT 记录，可以一次性获得对 *.example.com 下所有子域名的控制权。

技术细节：在调用 sitemaps.submit 时，如果使用的是网域级资源，siteUrl 参数必须带有 sc-domain: 前缀，例如 sc-domain:example.com。如果使用的是网址前缀资源，则必须提供包含协议头的完整 URL，如 https://sub.example.com/。

批量执行

准备环境需要安装 Python 3.7 以上版本，并使用 pip 安装 google-api-python-client 和 google-auth 库。

自动化脚本的起点是构造一个包含所有子域名及其对应 Sitemap 地址的数据源，通常采用 CSV 格式，包含 site_url 和 sitemap_url 两个字段。

site_url 必须是经过验证的 GSC 资源完整路径，例如 https://sub1.example.com/，而 sitemap_url 则是该子域名下 Sitemap 文件的绝对路径。

如果管理的是 Domain Property（网域级资源），site_url 的格式应为 sc-domain:example.com。

示例 Python 代码调用逻辑：service.sitemaps().submit(siteUrl=encoded_url, feedpath=sitemap_path).execute()。在这个过程中，siteUrl 必须进行 URL 编码，例如将 https:// 转换为 https%3A%2F%2F，否则 API 会返回 400 错误。

脚本执行的第一步是加载 Service Account 的 JSON 私钥文件。

通过 service_account.Credentials.from_service_account_file 方法读取凭据，并将 Scope 设置为 https://www.googleapis.com/auth/webmasters。

初始化 build('webmasters', 'v3', credentials=creds) 后，程序进入循环处理阶段。

为了保证在大规模提交时的稳定性，建议在脚本中加入 time.sleep(0.1)，将发送频率控制在每秒 10 次请求 左右。

处理 1,000 个子域名的提交时，程序逻辑应包含一个错误捕获机制，利用 try-except 结构捕获 googleapiclient.errors.HttpError。

如果返回 HTTP 204 状态码，表示 Google 已成功接收该 Sitemap 路径；

如果返回 403 状态码，通常是因为 Service Account 邮箱未被添加为该资源的受限用户或所有者。

数据量化参考：对于一个拥有 5,000 个子域名的站点，如果每个子域名下有 2 个 Sitemap（一个基础索引，一个图片索引），总计 10,000 次 API 调用在单线程下约耗时 15 至 20 分钟。

为了应对 API 可能出现的临时性故障，建议引入 指数退避算法（Exponential Backoff）。

当遇到 500 或 503 服务器错误时，脚本不应立即停止，而是等待 1秒、2秒、4秒、8秒后重新尝试，直到达到设定的最大重试次数（通常为 5 次）。

在提交完成后，可以通过 sitemaps().list() 方法再次验证各资源的 Sitemap 状态，检查 lastCheck 和 lastDownloaded 字段的时间戳是否已更新。

权限配置细节：在 Google Search Console 后台的“设置”——“用户和权限”中，必须确保 Service Account 的邮箱地址（形如 [email protected]）拥有“完整”或“所有者”权限。如果是网域级资源，只需在主域名下添加一次权限，即可覆盖所有子域名的 API 操作权限。

对于日均更新频率较高的站点，可以将该脚本部署在 Google Cloud Functions 或 AWS Lambda 上，配合 Cloud Scheduler 实现定时触发。

例如，每隔 24 小时自动扫描数据库中的新子域名并执行 API 提交。