AEO.js实战：为Next.js/Astro项目优化AI爬虫可读性

1. 项目概述：当AI成为新的搜索引擎，你的网站准备好了吗？

最近两年，我明显感觉到自己获取信息的方式变了。以前遇到问题，第一反应是打开搜索引擎，在一堆蓝色链接里点开三五个网页，快速浏览、对比、筛选。但现在，我越来越多地直接问ChatGPT、Claude或者Perplexity。它们能直接给我一个整合过的答案，省去了我大量点击和筛选的时间。我相信不止我一个人这样，数据也证实了这一点：接近六成的搜索行为，最终用户并没有点击任何链接，因为AI助手直接在对话界面里给出了答案。更惊人的是，年轻一代中，超过四成的人更倾向于使用AI助手而非传统搜索引擎。

这对我们这些做网站、做内容的人来说，意味着游戏规则正在发生根本性的改变。传统的SEO（搜索引擎优化）是针对Google、Bing这些“链接列表式”搜索引擎的，核心是让网页在搜索结果页（SERP）上排名靠前，从而获得点击。但AI驱动的“答案引擎”完全不同，它们的目标是直接消化你的内容，然后用自己的话生成答案，用户甚至不需要离开对话界面。如果你的网站没有被这些AI爬虫正确理解和抓取，那么在这些新兴的、用户粘性极高的流量入口里，你的内容就等于“隐形”了。

这就是AEO（Answer Engine Optimization，答案引擎优化）要解决的问题。而aeo.js这个开源项目，正是为现代Web开发者量身打造的一站式AEO解决方案。它不是一个空泛的概念，而是一个实实在在的npm包，能无缝集成到你的Astro、Next.js、Vite、Nuxt等现代前端项目中，用极低的成本，为你的网站生成AI爬虫所需的一切“饲料”：专用的llms.txt文件、完整的Markdown版本内容、结构化的AI索引以及标准的SEO元数据。简单来说，它帮你把网站“翻译”成AI能更好理解、更喜欢的格式，从而大幅提升你的内容被ChatGPT、Claude等AI助手发现并引用的几率。

2. AEO的核心逻辑：为什么传统的SEO不够用了？

要理解aeo.js的价值，我们得先拆解一下AI爬虫（或者说LLM网络爬虫）与传统网络爬虫的根本区别。这不仅仅是技术差异，更是产品逻辑和用户体验范式的转变。

2.1 传统爬虫 vs. AI爬虫：从索引链接到理解语义

传统搜索引擎爬虫（如Googlebot）的工作模式相对“机械”。它爬取网页，解析HTML，提取文本、链接和基础元数据（如title、description），然后根据复杂的排名算法（考虑反向链接、关键词密度、页面速度等）建立索引。当用户搜索时，搜索引擎从索引中匹配关键词，返回一个包含标题、摘要和链接的列表。它的核心输出是链接，用户需要自己点击进去消费内容。

AI爬虫（例如被用于训练或实时检索的爬虫）的目标则深刻得多。它需要理解内容。它不仅要抓取文本，还要理解文本的语义结构、核心论点、数据关系，甚至判断内容的权威性和时效性。它的目标不是返回链接，而是直接生成答案。因此，它对数据源的“可读性”和“信息密度”要求极高。

举个例子，一个充满复杂JavaScript交互、图片懒加载、内容分块加载的现代React单页应用（SPA），在Googlebot眼中可能经过渲染后还能正常索引。但对于一个追求效率、需要快速消化海量文本的AI爬虫来说，这种页面可能是个噩梦：它需要执行大量JavaScript才能获取完整内容，成本高昂且不可靠。AI爬虫更偏爱直接、纯净、结构化的文本数据。

2.2llms.txt：AI世界的“新机器人协议”

我们都知道robots.txt，它告诉普通爬虫哪些页面可以或不可以抓取。llms.txt可以看作是针对大型语言模型（LLM）爬虫的专属指引文件。虽然目前还没有一个像Robots协议那样被所有AI厂商强制遵循的官方标准，但提供llms.txt正在成为一项最佳实践。

