内容被整站搬走但流量报表看不出异常，先看哪一层

站点内容被整站搬走，但流量报表看不出异常——这是这类事故的正常形态，不是报表失灵。排查应该先看哪一层？顺序在下文。原因是采集行为天然绕开前台统计：采集方用脚本按列表页逐页拉取正文，请求不经过埋点、不落来源记录，就算落进了访问数，也淹没在正常抓取与爬虫流量里；而抄袭站拿到的搜索曝光，记在对方的报表上，永远不会出现在你的数字里。所以排查不能从报表起步，正确的层次是自下而上：先看抓取与访问日志，再看搜索环节的迹象，最后才是防护与处置。

第一层：抓取与访问日志

批量搬运在日志里的形态很稳定，找三种痕迹。一是短时间内对列表页与内容页的等差遍历——同一 IP 在几分钟内把文章按编号或分页参数扫了一遍，页码连续、间隔均匀、UA 单一。二是异常集中的「只读正文」请求：只拉详情页不拉样式与图片，说明请求方只要文本。三是对比 robots 记录：抓取类 UA 会按规则声明身份，而搬运脚本往往无视或伪造 UA；站点的 robots 配置（Robots.txt）里明确禁止的路径仍被高频访问，基本可以从正常抓取里排除。这一层的产出是「谁在拉、拉走了哪些页」，是后面所有动作的证据基础。

第二层：搜索环节的迹象

受害面用两个低成本信号估计。第一个是站内搜索词：内容被搬走后，原读者会搜完整句子找回你，站内统计里如果突然冒出「你站上某篇文章里的整句」作为搜索词，说明外部有同文在分发、用户在比对出处。第二个是外部搜索的重复页：抽几篇核心文章的标题全称与正文特征句去检索，看结果里有没有整段一致的页面，记下域名与时间。有快照更早、结构更薄的站点整篇命中，就可以定性为被搬运，而不是「疑似」。

干扰码管哪一层

确认被搬后，防护手段里和「批量采集」直接对抗的是防采集干扰码：AnQiCMS 内置的干扰码在页面渲染时加入只有采集脚本会原样带走、浏览器端不显形的内容，脚本整站拉走时把这些干扰一并抄走，抄袭站的正文里就混进无意义片段，搬运的成品质量被破坏。要看清它的作用边界：干扰码保护的是「再次被批量拉走」的增量页面，对已经被搬走的历史内容没有追溯力，也不能替代第一层的日志排查——它防的是拿走，不帮你发现已被拿走，发现永远靠日志与搜索信号。

别把采集能力当防护层

一个常见的概念倒置：把「内容采集」当成防护。AnQiCMS 的内容采集是从外部网站自动取入内容的能力，方向是往里拿，和防采集（防被拿）恰好相反，两者常被同名混谈。理顺之后的分工是：发现层靠访问日志与搜索迹象；对抗层靠干扰码这类防采集机制，加上对确认滥用者的投诉与封禁；规则层靠 robots 与站点声明划清抓取边界。给团队排事故手册时，按这三层写动作，不要写成「开了防采集就安全」——单层方案在这类事故里都会失效。

排查顺序小结

按这个次序执行：第一步拉访问日志，按 IP 聚合找等差遍历与只读正文的请求形态；第二步核对 robots 声明与实际抓取行为的偏差；第三步查站内搜索词里的整句命中；第四步到外部搜索抽核心文章做重复页比对；两步确认受害后，再启用干扰码止损、留证据走投诉。全程不需要动前台报表——它在任何一个环节都不是判定依据。

常见问题

问：CDN 挡一阵是不是更省事？ 答：能减负载，但挡不住伪装正常访问节奏的脚本，也不解决历史内容已被搬走的事实；可作为处置组合的一部分，不能代替日志定位。

问：被搬运的页面要不要发投诉？ 答：先固定证据再投诉：带时间的原发页快照、对方页面的抓取存证、日志里对应搬运窗口的记录，三件套齐了投诉效率最高。

问：小站没有能力看日志怎么办？ 答：把频率降一级：每周按 IP 聚合一次访问日志的头部流量，加每月一次标题全称的重复页抽查，两项都是十几分钟的工作量，足以发现整站级搬运。