结构化内容 vs WordPress HTML 代码块：为什么 AI 无法读取您的网站

我最近对一个拥有 3,000+ 篇文章的 WordPress 网站进行了审计。客户想将他们的内容导入 AI 工具来生成摘要并驱动推荐引擎。这应该很简单，对吧？导出内容，输入工具，完成。

但事实并非如此。每一篇文章都是 HTML 的混乱——来自不再存在的插件的短码、来自经典编辑器的内联样式、散落如地雷的 Gutenberg 块注释，以及使解析器出错的编码实体。数据库中的"内容"字段根本不是内容。它是一套仅 WordPress 本身可以解释的渲染指令集。AI 模型产生了垃圾输出。客户很生气。而我不得不解释一些更多团队需要听到的话：你存储内容的方式决定了你能用它做什么，不仅仅是今天，还包括你尚未想到的每一个用例。

这是结构化内容与 HTML blob 的故事，为什么它在 2025 年比以往任何时候都更重要，以及迁移路径实际上是什么样的。

目录

• 什么是 HTML Blob 以及为什么 WordPress 使用它们
• 结构化内容实际上意味着什么
• 为什么 AI 无法读取你的 WordPress 内容
• 非结构化内容的真实成本
• 无头 CMS 与 WordPress：诚实的比较
• WordPress 限制的复合影响
• 迁移路径：从 Blob 到结构
• 选择合适的无头 CMS
• 常见问题

什么是 HTML Blob 以及为什么 WordPress 使用它们

在任何 WordPress 网站上打开 phpMyAdmin 并查看 wp_posts 表。找到 post_content 列。你会看到一个包含所有内容的文本字段——标题、段落、图片、嵌入、短码、块标记、内联 CSS——全部混合成一个长字符串。

这是典型 Gutenberg 文章在数据库中的样子：

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">我们的服务</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>我们为企业提供<strong>高级咨询</strong>服务。</p>
<!-- /wp:paragraph -->

<!-- wp:shortcode -->
[contact-form-7 id="1234" title="Contact"]
<!-- /wp:shortcode -->

