Sitemap生成器怎么用？它说格式正确的时候其实只查了三件事

摘要：这款生成器把六种sitemap的XML骨架拼得很规整，但它底下那条绿色的“✅ Sitemap格式正确”只查了三件事：地址是不是以http开头、条数有没有超过五万、文件有没有超过50MB。除此之外它什么都不看。我们团队实测确认：基础地址栏里的占位域名 example.com 没改，四条地址全被拼成占位站的网址，绿灯照亮；批量导入时填的 2026-07-20T14:30:00+08:00 这种协议完全合法的完整时间戳，会被界面上的日期控件静默吞掉，输出里那行 lastmod 直接消失；完全重复的两条地址原样各输出一次；图片模式还在生成谷歌2022年就已作废的标签。它是个称手的拼装台，不是校验器——这两件事得分开看。

写sitemap这件事，处在一个尴尬的位置上。说它难吧，标签就那么几个，标准文档一页纸能读完；说它简单吧，真正手写过的人都知道，出问题的从来不是标签本身，而是那些看不见的地方——日期格式错了一位、地址少了个斜杠、上线三个月才发现整个文件根本没被读进去。

于是就有了各种在线生成器。它们的价值很实在：把重复的括号尖角拼装工作接过去，让你专心想清楚哪些页面该进、哪些不该进。但用生成器有个前提，你得知道它的手伸到哪儿为止。这篇文章要做的就是把这条线画清楚。

这个生成器到底在哪儿运行？

先说结论：全程在你自己的浏览器里，一个字节都不往服务器传。

页面加载完成后，选类型、填地址、点生成，这一整条链路都是本机的脚本在跑。最终那份XML是在你的内存里拼出来的，复制按钮读的是内存里的字符串，下载按钮把同一个字符串包成文件塞给浏览器。中间没有任何一步经过网络。

这一点对不少人是刚需。做迁移方案的时候，手里那份地址清单往往是还没上线的新站结构，或者干脆是客户的内部路径表。这类东西粘进一个会上传的在线工具，心里总归不踏实。这款不用担心，断网都能正常用——你可以把网线拔了试试，功能一点不少。

六种类型分别该在什么时候选？

工具首屏给了六张卡片，选错类型后面全白搭，所以先把它们对应的场景说清楚。

最容易被误选的是新闻类型。它不是“我站上有新闻栏目就该用”，而是“我这个站已经被谷歌新闻收录了才用”，而且谷歌只看最近两天的内容。普通企业站的博客栏目用标准类型就够了，套上新闻命名空间不会带来任何额外好处，只会让文件多出一堆没人读的标签。

索引类型的定位也常被搞混。它不是“更高级的sitemap”，它是个目录页——里面只放别的sitemap文件的地址，不放页面地址。站点没到需要拆分的规模，根本不需要它。

那句“Sitemap格式正确”到底验了什么？

这是全文最要紧的一段。生成完成后底下会出现一条绿色横幅，写着“✅ Sitemap格式正确，共N个URL，可直接使用”。很多人看到这行字就放心了。

但把生成逻辑逐行看下来，这条绿灯背后的判断只有三条半：

• 每条地址是不是以 http 或 https 开头——不是就提示“不是绝对路径”
• 条数有没有超过五万
• 整个文件有没有超过50MB
• 只有新闻类型才多查一条：出版物名称填了没有

就这些。它不查地址能不能打开，不查有没有重复，不查是不是同一个站的，不查日期格式，不查页面是不是被 noindex 挡着，更不查这些页面值不值得被收录。

所以那句话的准确含义应该翻译成：这份文件的XML骨架拼完整了，语法上能被解析。至于内容对不对，它没有立场发言。把它当成“XML拼装完成”的回执就对了，当成“这份sitemap可以上线”的体检报告就危险了。

为什么占位域名会被绿灯放行？

这是上一节那条规则最直接的后果，也是我们团队实测里最容易中招的一处。

工具的“网站基础URL”输入框默认预填了 https://example.com。批量导入时，任何不以 http 开头的行都会被自动补上这个前缀。而绝大多数人手里的清单，恰恰就是 /products/hat 这种从后台导出来的相对路径。

我们把四行相对路径粘进批量框，基础地址栏保持默认没动，点生成，得到的是这样一份文件：

<url>
  <loc>https://example.com/products/hat</loc>
  <changefreq>weekly</changefreq>
  <priority>0.5</priority>
