回看brightonSEO的渲染议题：AI建站后还要验收什么？

2024年11月19日，Danielle Rohe在brightonSEO San Diego分享了JavaScript渲染议题。公开幻灯片把渲染放进抓取与索引的过程，并讨论相关问题。本文回看的是这份公开材料，再结合当前Google文档整理验收思路，不是今天新举行会议的现场报道。会议页面 · 讲者幻灯片

这也是AI建站之后值得检查的一件事：同一张网页，初始响应、执行脚本后的内容，以及URL检查工具给出的信息，可能并不相同。把这些证据放在一起，才容易和开发者说明问题发生在哪里。

页面外观通过，不代表所有内容都已核对

用AI生成页面时，视觉反馈通常来得很快：首屏出现了，按钮有动画，产品卡片能展开。但这些操作来自当前浏览器会话，可能带着登录状态、本地缓存或刚才已经加载过的资源。

可以先选一张真正希望被搜索找到的详情页。用它自己的完整地址直接打开，而不是只从首页点进去。然后确认主要信息是否存在、刷新后是否仍能访问、重要链接能否到达正确目的地。这里不需要先争论哪个框架更适合SEO，先把这张页面的现象记录下来。

若详情页直接打开就失败，沿着首页点进去却正常，问题已经足够具体。把这个差异交给开发者，比只说“这个AI建站工具SEO不好”更容易得到有效修复。

例如，假设纸盒产品页的地址是 /products/folding-box/：从首页点击可以进入，复制地址到未登录窗口却返回404。此时应先修部署服务器对这个路径的响应。即使客户端已经写好了切换页面的代码，直接请求仍然要得到正确的页面。反过来，把所有地址都转给同一个应用外壳，也要继续测试不存在的产品，防止错误地址变成200状态的空模板。

记录时可以分成三条地址：正常纸盒详情、另一个正常详情、明确不存在的产品。第一条修好后，后两条分别验证修复有没有覆盖同类页面、有没有误把错误页变成正常页。这组样本比反复刷新首页更有用，也不要求一开始就换框架。

沿着一条URL，对照初始响应与渲染结果

Google的JavaScript说明将处理过程分为抓取、渲染和索引，并解释有些网站的初始HTML只有应用外壳，实际内容由脚本生成。Google能够处理JavaScript，但被阻止的页面或资源会影响这个过程。JavaScript SEO基础

可以给这一页列出几项必须出现的内容，例如产品名称、关键规格、购买或询盘入口、相关详情链接。分别在初始响应与渲染后的页面中查看，记下它们出现在哪一层。初始HTML里没有某项内容，是进一步核对的线索，不足以单独断言Google一定无法索引。

这份对照记录可以很短，但要保留访问条件：

同一段规格文字	初始Document响应	当前DOM	下一步
两处都有	找得到	找得到	继续核对Google测试，不再把问题停留在初始HTML
脚本加载后出现	找不到	找得到	看Google渲染是否取得相同文字与资源
渲染后仍缺失	找不到	找不到	查数据请求、脚本错误与显示条件

表中不是三个测试结论，只是整理观察的方式。登录后才出现的规格，还要确认是否本来就属于私人信息；只有确认应公开的内容，才进入公开输出修复。

最后再使用Search Console的URL检查功能查看对应页面的可用信息。当前测试与已存储的索引状态要分开理解；检查通过也不代表获得索引或排名保证。对状态含义仍不清楚时，可以先读抓取、索引与排名的区别。

可以照着做的一次单页检查

先准备一条公开的详情页URL，选出页面中一段独有文字和一个重要链接。下面以Chrome开发者工具为例说明；这是人工排查步骤，不是用普通浏览器冒充Googlebot。

1. 打开新窗口，直接输入完整URL，记录最终停留地址。若发生跳转，先确认是不是预期地址。不要只从首页点击后就开始判断。
2. 打开开发者工具的Network面板，重新加载页面，选择主要Document请求。查看状态与Response，搜索刚才选定的文字。这里看到的是这一请求返回的内容，不能把后续脚本补入的内容算作初始响应。
3. 再到Elements面板搜索同一段文字，查看当前DOM是否出现。若Response里没有、Elements里有，说明至少在这个浏览器条件下，内容经过后续处理出现；仍要继续核对Google侧结果。
4. 查看重要链接对应的元素与目标地址。同时留意Console是否有与主要内容相关的错误、Network里所需数据请求是否失败。一个无关统计请求报错，不足以解释正文缺失。
5. 保存检查时间、URL和必要片段，再用Google提供的检查工具对照。优先比较那段独有文字和链接，而不是只看截图整体像不像。

