205 lines
4.6 KiB
Markdown
205 lines
4.6 KiB
Markdown
# 1279-SEONexus 第一批候选修正方案评审建议 - 2026-04-17
|
||
|
||
## 目的
|
||
|
||
这份文档用于在 `1278` 的候选修正方案基础上，再往前走一步：
|
||
|
||
- 不只是列方案
|
||
- 而是给出当前更推荐的顺序和取舍建议
|
||
|
||
它的目标受众就是主 Codex。
|
||
|
||
## 先说结论
|
||
|
||
当前最值得主 Codex 优先推进的方案，不是“收兼容入口”，而是：
|
||
|
||
1. 先统一 host 规范口径
|
||
2. 再确认播放页 canonical 立场
|
||
3. 最后才动兼容入口和 fallback 边界
|
||
|
||
## 一、为什么 host 统一应该排第一
|
||
|
||
### 1. 模板与 sitemap 目前存在直接冲突
|
||
|
||
模板 canonical 普遍走：
|
||
|
||
- `https://{$DomainModel->d_domain}...`
|
||
|
||
而 sitemap 生成普遍走：
|
||
|
||
- `https://www.{$DomainModel->d_domain}...`
|
||
|
||
这不是抽象风险，而是当前代码中已经明确存在的双口径输出。
|
||
|
||
### 2. 日志已经证实多站存在 `www` / 裸域混合抓取
|
||
|
||
最近 24 小时百度抓取里，至少以下 base domain 已经同时出现裸域和 `www`：
|
||
|
||
- `ningxiaowei.com`
|
||
- `www.ningxiaowei.com = 78`
|
||
- `ningxiaowei.com = 9`
|
||
- `haotianhaiyuan.com`
|
||
- `www.haotianhaiyuan.com = 18`
|
||
- `haotianhaiyuan.com = 14`
|
||
- `yagyjt.com`
|
||
- `yagyjt.com = 162`
|
||
- `www.yagyjt.com = 17`
|
||
- `ctshuhua.com`
|
||
- `www.ctshuhua.com = 78`
|
||
- `ctshuhua.com = 72`
|
||
- `sctyjz.com`
|
||
- `sctyjz.com = 11`
|
||
- `www.sctyjz.com = 9`
|
||
- `junhaolab.com`
|
||
- `www.junhaolab.com = 9`
|
||
- `junhaolab.com = 4`
|
||
|
||
### 3. 这说明 host 级规范化损耗是真实存在的
|
||
|
||
因此：
|
||
|
||
- host 统一不是“理论上更好”
|
||
- 而是当前最像正在真实消耗抓取预算的一条主线
|
||
|
||
## 二、为什么播放页 canonical 应该排第二
|
||
|
||
### 1. 它影响深页 `301` 的理解方式
|
||
|
||
当前播放页模板：
|
||
|
||
- `robots = noindex,follow`
|
||
- `canonical = 当前播放页自身`
|
||
|
||
这会直接影响主 Codex 如何判断当前 `play|301`：
|
||
|
||
- 如果播放页本来就该保留自身规范 URL，那么当前主要问题是兼容入口过多
|
||
- 如果播放页本来应 canonical 回详情页，那么当前实现就更像未收口
|
||
|
||
### 2. 这条线虽然重要，但收益更依赖设计取舍
|
||
|
||
和 host 统一不同，这条线不是单纯的工程不一致。
|
||
|
||
它更像是：
|
||
|
||
- SEO 策略选择
|
||
|
||
所以它应排在第二位：
|
||
|
||
- 先统一明显冲突的 host
|
||
- 再确认播放页 canonical 立场
|
||
|
||
## 三、为什么兼容入口收缩不应排第一
|
||
|
||
### 1. 当前兼容入口仍在真实命中
|
||
|
||
日志里当前仍高频出现：
|
||
|
||
- `voddetail`
|
||
- `vodplay`
|
||
- `video-info`
|
||
- `video-play`
|
||
- `video-show`
|
||
- `vodbf`
|
||
|
||
这说明兼容入口不是“死代码”。
|
||
|
||
### 2. 现在先删，风险很高
|
||
|
||
如果主 Codex 第一刀就去删或大幅收缩兼容入口，很容易把当前一批还能：
|
||
|
||
- `301 -> 200`
|
||
|
||
的旧 deep link，重新打回：
|
||
|
||
- `404`
|
||
|
||
### 3. 更稳的顺序
|
||
|
||
更合理的是：
|
||
|
||
1. 先把 host 统一
|
||
2. 再把 canonical 立场统一
|
||
3. 观察日志
|
||
4. 再决定兼容入口是否还能继续收
|
||
|
||
## 四、为什么 fallback 边界也不应排第一
|
||
|
||
### 1. fallback 很可能正在帮助压低 `404`
|
||
|
||
当前 `404` 的明显下降，不排除有一部分就是 fallback 机制在止血。
|
||
|
||
### 2. 现在先收 fallback，会让数据倒退
|
||
|
||
如果主 Codex 在 host / canonical 还没统一之前，就先把 fallback 收紧，那么很可能会出现：
|
||
|
||
- `404` 重新回升
|
||
|
||
这样会把问题重新搅混，不利于判断主线修正是否有效。
|
||
|
||
## 五、当前更推荐的执行顺序
|
||
|
||
### 第一阶段
|
||
|
||
先统一以下几类输出的 host：
|
||
|
||
- 首页 canonical
|
||
- 分类 canonical
|
||
- 详情页 canonical
|
||
- 播放页 canonical
|
||
- sitemap
|
||
- RSS
|
||
- 结构化数据里的 URL
|
||
|
||
目标：
|
||
|
||
- 先让模板、站内主输出、sitemap 至少在 host 维度统一
|
||
|
||
### 第二阶段
|
||
|
||
再确认播放页 canonical 策略：
|
||
|
||
- 保留播放页自身
|
||
或
|
||
- 回详情页
|
||
|
||
目标：
|
||
|
||
- 让 `play` 页的规范信号有明确立场
|
||
|
||
### 第三阶段
|
||
|
||
最后再做：
|
||
|
||
- 兼容入口分组收缩
|
||
- fallback 适用范围收缩
|
||
|
||
目标：
|
||
|
||
- 在不把旧 deep link 直接打回 `404` 的前提下，继续压深页 `301`
|
||
|
||
## 六、当前最不建议的操作
|
||
|
||
### 1. 不建议先删大量历史兼容入口
|
||
|
||
原因：
|
||
|
||
- 风险最大
|
||
- 最容易直接把数据打坏
|
||
|
||
### 2. 不建议先动 fallback
|
||
|
||
原因：
|
||
|
||
- 当前还没搞清楚它对 `404` 下降贡献有多大
|
||
|
||
### 3. 不建议只改单个模板 canonical
|
||
|
||
原因：
|
||
|
||
- 当前问题是系统性 host 双口径
|
||
- 只改单页模板，很容易头痛医头
|
||
|
||
## 给主 Codex 的一句话
|
||
|
||
> 当前最值得优先批准推进的，不是“收旧路由”，而是“统一 host 输出口径”；因为这条线同时有代码证据和日志证据，而且副作用最可控、验证也最直接。
|