SEONexus/docs/old-tmp-seo/09-第一批候选修正方案-2026-04-17.md

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
• VideoService.php

模板里最终拼的是：

• https://{$DomainModel->d_domain}...

典型位置：

• 首页
• 详情页
• 播放页
• 分类页

而 sitemap 生成里大量直接写：

• https://www.{$DomainModel->d_domain}...

典型位置：

• VideoSiteMapLogic.php
• SiteMapLogic.php

候选修正

把 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

当前 canonical 指向：

• 当前播放页自身 URL

同时：

• robots = noindex,follow

候选修正方向 A

继续保留播放页 canonical 指向播放页自身。

适用前提：

• 业务明确希望每个播放页都拥有自洽的规范地址
• 只是通过 noindex 控制搜索引擎是否收录

候选修正方向 B

把播放页 canonical 改回详情页。

适用前提：

• 业务希望搜索引擎主要把权重聚合到详情页
• 播放页只作为观看页存在，不作为核心规范承载页

预期收益

如果改为回详情页，可能带来：

• 更强的 detail 聚合信号
• 更少的播放页规范化分叉

潜在副作用

如果播放页承载了明显不同的信息结构，强行 canonical 回详情页，也可能让页面意图变得不够清晰。

当前更值得主 Codex 先做的事

不是立刻改，而是先明确设计目标：

• “播放页保留自身 canonical”是设计决定 还是
• “本来想回详情页，只是现在实现成了播放页自身”

候选方案三：收缩历史深页兼容入口

优先级：P1

当前现状

兼容入口非常宽：

• router.php

包括：

• 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

查不到原始 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 边界。