老模板优化

This commit is contained in:
Your Name
2026-04-17 21:09:06 +08:00
parent 4dc78e3366
commit c8fb6956ef
60 changed files with 9113 additions and 146 deletions

View File

@@ -0,0 +1,258 @@
# 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 边界。