259 lines
6.3 KiB
Markdown
259 lines
6.3 KiB
Markdown
# 1278-SEONexus 第一批候选修正方案 - 2026-04-17
|
||
|
||
## 目的
|
||
|
||
这份文档用于把 `1277` 的只读审查发现，进一步收敛成主 Codex 可以直接评估的第一批候选修正方案。
|
||
|
||
这里先不进入具体代码实现，只做三件事：
|
||
|
||
1. 明确候选修正点
|
||
2. 说明它可能解决什么问题
|
||
3. 说明潜在副作用和验证重点
|
||
|
||
## 先说结论
|
||
|
||
当前最像值得优先动手的，不是十几处零散小修，而是下面 3 条主线：
|
||
|
||
1. 统一模板 canonical host 与 sitemap host
|
||
2. 明确播放页 canonical 策略
|
||
3. 收缩历史深页兼容入口或跳转链
|
||
|
||
## 候选方案一：统一 canonical 与 sitemap 的 host 口径
|
||
|
||
优先级：`P0`
|
||
|
||
### 当前现状
|
||
|
||
模板侧 `videoGpt1` canonical 普遍通过模板标签走 `VideoService -> UrlBuilder` 输出：
|
||
|
||
- [Site.php](/www/wwwroot/VideoSource2/code/extend/template/taglib/Site.php:238)
|
||
- [VideoService.php](/www/wwwroot/VideoSource2/code/app/services/VideoService.php:87)
|
||
|
||
模板里最终拼的是：
|
||
|
||
- `https://{$DomainModel->d_domain}...`
|
||
|
||
典型位置：
|
||
|
||
- [首页](/www/wwwroot/VideoSource2/code/app/home/view/videoGpt1/index/index.html:99)
|
||
- [详情页](/www/wwwroot/VideoSource2/code/app/home/view/videoGpt1/video/getVideoInfo.html:39)
|
||
- [播放页](/www/wwwroot/VideoSource2/code/app/home/view/videoGpt1/video/getVideoPlayUrl.html:117)
|
||
- [分类页](/www/wwwroot/VideoSource2/code/app/home/view/videoGpt1/video/getCategory.html:34)
|
||
|
||
而 sitemap 生成里大量直接写：
|
||
|
||
- `https://www.{$DomainModel->d_domain}...`
|
||
|
||
典型位置：
|
||
|
||
- [VideoSiteMapLogic.php](/www/wwwroot/VideoSource2/code/app/task/logic/VideoSiteMapLogic.php:203)
|
||
- [SiteMapLogic.php](/www/wwwroot/VideoSource2/code/app/task/logic/SiteMapLogic.php:158)
|
||
|
||
### 候选修正
|
||
|
||
把 sitemap 输出 host 统一到与模板 canonical 一致的规范 host。
|
||
|
||
### 预期收益
|
||
|
||
- 压低首页 `/|301`
|
||
- 压低 host 级 `301`
|
||
- 降低裸域 / `www` 并行抓取
|
||
- 让 sitemap、canonical、站内链接至少先在 host 维度统一
|
||
|
||
### 潜在副作用
|
||
|
||
- 如果真实线上规范 host 本来就是 `www`，而模板 canonical 才是错的，那么简单改 sitemap 会把问题转移，而不是解决
|
||
|
||
### 实施前必须先确认
|
||
|
||
- 当前业务最终想要的规范 host，到底是裸域还是 `www`
|
||
- 前置层 / nginx 的最终 host 跳转策略是什么
|
||
|
||
### 当前更倾向的判断
|
||
|
||
从现有模板和站内链接输出看，系统更像默认把裸域当规范 host。
|
||
|
||
如果这个判断成立，那么更像是：
|
||
|
||
- sitemap 侧应向模板 canonical 对齐
|
||
|
||
## 候选方案二：明确播放页 canonical 是回详情页，还是保留播放页自身
|
||
|
||
优先级：`P0`
|
||
|
||
### 当前现状
|
||
|
||
播放页模板：
|
||
|
||
- [getVideoPlayUrl.html](/www/wwwroot/VideoSource2/code/app/home/view/videoGpt1/video/getVideoPlayUrl.html:117)
|
||
|
||
当前 canonical 指向：
|
||
|
||
- 当前播放页自身 URL
|
||
|
||
同时：
|
||
|
||
- `robots = noindex,follow`
|
||
|
||
### 候选修正方向 A
|
||
|
||
继续保留播放页 canonical 指向播放页自身。
|
||
|
||
适用前提：
|
||
|
||
- 业务明确希望每个播放页都拥有自洽的规范地址
|
||
- 只是通过 `noindex` 控制搜索引擎是否收录
|
||
|
||
### 候选修正方向 B
|
||
|
||
把播放页 canonical 改回详情页。
|
||
|
||
适用前提：
|
||
|
||
- 业务希望搜索引擎主要把权重聚合到详情页
|
||
- 播放页只作为观看页存在，不作为核心规范承载页
|
||
|
||
### 预期收益
|
||
|
||
如果改为回详情页，可能带来：
|
||
|
||
- 更强的 detail 聚合信号
|
||
- 更少的播放页规范化分叉
|
||
|
||
### 潜在副作用
|
||
|
||
如果播放页承载了明显不同的信息结构，强行 canonical 回详情页，也可能让页面意图变得不够清晰。
|
||
|
||
### 当前更值得主 Codex 先做的事
|
||
|
||
不是立刻改，而是先明确设计目标：
|
||
|
||
- “播放页保留自身 canonical”是设计决定
|
||
还是
|
||
- “本来想回详情页，只是现在实现成了播放页自身”
|
||
|
||
## 候选方案三：收缩历史深页兼容入口
|
||
|
||
优先级：`P1`
|
||
|
||
### 当前现状
|
||
|
||
兼容入口非常宽：
|
||
|
||
- [router.php](/www/wwwroot/VideoSource2/code/app/home/config/router.php:209)
|
||
|
||
包括：
|
||
|
||
- `voddetail`
|
||
- `vodinfo`
|
||
- `vod`
|
||
- `video-info`
|
||
- `video-detail`
|
||
- `video`
|
||
- `shipin`
|
||
- `vodplay`
|
||
- `vodbf`
|
||
- `vodseed`
|
||
- `video-play`
|
||
- `video-show`
|
||
- `shipin-play`
|
||
- `shipin-bofang`
|
||
- `shipin-kan`
|
||
|
||
### 候选修正
|
||
|
||
不是一次性删兼容，而是分两步：
|
||
|
||
1. 先按日志命中频率分组
|
||
2. 再决定哪些入口必须保留，哪些入口可以逐步收缩
|
||
|
||
### 预期收益
|
||
|
||
- 压低深页 `301`
|
||
- 减少“多组别名 -> 同一规范页”的长期跳转预算损耗
|
||
|
||
### 潜在副作用
|
||
|
||
- 如果删掉仍被百度高频命中的入口，会把 `301 -> 200` 又打回 `404`
|
||
|
||
### 当前建议
|
||
|
||
这条线不适合第一刀就重手改。
|
||
|
||
更适合在统一 host 和 canonical 口径之后，再做第二轮收缩。
|
||
|
||
## 候选方案四：限制 fallback 的适用范围
|
||
|
||
优先级：`P1`
|
||
|
||
### 当前现状
|
||
|
||
`VideoService` 存在回退链：
|
||
|
||
- [VideoService.php](/www/wwwroot/VideoSource2/code/app/services/VideoService.php:905)
|
||
|
||
查不到原始 `v_id` 时，会：
|
||
|
||
- 读绑定
|
||
- 随机采样
|
||
- 排序兜底
|
||
|
||
### 候选修正
|
||
|
||
不是立即移除 fallback，而是评估是否加边界，例如：
|
||
|
||
- 只对部分入口生效
|
||
- 只对详情页生效，不对播放页生效
|
||
- 只在存在某些可信条件时生效
|
||
|
||
### 预期收益
|
||
|
||
- 减少“错链也 200”的语义风险
|
||
- 保留对 hard 404 的止血能力
|
||
|
||
### 潜在副作用
|
||
|
||
- fallback 一旦收紧，可能让部分当前已被兜住的旧 deep link 重新回到 `404`
|
||
|
||
### 当前建议
|
||
|
||
这条线适合在主 Codex 完成第一轮 host / canonical / 兼容入口收口后，再决定是否调整。
|
||
|
||
## 我更建议的落地顺序
|
||
|
||
### 第一刀
|
||
|
||
先统一 host 口径：
|
||
|
||
- 模板 canonical
|
||
- sitemap
|
||
- RSS
|
||
- 站内主要结构化 URL
|
||
|
||
### 第二刀
|
||
|
||
再确认播放页 canonical 的产品/SEO 立场：
|
||
|
||
- 保持播放页自身
|
||
或
|
||
- 回详情页
|
||
|
||
### 第三刀
|
||
|
||
最后再收缩历史兼容入口与 fallback 边界。
|
||
|
||
## 不建议的顺序
|
||
|
||
不建议一上来先动：
|
||
|
||
- 大规模删兼容路由
|
||
- 大规模关闭 fallback
|
||
|
||
原因：
|
||
|
||
- 这两条线会直接把一批目前还能 `301 -> 200` 的深链重新打回 `404`
|
||
|
||
## 给主 Codex 的一句话
|
||
|
||
> 第一批真正值得评估的修正方案，不是“怎么把所有问题都一起修掉”，而是先把 host 规范统一，再明确播放页 canonical 立场，最后才去收深页兼容入口和 fallback 边界。
|