</url>

底下那行绿字写着：“✅ Sitemap格式正确，共4个URL，可直接使用。”

它没说错——按它那三条规则，https://example.com/products/hat 确实是个以http开头的绝对地址，条数也没超标。规则本身自洽，只是这份文件里没有一个地址属于你的站。

更麻烦的是这种错误在下游很难被发现。文件上传上去，谷歌读到的是一份指向别人域名的清单，按sitemaps.org的协议规定，同一份sitemap里的所有地址必须来自同一个主机，跨主机的条目会被直接忽略。搜索控制台里通常表现为“已发现的网址：0”或者大批地址状态异常，而你盯着本地那份文件怎么看都觉得格式没问题。

所以养成一个习惯：点生成之前，先回头看一眼基础地址栏。这个动作花两秒，能省掉半天的排查。

填好的日期为什么在输出里不见了？

这一处的因果链有点绕，但值得完整讲一遍，因为它暴露的是工具设计上的一个结构性问题。

批量导入支持的格式是四列：地址、优先级、更新频率、最后修改时间。我们照着填了三行，日期分别用三种写法：

• 2026-07-20——标准的年月日
• 2026年7月20日——中文写法，明显不合规
• 2026-07-20T14:30:00+08:00——带时分秒和时区，协议完全支持

点导入之后，我们先看工具内存里存了什么，三行的日期字段原封不动全都在。再看界面上渲染出来的三个日期输入框，只有第一行显示着 2026-07-20，另外两个是空的。最后生成的XML里，只有第一条有 lastmod，另外两条那一行整个消失了。

原因在于界面用的是浏览器原生的日期控件。这类控件只接受严格的年月日格式，塞给它任何别的东西，它会静默把值置为空，不报错也不提示。而生成的时候，工具会重新从界面上把值读回内存——于是那两个被清空的格子，把内存里原本好好的数据覆盖掉了。

数据在内存里是完好的，是路过界面的时候被抹掉的。这种“中间环节偷偷改数据”的问题最难查，因为出错的地方和你操作的地方隔着好几层。

第二行填中文日期被清掉，这个不冤，本来就不合规。但第三行冤得很——2026-07-20T14:30:00+08:00 是W3C日期时间规范里明确定义的合法写法，sitemaps.org的协议文档给出的示例正是这种带时区的完整格式。工具支持的输入范围比协议窄，还不告诉你它做了裁剪。

这件事的实际影响要分场景看。日常内容站每天更新一次，精确到天完全够用，损失不大。但如果你做的是资讯类、电商促销类这种一天多次更新的站，时间粒度是有价值的信号——谷歌明确说过，只要 lastmod 的值持续准确、经得起和页面实际修改时间的比对，它就会采用。粒度被砍到天，这个信号就钝了一截。

绕开的办法很直接：生成完之后打开文件，把需要精确时间的那几条手动补上时分秒。或者干脆别用界面填日期，生成骨架之后用脚本批量写入。工具的定位本来就是拼装台，最后一道精修交给自己更靠谱。

优先级和更新频率还值得填吗？

先给结论：谷歌的官方文档里写得非常直白——“Google ignores <priority> and <changefreq> values.”，直译过来就是这两个值它一概不看。

而这款工具的默认行为，是给每一条地址都无条件加上这两行。优先级默认 0.5，更新频率默认 weekly，你什么都不设，它们照样出现在每个 url 块里。

算笔账：一份两万条地址的sitemap，这两行凑起来大约多出一点几兆的体积。文件本身有50MB的上限，一两兆看着不多，但如果你的站正好卡在需要拆分的临界点上，这些谁都不读的字符可能就是压垮骆驼的那把稻草。

更要紧的是心理成本。见过太多团队开会认真讨论“产品页给0.8还是0.9”，讨论半天，讨论出来的东西谷歌一眼都不看。这个时间拿去清理死链、补内链，回报率高得多。

那要不要删？如果你的sitemap是脚本生成的，顺手去掉这两行，文件更干净。如果是这款工具生成的，把“默认更新频率”那个下拉框选到“不设置”，优先级留着也无所谓。注意这两个字段本身不是错误，协议里它们合法存在，只是没有实际效果，属于无害冗余。

顺带说一句，别的搜索引擎未必和谷歌一个态度。协议原文对 priority 的措辞是“给所有页面都设高优先级不太可能帮到你”，意思是它在同一个站内部做相对排序时或许有点参考价值，但绝不是给你调排名的旋钮。

