Cloudflare上のLPに構造化データ6種とAI Crawl Controlを入れる

Posted at 2026-08-05

元ネタ: nompass-lp 構造化データ強化／Cloudflare AI Crawl Control設定
公開可: 2026-08-04 (audit)
パイプラインスコア: factcheck=100 style=85
ブランド文脈: 🔬Miyoki Labs（技術・体験レーン）

Cloudflare 上で動かしている LP に構造化データを入れたい開発者に向けて書きます。JSON-LD をどこまで出せばいいのか、AI 向けのクローラーをどう扱えばいいのかで迷っている人が対象です。

この記事で分かるのは2点です。ひとつは 6種類のスキーマをどう選んで実装したか、もうひとつは AI Crawl Control でクローラーの許可とブロックをどう振り分けたか。

nompass-lp で構造化データを強化し、あわせて Cloudflare の AI Crawl Control を設定しました。構造化データは FAQPage・Service・OfferCatalog を出力し、あわせて BlogPosting・BreadcrumbList・WebSite も入れています。bot 側は、学習系のクロールをブロックし、検索系のクロールは許可する形にしています。

扱うのは実装と設定の中身まで。順位や流入がどう動いたかには触れません。

前提知識：JSON-LD・schema.org・AI Crawl Control

先に用語を3つだけ整理します。ここが曖昧なままだと、あとの手順で「何のためにこれを書いているのか」が分からなくなります。

schema.org … 一言でいうと「Web上のモノを説明するための共通語彙」です。ページに何が書いてあるかを機械に伝えるための型が決められていて、Service（サービス）、FAQPage（Q&A）、BreadcrumbList（パンくず）といった名前がそれにあたります。人間は見出しや文脈からページの内容を読み取れますが、機械にはその手がかりが乏しい。だから型名で明示する、というのが発想の出発点です。

JSON-LD … schema.org の語彙を JSON の形で書く記法です。HTML のタグに属性を足していく方式（Microdata など）と違い、<script type="application/ld+json"> の中に構造をまとめて書けます。よく使われるのは、マークアップと構造化データを分離したいときです。見た目の HTML を触らずにデータだけ差し替えられるので、テンプレートが複雑なサイトほど扱いやすくなります。

AI Crawl Control … Cloudflare 側で、サイトに来るクローラーをどう扱うか決める機能です。ポイントは、クローラーが一枚岩ではないこと。検索インデックスを作りに来るものと、モデルの学習データを集めに来るものは目的が違うので、同じ扱いにする必要はありません。ここを分けて考えられるかどうかが、この記事の後半の要になります。

追加した構造化データ6種

出力したのは次の6つの型です。

スキーマ	何を説明するか
`Service`	提供しているサービスそのもの
`OfferCatalog`	サービスのメニュー・提供内容のまとまり
`WebSite`	サイト全体の情報
`BreadcrumbList`	ページの階層位置
`FAQPage`	よくある質問と回答
`BlogPosting`	記事ページ

並べてみると、6つが3つの層に分かれているのが見えてきます。

サイト全体を説明する層 … WebSite
ページの位置を説明する層 … BreadcrumbList
ページの中身を説明する層 … Service・OfferCatalog・FAQPage・BlogPosting

LP は1枚のページに情報を詰め込む構造になりがちですが、機械から見ると「サイトの話」「位置の話」「中身の話」は別ものです。層で分けておくと、あとからページを増やしたときに、どの型を足せばいいのかが迷わず決まります。

実装から検証までの手順

ページの役割を決める … そのページがサービス紹介なのか記事なのかを先に決めます。ここが決まらないと Service と BlogPosting のどちらを主役にするかが決まりません。
サイト共通の型を置く … WebSite と BreadcrumbList は全ページ共通の骨格なので、テンプレート側にまとめて置きます。
ページ固有の型を足す … サービス紹介のページなら Service と OfferCatalog、Q&A を持つページなら FAQPage、記事なら BlogPosting。
JSON-LD として出力する … <script type="application/ld+json"> に入れて HTML に埋め込みます。
構文と型を確認する … JSON として壊れていないか、schema.org の型名を間違えていないかを見ます。ここは目視ではなく検証ツールに任せた方が早いです。
クローラー側の方針を決める … 構造化データが出せたら、次はそれを誰に読ませるかの話に移ります（後述）。

