2026年了，浏览器里正文好好的，抓取工具拿到的 HTML 却只有空壳 div，这段字是 JS 补上去的吗？

浏览器里正文读得到、抓取工具拿到的 HTML 里却只有空壳 div，多数时候不是「渲染方式选错了」，而是首屏正文、可发现链接、独立 URL 这三件事只存在于浏览器里。2026 年的实际表现是：Google 与百度都会执行一定程度的 JavaScript，但渲染要排队、要消耗抓取预算，新站与小站更容易只停在被抓到空壳这一步。按交付经验，先把三查跑完、把源码可读和入口可发现补齐，成本常见比改渲染方案低一个量级。

抓到的 HTML 是空壳，正文丢在哪一步？

先分清抓取和渲染：爬虫先拿到服务器返回的 HTML，再决定要不要把这个页面放进渲染队列执行脚本。排队就有延迟，也有预算上限；页面越多、脚本越重，越容易只走完前一半流程。所以「用户在浏览器里能看到」和「引擎能读到」是两个不同结论，不能用前者推断后者。

两家引擎的差异，落在三个可核对的地方

• 渲染触发：Google 会把相当一部分页面送入渲染服务，抓取与渲染可能分两次完成；百度对 JS 渲染的覆盖更依赖页面权重与抓取配额，新站更容易只拿到初始 HTML。
• 排队时间：首屏要等接口返回、几秒后才出正文的页面，两边都可能被判为首屏无有效内容。
• 核对方式：两家搜索资源平台都提供抓取诊断、网址检查类工具，能看到抓到的 HTML 与渲染后的 HTML，差异直接写在报告里，比凭感觉猜测可靠。

还有一点：把「能不能收录」押在对方的渲染预算上，本身就不可控。公开文档里，Google 长期建议关键内容不要只靠脚本执行后才出现，百度也强调重要内容尽量在源码中可读。两家都在进步，但对新站来说，这份不确定性不值得赌。

可见性三查，动手前把顺序走完

与其争论引擎能力，不如按固定顺序自查：查源码、查渲染、查入口。顺序不能颠倒，因为每往下走一步，改动成本都明显上升——改文案和小结构当天能做，动构建要排期，换框架要走一轮回归。

1. 查源码：打开页面源代码，搜索首屏核心文案。搜不到就是初始 HTML 里没有正文，这是优先该修的一层。经验区间：首屏主标题、正文前 100–200 字、主要栏目名能在源码里直接读到。
2. 查渲染：浏览器禁用 JS 再看一次。只剩 logo 和空白容器，说明内容完全依赖脚本。合格线：关掉 JS 仍能读到核心信息和至少一组站内链接。
3. 查入口：列表、详情、分页之间有没有真实 a 标签互链（div 加 onclick 不算）。合格线：从首页出发三次点击内可达主要栏目页，且链接在源码里可见。

第三步常被漏掉。有的团队把首屏 SSR 补上了，内链还是按钮跳转，页面能渲染却没被发现，收录照样不动。三查的价值，是把「渲染不出来」和「没被发现」拆开，避免一上来换框架、做完才发现问题不在那里。

四种做法摆一起，成本差在哪

确认要动构建后再选方案，按页面规模和更新频率选，别按框架热度选。下面的周期都是经验区间，实际受页面数量、数据依赖和部署环境影响，波动可能很大。

• CSR 加首屏骨架：改动最小，适合登录后系统、后台和低频营销页；对公开内容页基本不解决问题，只是把空壳换个样子。
• SSG 预渲染：构建时生成静态 HTML，适合官网、活动页、帮助中心这类更新不频繁的内容。接入经验区间常见 2–8 人日，代价是构建时间随页面数增长。
• SSR 服务端渲染：首屏直出、数据实时，适合商品详情、资讯列表这类高频更新的公开页。改造常见区间 1–4 周，还要算上缓存、降级和运维。
• 按 UA 分流的动态渲染：只给爬虫返回静态版本。Google 公开文档说明过它属于过渡手段、不推荐长期依赖，用户与爬虫看到的页面不一致本身也有风险，一般只作临时救急。

要提醒的是：SSR 只解决首屏可见性，不解决内容质量和内链结构。一个本来没有站内链接、正文又单薄的站改成 SSR，收录大概率没有明显变化。合理顺序是内容与结构 → 入口与 URL → 渲染方式，倒过来做容易白花预算。

交付现场：先上线再补 SEO 的那次返工

一个典型约束是：甲方要求先上线、SEO 后面补，数据来自第三方 CMS，联调窗口只有两周，字段口径还卡在对方那边。做法上先挑两件低风险的事——列表页由服务端输出静态入口链接，详情页用预渲染生成首屏正文，构建脚本复用现有流水线，不新增服务端。上线后 Google 侧两到三周开始出现正文摘要，百度侧仍然只收标题。

后来排查发现：详情页 URL 带一串参数，站内又没有 a 标签互链，等于页面能渲染、却没法被发现。补了静态化路径和站点地图之后才逐步改善，前后多花约 5–8 人日返工；这个数在不同项目里波动不小，常见区间大致 3–10 人日，取决于页面数量和参数结构。代价其实不在技术上，而在排期：改构建要重新走一遍测试、回归和发布窗口。

适用与不适用边界

适合做这轮改造的：面向公开搜索流量的官网、商品与资讯详情页、帮助中心、活动落地页，也就是内容本身有检索价值、URL 能独立分享的页面。这类页面一处改造常能带一片流量，投入产出比较清楚。

不必上的：登录后的后台系统、强交互工具页、内容全部来自用户私有数据的页面，本来就不需要被搜索引擎收录，把 SSR 成本花在这里属于浪费。访问量很小、内容长期不变的站点，优先做静态化和内链，通常比接 SSR 更划算，维护也轻。

还有一种情况要先停手：正文本身单薄、同质化严重，或者拿不到独立 URL（比如全走路由参数加 hash），这时候动渲染，等于把预算投在了不合适的地方，先补内容和 URL 结构。

常见问题

关掉 JS 就看不到正文，是不是一定要上 SSR？

不一定。内容更新不频繁的站，预渲染或静态化就够；只有详情页高频更新、又要求首屏直出时，SSR 才更合适。

首屏放骨架屏，会被当成空页面吗？

有可能，等于把判断权交给引擎。骨架之外建议保留一段静态核心文案或说明文字，让初始 HTML 里就有可读内容。

只给搜索引擎返回静态 HTML，这种做法还行得通吗？

属于临时手段。Google 侧不推荐长期依赖，用户和爬虫看到的页面不一致也有风险，能预渲染就别长期走这条路。

只改 title 和描述，能救收录吗？

作用有限。标题是入口不是内容，正文在源码里读不到时，改标题带来的变化通常很小，先把正文和链接补上更实际。

如果手上正好有一套「浏览器里正常、抓到的 HTML 是空壳」的页面，建议先按三查跑一遍，把源码可读和入口可发现补齐，再评估要不要动构建。这套顺序适用于有公开内容页、又愿意投入一两个迭代的团队；对纯内部系统或几乎不更新的单页，先做静态化和内链就足够。