图片模式里的标题字段为什么该留空？

这一处是工具跟不上标准变化留下的遗迹。

选图片类型后，每条地址下面可以挂若干张图，每张图有两个输入框：图片地址、图片标题。填了标题，输出里就会多出一行 <image:title>。

问题是，谷歌在2022年5月发过一篇公告，清理了一批sitemap扩展标签，image:title 正在其中，同批被清理的还有 image:caption、image:geo_location、image:license。公告说得很清楚，2022年8月6日之后这些标签对索引和搜索功能不再有任何作用。现在的图片sitemap文档里，实际起作用的只剩 image:loc 这一个——就是图片地址本身。

所以那个标题输入框，填了不会错，但也不会有用。工具还专门给它留了个位置，容易让人误以为这是个该认真填的字段，甚至有人会为此专门整理一份图片标题表。那就真的白忙了。

正确的做法是：图片模式下只填图片地址，标题留空。想让谷歌理解图片内容，力气该花在页面本身的 alt 属性、图片周围的文字、以及文件名上，那些才是现在真正被读的信号。

另外补一条容量限制：官方文档规定每个 url 块最多挂1000张图。工具不拦，超了它照生成，但超出的部分不会被处理。产品图库类站点做图片sitemap时留意一下这个数。

重复地址和跨站地址，工具为什么不拦？

因为那三条验证规则里没有这两项。我们做过一次针对性验证：把同一个地址 /products/hat 在批量框里粘两遍，中间夹一条别的地址，再加一条完全不同域名的地址。

生成结果里，/products/hat 老老实实出现了两次，两个 url 块内容一模一样。那条外域地址也原样收下。绿灯亮着，统计写着“共4个URL”。

重复条目的实际危害有限，搜索引擎读到重复地址会自己合并，不会因此惩罚你。但它是个信号——说明你的清单来源有问题，可能是两个导出脚本的结果直接拼接了，那往往意味着还有别的更严重的重叠没被发现。这种时候文件本身能跑，上游的数据流程才是该修的地方。

跨站地址的问题要严重得多。协议原文规定“a Sitemap里的所有地址必须来自同一个主机”，放在 example.com 根目录的文件，只能列 example.com 下面的地址。列了别人的，那些条目直接不算数。

这条最常见的踩法是多语言站。有人把 en.example.com、de.example.com 的地址一股脑塞进主站的sitemap里，觉得反正都是自家的。从协议角度看，子域名就是不同主机，这份文件里只有主站那部分有效。正确做法是每个子域各自维护自己的文件，再用索引类型串起来——但索引文件同样有位置要求，它引用的子文件必须和它在同一个站点，且在同级或更下层的目录里。

新闻模式漏检了哪个必填项？

新闻类型是六种里唯一多做了一条校验的：出版物名称没填会警告。但它漏掉了另一个同样必填的字段。

谷歌的新闻sitemap文档列出的必填标签有六个：news:news、news:publication、news:name、news:language、news:publication_date、news:title。工具只盯住了 news:name。

我们实测生成了一条没填标题的新闻条目，输出是这样：

<news:publication_date>2026-07-20</news:publication_date>
<news:title></news:title>

一个空的必填标签，安安静静地待在那儿。底下依然是“✅ Sitemap格式正确”。这份文件提交上去，谷歌新闻侧会把这些条目判为无效，而你手里那份体检报告是全绿的。

还有个小瑕疵：新闻类型的输出里同样带着 changefreq 和 priority。这两个字段在新闻sitemap的规范里根本不存在，属于纯粹的冗余。不影响解析，但不干净。

至于日期粒度，新闻模式这里反倒不用太担心——谷歌的文档明确说完整年月日和带时区的完整时间戳两种都接受。虽然对时效性极强的新闻来说，带上准确的发布时刻显然更合适。

多语言模式反而是这款工具做得最对的地方？

讲了这么多毛病，得说一处它做得漂亮的。

选多语言类型时，工具会给每条地址挂上若干个 xhtml:link 标注。输出的结构是这样的：外层有完整的 urlset 外壳，头部声明了 xmlns:xhtml 命名空间，每一个语言版本各占一个独立的 url 块，块里列出这一组的全部语言标注。

