站点地图已经更新，服务器日志为什么看不到搜索抓取
网站人员刚把新产品页加入站点地图，文件能打开，地址也没有写错。几天后查看源站访问日志，却找不到对应页面的搜索抓取记录。有人据此判断页面没有提交成功，也有人反复生成站点地图。两种动作都可能偏离问题。站点地图只提供待发现的URL，日志记录的是实际请求；要判断请求停在哪里，先把提交、边缘访问和源站响应分开核对。
先确认查看的是哪一层日志
不少企业网站前面还有CDN、云防护或反向代理。搜索请求先到边缘节点，命中缓存后可能不再访问源站；被访问规则拦截时，源站同样没有记录。运维人员只查Nginx源站日志，就会把“没有回源”误解成“没有访问”。应先画出域名解析、CDN、Web服务器和应用程序的请求路径，列出每层日志的保存位置、时区与保留天数。
查询时不要只按某个爬虫名称筛选。先用新URL的路径查完整访问记录，再看请求时间、来源地址、User-Agent、状态码、响应字节和耗时。User-Agent可以作为线索，不能单独证明请求身份。若边缘日志有记录而源站没有，应继续判断缓存是否直接返回页面，或安全规则是否在回源前结束请求；两层都有记录时，再比较状态码和最终地址。
日志时间也容易造成错判。搜索平台、CDN和服务器可能分别使用北京时间、UTC或本地时区，按同一个小时搜索会漏掉记录。可以选一条自己访问新URL的请求作为校准，记录浏览器访问时间、边缘日志时间和源站日志时间。确认偏移后，再检查搜索请求。日志轮转、压缩和多台服务器分流也要纳入范围，不能只打开当天正在写入的一个文件。
站点地图本身需要做一次字段核对。确认公开文件返回200，内容类型合理，URL使用正式HTTPS域名与伪静态地址，且没有混入测试站、参数地址或旧查询式链接。新URL只出现一次，规范地址、导航和正文内链也应使用同一版本。已经下架的页面如何退出，可参考下架产品与站点地图的清理方法，不要一边删除页面，一边继续提交旧地址。
按状态码判断请求到站后发生了什么
找到请求后，先按状态码分组。200还要检查返回的是否为完整正文，有些应用遇到异常仍返回200，却输出登录页、空模板或错误提示。301和302要展开跳转链，确认最终落到新URL，而非首页、语言选择页或循环地址。404说明提交地址或路由不存在；403、429则要检查防火墙、访问频率和IP规则，保留当时的规则命中记录再调整。
页面能返回完整内容，还要核对robots规则、页面级索引指令、canonical和内部链接。站点地图中的地址若规范到另一页，搜索系统可能把它当成重复入口。产品列表分页也常把后续页全部指向第一页，具体检查方式可见产品分页与规范地址的处理方法。这些字段应从公开页面读取，不能只看后台配置，因为模板缓存与发布过程可能让线上结果不同。
若日志中一直没有目标URL，不要靠连续提交制造更多记录。挑一个新页与一个已稳定访问的旧页做对照，比较它们在导航深度、正文链接、状态码、加载时间和安全规则上的差异。再从首页或相关产品页增加一条自然内链，让访问路径可见。完成修改后记录准确时间，只观察本次变更对应的日志，不把其他页面的请求当成结果。
每次排查应留下简短工单：目标URL、加入站点地图的时间、公开状态码、各层日志结果、发现的限制、修改内容和复核人。以后更换CDN、改伪静态规则或清理栏目时，团队能知道日志从哪里查，也能分辨“尚未发现”“边缘已访问”和“源站返回异常”。这比反复改标题或重复提交更接近问题本身。
