百度新闻收录：动态页面怎样确认可见内容？交付前先锁定可见结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /20f132fa517c.html
📄
百度新闻收录：动态页面怎样确认可见内容？交付前先锁定可见结果
确认动态页面在百度新闻收录语境下的可见内容，不能只看浏览器里“看起来有字”，而要以不执行脚本时返回的HTML为基准，再对照渲染后的页面。交付时最稳的做法是：先约定“哪些内容必须可见”，再分别保存原始HTML、渲染结果和判定记录，最后按同一份清单验收。
先定义交付物：两类快照加一份判定表
多人协作最容易返工的地方，是有人用浏览器截图交差，有人用查看源代码交差，结论自然对不上。建议把交付物固定为三样：
- 原始响应快照：保存服务器返回的HTML，不经过浏览器脚本执行。
- 渲染后快照：保存脚本执行完成后的页面结构或可读文本。
- 判定表：逐条记录标题、正文、发布时间、作者等字段在两种快照中是否存在。
验收标准由内容负责人提前写明，例如“新闻标题和正文段落必须在原始HTML中可读到”。如果只写“页面能打开”，执行人无法判断该用哪份快照，返工几乎必然发生。
用“关闭脚本”的方法判断内容是否真的可见
最直接的检查项是：禁用JavaScript后重新请求页面，看关键内容是否仍然出现。可以用命令行抓取工具保存响应，也可以在浏览器开发者工具中临时禁用脚本后刷新。判断规则如下：
- 原始HTML中能找到标题和正文 → 内容属于服务端输出或静态输出，可见性较稳。
- 原始HTML只有空容器，文字出现在渲染后 → 内容依赖脚本注入，需要单独评估抓取与收录风险。
- 两种快照都有文字，但字段不一致 → 以约定的必见字段为准，逐项核对，不能凭整体印象通过。
这里要区分“可能原因”和“已经定位的原因”。原始HTML为空可能是脚本注入，也可能是服务端根据请求头返回了不同模板，还可能是抓取工具被拦截。只有分别复现并对比响应后，才能下结论。
把可见内容拆成字段，而不是笼统说“正文可见”
新闻类页面通常包含多个可独立判断的字段。交付清单建议至少覆盖：
- 新闻标题：是否在原始HTML的
<h1>或标题标签中出现。 - 正文主体：是否以段落文本形式存在，而不是仅存在于脚本变量中。
- 发布时间：是否可读、格式一致，且与页面展示一致。
- 来源与作者：是否为文本，而非图片或脚本拼接。
- 列表页摘要：动态加载的列表项是否在原始响应中可见。
每个字段都要有明确的通过条件。例如“正文主体在原始HTML中至少出现前两段”，比“正文可见”更容易验收，也能减少不同执行人之间的理解偏差。
抓取限制、站点地图与可见内容是三件事
robots.txt 的抓取限制不等于可靠的索引移除，允许抓取也不等于内容会被收录；站点地图不保证收录，它只提供发现线索。HTTPS 不保证安全无漏洞或排名。判断动态页面时，应把“能否被抓取”“内容是否可见”“是否被收录”分开记录，避免用一项结果替代另一项。需要核对具体规则时，直接查看目标站点当前的 robots.txt 与页面响应，不凭旧经验推断。
交付验收：用同一份清单减少返工
建议在任务开始时就确定责任分工：开发负责提供原始响应与渲染结果，内容负责确认必见字段，验收人按判定表逐项打勾。验收时随机抽取列表页和详情页各若干条，分别检查原始HTML与渲染结果。若某字段只在渲染后出现，应标注为“依赖脚本”，并说明是否需要改造为服务端输出。
下一步可以直接做一件事：挑一个动态新闻详情页，保存它的原始响应和渲染后文本，按上面的字段清单逐项标记“原始可见”“仅渲染可见”或“均不可见”，把结果作为改造与复验的依据。
