发布：更新：阅读：1933
内容发布后，运营人员在 sitemap 里看到一条新地址，往往就把任务标成完成。这个判断太早。XML 里有 URL，只能说明生成程序写出了一行记录；公开页可能经过跳转，canonical 也可能仍指向旧地址。遇到栏目路径改名或文章 filename 填错时，sitemap 甚至会把搜索引擎带到一条能打开、却并非正式地址的页面。
验收前先保存发布清单，至少记录内容 ID、栏目 filename、文章 filename、发布时间和更新时间。PbootCMS 采用带栏目路径的伪静态规则时，文章正式地址应由“栏目 filename/文章 filename.html”组成。清单里的预期地址要从实时栏目数据推导，不能照抄编辑人员发来的浏览器链接，也不能把带查询参数的预览地址当成正式 URL。
接着比较发布前后的 sitemap。新增文章应出现在差集里，而且只出现一次；同一篇内容若同时出现带 www、无 www、HTTP、HTTPS 或末尾形式不同的地址，说明规范化还没收干净。差集里若混入后台地址、搜索参数页或测试栏目，也应停下提交动作，先查 sitemap 的生成条件。
这一轮检查还要确认原有 URL 集合没有意外缩水。重建 sitemap 时只盯着新文章，容易漏掉其他栏目。可以按栏目统计新旧数量，再核对缺失集合。正常下线的页面要有内容台账和跳转去向；没有发布记录却从 sitemap 消失的地址，需要回到数据库状态、栏目启用状态和生成范围查原因。
对每条新增 URL 发起直接请求，目标应直接返回 200，不经过 301 或 302。随后读取页面的 canonical，要求协议、主机名、路径和预期地址完全一致。canonical 指向首页、旧文章或无 www 域名时，即使页面能浏览，也不适合继续提交。检查时保留最终地址和跳转链，能很快分清是伪静态规则、模板变量还是域名配置造成的偏差。
页面主体也要和这条 URL 对应。浏览器 title、H1、description 应围绕同一个问题，正文不能出现另一篇文章的标题或摘要。再从所属栏目列表点入一次，确认锚文本、发布日期和目标地址正确。如果栏目页找不到新文，可能是缓存未清、状态字段不对或列表调用范围有误，此时仅在 sitemap 增加地址无法补上站内发现路径。
移动端抽查关注实际版面，不用只看开发者工具里的状态码。长标题换行后，日期栏、面包屑和正文首段不能被挤出容器；页面中的图片若存在，要核对 URL、alt 与宽高属性。技术状态通过却出现主体遮挡，仍会影响用户读取，应该在发布记录里单独标为模板问题。
新增 URL 数量通常不大，适合逐条检查；旧地址则从每个栏目取样，并覆盖近期更新页和较早页面。取样结果记录 HTTP 状态、canonical、title、H1、栏目入口和 sitemap 是否存在。这样下一次出现异常时，可以判断问题只影响本轮内容，还是 sitemap 重建、模板或服务器规则波及全站。
lastmod 应反映页面真实更新时间。只改 sitemap 生成时间，却没有修改正文或页面信息，不应把全站日期统一刷新。XML 还要通过解析检查，确认特殊字符已转义、loc 没有重复、日期格式有效。清缓存后重新获取公网 sitemap，避免拿服务器文件验证成功，访客侧仍读到旧缓存。
验收记录通过后，再决定是否向搜索平台提交。HTTP 200、进入 sitemap 和提交成功都不能替代收录结果，未接入搜索资源平台账号时应如实标注“无法确认”。发布清单保留新旧 sitemap 摘要、目标 URL 和检查时间，后续复查只需比对变化项，不必靠记忆判断哪条地址曾经正常。
