# 1274-SEONexus 老模板蜘蛛日志变化与代码判断更新 - 2026-04-17

## 目的

这份文档是在 `1272` 与 `1273` 的基础上，继续把最新日志变化往代码判断上推进一步。

这一轮重点回答两个问题：

1. 为什么 `2026-04-17` 的 `404` 会明显下降
2. 为什么同一时间又出现更多 `444`

## 和前置文档的关系

- `1271`：日志观察首轮结论
- `1272`：日志现象与代码位置映射
- `1273`：`2026-04-17` 新日志更新
- `1274`：针对 `404 -> 444` 结构变化的代码判断

## 本轮关键结论

一句话总结：

> `2026-04-17` 这一轮里，`404` 下降更像是“历史深链和错误 ID 被更多地兜住了”，而 `444` 上升目前没有在应用层看到直接返回逻辑，更像是前置层或安全规则拦截带来的新噪音形态。

## 一、为什么 `404` 会明显下降

### 1. 旧深页入口早就不是直接裸 404

核心文件：

- [router.php](/www/wwwroot/VideoSource2/code/app/home/config/router.php)

已经明确存在大量历史兼容入口：

- `voddetail`
- `vodinfo`
- `vod`
- `video-info`
- `video-detail`
- `video`
- `shipin`
- `vodplay`
- `video-play`
- `video-show`
- `shipin-play`
- `shipin-bofang`

这意味着：

- 日志里的旧详情页、旧播放页路径
- 很多并不是“根本没路由，直接 404”
- 而是已经被路由先接住了

所以 `404` 的下降，不能只理解成“错误入口少了”，也要理解成“已有更多旧入口被应用层成功承接”。

### 2. VideoService 存在明显的 fallback 回退链

核心文件：

- [VideoService.php](/www/wwwroot/VideoSource2/code/app/services/VideoService.php:905)

关键逻辑：

- `getVideoByVId()` 查不到原始 `v_id` 时，不会立刻结束
- 而是进入 `resolveFallbackVideoByRequest()`

`resolveFallbackVideoByRequest()` 的处理顺序是：

1. 先读 host 维度的 fallback 绑定表
2. 如果已有绑定，则直接回用之前找到的视频
3. 没绑定时，从库里随机采样一批视频
4. 找到可用视频后，把“请求旧 id -> 真实新 id”的绑定写入本地文件
5. 如果随机采样还失败，再走按排序兜底

对应代码点：

- `readFallbackBindings()`
- `writeFallbackBindings()`
- `fallbackBindingsPath()`
- `_fallback_reason = bound_random_video / random_video / ordered_fallback_video`

### 3. 这条链足以解释一部分“404 明显下降”

这意味着：

- 某些过去会直接 404 的旧视频 ID
- 现在可能被 fallback 机制回落成一个可访问页面

所以：

- `404` 下降未必全部来自“外部噪音消失”
- 也可能来自“应用层兜底更积极了”

这对 SEO 的影响有两面性：

- 正面：减少了硬 404，抓取预算不再直接浪费
- 风险：如果旧 URL 被回落到语义不一致的视频页，就会带来 canonical 和内容一致性风险

## 二、为什么 `444` 会明显上升

### 1. 当前应用层没有看到明确的 `444` 返回逻辑

本轮代码检索没有在应用层发现：

- `http_response_code(444)`
- `return 444`
- `HttpException(444)`

这意味着：

- 当前日志里的 `444`
- 很大概率不是 ThinkPHP 应用层主动抛出来的

### 2. 应用层的主动拦截主要还是 `404`

核心文件：

- [SiteContext.php](/www/wwwroot/VideoSource2/code/app/services/SiteContext.php:560)

在 `limitRequestRate()` 和 `checkCnzzCookie()` 里，可以看到多类拦截：

- 黑名单 IP
- 普通访客短时限速
- 普通访客高频请求拉黑
- 伪 Googlebot UA
- `Amazonbot / zgrab / crawler` 等 UA
- 无 CNZZ cookie 的普通访客