这个结构完全符合谷歌的要求。官方文档的原话是“为每个网址创建一个单独的 url 元素”，并且“每个 url 元素都必须有子元素列出每一个替代版本，包括它自己”。工具的多语言模式是照着这个来的。

之所以要特意点出来，是因为同一个站上的另一款专门做hreflang的工具，在这件事上恰恰做反了——它只吐出一个 url 块。同样一件事，两款工具一对一错，具体的对比我们在hreflang生成器那篇实测里拆得很细，做多语言站的话建议连着看。

不过多语言模式有个操作上的限制：语言代码得手动一个个填，条目一多相当费手。语言版本超过三四个的站，还是脚本更省事。

生成之后还要做什么才算数？

文件下载下来只是第一步，剩下的事工具帮不了你，但每一步都不能省。

第一，放对位置。一般传到网站根目录。位置决定了这份文件的管辖范围——放在根目录才能管整个站，放在子目录里就只能管那个目录及以下。

第二，在 robots.txt 里声明。加一行 Sitemap: 后面跟完整地址。这一行是给所有爬虫看的通用入口，不限于某一家搜索引擎。

第三，去搜索控制台提交。提交之后过几天回来看“已发现的网址”数量，这个数字和你文件里的条数对不对得上，是判断文件有没有被正确读取的第一手依据。

第四，用真实地址抽查。从文件里随机挑几条，在浏览器里打开，确认没有404、没有跳转、没有被 noindex 挡着。sitemap的作用是告诉搜索引擎“这些页面我希望你收”，如果里面混着一堆不该收的页面，等于在给自己制造噪音。

这最后一步最容易被跳过，也最能发现问题。Sitemap提取器可以把现成的文件反向解析成地址清单，配合死链检测跑一遍，比人眼一条条看快得多。

控制台里报的那几种错，分别对应什么？

文件提交上去之后，真正的反馈来自搜索控制台。那几条错误提示措辞都很克制，翻译成人话对照着看，排查会快很多。

这张表里最值得琢磨的是最后一行。“已发现但未收录”是最常见也最容易被误解的状态，很多人一看到它就回去反复调整sitemap——加优先级、改更新频率、重新提交，折腾一圈毫无变化。

因为这个状态的含义是：地址我收到了，页面我也看过了，但我暂时不打算收。原因在页面这一侧，可能是内容太薄、可能是和站内别的页面重复度太高、也可能是整站的抓取配额有限先紧着重要页面。sitemap已经把它的活干完了，再怎么调都是隔靴搔痒。

另一个容易看错的是提交后的等待期。刚提交完就去刷报告，看到一片空白很正常，读取和统计都需要时间，通常一两天才有像样的数据。这期间反复重新提交没有任何加速作用，反而容易把自己搞糊涂——分不清看到的是哪一次提交的结果。

还有个提示容易让人虚惊一场：“Sitemap中的网址被robots.txt屏蔽”。这条是明确的自相矛盾信号——一份文件在说请来抓，另一份文件在说不许抓。通常是robots里某条规则写得太宽，误伤了一整个目录。这种时候改robots，别改sitemap。

什么时候该从生成器换成脚本？

这款工具适合的场景很清楚：手工维护几十到几百条地址、需要一份规整的骨架、或者临时验证某种sitemap长什么样。超出这个范围就该换工具了。

下面这几种情况，建议直接上脚本或者插件：

• 条数上千。手工填不现实，批量导入也得先有清单，那清单本身就得脚本生成。
• 需要定期更新。sitemap的价值在于反映当前站点状态，每周手动重生成一遍不现实，该做成定时任务。
• 需要真实的修改时间。准确的 lastmod 只能从数据库或者文件系统里取，手填的日期本质上是编的，而编造的更新时间被识破之后，这个字段就彻底失去作用了。
• 需要按规则筛选。比如排除掉库存为零的商品、排除掉标记了 noindex 的页面，这类判断得贴着业务数据做。

做定时任务这块，配合cron表达式生成器把重生成挂到服务器上，是最省心的做法。保哥经手过的站里，凡是sitemap出问题的，十有八九是因为它是某年某月手动传上去之后就再没动过——文件还在，内容早就和站点对不上了。

还有个小优化顺手可以做：文件传上去之前先用gzip压一下。协议是允许提交压缩版本的，五万条地址的文件压完通常只剩十分之一左右，爬虫拉取更快，你的带宽也省。注意50MB的上限算的是解压后的大小，别指望靠压缩绕过限制。