aeo.js生成的llms.txt文件，其核心作用是向AI爬虫清晰地声明：“这个网站的内容欢迎被用于AI训练和实时检索，并且我们已经为你准备好了易于处理的格式。” 这能带来几个潜在好处：

1. 提升抓取友好度：主动示好，可能让AI爬虫更愿意、更频繁地访问你的网站。
2. 引导至优质资源：你可以在llms.txt里指向llms-full.txt或ai-index.json，直接告诉爬虫：“别费劲解析我的HTML了，最干净、最完整的内容在这里。”
3. 建立信任：主动提供结构化数据，减少了AI生成内容时出现“幻觉”（胡编乱造）或误解的风险，可能间接提升你内容在AI答案中的引用准确性和权重。

2.3 结构化数据与Markdown：为AI“备餐”

AI模型处理信息，最喜欢的就是干净、有结构的“食材”。aeo.js在构建阶段，会为你的每个路由页面生成一个对应的.md（Markdown）文件。Markdown去除了所有样式和交互元素，只保留标题、段落、列表、代码块等纯语义化内容，这极大降低了AI的理解成本。

更进一步，aeo.js会生成ai-index.json和docs.json这类结构化索引文件。它们就像一个内容目录，以JSON格式清晰地列出了网站的所有页面、其URL、标题、摘要甚至内容块。对于AI爬虫来说，这就像拿到了一本带有详细书签和章节摘要的书，可以极快地定位和摄取所需信息，比从头解析HTML高效几个数量级。

实操心得：不要小看这个“静态生成”的过程。对于内容型网站（博客、文档、新闻站），在构建时预生成这些AI优化文件，相当于把最耗时的数据处理工作提前做了。当AI爬虫来访时，它可以直接享用“预制菜”，响应速度极快，这对争取在实时检索（RAG）场景中被优先选用非常有利。

3.aeo.js实战集成：为你的Next.js/Astro项目装上AEO引擎

理论讲完了，我们来点硬的。aeo.js最吸引我的地方就是它的开发者体验（DX）做得极好，与主流框架的集成几乎是无缝的。下面我以最常用的Next.js（App Router）和Astro为例，手把手带你走一遍集成流程，并分享一些配置上的细节和坑。

3.1 在Next.js (App Router) 项目中集成

首先，通过npm安装：

npm install aeo.js

接下来，修改你的next.config.mjs配置文件。aeo.js提供了一个withAeo高阶函数来包装你的Next.js配置：

// next.config.mjs import { withAeo } from 'aeo.js/next'; /** @type {import('next').NextConfig} */ const nextConfig = { // 你原有的Next.js配置... }; export default withAeo(nextConfig, { aeo: { // 这是核心配置 title: '我的技术博客', description: '分享前端开发、性能优化与AEO实践', url: 'https://my-tech-blog.com', // 建议开启所有生成器，一次性配齐 generators: { robotsTxt: true, llmsTxt: true, llmsFullTxt: true, rawMarkdown: true, sitemap: true, aiIndex: true, schema: true, }, // 结构化数据（JSON-LD），对SEO和AI都很有帮助 schema: { enabled: true, organization: { name: '我的博客', url: 'https://my-tech-blog.com' } }, // 别忘了Open Graph，社交分享和某些AI也会看 og: { enabled: true, image: 'https://my-tech-blog.com/og-default.png', }, }, });

关键一步：添加后构建脚本。Next.js的构建输出是静态文件，aeo.js需要在构建完成后，基于这些文件来生成Markdown和索引。在你的package.json中添加一个postbuild脚本：

{ "scripts": { "dev": "next dev", "build": "next build", "postbuild": "node -e \"import('aeo.js/next').then(m => m.postBuild({ title: '我的技术博客', url: 'https://my-tech-blog.com' }))\"", "start": "next start" } }

这个postbuild脚本会在next build命令执行成功后自动运行，调用aeo.js的后处理逻辑。

注意事项：

