最近、3,000以上の投稿を持つWordPressサイトを監査しました。クライアントは自分たちのコンテンツをAIツールに取り込んで、要約を生成し、レコメンデーションエンジンを動かしたいと考えていました。簡単なはずですよね？コンテンツをエクスポートして、パイプで流し込んで、完了。

ところが、違いました。すべての投稿が、もう存在しないプラグインからのショートコード、クラシックエディタからのインラインスタイル、地雷のように散らばったGutenbergブロックコメント、パーサーが窒息する符号化されたエンティティで、絡み合ったHTMLの塊でした。データベースの「コンテンツ」フィールドは、まったくコンテンツではありませんでした。それはWordPress自身だけが解釈できるレンダリング命令セットでした。AIモデルはゴミを生産しました。クライアントは激怒しました。そして私は、より多くのチームが聞く必要があることを説明しなければなりませんでした。コンテンツの保存方法が、今日だけでなく、あなたがまだ考えていないすべてのユースケースについて、あなたができることを決定します。

これは構造化されたコンテンツとHTMLの塊の物語であり、それがなぜ2025年以上に重要なのか、そして実際の移行パスがどのように見えるかについての物語です。

目次

HTMLの塊とは何か、そしてWordPressがそれらを使用する理由

任意のWordPressサイトでphpMyAdminを開き、wp_postsテーブルを見てください。post_content列を見つけてください。見えるのは、すべてを含む1つのテキストフィールドです。見出し、段落、画像、埋め込み、ショートコード、ブロックマークアップ、インラインCSS。すべてが1つの長い文字列にまとめられています。

データベース内の典型的なGutenbergの投稿は次のようなものです：

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">Our Services</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>We offer <strong>premium consulting</strong> for enterprises.</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の塊です。プレゼンテーションとコンテンツが絡み合っています。データベースは「Our Services」が見出しであることを知りません。画像がヒーロー画像であることも知りません。問い合わせフォームがCTAコンポーネントであることも知りません。それはすべてただ...フィールド内のテキストです。

WordPressはこれを行います。なぜなら2003年にブログプラットフォームとして設計されたからです。メンタルモデルはシンプルでした。投稿にはタイトルと本文があります。本文はHTMLです。あなたがそれを書き、WordPressがそれをレンダリングします。そのモデルはブログに非常にうまく機能しました。モダンなコンテンツ運用のために、それは劇的に崩壊します。

本来はこうなるはずだったGutenbergの改善

Gutenberg（ブロックエディタ）はこれを修正することになっていました。そして公平に言うと、それはいくつかの構造を追加しました。それらのHTMLコメントはブロックタイプと属性をJSONとしてエンコードしています。しかし、ここが重大な失敗です。その構造はHTML塊の内部に存在しています。クエリ可能ではありません。型付けされていません。検証されていません。「ヒーロー画像がXである全ての投稿をくれ」または「価格表ブロックを含むすべての投稿を見つけて」をデータベースに尋ねることはできません。

ブロックデータは本質的に、テキストフィールド内のコメントとしてエンコードされたメタデータです。それは構造ではありません。それはハックです。

構造化されたコンテンツが実際に意味すること

構造化されたコンテンツは、何であるかをどのように見えるかから分離します。HTMLの塊を保存する代わりに、離散的で型付けされたフィールドを持つコンテンツモデルを定義します。

Sanityのようなヘッドレスcmsの同じコンテンツを構造化データとして次に示します：

{
  "_type": "servicePage",
  "title": "Our Services",
  "heroImage": {
    "_type": "image",
    "asset": { "_ref": "image-abc123" },
    "alt": "Team collaborating on a project"
  },
  "sections": [
    {
      "_type": "textBlock",
      "heading": "Premium Consulting",
      "body": [
        {
          "_type": "block",
          "children": [
            { "_type": "span", "text": "We offer " },
            { "_type": "span", "text": "premium consulting", "marks": ["strong"] },
            { "_type": "span", "text": " for enterprises." }
          ]
        }
      ]
    },
    {
      "_type": "ctaForm",
      "formType": "contact",
      "placement": "inline"
    }
  ]
}

違いに注目してください。すべてのコンテンツにはタイプがあります。画像には要求されるフィールドとして明示的な代替テキストがあります。リッチテキストはポータブル形式（HTMLではなく）で保存されます。これは任意の出力にレンダリングできます。CTA形式は、ショートコード文字列ではなく、型付けされた参照です。プラグインを無効化したときに壊れる可能性があります。

これはSanity、Contentful、Storyblok、StrapiのようなヘッドレスCMSプラットフォームが提供するものです。そして彼らが存在する理由です。

PortableTextアドバンテージ