但这些分支最终抛出的都是：

- `HttpException(404, ...)`

而且 `isSpider()` 里对以下蜘蛛是直接白名单放行的：

- `Baiduspider`
- `Googlebot`
- `Sogou`
- `Bytespider`
- `Bingbot`
- 等主流搜索蜘蛛

这说明：

- 对真实 `Baiduspider` 来说，应用层限速本身不太像当前 `444` 的直接来源

### 3. 当前 `444` 更像前置层或安全规则拦截

从日志表现看，`444` 主要集中在：

- `/zb_system/login.php`
- `*.rar`
- `*.zip`
- `*.txt`
- `/www.rar`
- `/wwwroot.rar`

这类 URL 具有明显特点：

- 都不像正常内容页
- 更像安全探测、压缩包探测、站点根目录打包探测

结合本轮代码检索结果，更合理的判断是：

- 这类请求大概率在更前层就被拦掉了
- 例如 nginx / waf / 黑名单 / 探测规则

所以：

- `444` 的上升不应直接按“SEO 主路径坏了”解读
- 更像“非内容型噪音被更前层提前拒绝”

## 三、对当前日志变化的更准确解释

### 1. `404` 下降，不等于所有问题都解决了

更准确的说法应该是：

- 旧错误入口有一部分确实少了
- 另一部分则被路由兼容和 fallback 机制兜住了

### 2. `444` 上升，不等于主内容路径一定被误伤

更准确的说法应该是：

- 当前看到的 `444`
- 主要还集中在探测型、后台型、压缩包型 URL

如果后续 `444` 开始扩散到：

- `robots.txt`
- `sitemap*.xml`
- `/`
- `detail`
- `play`

那才是更值得警惕的 SEO 主路径误伤。

### 3. 目前最值得继续盯的仍然是深页 `301`

原因很简单：

- `404` 下降已是阶段性利好
- `444` 当前更像安全噪音
- 但 `yagyjt.com` 这类站点的 `detail|301 / play|301` 仍接近 `200`

这说明：

- 主内容抓取链路的最大损耗，依然还在深页规范化

## 四、给主 Codex 的代码排查建议更新

### 1. 优先继续查深页规范化，不要被 `444` 全部带偏

当前 `444` 虽然增加，但从现象和代码看：

- 还更像边缘噪音
- 暂时不像主内容入口集体误伤

所以主线仍应优先：

- 查 detail/play 主输出和兼容跳转链
- 查 canonical 是否和当前 family 一致

### 2. 对 fallback 机制要做“收益”和“风险”双向评估

`VideoService::resolveFallbackVideoByRequest()` 这条链现在值得主 Codex 明确判断：

- 它是不是正在帮我们减少 404
- 它是否会把错误 deep link 回落到语义不相干内容
- 这是否会影响 canonical、一致性、搜索引擎理解

### 3. `444` 这条线更适合联动前置层配置看

因为当前仓库内没有明显应用层 `444` 返回实现，所以如果主 Codex 要深挖 `444`，下一步更应该查：

- nginx 配置
- 前置防护规则
- UA / 路径黑名单策略

而不是只在 PHP 应用层里继续找。

## 五、补充说明

本轮尝试查看仓库最近提交时，`git` 返回了仓库 ownership 安全限制：

- `fatal: detected dubious ownership in repository at '/www/wwwroot/VideoSource2'`

因此这次没有继续依赖 `git log` 判断“哪次提交导致了日志变化”，这里只基于当前代码结构和最新日志做判断。

## 一句话交接

> 当前 `404` 的显著下降，很可能既有入口噪音减少的因素，也有 `VideoService` fallback 兜底在起作用；而 `444` 的上升目前更像前置层拦截探测噪音，不像应用层主动误伤主内容入口，所以主 Codex 仍应优先盯深页 `301` 和 canonical/family 一致性。