1. URL必须准确：url配置项务必使用你网站最终的、可公开访问的绝对地址（包含https://）。aeo.js生成的sitemap.xml和所有内部链接都基于这个值。开发环境下可以用本地地址，但生产环境一定要改过来。
2. 处理动态路由：如果你的网站有大量动态路由（如/blog/[slug]），aeo.js默认会尝试为构建时存在的所有页面生成文件。确保你在构建时通过generateStaticParams等方式预渲染了所有需要的页面，否则这些动态页面不会被AEO优化。
3. 检查输出：首次运行npm run build后，务必去检查生成的out目录（Next.js默认静态输出目录）。你应该能看到新生成的llms.txt,ai-index.json等文件。用文本编辑器打开看看，确认内容符合预期。

3.2 在Astro项目中集成

Astro的集成更为简洁，因为它本身就是构建时框架，与aeo.js的静态生成理念天生契合。 安装后，在astro.config.mjs中添加集成即可：

// astro.config.mjs import { defineConfig } from 'astro/config'; import { aeoAstroIntegration } from 'aeo.js/astro'; // https://astro.build/config export default defineConfig({ site: 'https://my-astro-site.com', // Astro的site配置很重要，aeo会用它 integrations: [ aeoAstroIntegration({ title: '我的Astro站点', description: '一个使用Astro构建并优化了AEO的网站', url: 'https://my-astro-site.com', // 通常与site一致 generators: { rawMarkdown: true, // ... 其他生成器 }, widget: { enabled: true, position: 'bottom-left', // 将小组件放在左下角 } }), ], });

在Astro中，aeo.js集成会直接挂钩到构建流程中，无需额外的postbuild脚本。构建完成后，你可以在dist目录下找到生成的所有AEO文件。

3.3 核心配置项深度解析

无论用哪个框架，都会接触到一个核心配置对象。我们来拆解几个最重要的配置项：

• title&description&url：这是网站的元信息基石。它们不仅会被写入llms.txt的注释、ai-index.json的元数据中，也会用来生成基础的JSON-LD结构化数据。description应是一段通顺的、概括网站核心价值的文字，而不是关键词堆砌。

• generators：这是控制输出哪些文件的开关。我的建议是，在项目初期全部开启。每个文件都有其作用：

  • robotsTxt: 生成包含AI爬虫指令的robots.txt。
  • llmsTxt/llmsFullTxt: 给AI爬虫的指引和完整摘要。
  • rawMarkdown:核心功能，为每个页面生成.md文件。
  • sitemap: 标准站点地图，利于传统搜索引擎和AI爬虫发现页面。
  • aiIndex: 结构化索引，是AI快速理解网站内容的“高速公路”。
  • schema: 生成JSON-LD结构化数据，丰富搜索结果摘要。

• widget：这个可视化小组件非常实用。当用户访问你的网站时，他们可以在右下角看到一个“Human/AI”切换按钮。点击“AI”视图，页面会展示由aeo.js生成的、纯净的Markdown版本。这有两个好处：一是向访客直观展示你的网站对AI友好，是一种很酷的技术宣传；二是这个Markdown视图本身也是一个极佳的可访问性版本，对屏幕阅读器用户非常友好。 你可以通过theme选项自定义小组件的颜色，使其与你的网站品牌保持一致。

4. 生成文件详解与部署策略

运行一次构建后，你的输出目录（如out/,dist/,build/）会多出一系列文件。理解每个文件的用途，能帮助你在部署时做出正确决策。

4.1 文件清单与用途对照表

4.2 部署到Vercel/Netlify的注意事项

现代前端项目最常部署在Vercel、Netlify这类平台上。部署aeo.js优化的项目时，你几乎不需要做额外配置，因为生成的都是静态文件。但有几个细节要注意：

