不少站点的 URL 早就不止五萬條，提交 sitemap 时才發現文件生成失敗、上传被拒，或者报告里只识別了一部分。問题往往不在搜尋引擎，而在 sitemap 的格式硬性限制，以及事先没有想清楚“哪些 URL 值得放進去”。
先记住三條硬性上限
- 單個 sitemap 文件最多包含 50,000 個 URL。
- 單個文件未压缩不超過 50MB，即使上传 .gz 压缩包，也按解压後的体积計算。
- 單個 sitemap 索引文件最多列出 50,000 個子文件，並且索引文件不支持再嵌套索引文件。
超過其中任意一條，文件就可能失效或被截断。URL 數量到几十萬时，分片基本是必選項。
分片怎么切，比切多少更重要
分片不是把列表按每五萬條砍一刀就完事。文件怎么划分，决定了以後排查問题的效率。
- 按目錄或内容類型：文章、商品、标簽頁各用一個文件，某一類收錄異常时能立刻定位。
- 按更新時間：把近期有改動的頁面單獨成片，便于观察更新是否带来重新抓取。
- 按語言或地区：多語言站点按子目錄划分，避免混在一起难以核對。
- 按业務優先級：真正希望被索引的栏目單獨放，次要頁面另作處理。
不推荐“每五萬條随机切一刀”的切法，文件之間没有语义差別，出問题时只能整批重跑。
索引文件怎么寫
分片之後需要一個 sitemap 索引文件指向各個子文件，内容形如 sitemap-article-1.xml、sitemap-article-2.xml 的列表。有几点常被忽略：
- 索引里的地址必须是完整 URL，並與子文件的真實路径一致，包括是否带 .gz 後缀。
- 子文件必须與索引文件處于同級或更下一級目錄，不能指向上級目錄中的頁面。
- 索引文件不能再套索引文件，想“分层管理”的做法在這里行不通。
- 在 robots.txt 里可以寫多行 Sitemap，但一般只需寫索引文件這一條，不必把每個子文件都列出来。
哪些 URL 不该放進 sitemap
分片只解决“放不下”，解决不了“放错了”。下面這些地址放進 sitemap，通常只會稀释信号、干扰自己的判断：
- 返回 301 或 302 的地址，應直接寫跳轉後的目标地址。
- 被 robots.txt 屏蔽或带 noindex 的頁面。
- canonical 指向其他頁面的重复地址，只保留規范版本。
- 返回 404 或 410 的歷史路径，以及由參數组合生成的大量篩選頁。
- 需要登入才能訪問、站内搜尋结果等對搜尋引擎没有意义的頁面。
sitemap 只解决“被發現”，不解决“被收錄”。把不该索引的地址塞進去，反而會让人誤判真實的收錄情况。
分片之後的自查顺序
- 在浏览器中直接打開索引文件和每個子文件，確認返回 200、無需登入、没有被防火墙拦截。
- 检查文件是否声明了正确的命名空間與编碼，带中文的 URL 是否做了規范的百分号编碼。
- 抽查若干條 URL，確認返回 200 且 canonical 指向自身，而不是指向別處。
- 對照 sitemap 报告里“已提交”與“已编入索引”的數量差距，再结合日誌看抓取频次是否匹配。
- 如果某一分片的收錄表現明顯低于其他分片，先检查该分片里是否混入了上面提到的不该提交的 URL。
還有一点：文件里的 lastmod 不要每天统一刷成当天。全站時間都變成同一天，相当于告诉搜尋引擎“所有頁面每天都改了”，更新信号會失去參考價值。只在頁面内容确實變動时，更新對應條目的時間。
几個實用的小建议
- 用脚本自動拆分並生成文件，不要手工维護一堆 XML。
- 命名保持規律，例如 sitemap-{類型}-{序号}.xml，方便和日誌、报告對照。
- 子文件不必用满 50,000 條上限，几千到一两萬條一個文件，重跑成本更低。
- 刪除或合並分片时，同步更新索引文件，別留下指向已刪除文件的條目。
把分片结构和 URL 取舍理清楚之後，就能比較快地判断：收錄不理想究竟是 sitemap 没被正确處理，還是這些頁面本身就不该或暂时不该進入索引。