我以为是小问题，后来发现是大坑：我以为91官网没变化，直到我发现分类筛选悄悄变了（一条讲透）

我以为是小问题，后来发现是大坑：我以为91官网没变化，直到我发现分类筛选悄悄变了（一条讲透）

那天半夜翻 GA 看流量，发现某个页面群突然掉了近四成。我以为只是节假日波动，顺手打开 91 官网检查了一圈——看不出任何明显改动，布局、栏目、内容都在。直到我随手点了下“分类筛选”，才发现问题：筛选逻辑悄悄改了，页面 URL、缓存策略和索引行为都跟以前不一样了。小小一次前端改动，结果把整条流量链路撕开了一个大口子。

这里把我这次排查、修复和防范的经验浓缩成可落地的步骤与清单，省得你踩同一个坑。

为什么一个“看起来很小”的筛选改动会影响这么大？

• 前端筛选可能会改变 URL 参数结构（例如 ?cat=10 → /category/10 或用 hash），影响搜索引擎抓取和已建立的外部链接权重。
• 前端用 JS 动态渲染筛选结果，但没有做好 server-side render 或 pushState，这会导致爬虫抓不到内容，搜索索引下降。
• 旧的分页/筛选 URL 可能被外部站点引用或已有收录，改动后未做 301 跳转，流量和权重丢失。
• 缓存策略或 CDN 配置未调整，用户看到的是旧页面或空结果集，体验差导致跳出率上升。
• 数据埋点/事件没有同步，导致监控失灵，异常发现延迟。

我怎么发现并定位问题（实操流程）

1. 立刻对比流量与事件：看哪些页面、哪些渠道、哪些搜索关键词掉得最厉害。
2. 访问一条典型问题 URL，使用开发者工具看 network、response、实际渲染的 DOM、是否有 JS 跳转或 hash 改变。
3. 用 curl 或 server-side 请求模拟爬虫访问，检查返回的 HTML 内容和状态码，排除“客户端渲染但无服务端内容”情况。
4. 查 server logs 与 CDN 日志，追溯请求链路，确认是前端改动还是后端接口变更导致。
5. 用站点爬虫（Screaming Frog、Sitebulb）抓取站点，找出大量 404、重复内容或参数不一致页面。
6. 检查 sitemap、robots.txt、canonical 标签、meta noindex 是否被误改。

快速修复清单（优先级排序）

• 如果是 URL 结构变更：立刻建立 301 重定向规则，把旧 URL 指向新 URL，保留权重。
• 如果是客户端渲染导致爬虫不可见：临时开启服务端渲染或为主要筛选页提供可抓取的快照。
• 修正 canonical 与 sitemap：确保指向你希望被索引的页面，并重新提交 sitemap 给搜索引擎。
• 修复缓存与 CDN：清理受影响的缓存，检查缓存策略是否不当导致用户看到错误内容。
• 恢复埋点与监控：补回遗漏的事件，给 GA/监控打注释（annotation），便于后续分析。
• 对外沟通：如果改动影响用户体验，发出说明或在 FAQ/公告中解释，减少用户疑惑和投诉。

长期防范建议（把“悄悄改动”变成可控改动）

• 任何前端逻辑涉及 URL、分页、筛选、搜索结果的变更，都必须走变更控制：PR 里列明 URL 变化、影响的 SEO 元素和回滚方案。
• 在上线前用自动化脚本做一次站点抓取比对（包括可抓取性、canonical、meta、HTTP 状态码）。
• 发布采用 Feature Flag 或灰度，先在一小部分用户上验证，监控关键指标再全面放开。
• 将 SEO 检查写进 CI/CD 流程：每次部署报表输出收录/抓取可见性差异。
• 建立基线监控：一旦核心页面流量或抓取量突降，立刻告警并自动展开回溯脚本。

一句话讲透 别把前端的“筛选展示”当作纯 UI 改动——它往往牵动 URL、抓取、缓存和外部链接，影响流量和营收。