SanityのPortable Textフォーマット（および他のヘッドレスCMSの同様のアプローチ）は、型付けされたオブジェクトの配列としてリッチテキストを保存します。これは次のことができることを意味します：

  • Webに対してHTMLとしてレンダリング
  • ドキュメント用にMarkdownとしてレンダリング
  • AI処理用にプレーンテキストとしてレンダリング
  • Reactコンポーネント用にJSXとしてレンダリング
  • 音声アシスタント用にSSMLとしてレンダリング

HTMLの塊は1つの出力形式を与えます。HTML。そして、すべてのQuirksを備えたWordPress風HTMLでさえもありません。

AIがあなたのWordPressコンテンツを読むことができない理由

これは2025年の緊急事態になっている部分です。ChatGPTおよびClaudeからGoogleのAI概要および内部RAG（Retrieval-Augmented Generation）システムまで、すべてのAI搭載ツールは、コンテンツをセマンティックに理解する必要があります。彼らはブラウザでどのように見えるかではなく、物が何であるかを知る必要があります。

パースの問題

WordPressのHTMLの塊から意味のあるコンテンツを抽出しようとすると、これらの問題が直ちに発生します：

  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生成の要約）は、解析と理解が簡単なページからコンテンツを引き出しています。2025年初頭のAutoritasからの調査によると、明確なコンテンツ階層とスキーママークアップを持つページは、同等のコンテンツ品質を持つがページ構造が低いページよりも、AI概要で引用される可能性が2〜3倍高くなっています。

LLMはコンテンツがきれいなときにあなたのコンテンツをより良く処理します。ポイント。あなたのコンテンツがマークアップスープに埋もれている場合、信号対ノイズ比は下落します。モデルは、コンテンツが何であり、装飾が何であるかを推測する必要があります。時々間違って推測します。

RAGシステムと内部AIツール

2025年の多くの企業は、独自のコンテンツ（知識ベース、製品ドキュメント、マーケティングコピー）を取り込む必要がある内部AIツールを構築しています。そのコンテンツがWordPressに住んでいる場合、抽出パイプラインは次のようになります：

  1. WordPress REST APIまたはデータベースをクエリ
  2. HTMLの塊を取得
  3. HTMLタグを削除（すべての構造を失う）
  4. またはHTMLを解析（信号とノイズが混ざる）
  5. 埋め込みのテキストをチャンク
  6. 最高を願ってください

ヘッドレスCMSから構造化されたコンテンツを使用すると、それは：

  1. APIをクエリ
  2. 型付けされた構造化されたJSONを取得
  3. 必要な正確にフィールドを選択
  4. コンテンツタイプできれいにチャンク
  5. 高品質の埋め込みを生成

出力品質の違いは劇的です。私はHTMLで抽出されたコンテンツから構造化されたコンテンツにソースを切り替えるだけで、RAG精度が30〜40%改善されるのを見ました。

非構造化コンテンツの実際のコスト

請求書に表示されないが、時間をかけてあなたの予算を完全に破壊する実際のコストについて話しましょう。

コスト要因 WordPress HTMLの塊 構造化コンテンツ（ヘッドレスCMS）
チャネル間でのコンテンツの再利用 手動コピーペースト、再フォーマット APIドリブン、自動
AI/MLコンテンツ処理 パースパイプラインが必要、エラーが発生しやすい 直接JSONの消費
再設計/リプラットフォーム努力 コンテンツがテーマに結合、努力が高い コンテンツが分離、フロントエンドを自由に交換
マルチ言語サポート プラグイン依存、脆弱 組み込み、フィールドレベルのローカライゼーション
コンテンツガバナンス 限定的なフィールド検証 スキーマ強制されたコンテンツタイプ
モバイルアプリコンテンツ REST APIはHTMLの文字列を返す きれいなJSON、ネイティブ対応
開発者のオンボーディング時間 テーマ+プラグインエコシステム学習曲線 APIドキュメント+コンテンツスキーマ
新しいプラットフォームへのコンテンツの移行 痛いHTMLパース 構造化されたJSONのエクスポート

そのテーブルのすべての行は、実際の時間と実際のお金を表します。WordPressからヘッドレスへの移行に取り組んだことがあります。そこでは、プロジェクト予算の60%がコンテンツ変換に費やされました。新しいシステムが難しかったからではなく、古いHTMLの塊から意味を抽出することが苦痛だったからです。

ヘッドレスCMS対WordPress：正直な比較

WordPressがすべてで恐ろしいと言うつもりはありません。そうではありません。各アプローチが何をうまくやっているかについて正直に話しましょう。