说到底，这类工具的正确用法是把它当成一副趁手的镊子，而不是一台自动化流水线。它帮你把最枯燥的那部分——记住每个标签叫什么、括号该怎么闭合——接过去，让你能把注意力放在真正需要判断的地方：哪些页面值得推荐给搜索引擎，那份清单的来源可不可靠，以及上线之后怎么确认它真的在干活。这三件事，任何生成器都替不了你。

视频模式为什么最容易生成出空结果？

六种类型里，视频是最容易白忙一场的一个，原因藏在一行判断里。

每条地址下面可以挂视频，一个视频有五个输入框：缩略图地址、标题、描述、视频文件地址、播放器地址。看起来都是选填，实际上前两个是硬门槛——缩略图和标题只要缺了任意一个，这条视频会被整条跳过，一声不吭。

这意味着什么？你认认真真填了视频文件地址、播放器地址、时长，唯独缩略图那栏因为一时找不到图先空着，打算回头补。点生成之后，这条视频在输出里完全不存在。而统计栏里的“视频数”也跟着变成0，绿灯照亮，说格式正确。

这种静默跳过比报错难受得多。报错至少告诉你哪儿不对，静默跳过让你以为活干完了。所以视频模式有个操作纪律：填之前先把缩略图地址备齐，这一栏不是可选项，是入场券。

生成之后建议数一下统计栏里的视频数，和你实际填的条数对不对得上。对不上，就回去挨个检查缩略图和标题这两栏。这个数字是工具唯一透露给你的线索。

索引类型什么时候才真的需要？

前面提过索引不是“更高级的sitemap”，这里展开说说什么时候该动用它。

触发条件只有一个：单个文件装不下了。协议给的上限是五万条地址或者50MB，哪个先到算哪个。没到这条线，一个文件就够，拆开反而增加维护成本。

到线之后的拆法有讲究。最省事的是按数量硬切，一万条一个文件。但更聪明的做法是按内容类型拆——文章一份、产品一份、分类页一份、静态页一份。这样拆的好处是诊断方便：搜索控制台里每份文件的收录情况是分开统计的，哪类页面出了问题一眼就能看出来，而不是面对一个混着所有页面的大文件干瞪眼。

索引文件本身也有限制。谷歌的文档写明，一个索引文件最多容纳五万个条目，每个站点最多提交500个索引文件。这个规模远超绝大多数站点的需要，真正会卡住的是另外两条：被引用的子文件必须和索引文件在同一个站点，而且必须位于同级或者更下层的目录。

最后一条经常被忽略。把索引文件放在根目录，子文件也放根目录或者子目录里，这样是对的。反过来把索引塞进某个子目录，却去引用根目录下的文件，就越界了。

手动填和批量导入该怎么选？

工具提供了两种录入方式，各有各的适用面，混着用效率最高。

手动模式适合条数少、每条都要单独配置的情况。比如你只有十来个核心页面，想给每个页面单独挂图片或者视频信息，手动一条条填最直观。

批量模式接受多行文本，每行一条，用英文逗号分隔四个字段：地址、优先级、更新频率、最后修改时间。后三个都可以留空，留空就用全局默认值。

批量模式有两个细节值得记住。第一，以 # 开头的行会被当注释跳过，可以用来给清单分段做标记。第二，不以 http 开头的行会被自动补上基础地址栏里的前缀——这个特性是把双刃剑，用好了省事，忘了改前缀就是前面讲过的占位域名事故。

还有个坑要提醒：分隔符必须是英文逗号。从表格软件里复制出来的数据，分隔符可能是制表符，粘进去之后整行会被当成一个地址处理。稳妥的做法是先粘到纯文本编辑器里看一眼，确认分隔符对了再往工具里放。

批量导入之后，工具会把内容转成手动模式的表单，你可以继续逐条微调。这个设计挺贴心——先批量铺底，再针对重点页面精修，是最省力的动线。

哪些页面该进sitemap，哪些不该进？

这是全篇唯一一件工具完全帮不上忙、却最影响结果的事。文件拼得再规整，清单选错了照样白搭。

判断标准其实只有一条：这个页面，你希望它出现在搜索结果里吗？希望，就放进去；不希望或者无所谓，就别放。

按这条标准过一遍，下面这些通常不该进：

