主题
第 16 章 技术审计、日志与迁移：把问题缩小到能够修复的范围
16.1 审计的产物应该是可执行结论
一份包含几千条红色警告的爬虫报告，不等于完成了技术审计。读者真正需要知道的是：哪些问题影响重要页面，证据是什么，谁能修改，怎样验证，修完以后还剩什么不确定性。本章将前面几章的控制与渲染知识放到完整流程里，处理重复页面、分页、多参数、改版迁移和大型站点故障。
完成本章后，你应能独立制定审计范围，结合内容清单、抓取结果、搜索报告和日志建立问题假设，设计迁移映射与回滚条件，并在流量变化时优先排除可验证的技术故障。这里所有案例与数字均为假设，示范脚本没有对真实站点运行。
开始前先确定业务范围。个人作品站可能只需检查几十个公开页面；工具 SaaS 要把公开获客页与登录后应用分开；内容站关注栏目与文章发现；电商还要处理变体、库存和筛选；本地服务站则必须保留门店与服务区域的真实区别。范围不同，检查深度与优先级也应不同。
再列出已知变化：最近是否换域名、改路由、更新 CMS、切换 CDN、添加机器人防护或更改渲染方式。技术故障常沿部署边界出现，但时间接近只提供线索，不能直接证明原因。将变更记录与异常开始时间放在一起，是为了提出可检验假设，而不是先找一个人背锅。
16.2 建立四份清单，再比较它们的差异
第一份是业务期望清单：由 CMS、商品系统或路由注册表导出的正式公开内容。第二份是爬虫从内部链接发现的 URL。第三份是站点地图中的 URL。第四份是搜索引擎已知或已经带来展现的 URL。四份清单的交集和差集，通常比任何单个总数更有用。
第四份通常只能构成可观察样本。Search Console 页面索引报告的详情表示例最多列出 1,000 个 URL，不保证列出该状态下全部页面；报告外没有找到某页，不等于它未被索引。[D50] 先用业务清单确定“应当存在什么”，再用代表性 URL 检查补查状态，并在审计中注明导出时间与覆盖范围。
业务期望有、内部抓取没有的页面，可能是孤立页面 orphan page，也可能受登录或脚本限制。地图有但业务已经删除的页面，说明生成源没有同步。搜索引擎知道而当前站内找不到的 URL，可能来自旧链接、参数、历史版本或被入侵的内容。这些都只是候选原因，需要访问和历史证据进一步确认。
导出时保留原始 URL，再创建用于比较的规范化键。不要一开始就粗暴删除全部查询参数，因为 page=2、lang=zh 与商品变体参数可能承载真实内容。可先统一明确无业务差异的形式，其他变化作为单独字段分析。原始值一旦丢失，后面就很难判断服务器实际接收了什么。
审计样本应覆盖模板和风险边界。除高流量页面外，还要包含新发布、长期未索引、低库存、空分类、深分页、带特殊字符、不同语言与历史迁移地址。只检查首页和最热门文章，会漏掉导致大部分长尾页面异常的模板分支。
对于大型站点，全量抓取本身可能造成负担。先与技术团队约定速率、并发、时间窗口、排除路径和停止条件，再逐步扩展。抓取工具的 User-Agent 与真实搜索爬虫不同，被防火墙拦截不一定说明 Google 同样被拦；反之，给审计工具加入白名单也不能证明普通访客和搜索引擎正常。
16.3 从症状写出有证据的工单
不好的工单写“修复重复内容”。可执行的工单则写明：某模板中二百个假设商品地址同时存在带尾斜杠和不带尾斜杠版本，均返回成功状态；站内导航使用前者，地图使用后者，canonical 缺失；建议确定正式形式并统一输出，在测试环境验证查询参数和语言路由不被误改。数字必须来自真实检查，不能用示例数字填正式报告。
每条工单至少保留五个要素：影响的页面集合、可复现证据、预期业务行为、建议修改点、验收条件。若根因尚未确定，写成“待验证假设”，并列下一步要获取的证据。这样开发者能判断应改应用、网关、缓存还是内容数据库，不需要从模糊描述重新调查。
优先级可以依据影响、覆盖、确定性与成本综合决定，但不要把一个伪精确公式当作客观真理。全站意外 noindex 应高于少量缺少替代文本；核心产品无法渲染应高于某个非关键页面标题略长。另一方面，涉及用户安全和数据泄露的故障，应按安全响应处理，不能只按自然流量价值排序。
修复范围要与根因一致。发现一张页面 canonical 拼错，先判断是单条数据还是公共模板。如果是公共模板，手工覆盖一个 URL 会让样本变绿，却留下大部分风险。验收时也应按模板检查，不要只打开工单里那一个地址。
16.4 日志让“爬虫有没有来过”变成可回答的问题
服务器或 CDN 访问日志记录请求发生的时间、路径、状态、耗时等信息。它能帮助回答哪个地址被请求、返回什么、是否出现错误；它不能直接证明内容已经被索引，也不能直接证明排名为何变化。分析前要确认日志覆盖哪些层：CDN 缓存命中的请求可能根本不会到源站，源站日志没有记录不等于外部没有访问。
常用字段包括时间、主机、请求方法、原始路径、状态码、响应字节、响应耗时、缓存状态、用户代理和请求来源地址。日志也可能包含敏感查询参数或标识符，应遵循最少保留原则，在适当环境中脱敏并限制访问。做 SEO 不需要随意把完整用户请求日志上传到陌生在线工具。
不能仅凭 User-Agent 中写着 Googlebot 就认定是真实爬虫。Google 官方说明了反向 DNS 后再正向核对，以及按公布的 IP 范围自动匹配等验证方法。[D23] 自动流程还需记录采用的范围版本和验证结果，避免将验证失败、尚未验证与明确伪装混成一类。
同时区分常规抓取、资源加载和用户触发的测试。手动运行 URL 检查后看到一条 Google 相关请求，不代表正常发现与刷新抓取已经恢复。若把自己反复测试制造的访问算作自然抓取增长，结论会偏离事实。
下面是教学 SQL，表结构是假设，已用本地虚构数据验证基础统计，未用于真实日志。verified_crawler 字段应由独立、正确的身份验证流程产生，不能简单根据用户代理赋值。
sql
SELECT
DATE(request_time) AS day,
url_group,
COUNT(*) AS requests,
COUNT(DISTINCT requested_url) AS unique_urls,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS server_errors,
SUM(CASE WHEN status_code = 429 THEN 1 ELSE 0 END) AS limited_requests,
AVG(response_ms) AS mean_response_ms
FROM edge_access_log
WHERE verified_crawler = 'googlebot'
AND request_time >= :start_time
AND request_time < :end_time
GROUP BY DATE(request_time), url_group
ORDER BY day, url_group;这份结果还不够。平均耗时可能掩盖长尾，应再看分位数；请求数量不代表覆盖页面数，应同时看去重 URL；总量上升可能只是同一错误页反复请求，应结合状态码与内容类型。分组必须固定规则，例如商品、品类、文章、静态资源与参数变体，不能每周换一套分类再比较趋势。
Search Console 抓取统计提供请求、响应和主机可用性等信息，但示例 URL 并不完整，统计与本地日志也可能因为口径及覆盖不同而存在差异。[D44] 不必要求二者每一个数字都相等。先统一时间区间、时区、主机、资源范围和身份分类，再判断差异是否需要调查。
16.5 重复、分页与筛选参数要分开治理
重复内容可以来自协议、主机、路径大小写、尾斜杠、跟踪参数、打印视图、排序、内容转载或错误模板。修复前应比较主体内容，剔除导航、页脚等公共部分后再判断相似程度。标题一样不代表正文一样，正文哈希不同也不代表有独立价值，因为广告或随机推荐足以改变哈希。
分页的任务是把一个集合分段展示。Google 当前建议每页具有独立 URL，并使用自身的规范地址；它不再使用 rel=next 与 rel=prev 来识别分页关系。[D22] 因此，第二页应有可直接访问的内容与真实下一页链接，而不是只靠点击“加载更多”调用内存中的列表。
分页也会产生业务细节。商品排序持续变化时，同一个 page=2 今天和明天可能不是同一批商品，这是正常集合更新，但不能让前后页大量重复或漏项。可采用稳定排序键，并在合适情形下引入游标式内部接口；对公开页面仍需考虑地址稳定性和发现路径。数据库分页方案与搜索入口方案不必完全同构。
筛选导航 faceted navigation 是按颜色、尺寸、品牌等多个维度筛选集合。其风险来自组合数量，而非问号本身。Google 的相关指南强调对需要公开抓取的组合保持稳定结构，并对无结果或无意义组合返回合适的不存在响应。[D21] 具体网站还需区分临时缺货的有效落地页与毫无意义的组合，不能把所有空结果都当成同一个业务状态。
可以先建立有限的可索引组合白名单，例如用户有明确需求、集合足够稳定、能够提供独立说明的“轻量徒步鞋”。其他任意多条件组合保留为站内功能，并控制发现与索引策略。这个决定需要内容与商品团队参与；开发者无法只凭参数名称判断某个组合是否值得搜索入口。
参数治理从生成端开始。去掉重复筛选，统一顺序，拒绝无效值，禁止循环追加 session、排序和页数参数。对追踪参数在不破坏归因的前提下统一规范信号；对真正改变内容的参数保留明确策略。只靠 canonical 在尾端补救，无法阻止程序继续生成无限 URL 空间。
16.6 迁移前先决定哪些东西不一起改
迁移可以是换域名、换路径、换 CMS、换渲染框架，也可以只是更换托管服务。它们的风险不同。Google 对地址不变的托管迁移另有说明，重点包括新基础设施准备、测试与后续监测。[D46] 若 URL 没变，就不应为了“做迁移 SEO”凭空增加一层重定向。
尽量避免在同一次上线同时改变域名、URL、正文、导航、模板与分析工具，因为一旦出现下降，很难知道是哪一层导致。现实项目未必能完全拆开，但至少要明确哪些变化不可避免，为它们分别留基线与验收项。不能只说“新站已经更漂亮”，就认为搜索入口会自然保持。
迁移资产清单应包含正文页、图片、PDF、下载文件、语言版本、重要参数地址和历史重定向。经常被遗漏的是旧文章中的图片与手册，它们可能被外部网站直接引用。页面能打开而资源大量失效，既损害用户，也使迁移后的内容与原来不再等价。
备份应能恢复数据、配置和发布版本。恢复能力需要演练，不能把“系统每天有备份”视为已经拥有可用回滚。新旧系统的数据在迁移期间如何同步、是否暂停编辑、哪些新订单不能回滚，都必须由业务和技术团队共同决定。
16.7 URL 映射与重定向要按相关性制定
创建一份旧地址到新地址的映射，每行记录旧 URL、目标 URL、处理方式、原因和验证状态。一对一替代最清楚；多篇真正合并成一篇时，可以多对一，但新内容应承接旧页面的重要任务。没有对应内容的旧页，不能为了减少 404 数量全部指向首页。
Google 的迁移指南建议让重定向尽可能直接指向最终目标，并通常至少保留一年；它也提醒迁移中的搜索可见性可能暂时波动，所需时间取决于规模与处理情况。[D20] 这不是“保留一年后必须删除”的意思。如果旧外链与用户书签仍有价值，长期保留合理重定向通常值得评估。
服务器端永久与临时重定向分别表达不同迁移意图，Google 官方重定向说明列出了对应处理。[D25] 选择时先看业务事实，不要把 302 一律当作错误，也不要把所有短期活动跳转改成 301。协议行为、浏览器缓存与其他客户端也会受到影响。
映射测试至少覆盖目标存在、重定向循环、链条长度、跨域目标、参数处理和大小写。正则规则尤其要测试边界。例如把 /blog/(.*) 改到 /guides/$1，可能意外匹配上传目录、分类页或已经不存在的路径。规则越宽，越要保留具体样本证明它没有扩大范围。
可以在上线前对映射文件做离线验证：同一旧地址是否对应多个目标，目标是否再次作为旧地址产生不必要链条，是否出现 A 到 B、B 到 A 的循环，是否有错误测试域名。上线后再请求实际响应，因为代理规则的优先级可能改变最终行为。
新站的内部链接、canonical、站点地图、结构化数据和语言关联也要采用新地址。只配置旧站重定向，而新站仍把自己声明成旧站副本，会留下相互冲突的信号。迁移验收应把这些字段与映射文件一起检查，不要由不同团队分别维护无关联的名单。
16.8 上线窗口与迁移后的观察
上线前应验证新环境的公开访问方案，并确认测试阶段的保护不会遗留到生产。测试站可以使用认证限制访问；上线时要明确移除哪些阻碍、保留哪些真正的权限。不要为了方便测试先把客户后台公开，再承诺上线后补安全。
正式切换时，按计划启用新地址和重定向，更新内部入口与站点地图，核对证书、DNS、缓存和关键资源。旧域名的解析、证书和重定向服务也必须继续工作；仅保留一份已经无法被访问的跳转配置没有作用。
换域名或迁往另一子域时，先用同一 Google 账号取得旧、新 Search Console 资源的所有者权限，完成迁移和重定向检查，再从旧资源发起“地址变更”。工具不能从带路径的旧资源发起迁移，也不会自动包括该主机下的其他子域。跨域迁移要列出并处理已验证的旧主机变体，包括 www、非 www 和其他子域，不能只提交一个就假定全部覆盖。[D48][D20]
仅将 HTTP 改为 HTTPS、在同一域名切换 www 与非 www、调整站内路径，或在 URL 不变时换托管，都不使用地址变更工具；按实际情况维护重定向、规范信号与站点地图即可。[D48] 发布后检查旧、新资源的验证仍然有效，避免换 CMS 时遗失验证文件或标签。对实际网站操作还应取得相应权限与授权，本书仅解释流程。
迁移后先监测技术可用性，再监测搜索采用。技术层包括主要页面成功率、重定向循环、服务器错误、接口失败和核心任务完成；搜索层包括新旧地址的抓取、索引与展现变化。报表迁移还可能改变归因，因此应把新旧资源视图合并理解，而不是只看旧域名流量下降就宣布失败。
预先制定回滚条件，例如关键交易无法完成、全站误发 noindex、重要页面广泛返回错误。这些条件应具体到可观测症状，而不是“排名看起来不舒服”。小范围正确设置后的短期搜索波动不一定适合立即回滚，因为来回切换又会制造另一轮地址和缓存变化。
回滚也必须有负责人。有人决定业务是否可以恢复旧版本，有人处理 DNS 与基础设施，有人核对内容和订单一致性，有人持续记录时间线。SEO 负责人应说明搜索风险和证据，但不应在没有技术与业务确认时独自切换生产系统。
16.9 大站故障：先定位发生在哪一层
当自然搜索点击突然下降，先确认指标本身：是搜索展现下降、点击率下降，还是站内分析的自然会话减少？Google 的流量下降诊断文档建议结合技术问题、需求变化、季节性及搜索系统变化等方向分析。[D45] 若搜索点击保持稳定而站内会话骤降，首先检查分析脚本、同意管理与渠道归因，未必是索引事故。
如果展现与点击都下降，按范围切分：所有页面还是某模板，所有地区还是某地区，移动还是桌面，品牌词还是非品牌词，某个子域还是全站？范围能帮助定位共同组件。只有商品页下降而文章页稳定，可优先检查商品接口、库存逻辑、产品模板及分类入口；全站同时异常，再看基础设施与全局配置。
接着按访问链逐层排除：域名解析是否正确，证书是否有效，CDN 是否响应，防火墙是否拒绝，应用是否返回正确状态，页面是否含正文，渲染是否成功，索引指令是否符合预期。先恢复用户与爬虫能够访问正确内容，再讨论更复杂的排名解释。
一个完整的防火墙误拦案例
假设某内容站在周一发布新的机器人防护规则，周二新文章发现变慢，周三部分搜索点击下降。当前只是时间线，尚不能证明防火墙导致。团队先抽取新旧文章各一组，浏览器均正常；搜索实时测试却间歇失败。随后检查边缘日志，发现已验证的部分 Google 抓取请求收到 403，源站日志对此没有记录。
这组证据把问题缩到边缘访问层。下一步比较新规则命中的条件，而不是向源站开发者要求重写页面。若确认规则误拦合法请求，应由有权限的管理员修正特定判定，并保留对其他攻击流量的保护。不能简单关闭全部防火墙，也不能仅按可伪造的 User-Agent 无条件放行。
修复后，观察同类请求能否获得正常状态，搜索实时测试是否稳定取得正文，以及后续真实抓取是否恢复。搜索展现的恢复可能滞后，不能以测试成功当日仍低迷为由判定修复失败。反过来，若边缘响应已经正常而正文仍空，就继续检查渲染与接口，不要固守第一个解释。
一个参数爆炸案例
假设品类模板允许每次选择排序都保留旧排序参数，页面链接逐渐出现 sort=price&sort=rating&sort=price。日志显示大量独特组合被访问，而核心商品的更新等待变长。先从页面源码与请求记录证明这些地址确实由站内生成，再修 URL 构造逻辑，规定每个单值参数只能出现一次。
之后处理已经存在的无效组合、清理站内入口，并按目标采用合适的重定向、抓取限制或索引策略。修复效果应观察无效组合的新增速度、核心页面的请求与更新情况、服务器负载，而不是只看总抓取量下降。总量减少可能正是去掉浪费后的正常表现。
16.10 验收、复盘与防止同一问题再来一次
每次事故或迁移应保留简洁时间线：异常首次证据、受影响范围、已排除原因、实际根因、修复版本、验证结果与待观察项。没有证据的推断要明确标记。这样未来再次出现类似图形时，团队能复用检查方法，而不会把所有流量变化都套成上一次事故。
长期预防应优先选择便宜但覆盖关键风险的检查。例如每日少量请求确认首页与核心模板没有 noindex，发布时校验 canonical 域名，监测 robots.txt 的有效内容变化，为重定向映射跑循环检查，为商品模板检查主要正文是否存在。无需每天全量抓取百万页面才能发现全站配置错误。
监控阈值必须结合基线与业务活动。新批量发布会改变抓取量，促销会改变商品请求分布，迁移会增加重定向请求。报警应提供样本、变化范围和相关版本，帮助人作判断，而不是只发一个无法解释的红色数字。告警太多且没有行动路径，最终容易让真正重要的通知也被忽略。
练习与参考解答
练习一：CDN 日志有十万次抓取，源站只有两万次，是否丢了八万条？参考解答：先检查缓存命中、主机范围与采集口径。源站本来就可能看不到边缘直接响应的请求，不能直接把数量差当成数据损坏。
练习二：改版后旧域名流量下降九成，新域名同期增长。是否应该回滚？参考解答：先合并观察总搜索表现，并检查关键页面映射、用户任务和错误率。旧地址下降本身可能符合迁移目标，不能单独作为失败证据。
练习三：抓取工具发现三千个 404，应该全部跳到首页吗？参考解答：应区分真实删除、错误内链、迁移漏项与无意义 URL。只有存在相关替代的地址才适合相应跳转，其他情况应修链接或保留正确的不存在状态。
执行清单
- 确定业务范围，保存正式内容、内部发现、地图与搜索已知地址清单。
- 用可复现证据写工单，区分已确认根因与待验证假设。
- 验证日志中的爬虫身份，并核对 CDN、源站与搜索报告口径。
- 迁移前完成映射、备份、回滚方案和跨模板验收。
- 故障时按数据、范围、访问链定位，修复后持续验证实际结果。
本章参考来源
[D20] Site moves and migrations | https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes | 访问 2026-10-13 | 地址迁移、重定向保留与监测。 [D21] Managing crawling of faceted navigation URLs | https://developers.google.com/crawling/docs/faceted-navigation | 访问 2026-10-13 | 筛选组合与无效地址处理。 [D22] Pagination and incremental page loading | https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading | 访问 2026-10-13 | 分页地址、规范化与链接。 [D23] Verify requests from Google crawlers and fetchers | https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests | 访问 2026-10-13 | 请求身份验证。 [D25] Redirects and Google Search | https://developers.google.com/search/docs/crawling-indexing/301-redirects | 访问 2026-10-13 | 永久和临时重定向。 [D44] Crawl Stats report | https://support.google.com/webmasters/answer/9679690/crawl-stats-report?hl=en | 访问 2026-10-13 | 抓取统计口径与示例局限。 [D45] Debug Google Search traffic drops | https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops | 访问 2026-10-13 | 流量下降的诊断方向。 [D46] Changing your web hosting and SEO | https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes | 访问 2026-10-13 | 地址不变的托管迁移。 [D48] Change of Address tool | https://support.google.com/webmasters/answer/9370220?hl=en | 访问 2026-10-13 | 地址变更的所有者条件、操作顺序、主机范围与不适用情形。 [D50] Page indexing report | https://support.google.com/webmasters/answer/7440203?hl=en | 访问 2026-10-13 | 页面索引报告详情URL示例上限与非完整清单的边界。