WordPressがまだ勝つところ

  • エコシステムのサイズ。 60,000以上のプラグイン。すべての何かのためのプラグインがあります。品質は大きく異なりますが、幅は比類がありません。
  • 非技術的なエディタの認識。 ほとんどのコンテンツエディタはWordPressを使用しました。基本的なタスクの学習曲線はほぼゼロです。
  • オールインワンのシンプルさ。 基本的なブロシュアサイトまたはブログの場合、WordPressはあなたをゼロから公開するまで、何かより高速に取得します。
  • エントリの費用。 月額5ドルの共有ホスティング、無料のテーマ、そしてあなたはライブです。

ヘッドレスCMSが勝つところ

  • コンテンツの構造化とモデリング。 これはこの記事全体のポイントです。ヘッドレスCMSは、コンテンツが正確にデータのようにどのように見えるかを定義できます。
  • APIファーストデリバリー。 コンテンツはウェブサイト、アプリ、キオスク、音声アシスタント、HTTPリクエストを作成できる場所ならどこにでも行きます。
  • パフォーマンス。 Next.jsまたはAstroのようなフレームワークと組み合わせると、静的生成、エッジキャッシング、1秒以下のロード時間が得られます。
  • セキュリティ。 フロントエンドでのPHP実行はありません。ブルートフォース攻撃を受ける可能性のあるwp-login.phpはありません。攻撃面が大幅に縮小します。
  • AI準備。 構造化されたコンテンツは、AIツール、検索エンジン、自動化パイプラインでネイティブに消費できます。
  • 開発者体験。 モダンツール、TypeScriptサポート、リアルタイムコラボレーション、コンテンツ上のバージョン管理。

ほとんどの記事が見逃すニュアンス

WordPressは、WPGraphQLまたはREST APIを介してヘッドレスCMSとして使用できます。いくつかのチームはこれを行います。しかし、あなたはまだHTMLの塊を保存しています。あなたはそれらをPHPでレンダリングする代わりに、APIで提供しているだけです。根本的な問題は変わっていません。あなたのコンテンツはまだ構造化されていません。

ACF（Advanced Custom Fields）を持つWordPressは、構造化されたコンテンツに近づきます。型付けされ、クエリ可能なカスタムフィールドを作成できます。しかし、ACFは、そのために設計されていなかったシステムにボルトで留めたプラグインです。コンテンツモデリングUXはぎこちなく、複雑なフィールドグループではパフォーマンスが低下し、ホスティング、更新、セキュリティについてはWordPressエコシステムに依存しています。

時間とともに悪化するWordPressの制限

これらは理論的な問題ではありません。実際のプロジェクトで壊れるのを見てきたことです。

プラグイン依存地獄

典型的なWordPressサイトは、20〜40個のプラグインを使用しています。それぞれが他と競合できます。それぞれが更新が必要です。それぞれが潜在的なセキュリティの脆弱性です。プラグインが放棄されると（これは絶えず発生します）、あなたはリテラルテキストとしてレンダリングするショートコードで抱えられたコンテンツで立ち往生しています。

昨年、800の投稿全体にわたって[tabs]ショートコードを持つサイトを監査しました。タブプラグインは2021年以来更新されていません。コンテンツは死んだコードに人質に取られていました。

モノリシックアーキテクチャタックス

WordPressはルーティング、レンダリング、コンテンツストレージ、認証、メディア管理、およびプラグイン実行を単一のPHPプロセスで処理します。これは次を意味します：

  • コンテンツAPIを管理インターフェイスから独立してスケーリングすることはできません
  • トラフィックのスパイクは、エディターセッションを処理する同じサーバーにヒットします
  • コンテンツ取得のデータベースクエリは、プラグイン操作と競争します
  • フロントエンドの変更をWordPressサーバーに触れずにデプロイすることはできません

モダンなヘッドレスCMSアーキテクチャは、これらの懸念を完全に分離しています。コンテンツAPIは独立してスケール可能です。フロントエンドはエッジネットワークにデプロイします。エディタはパブリックトラフィックを処理する専用スタジオで動作します。

誰も話さないコンテンツロック

ここに秘密があります。WordPressのコンテンツは理論的にはポータブルですが、実際にはロックされています。確かに、XMLをエクスポートできます。しかし、そのXMLには、ショートコード、プラグイン固有のマークアップ、WordPress内部参照を含むHTMLの塊が含まれています。他のシステムに移動するには、コンテンツボリュームと複雑さにリニアでスケーリングされる解析と変換努力が必要です。

ヘッドレスCMSの構造化されたコンテンツはJSONとしてエクスポートしています。クリーンで、型付けされた、予測可能なJSON。SanityからContentfulへ（またはその逆）への移動には、HTMLのパースではなくコンテンツタイプのマッピングが必要です。

移行パス：BlobsからStructureへ

WordPressサイトに座っていて、この記事があなたを不快にしている場合は、良いです。何をすべきかについて話しましょう。