• 带 noindex 的页面。一边在sitemap里说“请收录”，一边在页面上说“别收录”，信号自相矛盾，纯属给自己制造噪音。
• 被canonical指向别处的页面。你已经声明了它不是正主，就别再单独推荐它。
• 分页列表的第二页往后。这类页面内容重复度高、独立价值低，放进去稀释整体质量。
• 搜索结果页、筛选组合页。参数一变就是新地址，能生成无穷多个，放进去等于自己给自己造重复内容。
• 登录页、购物车、后台入口。这些页面进搜索结果对谁都没好处。
• 已经301跳走的旧地址。放进去只会让爬虫多跑一趟冤枉路。

反过来，该进但经常被漏掉的：新上线还没有任何外链的页面、藏在多层筛选后面爬虫很难走到的深层商品页、以及刚做完内容更新希望被重新抓取的老文章。sitemap对这三类页面的帮助最实在——它的本职就是给那些光靠链接爬不到的页面开一条直通车。

把这条标准记牢，比纠结优先级填多少有用一百倍。一份两百条精挑细选的清单，价值远高于一份两万条什么都往里塞的清单。

地址里有中文或者问号，会不会出问题？

这一处工具做对了一半，另一半留给了你。

先说做对的。XML里有五个字符不能直接写，必须换成实体写法，其中最常见的是 &。带参数的地址经常出现它，比如筛选页的 ?color=red&size=l。工具在输出前会把这五个字符统一转义，这一步是标准要求的，它老老实实做了。所以带查询参数的地址直接粘进去，不会破坏文件结构。

没做的那一半是百分号编码。协议原文要求，sitemap里的所有地址都应当经过转义编码。按这个要求，中文路径 /产品/帽子 应该写成一长串以百分号开头的编码。工具是原样输出的，中文进去，中文出来。

实际影响要说得公道些：现在主流的解析器对UTF-8原文的容忍度很高，中文路径的sitemap在多数情况下能被正常读取，不至于直接报废。但严格按标准来说这不合规，遇上比较老或者比较轴的解析器就可能出岔子。

稳妥的做法是从源头绕开。中文路径本身在跨系统传递时问题就不少——服务器日志、分析工具、外部链接里的显示都可能乱套。做URL结构规划的时候直接用拼音或者英文，这个麻烦从一开始就不存在。已经用了中文路径的站，生成之后手动做一遍编码转换。

已经在用CMS插件了，还需要这个工具吗？

大多数情况下不需要，这话得说在前头。

主流建站系统基本都有成熟的sitemap插件，它们的优势是手工生成永远比不了的：内容一发布文件自动更新、lastmod 直接取数据库里的真实修改时间、被标记为不索引的页面自动排除、条数超标自动拆分。这几件事每一件手工做都很痛苦。

那这类手工生成器的位置在哪儿？在插件覆盖不到的缝隙里：

• 纯静态站。没有后台，也就没有插件可装，手工生成是最直接的选择。
• 临时补充清单。插件生成的文件里漏了某一批页面，单独做一份小文件补上，比改插件配置快。
• 验证格式长什么样。想确认某种特殊类型的结构，用它拼一份出来看看，比翻文档直观。
• 接手别人的站做诊断。先手工拼一份标准结构，和线上那份对比着看，差异在哪儿一目了然。

还有一种情况值得单说：插件装了，但生成出来的文件明显不对。这时候先别急着换插件，用手工工具拼一份最小可用的文件传上去，看看搜索控制台能不能正常读取。这一步能快速分清是插件的问题还是服务器的问题——如果手工文件也读不了，那就是服务器把爬虫挡在门外，换十个插件也没用。

提交之后怎么判断它真的起作用了？

文件传上去、控制台提交完，事情还没结束。至少要过三关才能确认这份文件在正常工作。

第一关看读取状态。提交后过一两天，搜索控制台的sitemap报告里会显示状态。显示“成功”说明文件能被正常解析；显示“无法读取”通常是地址填错、文件返回了404，或者服务器把爬虫挡在了外面。

第二关看已发现数量。这个数字应该和你文件里的条数基本对得上。差得离谱就说明有问题——差太多可能是跨主机的条目被忽略了，也可能是文件被截断。这一关最能暴露前面讲的占位域名事故。

第三关看收录进展。已发现不等于已收录，这中间隔着抓取和索引两道工序，需要时间。但如果过了几周，已发现的数量涨着而已收录的数量纹丝不动，那问题多半不在sitemap，而在页面本身——内容太薄、和别的页面重复度太高、或者被别的规则挡住了。