1. 路由冲突：aeo.js默认将Markdown文件生成在输出目录的根路径（如/about.md）。如果你的网站本身有一个/about路由（指向about.html），那么静态服务器在接收到/about请求时，需要正确返回HTML文件，而不是Markdown文件。幸运的是，Vercel和Netlify的静态文件服务通常有优先级规则（如.html>.md），一般不会冲突。如果遇到问题，可以在aeo.js配置中指定一个输出子目录，例如outputDir: ‘/ai-pages’。
2. 缓存策略：对于ai-index.json、llms-full.txt这类可能频繁更新（随内容更新）的文件，建议在部署平台设置较短的缓存时间（如Cache-Control: max-age=3600），确保AI爬虫能及时获取最新内容。而对于robots.txt和sitemap.xml，可以缓存久一点。
3. 验证部署结果：部署完成后，一定要手动访问这些生成的文件，例如https://你的域名.com/llms.txt，确认它们可以公开访问且内容正确。你可以使用aeo.js自带的检查工具：npx aeo.js check --url https://你的域名.com，它会给你一份详细的AEO健康报告。

4.3 利用生成文件构建额外功能

这些生成的文件不仅是给AI看的，你也可以利用它们为你的网站添加实用功能：

• 站内全文搜索：ai-index.json包含了所有页面的标题、URL和纯文本摘要。你可以很容易地在前端加载这个JSON文件，实现一个轻量级、无需后端的客户端全文搜索功能。
• 内容预览API：如果你有移动端App或其他第三方应用，/ai/index.json可以作为一个简易的内容API，供它们快速获取网站的文章列表和摘要。
• 可访问性增强：为每个页面提供的Markdown版本，可以通过一个简单的切换按钮（类似aeo.js的小组件）提供给用户。这对于喜欢阅读纯净文本的用户，或者在使用屏幕阅读器时希望避免页面复杂布局干扰的用户，是一个很棒的可访问性特性。

5. 高级技巧与疑难排查

用了aeo.js一段时间，也帮几个项目做了集成，踩过一些坑，也总结出一些让效果更好的技巧。

5.1 提升AI内容理解度的技巧

aeo.js自动化了文件的生成，但内容本身的质量，还是取决于你的网站。为了让AI更好地理解和引用你的内容，你可以在编写内容时注意以下几点：

1. 清晰的层次结构：在HTML中使用正确的标题标签（<h1>到<h6>）。aeo.js在生成Markdown时会保留这些结构，这能帮助AI理解文章的逻辑脉络。避免用<div>加CSS来模拟标题。
2. 为图片添加信息丰富的alt文本：AI虽然主要处理文本，但alt属性中的描述性文字会被aeo.js提取并放入上下文。一张写着“<img src=”chart.png” alt=”2023-2024年季度营收增长趋势图，显示Q4环比增长15%”>”的图片，比“<img src=”chart.png”>”能给AI提供多得多的信息。
3. 在代码块中使用语义化语言标记：如果你的博客有技术代码，确保Markdown或代码高亮组件正确指定了语言（如```javascript,```python）。这有助于AI识别这是代码，并可能进行更准确的分析（例如，知道这是API调用示例还是配置片段）。
4. 使用<time>等语义化标签：对于发布日期、更新时间，使用<time datetime=”2024-10-27″>标签。aeo.js可以提取这些信息并放入结构化数据中，帮助AI判断内容的时效性，这对于新闻、教程类内容至关重要。

5.2 常见问题与解决方案

问题一：构建后，生成的Markdown文件内容为空或只有标题。

• 原因排查：这通常是因为aeo.js在构建阶段无法从页面中提取到足够的文本内容。
• 解决方案：
  1. 检查你的页面组件是否在客户端渲染（CSR）了大量内容。aeo.js通常在构建时（SSG）运行，它只能抓取到服务端渲染（SSR）或静态生成（SSG）阶段就存在的内容。确保核心内容在服务端即可用。
  2. 对于Next.js，确保你使用的是App Router的静态生成或Pages Router的getStaticProps。如果使用服务端渲染（getServerSideProps），aeo.js在构建时无法执行这些函数。
  3. 在Astro中，确保你的内容写在.astro文件的组件脚本之外，或者通过<slot />正确传递。

问题二：动态路由的页面没有生成对应的Markdown文件。