Google的JavaScript排查文档建议使用URL检查或富媒体搜索结果测试查看渲染信息、资源与错误。使用富媒体测试时，即使页面没有适用的富媒体标记，也要把标记结果与本次要检查的内容渲染问题分开。Google JavaScript排查说明

假设初始响应只有页面外壳，普通浏览器渲染后有完整产品说明，而Google测试中缺少说明，应继续查看缺的是哪个请求或资源、有没有访问限制。不能仅凭第一步没有正文就直接重写全站，也不能凭普通浏览器有正文就关闭问题。

一张规格表消失，怎样追到具体修复位置

下面是演示排查方法的假设，不是本站或某个AI建站工具的实测。纸盒页应出现“可选纸张克重”这段文字：初始Response没有，已登录浏览器的Elements有，未登录浏览器和Google实时测试的HTML都没有。

接口在未登录条件下返回401

先比较普通窗口与未登录窗口请求同一数据接口的结果。如果登录后是200并返回规格，未登录时是401，已找到可复现的访问差异。交给开发者的要求应写成“公开产品页所需的公开规格，在未登录条件下也能取得”。可以拆出只读公开数据接口，或把获准公开的规格输出到服务端HTML；客户价格、订单和私人资料仍需保留权限。

接口正常，组件却没有输出

若两边接口都是200、数据也齐全，下一步才检查模板有没有等到登录状态、同意按钮或点击动作之后才插入规格。把公开规格的显示从这些条件中分离，保留确实需要同意或权限的功能。若接口返回正确而控制台报错阻断组件渲染，要定位错误发生的组件及依赖，不必把页面上所有统计报错都当作原因。

用原失败条件复测，并检查另一个产品

修好以后，用原来失败的未登录访问重复检查，再运行Google实时测试，寻找同一段规格文字。还要打开另一个采用相同组件的产品，确认规格没有被硬写成第一款的数据。此时可以关闭“当前公开内容缺失”的缺陷；是否已重新抓取并进入索引，仍要另查后续状态。

URL实时测试与已索引结果，要分开看

Search Console首次显示的URL检查信息来自Google已保存的情况，实时测试则针对当前可访问的版本。两次查看所代表的时间不同；网站刚改好时，旧抓取信息仍然可能描述修改前的页面。URL检查工具说明

可以先记录已存储结果中的抓取时间及相关状态，再选择“测试实际网址”（Test live URL）。测试成功且详情可用时，打开“查看测试的网页”（View tested page），分别查看HTML、截图和更多信息，核对之前选出的文字及相关资源。界面项目会随测试结果而变化，没有某项信息时就如实记录，不用猜测Google看到了什么。

实时测试能帮助回答“现在能否取得并处理这张页面”，不能保证它最终被选入索引，也不能让你看到完整的排名决策。若实时结果已出现正确内容，而旧状态尚未更新，应保留两份证据并继续观察，不要把不同时间的结果当作互相矛盾的测试。

如果没有该站点的Search Console权限，可先提供浏览器侧记录，让网站负责人完成对应URL检查。不要索取不必要的管理员密码，也不要为了测试把私人内容临时公开。

能点击的文字，还要有可发现的链接

Google建议使用带有href属性的a元素承载可抓取链接，并说明JavaScript动态插入的链接也应符合这些要求。一个看起来像按钮的区域，仅靠点击事件执行跳转，不能因为人能点开，就认定搜索引擎能以相同方式发现目标。Google链接最佳实践

这对产品卡片、分页和“阅读更多”尤其值得检查。抽取一两个实际元素，看它们有没有指向真实地址；同时确认链接文案让人知道会到哪里。不要只测试鼠标点击动画。

例如，一个文章中心列出很多文章标题，却没有可提取的目标链接，用户的视觉印象与页面提供的导航信息就不一致。先把这个组件修好，再判断是否需要增加其他内链。相关原理可以参考爬虫如何发现页面。

状态码和索引指令，需要与页面用途一致

Google当前文档还提醒，应使用有意义的HTTP状态码；canonical在初始HTML和脚本处理后不应指向互相矛盾的地址。需要索引的页面，也不应依赖脚本事后移除初始noindex来保证可索引。

