253 lines
7.0 KiB
Markdown
253 lines
7.0 KiB
Markdown
# 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 一致性。
|