2026年了，页面 title 在源码里看不到，百度收录的标题是从哪来的？

页面标题如果在浏览器「查看网页源代码」（Ctrl+U）里看不到，而是靠 JS 挂载后写入，百度抓取到的初始 HTML 里通常还是模板默认值甚至空值。Google 多数会排队执行 JS 后再取一次 DOM，百度对 JS 渲染的覆盖和延迟更保守，于是同一套代码常出现「Google 标题对、百度是默认那份」。2026 年按交付习惯，要收录的页面应让 title、description、canonical 直出在初始 HTML，JS 动态写入只作为增强。

直出 HTML 与渲染后 DOM 差在哪

搜索引擎抓一个页面通常分两步：先请求服务器拿回原始 HTML，再在有渲染能力时执行页面里的 JS，得到渲染后的 DOM。问题在于两次看到的可能是两个页面：初始 HTML 取决于服务端或构建期吐出了什么，渲染后 DOM 取决于前端脚本跑完后的结果。

TDK 最容易踩在这条缝上，因为很多项目的做法是路由切换时用 JS 改 document.title 和 meta 标签。浏览器里看完全正确，但初始 HTML 里往往还是模板默认值。

• 应优先直出的字段：首屏 title、description、canonical
• 主题判断用：h1 与首屏正文的关键段落
• 发现入口用：指向详情页、分页的 a 标签，href 要真实可点，而不是按钮加 JS 跳转

不直出，收录和点击会受什么影响

title 是搜索结果里的主文案，description 影响点击意愿，canonical 影响多地址内容的聚合判断。这三样如果只在渲染后才出现，等于把展示位置交回给平台默认策略：有的平台抓页面第一段文字拼标题，有的直接用站点名占位。

更实际的影响是判定成本。百度对 JS 渲染的覆盖和延迟历来比 Google 保守，Google 虽然会执行 JS，但渲染是排队进行的，并非每次抓取都立刻做。动态写入只能算增强，救不了完全依赖初始 HTML 的那条链路。

• 结果标题失控：平台自行拼装，品牌词的位置和长度都不可控
• 摘要不贴题：description 缺失时平台截取首段，常把导航文字也带进去
• 聚合不稳定：canonical 后置写入，多参数、多排序地址更难收敛

几种做法对比：从纯 CSR 到同构 SSR

按投入产出排序，2026 年项目里常见四条路。周期只是经验区间，实际差异主要来自模板数量、是否已有构建流水线、以及要不要处理登录态与缓存。

• 纯前端 JS 注入 TDK：改动集中在组件层，经验区间 0.5～2 人天（站点级）；只适合登录后页面和后台，收录基本指望不上。
• 构建期预渲染（prerender / 静态生成）：把 TDK 和首屏内容写进静态 HTML，经验区间 2～8 人天，取决于模板数量和路由参数复杂度；适合路由有限、内容相对静态的站点。
• 服务端或模板层注入：改后端模板或 Node 层，经验区间 1～5 人天；适合已有服务端渲染能力的站点，改动面通常最小。
• 同构 SSR：经验区间 1～4 周（含联调、缓存与降级改造）；适合内容量大、数据实时、对首屏有要求的站点，代价是运维与排错复杂度上升。

选哪条不用追求统一：同一个站点里，入口页预渲染、后台保持 CSR 是很常见的组合。

适用与不适用边界

判断标准其实很直接：这个页面是否指望从搜索结果进来。是，就值得为它做直出；不是，做了就是净增成本。

• 值得做：文章页、商品详情、帮助中心与 FAQ、说明型活动页、带分页的列表页
• 不必做：后台管理、数据看板、内部工具、登录后才可见的内容
• 可以先不做：生命周期很短、主要靠分享链接传播的一次性页面，用短链或单独落地页承接即可

如果页面本身不需要从搜索进入，为它上 SSR 或预渲染属于不必要的投入；不要为了「架构统一」顺手全站改造，先把真正的入口页做扎实更划算。

交付现场：预渲染漏配一次，代价是补一轮改稿

在预算偏紧的一次交付里，甲方只给接口、不给模板层改造时间，周期压到两周内，还要求正文和后台内容保持一致。我们的做法是构建期预渲染文章页与商品详情页，把 TDK 和首屏正文写进静态 HTML，列表页保留客户端渲染，只把分页入口换成真实 a 链接。上线后收录量级是缓慢增长的，涨幅与域名历史关系很大，不建议当成任何承诺；代价是每新增一类详情路由都要回顾预渲染配置，漏配的那一次直接让一批页面继续抓默认标题，又补了一轮改稿。

按经验区间，模板级页面通常覆盖 10～30 个模板就能拿到大部分入口收益。验收时抽 5～10 个代表性 URL（首页、列表页、两个带参详情页、一个带筛选参数的列表页），逐个按 Ctrl+U 看源代码，确认目标 title、description、canonical 都在 HTML 里，再用平台抓取工具复核一次。这份清单可以写进交付文档，作为上线前的一次核对动作。

常见问题

Google 会执行 JS，是不是就不用管直出了？

执行不等于每次都执行、也不等于及时。渲染要排队、抓取预算有限，关键字段直出成本远低于事后排查收录异常的成本。

用前端 head 管理方案改 title，算直出吗？

不算。这类方案只在浏览器里改 DOM，初始 HTML 仍是默认值。要让同一份 head 数据在服务端或构建期也渲染出来，才算直出。

只在首页写死 title，内页靠 JS 改，影响大吗？

影响主要在内页。搜索流量大多落在详情页和文章页，内页标题缺失时结果页标题由平台自行拼装，质量不可控。

怎么快速判断一个页面有没有直出？

按 Ctrl+U 看源代码，搜索 title、description、canonical 和首屏关键词。源代码里没有就是没直出，F12 里能看到不算。

预算有限时先改哪几个页面？

按流量排序，优先改详情页、文章页、商品页这类模板级页面，通常覆盖 10～30 个模板就能拿到大部分入口收益，先做模板再谈全量。

要动手的话，建议先做一次首屏直出核对，把差异清单落成表格，再按流量排优先级决定改哪些模板。内容量大、数据实时的站点再考虑同构 SSR；路由有限、内容偏静态的站点用构建期预渲染通常更划算。纯后台与登录后页面不必为此投入，把预算留给真正的入口页。