摘要：让页面不只好看，还能被看懂
系列：AI建站与SEO/GEO营销完整教程｜第 09/20 篇
关键词：JavaScript SEO、Next.js SEO、网站不收录
现在用 AI 做网站，很容易得到一个“第一眼很漂亮”的页面。
首页有动效，卡片有渐变，按钮会弹出，工具页能即时计算。老板打开浏览器一看：不错，可以上线。
但上线一个月后，问题来了：Google 只收录首页，文章页收录慢，工具页没有展示，分类页看起来有内容但 Search Console 里状态不稳定。
这时很多人会说：“是不是 Google 不喜欢 AI 写的内容？”
有时候不是内容问题，而是 JavaScript SEO 问题。
这篇文章的核心观点：JavaScript 本身不是 SEO 敌人。真正的问题是，搜索系统抓取和渲染页面时，能不能稳定看到正文、链接、标题、状态码、结构和下一步路径。
如果页面只是在你的浏览器里好看，但搜索引擎、AI 搜索系统和部分爬虫看不到核心内容，这个网站就像一个灯光很漂亮、但白天不开门的门店。
一个真实场景：AI生成的工具站，用户能用，Google看不全
假设你是一个做宠物用品的跨境卖家，准备做一个英文获客站。
你让 AI 帮你做了一个 Dog Crate Size Calculator 工具页。页面打开后很漂亮：
- 用户输入狗的身长、身高、体重；
- 页面即时计算建议笼子尺寸；
- 底部推荐相关文章；
- 右侧有产品卡片；
- 按钮动效也很顺。
但你用 view-source: 看源代码，发现页面里几乎没有正文，只有一个空的 div 和一堆 JavaScript 文件。
再关掉浏览器 JavaScript，页面只剩下导航和 loading。
这意味着什么？
对真实用户来说，页面可能能用。对 Google 来说，页面需要先抓取 HTML，再排队渲染，再执行 JavaScript，最后才可能看到正文和工具结果说明。对一些不执行 JavaScript 的爬虫来说，它可能只看到空壳。
这类页面不是一定不能收录，但风险明显更高。
尤其是工具站和内容站，如果核心价值都藏在客户端 JavaScript 后面，SEO 会变得很被动。
先把事实边界说清楚
资料事实一：Google 官方 JavaScript SEO 文档明确说明，Google 处理 JavaScript 网页主要经历三个阶段：抓取、渲染、索引。Googlebot 会先抓取 URL 和 HTML，再在资源允许时用 Chromium 渲染页面，并用渲染后的 HTML 继续提取链接和索引内容。
资料事实二：Google 官方也说明，Google Search 能运行 JavaScript，但仍有需要优化的地方。服务端渲染或预渲染依然是好主意，因为它通常能让网站对用户和爬虫更快，而且不是所有爬虫都能运行 JavaScript。
资料事实三：Google 对可抓取链接的建议强调，链接应使用可被发现的 href。JavaScript 可以向 DOM 注入链接，但这些链接仍要符合可抓取链接的最佳实践。
资料事实四：Google 对懒加载内容的文档提醒，如果懒加载实现不当，可能会把内容从 Google 面前“藏起来”。Google Search 不会像真实用户那样主动点击按钮或滚动来触发所有内容加载。
资料事实五：Next.js App Router 中，页面和布局默认使用 React Server Components；需要交互、状态、事件或浏览器 API 的部分，才用 'use client' 声明客户端组件。Next.js 也支持构建时静态生成、服务端渲染、客户端导航和静态导出等模式。
合理推断：对 AI 内容站、工具站、产品站来说，最稳妥的策略不是“完全不用 JavaScript”，而是把正文、标题、内链、产品信息、FAQ、工具说明这类 SEO 核心内容放在服务端渲染或静态生成路径里，把计算器、筛选器、交互面板这类体验增强部分放在客户端。
实操建议：判断一个页面是否适合 SEO，不要只看视觉效果，要看“首个 HTML 响应、渲染后 HTML、可抓取链接、无 JS 降级、Search Console 渲染结果”五个点。
JavaScript SEO 的底层机制
传统 HTML 页面像一个打开门就能看到货架的门店。
搜索爬虫进来，马上能看到标题、正文、链接、产品、价格、FAQ。
纯客户端渲染页面更像一个空门店。爬虫先进门，看到货架还没摆出来。它需要等脚本运行，接口返回数据，前端把内容画到页面上，才知道这个页面到底卖什么。
Google 可以渲染 JavaScript，但这里有三个现实问题。
第一，渲染不是抓取同一瞬间完成。
Google 官方说页面会进入渲染队列，资源允许时再执行 JavaScript。对新站、低权重站、大量新页面来说，这个等待和不确定性会影响发现和索引节奏。
第二，渲染可能失败。
如果 JavaScript 文件被 robots 挡住，接口失败，代码报错，依赖浏览器不支持的 API，或者内容必须用户点击后才加载，渲染后的页面就可能不完整。
第三，不是所有爬虫都像 Googlebot 一样执行 JavaScript。
AI 搜索、价格监控、内容抓取、社媒预览、外链检查工具、部分行业爬虫，能力各不相同。你不能假设所有系统都能像 Chrome 用户一样完整执行页面。
所以商业上更稳的原则是：关键内容默认可见，交互体验逐步增强。
这就是 JavaScript SEO 的核心。
四种渲染方式，用卖家能听懂的话解释
很多人一听 CSR、SSR、SSG、ISR 就头大。我们换成业务语言讲。
1. CSR：客户端渲染
CSR 是 Client-Side Rendering。
服务器先给浏览器一个基础外壳，正文内容主要靠浏览器下载 JavaScript、调用接口、再渲染出来。
优点是交互灵活，适合后台系统、仪表盘、登录后应用。
缺点是 SEO 风险更高，因为核心内容可能不在初始 HTML 里。
适合：登录后台、数据看板、需要大量个性化交互的页面。
不适合：文章页、专题页、产品详情页、SEO 工具页的核心正文。
2. SSR：服务端渲染
SSR 是 Server-Side Rendering。
用户或爬虫请求页面时，服务器直接生成带内容的 HTML。
优点是搜索系统更容易看到内容，页面个性化也更灵活。
缺点是服务器压力和响应时间要控制好。
适合：价格库存变化较快的产品页、需要实时数据但又要 SEO 的页面。
3. SSG：静态生成
SSG 是 Static Site Generation。
页面在构建时提前生成 HTML，上线后用户访问的是静态文件。
优点是快、稳定、适合 SEO。
缺点是内容更新需要构建或增量更新机制。
适合：博客文章、专题页、知识库、常青内容。
4. ISR：增量静态再生成
ISR 可以理解为“静态页面 + 定期或按需刷新”。
它适合大量内容站：大部分时间页面像静态页一样快，但内容更新后可以重新生成。
适合：文章很多、产品很多、内容需要更新但不需要每次访问都实时渲染的网站。
对跨境卖家来说，简单决策可以这样做：
- 文章页：优先 SSG 或 ISR；
- 专题页：优先 SSG 或 ISR；
- 产品详情页：库存价格不实时就 SSG/ISR，需要实时就 SSR；
- 工具页：说明文字和示例结果服务端输出，计算器客户端交互；
- 登录后台：CSR 可以接受；
- 筛选搜索页：要有可抓取的基础版本，避免只有前端过滤结果。
AI生成网站最常见的7个 JavaScript SEO 问题
1. 页面源代码是空壳
最典型的 AI 网站问题是：用户打开页面看起来有内容，但源代码里没有文章正文、产品参数、FAQ 和内链。
这通常说明页面主要靠客户端渲染。
不是说一定不能收录，但对 SEO 内容站来说，不值得冒这个风险。文章页、专题页、工具页说明、产品核心信息，应该尽量在服务端或静态 HTML 中出现。
检查方法：
- 打开页面；
- 右键查看网页源代码；
- 搜索页面标题、正文第一段、FAQ 问题；
- 如果完全搜不到，再用 Search Console URL Inspection 看渲染后的 HTML。
修复建议：
- Next.js 中让文章页和专题页使用 Server Components；
- 不要在顶层页面随手写
'use client'； - 把交互组件拆出去，只让需要状态和事件的部分成为 Client Component；
- 用 MDX、CMS、数据库或 Markdown 在服务端读取内容。
2. 所有数据都靠浏览器接口加载
很多工具页会这样写：
页面加载 -> 前端调用 /api/article?id=123 -> 拿到正文 -> 渲染到页面
用户看起来没问题，但搜索系统需要等待接口、执行脚本、渲染 DOM。任何一步失败，内容就不完整。
更稳的做法是：
服务端先输出标题、说明、核心正文、FAQ、相关文章
客户端只负责计算器、筛选器、动态图表、结果复制
以 Dog Crate Size Calculator 为例，SEO 核心内容应该包括：
- 工具适合谁；
- 输入字段怎么填；
- 尺寸计算逻辑；
- 结果如何解释；
- 常见误差；
- 示例场景；
- 相关文章；
- 产品选择建议。
这些内容不要等用户点击“Calculate”之后才出现。
3. 内链不是标准链接
搜索系统发现页面，靠的是 URL 和链接关系。
有些 AI 生成页面为了动效，会把按钮写成：
<button onclick="goTo('/tools/dog-crate-size-calculator')">Calculator</button>
或者：
<div onclick="window.location.href='/guides/dog-crate-size-chart'">Read more</div>
用户能点，但这不是最稳的可抓取链接写法。
更好的做法是：
<a href="/tools/dog-crate-size-calculator">Dog Crate Size Calculator</a>
如果用 Next.js，可以用 Link 组件：
import Link from 'next/link'
export function RelatedLinks() {
return (
<Link href="/tools/dog-crate-size-calculator">
Dog Crate Size Calculator
</Link>
)
}
注意，链接文字也要具体。不要写“click here”，要写“Dog Crate Size Calculator”或“Dog Crate Size Chart”。
4. 懒加载把核心内容藏起来
懒加载图片、视频、非关键模块，本来是性能优化。
但如果懒加载写错，就会变成 SEO 问题。
常见错误：
- 首屏正文也懒加载；
- FAQ 要点击展开后才请求；
- 文章列表只有滚动到底才加载；
- 产品卡片只有用户筛选后才出现；
- 无限滚动没有独立分页 URL；
- 图片进入 viewport 也不加载，需要真实滚动或点击。
Google 对懒加载内容的建议很明确：相关内容应该在进入视口时加载，不能依赖用户操作；无限滚动要支持可索引的分页 URL。
实操建议：
- 文章正文不要懒加载；
- 核心 FAQ 默认存在于 HTML 或渲染后 HTML 中；
- 无限滚动同时提供
/page/2或?page=2； - 加载更多按钮不能是唯一发现路径；
- 用 Search Console 检查渲染后 HTML 里是否有这些内容。
5. SPA 错误页返回 200
单页应用经常有一个问题：不存在的 URL 也返回 200。
例如：
/products/does-not-exist
页面显示“Product not found”，但服务器状态码仍然是 200。
这会让搜索系统困惑：这是一个有效页面，还是错误页面？
Google JavaScript SEO 文档也专门提到，客户端路由的 SPA 容易出现 soft 404 问题。对不存在页面，要用有意义的 HTTP 状态码，或者用更合适的错误处理方式。
在 Next.js 中，应正确使用：
not-found.tsx；redirects；permanentRedirect；- 正确的服务端数据判断；
- 不存在页面不要输出正常产品页模板。
对跨境独立站来说，软 404 很常见：产品下架、旧链接迁移、活动页过期，都可能出问题。
6. title、description、canonical 只在客户端改
有些 AI 生成站，会在浏览器运行后才设置页面标题、描述和 canonical。
Google 文档说可以用 JavaScript 设置或修改 title、description，也提到 canonical 可以用 JavaScript 设置。但实操上，对商业站点更稳的方案是：核心页面的 title、description、canonical 尽量在 HTML 中稳定输出，避免前后不一致。
常见错误：
- 所有页面初始 title 都是
My App； - canonical 初始指向首页，渲染后才改；
- description 全站一样；
- Open Graph 图和标题只有客户端状态里有；
- 多语言页面 metadata 混乱。
Next.js 里建议用 metadata 或 generateMetadata 为不同页面生成稳定元数据。
7. JS/CSS资源被 robots 或构建错误挡住
很多人只检查网页 URL 能不能打开，却不检查 JS、CSS、图片资源能不能被抓取。
如果关键 JavaScript 文件、CSS 文件、接口资源被 robots 阻止，Google 渲染页面就可能看不完整。
上线前检查：
- robots.txt 是否误封
/_next/、/assets/、/static/； - 页面加载是否有 404 JS 文件；
- 控制台是否有严重 JavaScript 报错；
- 接口是否对爬虫返回 403；
- CSS 是否阻止导致布局和隐藏内容异常；
- 构建后的 chunk 路径是否和部署路径一致。
这类问题常见于：换域名、换 CDN、从预览环境复制配置到生产环境、把测试 robots 带上线。
Next.js内容站应该怎么设计，才更稳
如果你用 Next.js 做 AI 内容站或工具站，我建议用一个非常实用的分层原则：
能服务端输出的内容，不要放到客户端再拼；必须交互的功能，才放到客户端。
文章页
文章页应该尽量是 Server Component 或静态生成。
页面应在 HTML 中稳定包含：
- H1；
- 摘要；
- 正文；
- 目录；
- FAQ；
- 作者；
- 更新日期；
- 参考资料；
- 相关文章链接。
客户端可以负责：
- 目录高亮；
- 复制按钮；
- 评论区；
- 订阅弹窗；
- 阅读进度条。
不要为了一个复制按钮，把整篇文章页都变成 'use client'。
专题页
专题页应该输出主题说明、学习路径、精选文章和工具入口。
如果文章列表来自 CMS，可以在服务端读取后生成；不要等浏览器加载后才请求列表。
产品页
产品页核心信息应该服务端可见：
- 产品名称；
- 价格或价格区间；
- 主要参数；
- 适用场景；
- FAQ；
- 图片 alt；
- 产品 Schema；
- 购买或咨询入口。
库存、个性化推荐、动态优惠可以客户端增强。
工具页
工具页最容易被做错。
正确结构应该是：
服务端可见：
- 工具标题
- 使用场景
- 输入字段说明
- 计算逻辑解释
- 示例结果
- FAQ
- 相关文章
- 产品或咨询入口
客户端交互：
- 表单输入
- 即时计算
- 图表展示
- 结果复制
- 邮件发送
这样，即使交互脚本失败，页面仍然是一篇有价值的工具说明页；脚本成功时，它又是一个好用的工具。
一套 JavaScript SEO 诊断 SOP
如果你明天要检查自己的网站，按下面流程走。
第一步，选 5 类 URL 样本。
不要只测首页。至少测：
- 首页；
- 专题页；
- 文章页；
- 工具页；
- 产品页或资源页。
第二步，看源代码。
打开 view-source:https://yourdomain.com/page，搜索：
- H1；
- 正文第一段；
- FAQ；
- 相关文章链接；
- canonical；
- title；
- description。
如果核心页面完全搜不到正文，就要进入下一步。
第三步，禁用 JavaScript。
在浏览器开发者工具里禁用 JavaScript，或者用浏览器插件测试。
看页面是否仍然有：
- 基础标题；
- 核心说明；
- 主要链接；
- 关键产品信息；
- 工具使用说明。
第四步，看渲染后 DOM。
浏览器 Elements 面板看到的是渲染后的 DOM。你要确认用户看到的内容，是否真的进入了 DOM，而不是在 canvas、图片或 iframe 里。
第五步，用 Search Console URL Inspection。
对已上线页面，用 URL Inspection 查看 Google 抓取和渲染情况。重点看页面是否可访问、是否允许索引、渲染后 HTML 是否包含核心内容。
第六步，检查网络和控制台错误。
打开 DevTools：
- Console 是否有红色报错；
- Network 是否有 404/403/500；
- JS chunk 是否加载成功；
- API 是否依赖登录或特殊 header；
- 页面是否因接口失败只显示 loading。
第七步，检查内链。
用页面源码或爬虫工具抽查：
- 重要链接是否是
<a href="">； - 相关文章是否能被发现；
- 分页是否有 URL；
- 工具页是否链接到文章和产品；
- 不要只有按钮点击事件。
第八步，检查懒加载。
确认核心内容不依赖点击、滚动到底、鼠标悬停才加载。无限滚动要有分页 URL。
第九步，检查错误页。
打开不存在 URL，看是否返回 404，而不是返回 200 + “not found” 文案。
第十步，写修复优先级。
不要一次改全站。先改会影响索引的核心页面：文章页、专题页、工具页、产品页。
可以直接复制的提示词
下面这段可以直接给 Cursor、Codex、Claude Code 或技术同事。
你是一个熟悉 JavaScript SEO、Next.js App Router、Google Search 抓取渲染机制和跨境内容站的技术 SEO 顾问。
我要诊断一个网站的 JavaScript SEO 风险：
- 网站类型：[内容站 / 工具站 / 品牌站 / 产品站 / 多语言站]
- 技术栈：[Next.js App Router / React SPA / Vite / WordPress Headless / 其他]
- 核心页面：[首页、专题页、文章页、工具页、产品页]
- 目标市场：[美国 / 欧洲 / 日本 / 其他]
- 当前问题：[不收录 / 收录慢 / 工具页无展示 / 只收录首页 / Search Console 报错]
请你输出一份诊断方案，必须包含：
1. 抓取阶段风险：robots、状态码、资源阻挡、链接发现。
2. 渲染阶段风险：客户端渲染、接口失败、JS 报错、懒加载、无限滚动。
3. 索引阶段风险：noindex、canonical、soft 404、重复页面、薄内容。
4. 页面类型诊断：文章页、专题页、工具页、产品页分别检查什么。
5. Next.js 修复建议：哪些内容应放在 Server Component，哪些才用 Client Component。
6. 内链修复建议：如何把按钮跳转改成可抓取链接。
7. 工具页修复建议：如何保留可索引说明、示例、FAQ 和相关内容。
8. 测试步骤：view-source、禁用 JS、渲染后 DOM、Search Console URL Inspection、DevTools Network/Console。
9. 输出 P0/P1/P2 修复优先级。
要求：
- 不要泛泛而谈，要给检查方法。
- 每项都说明“为什么影响 SEO”和“如何修复”。
- 标记哪些判断必须用 Search Console 或线上环境确认。
如果你要让 AI 直接检查代码，可以追加：
请检查当前项目代码，重点看：
- app 目录下是否把整页误写成 'use client'
- 文章页/专题页/工具页是否服务端输出核心正文
- metadata 或 generateMetadata 是否按页面生成
- 内链是否使用 <a href> 或 Next.js Link
- 工具页是否只有客户端组件，没有可索引说明
- not-found 和重定向是否正确
- 懒加载和无限滚动是否有可抓取路径
请输出问题文件、风险等级、修改建议和验收方法。
给老板看的检查清单
如果你只想快速判断“这个 AI 生成网站能不能上线做 SEO”，用下面这张表。
| 检查项 | 通过标准 | 不通过的风险 |
|---|---|---|
| 源代码可见核心内容 | title、H1、摘要、正文或说明能被找到 | 页面像空壳 |
| 渲染后 HTML 完整 | Search Console 能看到主要内容 | Google 看到的不等于用户看到的 |
| 链接可抓取 | 重要入口是 <a href> 或可靠 Link | 页面发现慢、内链弱 |
| 工具页有正文 | 不只有输入框，还有说明、示例、FAQ | 工具页内容太薄 |
| 懒加载合理 | 关键内容不依赖点击或滚动到底 | 内容被隐藏 |
| 状态码正确 | 不存在页面返回 404 | soft 404 |
| metadata 稳定 | title、description、canonical 不靠客户端乱改 | 页面主题混乱 |
| 资源可访问 | JS/CSS/API 不被 robots 或权限挡住 | 渲染失败 |
| 移动端可用 | 表单、导航、正文都能操作 | 流量难转化 |
| 有监控 | Search Console 和错误监控可用 | 问题发现太晚 |
这张表的价值，是让“设计好看”和“SEO 可用”变成两个独立验收项。
不要误读：不是所有页面都必须服务端渲染
这里要避免几个误区。
第一，不要把 JavaScript 妖魔化。
现代网站离不开 JavaScript。筛选、计算器、地图、登录、图表、复制按钮、表单反馈，都需要 JavaScript。问题不是用了 JavaScript，而是把 SEO 核心内容完全藏在 JavaScript 后面。
第二，不要以为“Google 能渲染 JS”就万事大吉。
Google 能渲染，不代表每次都立刻渲染、完整渲染、没有失败。对商业网站来说，把关键内容提前输出更稳。
第三，不要只看 view-source 就判死刑。
有些页面源代码不完整，但渲染后 HTML 完整，Google 也可能索引。正确做法是结合源代码、渲染后 DOM、Search Console 和实际索引表现判断。
第四，不要为了 SEO 放弃交互体验。
工具站的价值就在交互。正确做法是“服务端输出解释内容 + 客户端增强交互”，不是把工具变成一篇死文章。
第五，不要把所有页面都 SSR。
SSR 不是越多越好。文章、专题和知识库适合静态或增量静态；实时页面适合 SSR；后台适合客户端渲染。要按页面任务选渲染方式。
最后给一个最小修复方案
如果你的网站已经上线，而且发现很多页面不收录，先别大改全站。
按下面顺序修 5 个页面模板：
- 文章页：让 H1、摘要、正文、FAQ、相关文章在服务端或静态 HTML 中出现。
- 专题页：输出主题说明、学习路径、文章列表和工具入口。
- 工具页：保留可索引说明、输入字段解释、示例结果、FAQ 和相关文章。
- 产品页：输出产品名称、参数、场景、FAQ、图片 alt、购买或咨询入口。
- 错误页：不存在 URL 正确返回 404，不要返回 200。
然后用 Search Console 抽查这些模板下的页面。
AI 建站的下一阶段，不是让页面更花，而是让页面在用户、搜索引擎和 AI 系统眼里都“可见、可懂、可访问”。
JavaScript 可以继续用，但核心内容不要只活在浏览器执行完脚本之后。
官方参考资料
- Google Search Central: Understand the JavaScript SEO basics：用于核对 Google 处理 JavaScript 的抓取、渲染、索引阶段，Googlebot 执行 JavaScript 的边界，以及服务端或预渲染建议。
- Google Search Central: Fix Search-related JavaScript problems：用于核对 JavaScript 搜索问题的排查方向。
- Google Search Central: SEO Link Best Practices for Google：用于核对可抓取链接、
href和锚文本建议。 - Google Search Central: Fix lazy-loaded content：用于核对懒加载内容、无限滚动、分页 URL 和 URL Inspection 测试建议。
- Google Search Central: Optimizing for generative AI features on Google Search：用于核对生成式 AI 搜索仍依赖 Google Search 核心排名和质量系统的表述。
- Next.js Docs: Server and Client Components：用于核对 App Router 中 Server Components 和 Client Components 的使用边界。
- Next.js Docs: Linking and Navigating：用于核对 Next.js 路由、链接和导航相关机制。
- Next.js Docs: Static Exports：用于核对静态导出和构建时生成 HTML 的能力。
- Next.js Docs: Metadata and OG images：用于核对 metadata 和
generateMetadata的官方能力。