网站改版后 Server Log SEO 审计检查清单

网站改版后，即使视觉 QA、sitemap 检查和 Search Console inspection 都通过，搜索引擎爬虫仍可能把时间花在错误位置。Server logs 能告诉你上线后实际发生了什么：Googlebot 和其他爬虫请求了哪些 URL，收到什么响应，旧路径、参数、被阻止文件或错误重定向是否正在浪费抓取资源。

这份清单适合网站改版、CMS 迁移、Shopify 主题上线、Headless Commerce 切换或大规模 URL 清理后的技术 SEO 审计。它不替代常规 crawl 或 Search Console 检查，而是补上一个证据层：真实爬虫在真实站点上的行为。

先找能看到真实爬虫请求的数据源。根据技术栈不同，来源可能是 origin server logs、CDN logs、Vercel 或 Netlify logs、Cloudflare logs、load balancer logs、reverse proxy logs，或应用路由日志。Analytics 不够，因为很多搜索爬虫请求不会执行追踪脚本。

至少导出上线后前 7 天的数据。较大网站建议保留 30 天窗口，方便比较发现、重新抓取和清理趋势。在下结论前，先记录时区、可用字段、采样规则和已知缺口。

• 字段尽量包含 timestamp、host、path、query string、method、status code、user agent、referrer、bytes、response time 和 cache status。
• 覆盖所有相关 host，包括 www、非 www、locale 子域名、CDN 域名、staging 泄漏、图片 host 和会渲染 SEO 内容的 API 路由。
• 确认日志来源是否采样，或是否省略了 edge cache 命中的请求。
• 把原始导出和清洗后的分析文件分开保存，方便之后复查证据。
• 对外分享日志前，先审查 IP 地址、query string 和敏感参数。

User agent 可以伪造，所以不要把所有写着 Googlebot 的请求都当真。高风险分析应使用 reverse DNS 或可信规则验证主要搜索爬虫。至少要把已知搜索爬虫、未知爬虫、监控工具、uptime check 和普通浏览器流量分开。

爬虫集合清洗后，再按 bot、状态码、模板类型、目录、locale 和 canonical URL group 汇总请求。目标不是欣赏表格，而是判断改版后爬虫是否把时间花在重要页面上。

• 分开 Googlebot smartphone、Googlebot image、Bingbot、广告爬虫、SEO 工具、AI crawlers 和未知爬虫。
• 按模板归类 URL：首页、collection、product、service、article、category、search、filter、asset、API 和 redirect。
• 统计前先规范化 trailing slash、大小写路径、追踪参数和已知 query strings。
• 标记访问 staging、preview、admin、checkout、cart、站内搜索和旧 CMS 路由的爬虫请求。
• 把爬虫活动和上线 URL inventory 对比，不要把日志当成孤立行来审。

重定向表在 spreadsheet 里正确，不代表线上一定正确。日志能揭示爬虫是否仍在访问旧 URL，重定向是否返回预期状态，以及 chain、loop、soft 404 或 fallback page 是否藏在上线结果里。

先看改版前有自然流量、外链、广告使用或重要内链的 URL。如果这些 URL 返回 404、500、长链或不相关目标页，应优先修复，再处理低价值抓取噪音。

• 列出上线后仍被搜索爬虫请求的旧高价值 URL。
• 检查每个旧 URL 是否通过单次 301 或 308 到达最匹配的新目标页。
• 找出 chain、loop、协议混用跳转、locale 错配和跳到泛页面的重定向。
• 区分可以接受的退役 URL 和本该重定向或恢复的意外 404。
• 修复后重新 crawl，并继续监控爬虫是否反复请求旧路径。

有新 sitemap 不代表一定被发现。日志应该显示爬虫在请求重点页面，而不只是旧 URL 和低价值参数路径。根据网站规模和权重，检查重要新页面是否在合理时间窗口内被爬虫请求。

把 XML sitemap、上线 URL inventory、内链 crawl 和日志请求放在一起对比。缺失页面通常指向 sitemap 错误、noindex 误用、内链不足、canonical 冲突、被阻止资源或 JavaScript 渲染问题。

• 创建重点 URL 列表：首页、核心转化页、collection、PDP、服务页、文章和本地化页面。
• 检查已验证爬虫是否请求这些 URL，以及收到什么状态码。
• 寻找只以追踪参数、大写路径或非 canonical 版本出现的重点页面。
• 确认 sitemap URL 返回 200、可收录、适当 self-canonical，并且有内部链接。
• 如果提交 sitemap 并完成内链 QA 后，重点页面仍没有爬虫请求，应升级处理。

每个网站都会有一些低价值抓取，但改版常常制造新的浪费：筛选导航组合、站内搜索页面、日历归档、重复 locale 路径、旧资源 URL、追踪参数、preview 路由和 app 生成页面。日志能显示爬虫是否正在大规模发现这些路径。

修复方式不一定是全部禁止。有些模式需要 canonical 清理、删除内链、参数处理、robots 规则、noindex、重定向规则或模板调整。要根据 URL 是否应该被抓取、收录、内部链接或退役来选修复方式。

• 识别会制造重复抓取路径、但没有独立搜索价值的参数模式。
• 分别审查站内搜索、filter、sort、pagination、tag 和 archive URL。
• 检查爬虫是否在被阻止资源、缺失图片、app endpoints 或旧静态文件上浪费请求。
• 跨 locale、market 和 subdomain 比较抓取浪费，避免一个市场的问题被平均值掩盖。
• 为每类模式记录修复方式：canonical、redirect、robots、noindex、link cleanup 或 route removal。

Server logs 和其他证据一起用才最强。Search Console 告诉你 Google 如何报告索引和表现。爬虫工具告诉你网站通过链接和 metadata 暴露了什么。Logs 告诉你爬虫实际请求了什么、收到什么。

改规则前要把三者合在一起看。例如某类 URL 在日志中看起来很多，但可能仍然承接有价值的长尾需求。另一类 URL 在 crawl 中看似无害，却反复给爬虫返回 500。组合视角能让修复更精准。

• 把日志里的 404 和 5xx 对照 Search Console 的 page indexing 和 crawl stats 报告。
• 把 crawl 得到的 canonical、robots directives 和 sitemap inclusion 对照爬虫实际请求 URL。
• 检查有曝光的重要页面，在改版后是否也被重新抓取。
• 修改 redirect、robots、canonical、sitemap 或内链后，用日志验证修复是否生效。
• 向团队汇报时，保留修复前后的截图或导出作为证据。