XML Sitemap是交给搜索引擎的网址清单。WordPress网站通常可以由系统或SEO插件自动生成：找到实际入口，确认清单里的网址正确、文件能够读取，再提交到Search Console。以后发布和修改文章，由同一个生成工具维护清单，不必每天重新上传一份。
最容易误判的是“提交成功”。它只能说明站点地图得到相应处理，不能证明其中每篇文章已经收录。遇到问题时，把检查拆成三层会清楚很多：索引文件能否打开、子地图能否解析、正文页面是否符合收录条件。
先找到你的网站真正使用的地图
在WordPress后台确认当前启用的SEO插件，然后从它的设置中打开地图。不要看见别人使用某个文件名，就把同样的路径填进自己的Search Console。
使用Yoast SEO时，当前官方路径是“Yoast SEO → Settings → Site features”，在Technical SEO区域启用XML sitemaps，再点查看地图。由它生成的索引和子地图会随内容增删自动更新。中文界面的翻译可能不同，以功能名为准。Yoast操作说明
没有SEO插件接管时，可以检查WordPress原生入口https://你的域名/wp-sitemap.xml。原生XML地图从WordPress 5.5开始提供；这不代表所有网站现在都保留这个入口，插件和站点设置可以改变它。WordPress原生站点地图说明
打开后，先看看文件结构及loc指向什么。sitemapindex里列的是子地图入口，urlset里列的是网页网址；不能只凭文件名猜类型。点进文章对应的子地图，才会看到文章网址。浏览器可能将XML显示成漂亮的表格，也可能只显示原始文本，这两种外观都不能单独说明文件有错。
把正在使用的生成工具、索引地址和文章子地图地址记下来。如果发现几套工具各生成一份清单，先比较内容及维护者，再统一维护入口。不要未确认来源就删除服务器上的文件，否则可能删掉当前仍在使用的地图。
如果网站还有一页供访客浏览的“网站地图”或“全部文章”，它属于HTML导航页面，可以帮助人和爬虫通过链接找内容，但不等于XML地图索引。两种入口可以同时存在，各有用途。XML也不能代替文章中心、栏目和正文内链：清单给出网址，不会自动补全读者从主题到文章的阅读关系。
对内容少、链接清楚的小站，地图不一定是发现页面的唯一方式；文章多、更新频繁或存在难以通过正常链接发现的页面时，清晰的自动地图更有维护价值。孤立页面仍应补上合理入口，不能仅因已经列入XML就当作站点结构完善。
清单里应该放哪些网址
这份清单适合列出你希望Google索引的首选网址。已永久跳转的旧地址、明确不需要索引的页面、预览网址和无内容的错误页，不应成为日常维护的目标清单。Google也建议提交首选规范网址。Google站点地图规范
例如，同一篇文章能通过无参数地址和带追踪参数的地址访问，你希望搜索结果展示前者，地图就应列出前者。这里的工作是核对清单与网站意图是否一致，不是把所有访问过的网址全部收进去。
可以抽查三类页面：刚发布的文章、最近修改的旧文，以及明确不应收录的页面。前两类应出现在相应清单中，后一类应按你的索引设置被排除。假如整类文章都缺失，应先查文章类型和SEO插件的索引设置；只缺一篇，再查它是否已公开发布、是否设为noindex、是否被单独排除。
定时文章尚未公开时，不要为了提前进入地图把预览链接填进去。等文章公开后再查最终地址。地图之外，重要文章也应当从栏目、相关文章或正文链接中被找到；这部分可以结合站内链接的安排方法一起维护。
日常内容更新可以沿着同一篇文章的状态核对，避免把后台“保存了”当成公开页面已经更新。以下是虚构的内容站维护记录：
| 内容状态 | 地图里的预期 | 还要确认什么 |
|---|---|---|
| 明天发布的定时文章 | 暂不纳入预览URL | 公开时间与最终固定链接已确认 |
| 已到发布时间且公开可访问 | 纳入最终首选地址 | 定时任务确实执行，页面没有登录限制或意外noindex |
| 旧文正文已实质更新 | URL保持稳定，合理更新lastmod | 公共正文与地图缓存都已更新，日期不是每天自动刷新 |
| 旧文合并到承接内容的新页 | 日常地图使用新首选地址 | 旧地址的跳转与新页用途一致 |
| 暂不希望索引的空归档 | 按既定索引策略排除 | 页面层设置与地图一致；不只是从清单里删除 |
例如，文章在后台仍显示“已错过定时发布”，它没有进入公开地图，可能只是发布任务还未执行，先修定时任务。若前台已经公开而文章子地图仍没有，再查生成器排除规则和缓存。两个现象都叫“新文没出现”，实际应该处理的环节不同。
XML里真正需要看懂的内容
页面清单与修改日期
下面是一份教学用的简化地图，示例域名不是要提交的真实网站：
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/guide/</loc>
<lastmod>2026-09-19</lastmod>
</url>
</urlset>
loc是完整页面地址。lastmod可以表示页面最近一次有意义的修改时间；没有可靠更新时间时，不必为了看起来新鲜，给所有旧文每天写上当天日期。Google不会使用priority和changefreq决定抓取，因此反复调整这两个值通常不能解决收录问题。单份地图不得超过50,000个网址或解压后50MB，超过时再拆分。Google对字段与文件规模的说明
普通内容站通常不需要手写XML。更实用的检查是：新文章的网址是否完整，旧网址是否还在，修改后日期是否合理。即使只有几百篇文章，插件分成多个子地图也不代表异常；不同实现可以自行控制每份文件的大小。
索引引用与XML转义
如果上面那份文件是文章子地图，外层索引可以像下面这样引用它。以下代码表达文件关系，不是让WordPress站再创建一套手写地图：
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/post-sitemap.xml</loc>
</sitemap>
</sitemapindex>
验证时沿着这条关系走：索引中的post-sitemap.xml能够获取，里面的guide/是预期文章，打开后正文正确。不能把文章URL直接放进sitemapindex的子地图位置，也不能把子地图数量当作文章数量。
手工导出XML时，还要留意编码和转义。比如确实需要保留在首选URL中的两个参数，在XML中应把连接它们的&写成&；这与网址本身的百分号编码是不同层面的处理。不要为了修XML，擅自把现有中文slug改成拼音，或创建第二个文章地址。自动生成器通常负责这些细节，出现解析行号错误时应定位具体字段及生成方式。Sitemaps协议中的结构与转义
页面地图里的lastmod描述页面修改，而索引文件中子地图条目的lastmod描述相应地图文件修改。两处不能不加区分地填同一个“导出时间”。对于普通WordPress维护，更有意义的是抽一篇真正更新过的文章核对，而不是追求所有日期整齐一致。
排错时，从文件走到页面
假设有一个教学场景：地图索引能打开，也列出了文章子地图，但点进文章子地图后，看到的却是登录页面。此时索引本身存在，文章正文也可能正常，故障发生在中间一层。继续对每篇文章点“请求编入索引”，并不能让那份登录页面变回XML。
| 检查对象 | 实际看到的情况 | 应该去查哪里 |
|---|---|---|
| 地图索引 | 404，或者跳到首页 | 提交地址、生成工具及服务器路由 |
| 某份子地图 | 登录页、验证页面、HTML报错 | 访问控制、缓存或插件输出 |
| 地图中的单篇文章 | 页面不存在、跳转、noindex | 文章状态及页面SEO设置 |
| 文件正常，页面也能抓取 | 仍未收录 | 索引报告、规范网址选择及页面内容 |
在浏览器中打开地图时，可以用开发者工具的Network面板刷新页面，选中该请求，看Status和Response。200只说明服务器成功返回了某个响应，还要确认内容确实是地图；一份返回200的登录HTML同样不合要求。反过来，XML没有漂亮表格，也不等于不能解析。
还要检查最初提交的地址有没有跳转。浏览器会自动到达最终XML，容易让旧地址看起来仍然可用；GSC站点地图报告说明，它不跟随提交地址的重定向。若记录填的是已跳转的旧地图，用Network核对最初响应与最终地址，确认最终文件有效后，将这个地址作为提交入口。提交地址与重定向规则
Search Console显示“无法抓取”时，先点进该记录看最近一次读取详情，再针对地图URL做实时测试，核对抓取是否允许和页面获取结果。Google的错误说明也区分了文件无法获取、XML解析错误及地图内URL问题。站点地图报告与错误说明
如果是缓存或插件冲突，保留当前配置记录，针对产生错误的文件修复，再清理受影响的缓存；随后重新打开索引及出错的子地图。不要只验证首页。修好“今天浏览器看到的版本”后，还应等报告显示新的读取时间，再判断Google是否已获得新文件。
还有一个容易被插件响应头误导的细节：Yoast会给XML地图本身设置X-Robots-Tag: noindex, follow，这是让地图文件不作为搜索结果展示，并不等于禁止读取其中的网址。Yoast对此的说明
提交后，保留两种不同的检查
确认文件可用后，在对应网站资源的Search Console中打开“站点地图”，填写实际地图地址并提交。如果还没有合适的资源或权限，先完成Search Console设置与验证。
以后把“地图维护”和“文章收录”分开看。地图维护关注最近读取是否成功、子地图是否完整、新公开文章有没有进入清单；文章收录则查看页面索引报告和具体URL检查。发现网址数量不是收录数量，不能拿两者直接计算所谓收录完成率。报告字段说明
如果文件和网址都正常，问题已经进入页面层面，可以接着做抓取与索引排查。此时重复更换地图文件名，会让原本稳定的入口多一项变动，通常没有必要。
首次提交可以优先提交正在使用的地图索引，并检查其中的子地图是否被正常读取。一般不需要为了同一套内容把索引、每个子地图和手工旧清单反复全量提交。robots.txt也可以声明实际地图地址，方便发现；这不替代文件本身可获取和解析。
选择GSC资源时确认协议、主机与权限范围，尤其别把测试站地图填进正式站记录。URL前缀资源和Domain资源的覆盖范围不同，提交表单也可能展示固定前缀或完整地址输入方式；应根据当前表单填写并核对最终记录URL，避免出现重复域名或错误路径。
显示成功却发现0个网址，怎么继续查
先打开对应记录看类型和最后读取时间，再看是否存在子地图记录。对于索引文件，浏览器看到子地图地址，不代表Google已经在同一时刻处理了每个子文件。随后任选一份应该包含文章的子地图，查看原始响应里有没有真正的url/loc条目。
如果子地图本身为空，回到文章类型与发布/索引设置；如果返回的是HTML或XML报错，修复生成和访问层；如果文件里网址完整，Google的读取时间仍早于修复，则保留现有入口继续观察新的读取结果。文件正常但报告暂未反映时，可以对重要文章单独进行URL检查，确认它是否已经通过其他路径被发现，不把“0”直接翻译成全站没有收录。站点地图报告字段与错误说明
比较数量时也要使用同一批网址和时间。某地图列出100个网址，而全站索引报告显示80个已索引，两者未必是相同集合；其中可能包含其他地图、历史URL或不同读取时点。要评估该批文章，应限定相应地图或固定URL清单，再看每类页面的状态。即使如此，也要区分本来不该独立索引的副本与真正需要处理的主文章。
更换生成器与日常维护，留下可追溯的结果
从原生地图切换到SEO插件时，先记录旧入口和代表URL，再打开新索引及文章、页面等子地图，确认没有因默认设置变化丢失重要内容或增加大量不想索引的归档。更新GSC提交入口及robots中的地图声明后，核对新文件读取。旧入口如何处理应结合生成器支持和现有引用，不能先删光再检查。
从GSC记录中移除一份地图，也不等于把其中的文章从Google删除；同样，从XML删除某URL不是可靠的索引排除方式。需要下线或退出索引时，应该回到页面自身的状态与控制方式。站点地图报告的管理说明
一次维护记录至少写明：修改的生成器或设置、公开索引地址、出错子文件、两三条受影响文章、修改时间和复查结果。以子地图被登录拦截为例，完成标志是未登录请求确实返回正确XML、相应文章URL仍正确，以及后续读取记录反映修复；仅把插件开关重新打开不算验收。
日常发布则不需要重做这套全过程。确认新文章已公开、进入自动清单并有正常站内入口；遇到读取错误、整类网址缺失或生成器切换，再展开针对性检查。把检查留在真正变化的地方，才能分清内容发布和地图故障。
常见问题
每发布一篇文章，都要重新提交站点地图吗？
使用正常自动更新的CMS地图时，通常不用。首次提交后，确认新文章出现在清单内即可。地图路径改变、之前提交失败或修复明确错误时，再针对相应记录处理。提交本身不保证文章被抓取或收录。
分类页和标签页要不要放进地图？
看这些页面是否是你希望索引的有效入口。有介绍、有清楚主题且能帮助读者浏览的聚合页，可以作为候选；大量空标签或重复归档则应先决定是否保留索引资格。不要只为增加地图数量把所有标签都列入，也不要仅因它叫标签页就一概排除。
站点地图显示成功，但文章还没收录，应该重做地图吗？
先查一篇具体文章。确认最终网址出现在清单中，页面能抓取且没有索引限制，再查看Google选择的规范网址和索引状态。如果问题是“已抓取，尚未编入索引”，接着处理对应状态的原因，不要仅凭未收录就认定地图失效。