SEONexus/docs/old-tmp-seo/08-第一轮只读代码审查发现-2026-04-17.md

1277-SEONexus 第一轮只读代码审查发现 - 2026-04-17

目的

这份文档是在 1275 和 1276 的基础上，进一步给主 Codex 提供“第一轮只读代码审查发现”。

这不是改动方案文档，而是：

• 先列发现
• 再说明为什么它可能对应当前蜘蛛日志
• 方便主 Codex 直接决定先改哪一处

发现一：模板 canonical host 与 sitemap host 口径明显不一致

严重度：高

证据

videoGpt1 模板侧 canonical 普遍使用：

• index.html
• getCategory.html
• getCategoryType.html
• getVideoInfo.html
• getVideoPlayUrl.html

这些位置都在输出：

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

而 sitemap 生成侧：

• VideoSiteMapLogic.php
• SiteMapLogic.php

都在直接拼：

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

为什么重要

如果站点真实规范 host 不是固定 www，那么当前系统会同时存在：

• 模板 canonical 喂一套 host
• sitemap 喂另一套 host

这会直接制造：

• 首页 /|301
• 深页 host 规范化 301
• 裸域与 www 并行抓取

对应当前日志

这和当前多站点反复出现的：

• /|301
• www 与裸域并行命中

是高度一致的。

发现二：播放页 canonical 指向播放页自身，而不是详情页

严重度：中高

证据

播放页模板：

• getVideoPlayUrl.html

当前输出：

• <link rel="canonical" href='https://{$DomainModel->d_domain}{$strPlayCanonicalUrl}'>

并且：

• $strPlayCanonicalUrl 是通过 VideoService::getVideoPlayUrl() 生成的当前播放页 URL
• 不是详情页 URL

为什么重要

这意味着当前策略是：

• 播放页 robots = noindex,follow
• 但 canonical 仍指向播放页自己

这不是绝对错误，但它值得主 Codex 明确确认设计意图：

• 是不是故意让播放页保留自身规范地址
• 还是本来希望回详情页，只是实现现在没有这么做

对应当前日志

如果播放页长期保留自己作为 canonical，再叠加历史 video-play / video-show / vodplay 兼容路径，就更容易形成：

• play|301
• 多播放路径并行规范化

这和 yagyjt.com、junhaolab.com 当前的播放页 301/200 并存现象是对得上的。

发现三：历史深页兼容入口数量非常大，且覆盖多组别名

严重度：高

证据

文件：

• router.php

当前兼容了大量 detail/play 历史入口：

• voddetail
• vodinfo
• vod
• video-info
• video-detail
• video
• shipin
• shipin-xiangqing
• shipin-neiron
• vodplay
• vodbf
• vodseed
• video-play
• video-bofang
• video-show
• shipin-play
• shipin-bofang
• shipin-kan

为什么重要

这套兼容入口本身有价值，因为它能避免旧外链直接 404。

但副作用也很明显：

• 会显著扩大“先接住，再跳一次”的路径面
• 如果 canonical、sitemap、站内链接又没有完全统一，就容易长期维持高位深页 301

对应当前日志

这和当前高频异常里的：

• /voddetail/...|301
• /vodplay/...|301
• /video-info/...|301
• /video-play/...|301
• /video-show/...|301
• /vodbf/...|301

完全一致。

发现四：分类页 canonical 与 og:url 口径不完全一致

严重度：中

证据

分类列表页：

• getCategory.html
• getCategory.html

当前表现为：

• canonical 指向分类基础页，不显式带当前分页
• og:url 指向当前分页 URL

为什么重要

这不一定是错误，因为分页页面常见策略就是：

• canonical 回第一页
• 当前页保留独立可访问 URL

但如果当前页面内容与第一页差异较大，或者系统没有对深分页做更明确的 noindex/canonical 设计，就可能造成：

• 蜘蛛抓取了分页
• 但规范化信号又全部回第一页

当前判断

这条不是现在最优先要改的点，但值得主 Codex 顺手确认是否符合当前分页 SEO 设计。

发现五：详情页 canonical、列表页 canonical、首页 canonical 都统一走非 www 口径

严重度：中高

证据

可以从以下模板直接看到：

• 首页 canonical
• 分类页 canonical
• 一级分类 canonical
• 详情页 canonical
• 播放页 canonical

都统一是：

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

为什么重要

这说明当前模板层其实已经隐含表达了一种明确立场：

• 规范 host 更像是裸域

如果真是这样，那么 sitemap 仍然统一输出 https://www. 就更像一个明确冲突，而不是单纯“不同文件各写各的”。

当前最像真实改动入口的 3 个点

1. 先统一模板 canonical host 与 sitemap host

这是当前最像“改完后能直接压掉一批 host 级 301”的地方。

2. 再明确播放页 canonical 策略

要么确认：

• 播放页 canonical 就该留在播放页

要么确认：

• 播放页 canonical 应该回详情页

现在最怕的是逻辑处于“既 noindex，又不完全统一 canonical 目标”的中间态。

3. 再评估兼容入口是否还能继续收窄

因为当前日志里已经明确能看见：

• 哪些旧入口还在持续命中
• 哪些别名组仍然在吃 301 预算

给主 Codex 的一句话

第一轮只读审查看下来，最像真问题的不是某一条单独路由，而是“模板 canonical 统一走裸域、sitemap 统一走 www、同时历史深页兼容入口又很多”这三件事叠在一起，持续制造了当前日志里看到的首页和深页 301 损耗。