# 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 边界。