背景

我的博客运行了不到一个月,16 篇文章,每天几十个 PV——其中大量来自爬虫。SEO 做得粗糙:大部分文章的 descriptionkeywords 是空的,标签膨胀到 42 个(文章数量的 2.6 倍),结构化数据只有 1 篇有。

但真正推动这次升级的,不是传统搜索引擎,而是 AI。

2026 年 3 月,搜索引擎的核心更新方向已经明确:结构化数据不再是”提升展示”的加分项,而是 AI 抓取和引用的基础信号。如果你的文章没有清晰的机器可读标记,GPT、Perplexity、搜索引擎的 AI 模式看不见你。

于是周末花了一晚上做了一次全站结构化数据升级。这篇文章记录过程和收获。

第一步:诊断现状

先过一遍博客的 SEO 基线:

指标 优化前
JSON-LD 覆盖率 1/16
description 覆盖率 3/16
keywords 覆盖率 6/16
内链 0
标签数量 42 个
llms.txt 不存在

42 个标签对 16 篇文章,意味着平均每个标签只被 1.5 篇文章使用——搜索引擎会判定这个站点主题不聚焦。

第二步:研究 GEO 最佳实践

花了一个小时检索行业资料,核心发现:

1. Graph-based JSON-LD 是 2026 年推荐方案

不再是每页一个孤立的 BlogPosting Schema,而是通过 @id 引用把文章、作者、组织、网站串联成一个知识图谱。Schema.org 的推荐做法是用 @graph 数组包裹多个实体:

1
2
3
4
5
6
7
8
{
"@context": "https://schema.org",
"@graph": [
{ "@id": "#article", "@type": "BlogPosting", ... },
{ "@id": "#organization", "@type": "Organization", ... },
{ "@id": "#person", "@type": "Person", "worksFor": { "@id": "#organization" } }
]
}

好处是 AI 抓取时能理解”这篇文章的作者是这个组织的成员”,而不是三个孤立的碎片。

2. BreadcrumbList 不要省略

面包屑导航的结构化数据能帮助搜索引擎理解页面在站点中的位置层级。很多中文博客忽略了这个字段,但它在实体关系建模中价值很高。

3. Speakable 是语音搜索入口

SpeakableSpecification 标记告诉语音助手和 AI 模型页面的”可说内容”在哪里。虽然目前使用比例极低(中文博客 <1%),但这是个先发优势窗口。

4. llms.txt 是 AI 的 sitemap

2024 年由 Jeremy Howard 提出的标准——在网站根目录放一个 Markdown 格式的 /llms.txt 文件,告诉 LLM 哪些页面重要、内容是什么。类似于 robots.txt 之于爬虫,llms.txt 之于 AI。

第三步:执行升级

分 7 个阶段执行,用 Python 脚本自动化处理 16 篇文章。

站点级 Schema

在 Butterfly 主题的 inject.head 注入三合一实体:

  • Organization:博客品牌
  • Person:作者实体 + knowsAbout(知识图谱领域的标记)
  • WebSite:站点描述 + SearchAction

文章级 JSON-LD

每篇文章的 front matter 写入 graph-based JSON-LD(BlogPosting + BreadcrumbList),用 Python 脚本批量生成。关键点:

  • @id 使用完整 URL,不是相对路径
  • datePublisheddateModified 用 ISO 8601 格式
  • speakable 指向页面标题
  • 引用 #person#organization@id

标签精简

42 个标签合并为 12 个核心标签:

OpenClaw, AI Agent, AI Engineering, 自动化, 大模型, 本地部署, 前端开发, 项目实战, 技术实践, 思考感悟, SEO/运维, 工具笔记

合并规则:英文同义词合并(Skill → OpenClaw),近似标签归并(Git + GitHub → SEO/运维),单独使用无搜索价值的标签删除。

其他

  • 16 篇文章全部补齐 description(120-160 字)和 keywords(5-8 个精准词)
  • 16 篇文章全部添加 2-3 条相关文章内链
  • 3 篇核心文章添加 FAQ 区块
  • 创建 llms.txt(46 行索引)+ llms-full.txt(33KB 全文)
  • 创建 16 个 Markdown 镜像文件(source/md/*.md.txt)供 AI 直接读取
  • 启用 Twitter Card
  • 添加 4 条 Nginx 301 重定向(修复旧 URL 日期前缀问题)

第四步:验证

在线验证结果

用 curl 抽取随机文章验证 HTML 输出:

1
2
3
4
5
6
7
8
9
BlogPosting: ✓
BreadcrumbList: ✓
SpeakableSpecification: ✓
Organization (site-wide): ✓
Person (site-wide): ✓
WebSite (site-wide): ✓
description meta: ✓
keywords meta: ✓
twitter:card: ✓

llms.txt HTTP 200 正常返回。

内链修复

第一版生成的内链是 /2026/04/17/openclaw-zero-cost-guide/(缺少 /blog 前缀),导致全部 404。sed 批量替换后修复。

Schema 验证

用 Google Rich Results Test 和 Schema.org Validator 对 3 篇抽样文章验证,BlogPosting + BreadcrumbList 均通过。

第五步:固化到工作流

最大的变化不是升级本身,而是把全流程固化到 Agent。

创建了 blog-post-publish skill,以后每次发布新文章,Agent 自动执行:

  1. 注入完整 front matter(title/description/keywords/tags/categories/cover)
  2. 生成 graph-based JSON-LD(BlogPosting + BreadcrumbList)
  3. 添加 2-3 条相关文章内链(URL 格式自动校验)
  4. 可选的 FAQ 区块
  5. hexo generate + 在线验证
  6. llms.txt 更新
  7. Git 提交

整个流程从手动 30 分钟优化到自动 2 分钟。

最终效果对比

指标 优化前 优化后
JSON-LD 覆盖率 1/16 16/16(graph 格式)
BreadcrumbList 0 16/16
Speakable 0 16/16
description 3/16 16/16
keywords 6/16 16/16
内链 0 32 条(每篇 2 条)
标签 42 个 12 个
llms.txt 46 行索引 + 33KB 全文
Twitter Card 已启用
site-wide Schema Person only Organization + Person + WebSite graph

常见问题

Q: 结构化数据对中文博客真的有用吗?

搜索引擎不会因为你是中文博客就忽略 Schema。Google 和百度的爬虫都解析 JSON-LD。关键不是”加了就能排名第一”,而是”不加的话你的内容在 AI 提取时是一团无法理解的非结构化文本”。

Q: llms.txt 目前有实际效果吗?

2026 年初的现状:Google 的 John Mueller 公开表示没有 AI 爬虫声称通过 llms.txt 提取信息,但也有案例显示添加 llms.txt 后 AI 爬虫访问量增加(Mintlify 报告 436 次增量)。这是一个低成本的赌注——几分钟写完一个 Markdown 文件,未来可能收益。

Q: 为什么不用 SEO 插件而用 Python 脚本?

Hexo 的 SEO 插件(如 hexo-generator-seo-friendly-sitemap)只能覆盖基础场景,无法处理:graph-based JSON-LD、BreadcrumbList、Speakable、llms.txt 生成。这些需要自定义逻辑,Python 脚本更灵活。

Q: Agent 自动发布会不会出问题?

会。比如这次升级中内链前缀缺失导致 404。解决方案是把验证步骤写进 skill:每次发布后自动 curl 抽查 2 条内链、检查 JSON-LD 和 meta tag。越自动化,越需要自检。

相关文章