<!-- wp:image {"id":5678,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large">
<img src="/wp-content/uploads/2024/03/hero.jpg" alt="" class="wp-image-5678"/>
</figure>
<!-- /wp:image -->

这是一个 HTML blob。它是呈现和内容混合在一起。数据库不知道"我们的服务"是一个标题，图片是英雄形象，还是联系表单是 CTA 组件。它就是……一个字段中的文本。

WordPress 这样做是因为它在 2003 年被设计为博客平台。心智模型很简单：一篇文章有标题和正文。正文是 HTML。你写它，WordPress 渲染它。这个模型对博客来说效果很好。但对现代内容运营来说，它会彻底崩溃。

Gutenberg 的改进未能解决的问题

Gutenberg（块编辑器）本应修复这个问题。公平地说，它添加了一些结构——那些 HTML 注释将块类型和属性编码为 JSON。但这里是关键的失败：该结构位于 HTML blob 本身内部。它不可查询。它没有类型。它没有验证。你不能让数据库"给我所有英雄形象是 X 的文章"或"找出所有包含定价表块的文章"。

块数据本质上是编码为文本字段内注释的元数据。那不是结构。那是一个黑客。

结构化内容实际上意味着什么

结构化内容将某物是什么与它看起来如何分离开来。与其存储 HTML blob，你定义一个包含离散、有类型字段的内容模型。

以下是相同内容在像 Sanity 这样的无头 CMS 中的结构化数据：

{
  "_type": "servicePage",
  "title": "我们的服务",
  "heroImage": {
    "_type": "image",
    "asset": { "_ref": "image-abc123" },
    "alt": "团队合作开展项目"
  },
  "sections": [
    {
      "_type": "textBlock",
      "heading": "高级咨询",
      "body": [
        {
          "_type": "block",
          "children": [
            { "_type": "span", "text": "我们为" },
            { "_type": "span", "text": "高级咨询", "marks": ["strong"] },
            { "_type": "span", "text": "服务企业。" }
          ]
        }
      ]
    },
    {
      "_type": "ctaForm",
      "formType": "contact",
      "placement": "inline"
    }
  ]
}

注意区别。每个内容片段都有一个类型。图片有明确的 alt 文本作为必需字段。富文本存储为便携格式——不是 HTML——可以呈现为任何输出。CTA 表单是一个有类型的引用，而不是停用插件时会中断的短码字符串。

这就是 Sanity、Contentful、Storyblok 和 Strapi 等无头 CMS 平台提供的。这就是它们存在的原因。

Portable Text 的优势

Sanity 的 Portable Text 格式（以及其他无头 CMS 中的类似方法）将富文本存储为有类型对象的数组。这意味着你可以：

• 将其呈现为网页 HTML
• 将其呈现为文档 Markdown
• 将其呈现为 AI 处理的纯文本
• 将其呈现为 React 组件的 JSX
• 将其呈现为语音助手的 SSML

HTML blob 给你一种输出格式：HTML。甚至不是干净的 HTML——带有所有怪癖的 WordPress 风格 HTML。

为什么 AI 无法读取你的 WordPress 内容

这是在 2025 年变得紧迫的部分。AI 驱动的工具——从 ChatGPT 和 Claude 到 Google 的 AI 概览和内部 RAG（检索增强生成）系统——都需要从语义上理解你的内容。它们需要知道东西是什么，而不仅仅是它们在浏览器中的样子。

解析问题

当你尝试从 WordPress HTML blob 中提取有意义的内容时，你会立即遇到这些问题：

1. 短码在 WordPress 外无法解析。 [gallery ids="1,2,3"] 在没有扩展它的 PHP 函数时毫无意义。
2. 块注释是非标准的。 <!-- wp:columns --> 不是网络标准。AI 解析器不知道如何处理它。
3. 内联样式和类没有语义含义。 <div class="wp-block-group has-background"> 告诉你内容目的什么都不是。
4. 嵌套 HTML 结构是模糊的。 那个嵌套 div 是侧边栏？标注？布局容器？无法以编程方式知道。
5. 插件生成的标记是不可预测的。 每个插件注入自己的 HTML 模式，通常彼此冲突。

这对 AI 概览和 LLM 的意义

Google 的 AI 概览（搜索结果顶部的 AI 生成摘要）从易于解析和理解的页面中拉取内容。根据 Authoritas 在 2025 年初的研究，具有清晰内容层次结构和架构标记的页面在 AI 概览中被引用的频率比内容质量相同但结构差的页面多 2-3 倍。

LLM 在内容干净时处理你的内容更好。句号。如果你的内容埋在标记汤中，信噪比会下降。模型必须猜测什么是内容，什么是装饰。有时它猜错了。

RAG 系统和内部 AI 工具

许多公司在 2025 年正在构建需要摄取自己内容的内部 AI 工具——知识库、产品文档、营销文案。如果该内容存在于 WordPress 中，提取管道看起来像这样：

1. 查询 WordPress REST API 或数据库
2. 获取 HTML blob
3. 剥离 HTML 标签（丢失所有结构）
4. 或解析 HTML（将噪声与信号混合）
5. 为嵌入分块文本
6. 祈祷一切顺利

使用来自无头 CMS 的结构化内容，它是：

1. 查询 API
2. 获取有类型的结构化 JSON
3. 选择完全你需要的字段
4. 按内容类型干净地分块
5. 生成高质量嵌入

输出质量的差异是巨大的。我看到仅通过将内容源从 HTML 提取的内容切换到结构化内容，RAG 准确性就提高了 30-40%。

非结构化内容的真实成本

让我们谈论不会出现在发票上但会彻底摧毁你的预算的成本。

成本因素	WordPress HTML Blob	结构化内容（无头 CMS）
跨渠道内容重用	手动复制粘贴、重新格式化	API 驱动、自动化
AI/ML 内容处理	需要解析管道、容易出错	直接 JSON 消费
重设计/重新平台努力	内容耦合到主题、高成本	内容解耦、自由切换前端
多语言支持	插件依赖、脆弱	内置、字段级本地化
内容治理	有限字段验证	架构强制内容类型
移动应用内容	REST API 返回 HTML 字符串	干净 JSON、原生就绪
开发者入职时间	主题 + 插件生态学习曲线	API 文档 + 内容架构
迁移到新平台的内容	痛苦的 HTML 解析	导出结构化 JSON

表中的每一行都代表真实的小时和真实的金钱。我在 WordPress 到无头的迁移项目中工作过，其中 60% 的项目预算用于内容转换——不是因为新系统很难，而是因为从旧 HTML blob 中提取意义是痛苦的。

无头 CMS 与 WordPress：诚实的比较

我不会假装 WordPress 在所有方面都很糟糕。并非如此。让我们诚实地看待每种方法的优势。

WordPress 仍然胜出的地方

• 生态系统规模。 60,000+ 插件。有插件可以处理所有事情。质量差异很大，但广度是无与伦比的。
• 非技术编辑熟悉度。 大多数内容编辑都使用过 WordPress。基本任务的学习曲线接近零。
• 一体化简洁性。 对于基本的宣传册网站或博客，WordPress 让你从零到发布的速度比任何东西都快。
• 进入成本。 共享托管 $5/月、免费主题，你就上线了。

无头 CMS 胜出的地方

• 内容结构和建模。 这是整篇文章的重点。无头 CMS 让你精确定义你的内容作为数据的样子。
• API 优先交付。 内容去往网站、应用、亭台、语音助手——任何能发送 HTTP 请求的地方。
• 性能。 与 Next.js 或 Astro 框架配对时，你可以获得静态生成、边缘缓存和亚秒级加载时间。
• 安全性。 前端没有 PHP 执行。没有 wp-login.php 可被暴力破解。攻击面大幅缩小。
• AI 就绪。 结构化内容本身可被 AI 工具、搜索引擎和自动化管道消费。
• 开发者体验。 现代工具、TypeScript 支持、实时协作、内容版本控制。

大多数文章忽略的细微差别

WordPress 可以通过 WPGraphQL 或 REST API 用作无头 CMS。一些团队这样做。但你仍然存储 HTML blob——你只是通过 API 提供它们，而不是用 PHP 呈现它们。根本问题没有改变。你的内容仍然是非结构化的。

带有 ACF（高级自定义字段）的 WordPress 更接近结构化内容。你可以创建有类型且可查询的自定义字段。但 ACF 是一个插入到不是为此设计的系统中的插件。内容建模 UX 很笨拙，复杂字段组的性能会下降，你仍然依赖于 WordPress 生态进行托管、更新和安全。

WordPress 限制的复合影响

这些不是理论问题。它们是我在实际项目中看到的破坏事物。

插件依赖地狱

典型的 WordPress 网站使用 20-40 个插件。每一个都可能与其他冲突。每一个都需要更新。每一个都是潜在的安全漏洞。当一个插件被放弃时（这经常发生），你就被留下了在你的内容中呈现为字面文本的短码。

我去年审计了一个网站，在 800 篇文章中有 [tabs] 短码。标签插件自 2021 年以来就没有更新过。内容被死代码绑架了。

单体架构税

WordPress 处理路由、渲染、内容存储、身份验证、媒体管理和插件执行都在单个 PHP 进程中。这意味着：

• 你不能独立于管理界面扩展内容 API
• 流量激增会影响处理编辑器会话的同一服务器
• 内容检索数据库查询与插件操作竞争
• 你不能在不接触 WordPress 服务器的情况下部署前端更改

现代无头 CMS 架构完全分离这些问题。内容 API 独立扩展。前端部署到边缘网络。编辑在不与公开流量共享资源的专用工作室中工作。

没人谈论的内容锁定

这是一个肮脏的秘密：WordPress 内容在理论上是便携的，但在实践中是锁定的。当然，你可以导出 XML。但该 XML 包含 HTML blob，其中包含短码、特定于插件的标记和 WordPress 内部引用。迁移到任何其他系统需要解析和转换努力，该努力与内容量和复杂性呈线性关系。

无头 CMS 中的结构化内容导出为 JSON。干净、有类型、可预测的 JSON。从 Sanity 迁移到 Contentful（反之亦然）需要映射内容类型，而不是解析 HTML。

迁移路径：从 Blob 到结构

如果你坐在一个 WordPress 网站上，这篇文章让你感到不适，那很好。让我们谈谈该怎么办。

步骤 1：审计你的内容

在你触及任何东西之前，了解你拥有什么。对你的数据库运行查询：

-- 查找使用中的所有短码
SELECT DISTINCT
  REGEXP_SUBSTR(post_content, '\\[[a-zA-Z_-]+') AS shortcode,
  COUNT(*) AS usage_count
FROM wp_posts
WHERE post_status = 'publish'
  AND post_content REGEXP '\\[[a-zA-Z]'
GROUP BY shortcode
ORDER BY usage_count DESC;

记录每个短码、每个自定义块、每个 ACF 字段组。这个清单驱动你的内容模型设计。

步骤 2：首先设计你的内容模型

不要选择 CMS 然后弄清楚你的模型。根据你的内容需求设计模型，然后选择最支持它的 CMS。

问这些问题：

• 有哪些不同的内容类型？（博客文章、案例研究、产品页面、团队成员……）
• 每个类型需要哪些字段？
• 类型之间的关系是什么？
• 谁需要编辑什么？
• 这些内容需要在哪里出现？（网络、应用、电子邮件、AI 工具……）

步骤 3：构建转换管道

这是艰苦工作发生的地方。你需要将 HTML blob 转换为结构化数据。帮助的工具：

• 自定义 Node.js 脚本使用 cheerio 或 unified/rehype 进行 HTML 解析
• Sanity 的迁移工具用于导入结构化内容
• Contentful 的迁移 CLI 用于编程内容创建
• OpenAI 或 Claude API 用于 AI 辅助内容分类（认真地——在迁移期间使用 AI 标记和分类你的内容）

// 示例：将 WordPress HTML 转换为 Portable Text
import { htmlToBlocks } from '@sanity/block-tools'
import { Schema } from '@sanity/schema'

const defaultSchema = Schema.compile({ /* your schema */ })
const blockContentType = defaultSchema
  .get('post')
  .fields.find(field => field.name === 'body').type

const blocks = htmlToBlocks(
  '<p>你的<strong>WordPress</strong> HTML 在这里</p>',
  blockContentType
)

步骤 4：并行运行

不要做大爆炸迁移。并行运行 WordPress 和你的新无头 CMS。分批迁移内容。验证每批。对无头 CMS API 构建新前端，同时保持旧网站实时。

这是我们在我们的无头 CMS 项目中采取的方法。虽然前期工作更多，但可大幅降低风险。

步骤 5：重定向和停用

一旦新网站上线并通过验证，设置 301 重定向、监控 404 和关闭 WordPress。永远保持数据库备份——你永远不知道何时需要引用旧内容。

选择合适的无头 CMS

市场已经成熟显著。以下是 2025 年主要玩家的堆栈情况：

CMS	内容建模	价格（起始）	最适合	AI 功能
Sanity	优秀——代码定义的架构	免费层，然后 $99/月（增长）	自定义内容模型、开发者团队	Sanity AI Assist 内置
Contentful	强大——基于 UI 的建模	免费层，然后 $300/月（团队）	企业内容运营	AI 内容生成附加组件
Storyblok	良好——视觉编辑焦点	免费层，然后 €106/月（业务）	需要视觉预览的营销团队	AI 驱动的内容创建
Strapi	良好——自托管灵活性	免费（自托管）、云从 $29/月	想要完全控制的团队	社区插件
Payload CMS	优秀——代码优先、TypeScript 原生	免费（自托管）、云即将推出 2025	开发者团队、Next.js 项目	通过插件可扩展

没有通用最佳选择。这取决于你的团队、内容复杂性和预算。如果你需要帮助评估选项，我们为数十个团队做过这个分析。

常见问题

什么是结构化内容，为什么它对 SEO 很重要？ 结构化内容将信息存储为有类型、标记的数据字段，而不是原始 HTML。对于 SEO，这很重要是因为搜索引擎——特别是 Google 的 AI 驱动系统——可以更精确地理解和引用结构化内容。从结构化内容构建的页面往往具有更干净的 HTML 输出、适当的标题层次结构和更一致的架构标记，所有这些都是 2025 年的排名信号。

WordPress 可以用作无头 CMS 吗？ 从技术上讲是的。WordPress 有 REST API，可以用 WPGraphQL 扩展。但核心问题仍然存在：你的内容仍然作为 HTML blob 存储在数据库中。以无头方式使用 WordPress 给你非结构化内容的 API 访问。你获得了无头架构优势（前端灵活性、更好的性能），但没有获得结构化内容的优势。对于某些团队，这是可接受的权衡。对于大多数团队，这不值得复杂性。

从 WordPress 迁移到无头 CMS 需要多少成本？ 这差异很大，取决于内容量和复杂性。拥有 50-100 个干净内容页面的小网站可能需要 2-4 周的开发工作。拥有数千篇文章、自定义文章类型、ACF 字段和富有短码内容的大型网站可能需要 2-4 个月。内容转换工作——将 HTML blob 转换为结构化数据——通常占总工作的 40-60%。查看我们的定价页面获取无头 CMS 项目的粗略估计。

AI 概览会降低我的 WordPress 网站的排名吗？ 不直接——Google 不会惩罚 WordPress 网站。但 AI 概览和类似功能更倾向于易于解析和理解的内容。具有干净、结构良好的 HTML（结构化内容自然生成）的网站往往被引用更频繁。带有插件生成的标记、内联样式和损坏短码的混乱 WordPress 页面对任何 AI 系统来说都更难可靠地处理。

如果我停用插件，我的 WordPress 内容会怎样？ 该插件的任何短码将在你的文章中呈现为字面文本。例如，如果你停用图库插件，你的访客将在页面上看到 [gallery ids="1,2,3"] 作为纯文本。基于块的插件可能会留下损坏的 HTML 或空容器。这是最常见的——也是最令人沮丧的——WordPress 内容问题之一。无头 CMS 中的结构化内容没有这个问题，因为内容和呈现是完全分离的。

Gutenberg（WordPress 块编辑器）被认为是结构化内容吗？ 这是向结构迈进的一步，但它不足。Gutenberg 块在 post_content blob 内的 HTML 注释中编码类型信息。此元数据不存储在单独的数据库字段中，不可通过 SQL 查询，并且不根据架构验证。与经典编辑器相比，它的结构更好，但从根本上不同于由 Sanity 或 Contentful 等无头 CMS 实现的真正结构化内容。

哪个无头 CMS 最适合 Next.js 项目？ Sanity 和 Payload CMS 是 2025 年 Next.js 开发的最强选项。Sanity 提供优秀的实时预览功能和成熟的生态系统。Payload CMS 特别有趣，因为它是 TypeScript 原生的，可以在 Next.js 应用程序内部运行。Contentful 和 Storyblok 也有可靠的 Next.js 集成。"最佳"选择取决于你是否优先考虑内容建模灵活性、视觉编辑、自托管还是企业功能。

在不进行完整迁移的情况下，我如何使我的内容 AI 就绪？ 如果完整迁移现在不可行，你可以采取增量步骤。使用 Yoast 或 RankMath 等插件向你的 WordPress 页面添加 JSON-LD 结构化数据。清理短码使用——在可能的地方用原生 Gutenberg 块替换它们。使用 ACF 和 WPGraphQL 创建内容 API 层，将关键字段公开为结构化数据。这些步骤不会给你真正的结构化内容，但会改进 AI 可读性，同时你计划适当的迁移。