順番のポイントは、2 と 3 を分けているところです。共通の型とページ固有の型を同じ場所に書くと、ページを追加するたびに全部をコピーすることになり、WebSite の情報がページごとにずれていきます。骨格と中身を別の場所で管理すると、この種のずれが起きません。

JSON-LD のコード例

Service と OfferCatalog を組み合わせた形です。この2つは単独で置くより、入れ子にした方が意味が通ります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",

  "name": "サービス名",
  "description": "サービスの説明文",

  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "提供メニュー",

    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "メニュー1の名前"
        }
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "メニュー2の名前"
        }
      }
    ]
  }
}
</script>

この構成を選んだ理由を書いておきます。Service と OfferCatalog を別々の JSON-LD ブロックとして並べて置くこともできますが、それだと「このメニュー一覧が、どのサービスのものなのか」が機械側に伝わりません。hasOfferCatalog で入れ子にすると、サービスとメニューの所属関係がそのまま構造に出ます。LP は視覚的なレイアウトで「これはこのサービスの料金表です」と示していますが、その関係は HTML の見た目にしか存在しないことが多い。入れ子はそれを機械が読める形に置き換える作業だと考えると分かりやすいです。

FAQPage も考え方は同じで、質問と回答が対になっている関係を構造で示します。並べるだけでは対応関係が落ちるので、型で結ぶ。構造化データは全体を通して「見た目に埋もれている関係を、明示的に書き出す」作業だと捉えると、どの型をどう入れ子にすべきかの判断が付きやすくなります。

同じような実装をやってみたい方向けに、これまで作ったものは Miyoki Labs のポートフォリオにまとめてあります。

Cloudflare 側でクローラーを振り分ける

構造化データを整えたら、次は bot 側です。今回入れた方針は次の2行。

学習系のクロールはブロック
検索系のクロールは許可

なぜ分けるのか。構造化データを丁寧に書く目的は、ページの内容を機械に正しく理解してもらうことです。検索インデックスを作るクローラーに対しては、それがそのまま利益になります。一方で、モデルの学習データを集めるクロールは目的が別で、構造化データを整えたことの見返りが同じ形では返ってきません。同じ「bot」という言葉でくくると、この違いが消えます。

実装した内容としてはシンプルで、AI Crawl Control の設定でクローラーの種類ごとに許可とブロックを振り分けるだけです。構造化データ側のコードは一切変わりません。ここが今回いちばん言いたいところで、構造化データの実装と bot の制御は、同じ「AEO」という文脈で語られるわりに、触る場所がまったく別です。

構造化データとbot制御は分けて運用する

この題材は、構造化データの実装と bot 設定の2つを通しで扱えます。

構造化データ … FAQPage・Service・OfferCatalog・BlogPosting・BreadcrumbList・WebSite を追加
bot 制御（AI Crawl Control） … 学習系をブロック、検索系を許可

作業として並べると1つのタスクに見えますが、片方はコードの話（テンプレートに JSON-LD を出す）、もう片方は設定の話（Cloudflare のダッシュボードでクローラーを振り分ける）です。混ぜて考えると、構造化データを直したいときに Cloudflare の設定を疑ったり、その逆をやったりして時間を落とします。

同じ文脈で語られるものほど、触る場所で切って管理する。この記事で残しておきたいのはその一点です。

Miyoki Labs で AI プロダクトを作っている Miyoki です。個人開発と受託の合間に、実装の記録をこうして残しています。

作ったものと受けている仕事の内容は、こちらにまとめています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up