ステップ1：コンテンツを監査

何かに触れる前に、何を持っているかを理解してください。データベースに対してクエリを実行します：

-- Find all shortcodes in use
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の塊を構造化されたデータに変換する必要があります。ツールの役に立ちます：

  • cheerioまたはunified/rehypeを使用したカスタムNode.jsスクリプト（HTMLパース用）
  • 構造化されたコンテンツをインポートするためのSanityの移行ツール
  • プログラムによるコンテンツ作成のためのContentfulの移行CLI
  • OpenAIまたはClaudeAPI（移行中にコンテンツをタグ付けおよび分類するためのAI支援コンテンツ用）
// Example: Converting WordPress HTML to 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>Your <strong>WordPress</strong> HTML here</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プロジェクト プラグイン経由で拡張可能

普遍的な最良の選択肢はありません。それはあなたのチーム、あなたのコンテンツの複雑さ、そしてあなたの予算に依存します。オプションの評価に役立つ場合は、私たちはダースのチームのためにこの分析を行いました。

FAQ

構造化されたコンテンツとは何であり、なぜSEOにとって重要なのですか？

構造化されたコンテンツは、生のHTMLではなく、型付けされたラベル付きデータフィールドとして情報を保存します。SEOの場合、これが重要です。なぜなら、検索エンジン（特にGoogleのAI搭載システム）が構造化されたコンテンツをより正確に理解および引用できるためです。構造化されたコンテンツから構築されたページは、よりきれいなHTML出力、適切な見出し階層、およびより一貫性のあるスキーママークアップを傾向があり、2025年のランキング信号です。

WordPressはヘッドレスCMSとして使用できますか？

技術的にはい。WordPressにはREST APIがあり、WPGraphQLで拡張できます。ただし、根本的な問題は残ります。コンテンツは依然としてデータベースのHTMLの塊として保存されます。WordPressをヘッドレスで使用すると、構造化されていないコンテンツへのAPIアクセスが得られます。フロントエンドの柔軟性や改善されたパフォーマンスなどのヘッドレスアーキテクチャの利点が得られますが、構造化されたコンテンツの利点はありません。いくつかのチームの場合、それは複雑さに値する許容可能なトレードオフです。ほとんどの場合、そうではありません。

WordPressからヘッドレスCMSへの移行にはどのくらいの費用がかかりますか？

コンテンツボリュームと複雑さに基づいて、それは非常に異なります。クリーンなコンテンツの50〜100ページの小さなサイトは、2〜4週間の開発努力を取ることがあります。千の投稿、カスタムポストタイプ、ACFフィールド、およびショートコードが豊富なコンテンツを持つ大規模なサイトは、2〜4か月かかることがあります。コンテンツの変換作業（HTMLのBlobを構造化データに変換する）は、通常、合計努力の40〜60%です。価格ページでヘッドレスCMSプロジェクトのおおよその見積もりを確認してください。

AI概要は自分のWordPressサイトのランク付けを下げますか？

直接的にはありません。Googleはこんにちはサイトを罰しません。しかし、AI概要および同様の機能は、簡単に解析して理解できるコンテンツを好みます。クリーンでよく構造化されたHTML（構造化されたコンテンツが自然に生産する）を持つサイトは、より頻繁に引用される傾向があります。プラグイン生成マークアップ、インラインスタイル、壊れたショートコードを備えた混乱したWordPressページは、あらゆるAIシステムが信頼して処理するのは難しいです。

プラグインを無効化してもWordPressのコンテンツはどうなりますか？

そのプラグインからのショートコードは、投稿内にリテラルテキストとしてレンダリングされます。たとえば、ギャラリープラグインを無効化する場合、訪問者はページ上のプレーンテキストとして[gallery ids="1,2,3"]を見ます。ブロックベースのプラグインは、壊れたHTMLまたは空のコンテナを残す可能性があります。これは最も一般的な（そして最も欲求不満）WordPressコンテンツの問題の1つです。ヘッドレスCMSの構造化されたコンテンツは、この問題を抱えていません。コンテンツとプレゼンテーションは完全に分離しているためです。

Gutenberg（WordPressのブロックエディタ）は構造化されたコンテンツと見なされていますか？

それは構造に向かった一歩ですが、短くなります。Gutenbergブロックはpost_contentの塊内のHTMLコメント内で情報を型別にエンコードします。このメタデータは、個別のデータベースフィールドに保存されず、SQL経由でクエリ可能ではなく、スキーマに対して検証されません。それはクラシックエディタより構造化されていますが、SanityやContentfulのようなヘッドレスCMSによって実装された真の構造化コンテンツとは根本的に異なります。

Next.jsプロジェクトに最適なヘッドレスCMSはどれですか？

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読み取り性が向上します。