AI検索のためのテクニカルSEO｜構造化データとllms.txt

AI検索の対策では、優れた文章を書くことよりも先に、「機械が正しく読み取れるサイトかどうか」が土台になります。生成AIの回答やAIによる検索結果は、クローラが集めたページを解釈し、意味を構造として理解した上で引用元を選びます。そのため、構造化データ（＝ページの意味を機械可読な形で明示する記述）、llms.txt（＝AIに読ませたい情報を案内するファイル）、サイトマップ、インデックス性、表示速度という技術基盤を整えることが、AIに引用・参照される確率を底上げする近道になると考えられます。本稿はこの5つを、Web・マーケ担当がすぐ着手できる粒度で解説します。

なぜAI検索でテクニカルSEOが土台になるのか

AI検索の裏側では、クローラ（＝Webを巡回してページを取得する自動プログラム）がHTMLを取得し、その内容を解釈して「何について書かれたページか」を判断します。人間なら見出しや文脈で自然に読み取れることも、機械にとっては曖昧です。ここで技術基盤が働きます。ページの意味を機械可読な形で明示し、巡回しやすく整え、速く安定して表示できるようにするほど、AI側は正確に理解し、引用元として採用しやすくなるとみられます。

テクニカルSEO（＝サイトの技術的な土台を最適化する取り組み）は、従来の検索エンジン対策とAI検索対策で共通する部分が大きいのが実務上の利点です。クロール（巡回）・インデックス（索引登録）・レンダリング（表示処理）という基本の流れは同じで、そこにAI向けの案内（llms.txtや構造化データの強化）を上乗せする形になります。つまり既存のSEO資産を捨てずに拡張できます。

図1：クローラが取得したページを解釈し、引用元として選ぶまでの基本ステップ。

拡大

図1：クローラが取得したページを解釈し、引用元として選ぶまでの基本ステップ。

閉じる

構造化データ（schema.orgとJSON-LD）で意味を明示する

構造化データは、ページの内容を「これは会社名」「これは価格」「これは著者」と機械に明示するための記述です。語彙（＝意味の共通辞書）にはschema.org（スキーマドットオルグ＝主要検索企業が共同運営する構造化データの標準規格）を使い、記述形式にはJSON-LD（ジェイソン・エルディー＝ページ本文と分離してscriptタグに埋め込む方式）を使うのが標準的です。本文の見た目を変えずに意味情報だけを足せるため、実装と保守がしやすいのが利点です。

どの型（Type＝schema.orgが定めるカテゴリ）を使うかはページの役割で決めます。企業サイトならOrganization（組織）、記事ならArticle、商品ならProduct、よくある質問ならFAQPage、パンくずならBreadcrumbListが基本です。重要なのは、構造化データに書く内容とページに実際に表示されている内容を一致させることです。表示していない情報を構造化データにだけ書くと、ガイドライン違反として扱われる場合があります。

図2：意味を明示する記述は「語彙・形式・型」の三層で成り立つ。

拡大

図2：意味を明示する記述は「語彙・形式・型」の三層で成り立つ。

閉じる

llms.txtでAIに読ませたい情報を案内する

llms.txt（エルエルエムズ・ドットテキスト）は、サイトのルート（＝トップ階層）に置くテキストファイルで、AIに優先的に読んでほしいページや要点を案内する目的の提案仕様です。人間向けのナビゲーションとは別に、AIが要点を効率よく把握できる「案内板」を用意する発想です。まだ広く確立した標準ではなく提案段階の取り組みですが、主要ページへのリンクと簡潔な説明をまとめておく実装コストは低く、先行して整える価値があります。

混同しやすいファイルとの違いを押さえておきます。robots.txt（ロボッツ・ドットテキスト）はクローラの巡回可否を指示するファイル、サイトマップは全ページの一覧をクローラに渡すファイル、llms.txtはAIに読ませたい要点を案内するファイルです。役割が異なるため、どれか一つで代替はできません。三者を併用して、巡回・網羅・要点案内を分担させるのが筋の良い設計です。

図3：AI向けの案内ファイルを整備する基本的な流れ。

拡大

図3：AI向けの案内ファイルを整備する基本的な流れ。

閉じる

サイトマップとインデックス性で確実に拾わせる

どれだけ良いページを作っても、クローラに存在を知られず索引に登録されなければAIの参照対象になりません。ここで役に立つのがサイトマップ（＝サイト内の全URLと更新日をまとめてクローラに渡すXMLファイル）です。特に新規ページや深い階層のページは自然な巡回で見つかりにくいため、サイトマップで明示的に知らせることで発見漏れを減らせるでしょう。

インデックス性（＝ページが索引に登録されうる状態か）も点検が要ります。noindex（＝索引に登録しないようクローラへ指示するタグ）が誤って残っていないか、robots.txtで重要ページの巡回を意図せず塞いでいないか、正規化タグ（canonical＝重複ページの代表URLを示すタグ）が正しい先を指しているかを確認します。これらの設定ミスは「作ったのに一切参照されない」という事態を静かに招く可能性があるため、公開前後の定番チェック項目にしておきたいところです。

図4：発見・許可・重複整理の三層でインデックス漏れを防ぐ。

拡大

図4：発見・許可・重複整理の三層でインデックス漏れを防ぐ。

閉じる

表示速度とレンダリングでAIの取りこぼしを防ぐ

表示速度と描画方式は、クローラがページ内容を最後まで取得できるかに直結します。読み込みが遅い、あるいは重要な本文がJavaScript（＝ブラウザ上で動く処理を記述する言語）実行後にしか現れない構成だと、クローラが本文を取りこぼす恐れがあります。Core Web Vitals（コア・ウェブ・バイタルズ＝Googleが定める表示体感の指標群）を目安に、読み込みや操作応答の遅さを潰しておくことが、人間の使い勝手とAIの読み取りやすさの両方につながります。

描画方式では、本文が最初のHTMLに含まれる形（サーバー側で描画してから返す方式）が読み取り上は安全です。クライアント側でJavaScriptを実行して初めて本文が出る構成に依存すると、レンダリングの成否や重さ次第で本文が拾われない場合があります。重要な本文・見出し・構造化データは、JavaScript実行を待たずに取得できる状態にしておくのが堅実です。

図5：速度と描画方式を整え、本文を確実に読み取らせる手順。

拡大

図5：速度と描画方式を整え、本文を確実に読み取らせる手順。

閉じる

まとめ。繰り返し引用される側に回るには、土台が要る

当ラボの定点観測では、引用先5,783ドメインのうち45.3%にあたる2,619件が、期間中に1回しか引用されていません。一方、12日間の観測で引用され続けた283件は、引用延べ件数の63.8%を占めていました。一度きりで消えた1,871件が占める割合は4.8%です。

図6：クローラが取得したページを解釈し、引用元として選ぶまでの基本ステップ。

拡大

図6：クローラが取得したページを解釈し、引用元として選ぶまでの基本ステップ。

閉じる

繰り返し引用される側に回るには、まず機械が問題なく読み取れる状態にあることが前提になるとみられます。文章の出来を上げる前に、土台のほうで落ちていないかを確かめておくとよいでしょう。