这些检查适合放在上线验收中。比如，正常详情页直接访问却返回错误状态，或本应不存在的地址只显示空白内容，都应该让开发者确认。测试环境复制到正式站时，也应检查是否带入了原先的索引限制。

不必把所有异常都归为渲染问题。如果页面主动要求登录，或业务确实决定不让它进入搜索，限制可能是有意设置的。修改之前先确认页面用途，避免为了消除工具提示，把本来不公开的页面开放出去。

懒加载、错误页面和旧资源，分别怎么补查

当正文依赖“展开”“加载更多”后才出现时，先分清这是用户交互的附加功能，还是搜索需要理解的主要内容。不能用手动连续点击后的页面，代表任何爬虫都会执行同样动作。应在未经这些操作的测试结果里确认主要答案是否存在，再与开发者讨论加载方式。

不存在的详情URL沿用开头的三URL样本验收即可：正常详情取得自己的信息，不存在的地址得到正确错误处理。这里无需再建一套测试；把同一结果记录交给路由和模板负责人。

如果刚发布的新脚本在浏览器正常，Google测试却仍表现像旧版本，可以核对资源文件名与实际响应，而不是继续改正文。Google排查文档提到缓存及文件指纹；具体该如何处理，应由开发者按现有构建与缓存流程解决。检查前先保留复现材料，避免清掉缓存以后再也无法说明原来发生了什么。

这些问题可能出现于AI生成的站点，也可能出现于人工开发的网站。工具生成速度快，减少的是初稿时间；页面状态、公开信息与交付责任仍需要有人验收。

如果文章中心使用无限滚动，也要测试第二批文章在哪里。假设页面每次显示12篇，后面还有24篇，验收不能止于第一屏12个链接。让后续批次有可直接访问的稳定分页URL，并能从页面的真实链接到达；复制第二页地址到新窗口时，应取得对应文章，而不是又回到第一页。用户可以保留流畅的滚动体验，搜索发现路径则不应只依赖手动滚动。Google懒加载与分页说明

需要换成服务端渲染吗？先看故障是否已经定位

当公开内容持续依赖复杂客户端条件、详情页又必须从搜索直接进入时，让主要内容先出现在响应HTML中，是值得与开发者讨论的改造方向。但名称相同的渲染方案也有更新与缓存约束，验收要落到自己的内容上。

对于更新不频繁的公司介绍、教程，可以讨论构建时生成页面；实际要问的是编辑发布后怎样触发更新，失败时谁会收到通知。对于库存、价格等变化频繁的数据，要确认哪些内容实时取得、哪些允许缓存，以及更新后多长时间内应该一致。这些都是交付约定，不能用一句“已经SSR”代替。公开幻灯片讨论了SSR、SSG和增量更新的区别；这里是在此基础上提出的项目验收问题，不把幻灯片的概括当作所有框架的绝对属性。

如果只是一个公开接口误设权限，先修权限和输出往往就能解决眼前缺陷；没有证据时整站迁移会增加另一批路由、URL和发布流程问题。若确实需要迁移，保留现有可用地址和链接，先用代表性页面证明新方案能稳定发布、直接访问和更新，再扩大范围。

把问题交给开发者时，写清哪一层不同

一个可复核的交付记录可以这样写：检查的是哪条URL、什么时间、是否登录；原本应该出现什么；初始响应和渲染后分别看到了什么；修改后需要重复哪一步。附上与问题相关的片段就够了，不必把整站所有日志一起丢过去。

观察到的现象	交给开发者的具体问题	修改后复查
首页点入正常，详情URL直接打开失败	直接请求该路径时如何处理？	用完整详情地址重新打开与刷新
正文有规格，某种访问条件下缺失	数据请求和内容加载条件是什么？	用原来失败的条件再次检查
卡片能点击，但没有实际目标链接	能否提供明确的a元素与href？	查看元素和目标页面
页面用途与索引指令不一致	是测试配置遗留，还是业务限制？	核对响应、指令与实际用途

表格是操作示例，不代表已经在某个工具上测到了这些故障。实际验收应围绕自己的页面，把“观察到的”与“猜测的原因”分开写。

修复一张模板生成的页面后，可以抽查同类详情页、空数据页和不存在的地址。它们有不同状态，不应只用首页通过来代替全站验收。后续学习可以回到谷歌SEO学习路径，或在AI搜索与谷歌更新继续查看相关会议与工具材料。