• 原因排查：aeo.js依赖于构建系统提供的页面列表。如果动态路由（如/blog/[id]）在构建时没有生成具体的静态页面，aeo.js自然无法为其生成文件。
• 解决方案：你需要在框架层面确保所有需要AEO优化的路径都在构建时被预渲染。在Next.js App Router中，使用generateStaticParams函数。在Astro中，使用getStaticPaths函数。确保这些函数返回了所有可能的params。

问题三：llms.txt或sitemap.xml中的URL不正确，还是本地开发地址（http://localhost:3000）。

• 原因排查：aeo.js的配置中url选项没有正确设置为生产环境地址，或者框架的配置（如Astro的site配置）未生效。
• 解决方案：使用环境变量来动态配置。这是最推荐的做法。

  // next.config.mjs 或 astro.config.mjs const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || 'https://my-site.com'; export default withAeo(nextConfig, { aeo: { title: 'My Site', url: siteUrl, // ... }, });

  然后在Vercel、Netlify等平台设置对应的环境变量NEXT_PUBLIC_SITE_URL。

问题四：AEO小组件没有显示，或者样式错乱。

• 原因排查：小组件是客户端JavaScript，可能因为脚本加载失败、与现有CSS冲突或配置错误而不显示。
• 解决方案：
  1. 检查浏览器控制台是否有JavaScript错误。
  2. 确认小组件的配置中enabled: true。
  3. 如果网站有严格的Content Security Policy (CSP)，需要确保允许加载aeo.js小组件相关的脚本源。
  4. 尝试调整position配置（如'bottom-left'），看是否是位置被其他元素遮挡。

5.3 性能与监控考量

引入aeo.js会增加构建时间，因为它需要在构建后额外处理所有页面。对于有几百个页面的网站，这个时间增长可能是显著的。建议：

• 在CI/CD流水线中监控构建时间变化。
• 考虑是否需要对所有页面开启rawMarkdown生成。对于某些管理页面、登录页面，可以在aeo.js配置中通过路径规则排除。
• 生成的静态文件（尤其是llms-full.txt和所有.md文件）会占用额外的存储空间和带宽，部署前需评估。

至于效果监控，目前还没有像Google Search Console那样直接的“AEO控制台”。但你可以通过以下方式间接评估：

• 关注你的网站在ChatGPT、Claude等AI产品的对话中被提及或引用的频率（如果可能的话）。
• 观察来自一些已知AI爬虫User-Agent（如ChatGPT-User,anthropic-ai,Google-Extended）的服务器访问日志。
• 使用npx aeo.js check定期检查你的生产站点，确保所有AEO文件状态健康。

6. 写在最后：AEO是未来，但内容依然是王道

折腾完aeo.js，给我的最大感触是，技术工具让我们能够以极低的成本跟上趋势。以前做SEO要研究算法、做外链、优化代码，现在做AEO，几乎就是安装一个包、改几行配置的事情。它把那些繁琐的、针对AI的标准化工作给自动化了。

但这绝不意味着你可以高枕无忧。aeo.js解决的是“被发现”和“被理解”的问题，是渠道和格式的问题。而“被引用”和“被信任”的核心，最终还是落回到内容本身的质量、深度、独特性和权威性上。AI在生成答案时，会倾向于选择那些信息准确、论述清晰、来源可靠的资料。你的文章是否解决了某个具体问题？数据是否详实？逻辑是否严密？观点是否有独到之处？这些才是决定你的内容能否在AI时代脱颖而出的根本。

所以，我的建议是：把aeo.js这类工具看作是给你的优质内容“装上翅膀”，让它能飞入AI的视野。但首先，你得有值得被看见的“内容之躯”。花80%的精力创作无法被机器替代的好内容，再用20%的精力像今天这样，用好工具做好技术优化，这可能才是我们在AI搜索时代最踏实的立足之道。至少从今天起，当有人在ChatGPT里问起你专业领域的问题时，你的网站已经做好了被它“看到”并“引用”的一切准备。