这三关走下来，才算真正确认这份文件在干活。整个过程里工具只参与了最开始的拼装，剩下的都得自己盯。这也是为什么开头要把那句“格式正确”的含义讲清楚——它是起点的回执，不是终点的凭证。

常见问题解答

生成的文件底下显示“格式正确”，是不是就可以直接上线了？

不能等同。这句话的实际含义是XML骨架拼完整了，具体只查了三件事：每条地址是不是以http开头、条数有没有超过五万、文件有没有超过50MB。它不查地址能不能打开、有没有重复、是不是同一个站的、页面是不是被noindex挡着。最典型的翻车是基础地址栏留着默认的占位域名没改，四条地址全被拼成别人家的网址，绿灯照样亮。上线前请自己抽查几条地址。

我在批量导入时填了日期，为什么输出里没有lastmod？

因为界面上的日期输入框是浏览器原生控件，只接受严格的年月日格式。你填的如果是中文日期，或者是带时分秒时区的完整时间戳，控件会静默把它清空，然后生成时工具又从界面把这个空值读回去，覆盖掉内存里原本好好的数据。带时区的完整时间戳其实是协议明确支持的合法格式，属于工具的输入范围比标准窄。解决办法是生成后手动补，或者干脆用脚本写。

优先级和更新频率到底要不要填？

谷歌官方文档写得很明白，这两个值它一概忽略。而工具默认给每条地址都加上，优先级0.5、更新频率weekly，你不设它也加。想去掉的话，把“默认更新频率”下拉框选到“不设置”即可。它们不是错误，协议里合法存在，只是没有实际效果。别再为产品页该给0.8还是0.9开会了，那个时间拿去清死链更值。

图片模式里的图片标题要不要认真填？

不用填。谷歌2022年5月发公告清理了一批sitemap扩展标签，image:title就在其中，同批还有image:caption等几个，2022年8月6日之后彻底不起作用。现在图片sitemap里真正有效的只剩图片地址一个字段。工具还留着这个输入框属于历史遗留。想让谷歌理解图片，力气该花在alt属性和图片周边文字上。

可以把多个子域名的地址放进同一份sitemap吗？

不行，工具不拦但协议不认。sitemaps.org明确规定同一份文件里的所有地址必须来自同一个主机，放在主站根目录的文件只能列主站的地址。子域名算不同主机，混进去的那部分直接不算数。多语言站常踩这个坑。正确做法是每个子域各自维护，再用索引类型串起来，而索引文件引用的子文件也必须在同一站点、同级或更下层目录。

新闻类型除了出版物名称，还有什么必填项容易漏？

文章标题。谷歌的新闻sitemap必填标签有六个，工具只校验了出版物名称这一个。标题不填，输出里会出现一个空的news:title标签，底下依然显示格式正确，但提交上去这些条目会被判无效。另外新闻类型的输出里还带着changefreq和priority，这两个在新闻规范里根本不存在，属于冗余，不影响解析但不干净。

我的地址清单会被上传到服务器吗？

不会。选类型、拼装、生成、下载全部在你自己的浏览器里完成，页面没有任何一步把清单发往后端。你可以断网测试，功能完全正常。整理还没上线的新站结构，或者处理客户的内部路径表，这一点可以放心。

权威参考资料

• Sitemaps XML协议——单文件五万条地址与50MB的上限出处，也是“所有地址必须来自同一主机”这条规定的原文，判断跨域条目是否有效时以它为准。
• 谷歌构建与提交Sitemap指南——“Google ignores priority and changefreq values”的原始表述在这里，同时说明了lastmod只有在持续准确、经得起比对时才会被采用。
• 谷歌图片Sitemap文档——列出当前唯一有效的image:loc，并注明image:title、image:caption等标签已被移除，另有每个url块最多1000张图的限制。
• W3C日期时间格式规范——sitemap里lastmod所遵循的格式定义，从只写年份到带毫秒和时区共六档粒度，工具的日期控件只覆盖了其中的完整日期这一档。
• 谷歌新闻Sitemap规范——六个必填标签的完整清单，其中news:title正是工具漏检的那一个，同时说明发布时间接受完整日期与带时区时间戳两种写法。
• 谷歌Sitemap索引文件说明——索引文件最多容纳五万个loc、每站最多提交500个索引文件，以及被引用的子文件必须与索引同站且不高于其目录层级的要求。