STARTER GUIDEAIO / GEO 基礎企業サイト診断基準

AIO対策 基礎知識ガイド

生成AI検索(ChatGPT Search・Perplexity・Google AI Overviews等)時代に企業サイトが直面する課題を、「4つのLayer(4層構造)」「12のチェック項目」で体系的に整理した基礎マニュアルです。 自社サイトの現状把握やクライアント提案の優先順位付けにご活用ください。

Published by Bennu Inc.読了目安: 約15分

企業サイトに発生する課題の4つのLayer(4層構造)

AI検索に最適化されたWebサイトは、基盤となる「Layer 1(土台)」から「Layer 4(コンテンツ)」まで一貫した構造を持っています。 下のLayerほど根本的な重大欠陥になりやすく、上のLayerほど仕上げの質に関わります。

診断・提案の優先順位:下位の「Layer 1・Layer 2」が崩れていると、上位の「Layer 3・Layer 4」をどれだけ改修してもAIに正しく巡回・理解されません。 まず基盤(Layer 1・2)を固め、その後に表現(Layer 3・4)を整えるのが鉄則です。

第1層(Layer 1):インフラ / 土台

サイト全体の「クロールされ方」「見つけられ方」を左右する、最も基礎的な設定基盤

01

robots.txt

サイト全体に対して、どのクローラー(検索エンジン・AIエージェント)にどこへのアクセスを許可/制限するかを宣言するファイル。 これが無かったり、AI関連クローラーへの設定が不十分だと、AIがサイトのどこを見てよいか分からず、意図しない範囲までクロールされたり、見せたいページさえ見落とされたりします。

robots.txtとは

サイトのルート直下(https://example.com/robots.txt)に置くプレーンテキストのファイル。 User-Agent(クローラーの種類)ごとにAllow / Disallowを記述します。 検索エンジン向けの一般的なクローラーだけでなく、ChatGPT Search(OAI-SearchBot)、GPTBot、ClaudeBot、PerplexityBot、Google-Extendedなど、AI関連の20種類以上のUser-Agentも個別に設定できます。

なぜ重要か

サイト全体の「クロールの入り口」であり、個別ページの最適化以前の最も基礎的な土台です。 ファイル自体が完全に存在しない場合やAIボットを全遮断している場合は、他の指摘とは別格の重大度(CRITICAL)として扱われます。

推奨パターンの記述例
User-agent: *
Disallow:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://example.com/sitemap.xml
全体向けの基本方針に加え、主要なAI関連クローラーごとに個別の意思表示がされており、sitemap.xmlの場所も明示されている状態。
課題パターン(未設置または過剰拒否)
# パターンA: ファイル自体が存在せず404エラー

# パターンB: 知らずにAIを全面拒否
User-agent: *
Disallow: /

# パターンC: AIクローラーの個別意思表示が一切ない
ファイルが無いか、一括拒否になっているため、AIエージェントがサイトコンテンツを参照できず引用対象から除外されます。
02

llms.txt

AIエージェント(ChatGPT、Claude、Perplexity等)に対して、サイトの要約・重要ページ・問い合わせ先などを案内するための新しい仕組みのファイル。 これが無いと、AIはサイト構造を自力で推測しながら巡回するしかありません。

llms.txtとは

/llms.txt という、Markdown形式でサイト概要と重要リンク集を記述したファイル。 robots.txtがアクセス許可/制限のルールであるのに対し、llms.txtは「このサイトはこういう内容で、ここが主要なページです」という要約案内に近いです。

なぜ重要か

AI検索エージェントやAIコーディングツール(Cursor、Claude Code等)への露出を意識するサイトで急速に採用が広がっている新しい規格です。 普及率はまだ低く、対応していること自体が「最新のAI時代に対応している企業」としての証明にもなります。

推奨パターンの記述例 (/llms.txt)
# Example Inc.

> 企業のマーケティングソリューション事業に関する情報を提供する公式サイトです。

## 主要ページ
- [会社概要](https://example.com/about): 設立年・代表者・事業内容
- [サービス一覧](https://example.com/services): 提供サービスの詳細
- [お問い合わせ](https://example.com/contact): 問い合わせ方法

最終更新: 2026-01-01
サイトの要約と主要ページへのリンクがMarkdownで整理されており、AIがサイト構造を一目で正確に把握できます。
課題パターン(未設置)
https://example.com/llms.txt
Status: 404 Not Found

# ファイルが存在しないため、AIは数千〜数万のURLから
# 自力で重要ページを推測・探索する必要がある
AIエージェントに対してサイトの優先度やコンテキストを渡せないため、重要な会社情報や製品情報が見落とされるリスクがあります。
03

canonical(URL正規化)

同じ内容のページが複数のURLで存在する場合に、「正式なURLはこれです」とAIや検索エンジンに明示するタグ。 これが無いと、重複コンテンツとして評価が分散したり、どのURLを正として引用してよいか分からなくなります。

canonicalとは

<link rel="canonical" href="..."> という1行を各ページの <head> 内に書く設定です。

なぜ重要か

トラッキングパラメータ付きURL、http/https両方でアクセスできる状態、www有無の違いなど、「同じページなのに複数のURLが存在する」ケースは非常に多いです。 canonicalが無いと、これらが別々のページとして扱われ、評価も引用も分散します。

推奨パターン
<head>
  <title>会社概要 | Example</title>
  <link rel="canonical" href="https://example.com/about">
</head>
パラメータを含まない、自己参照の正式URLが明確に1つだけ指定されています。
課題パターン(未実装・パラメータ残り)
<head>
  <title>会社概要 | Example</title>
  <!-- canonicalタグが存在しない -->
</head>

<!-- または計測パラメータが付いたまま正規化 -->
<link rel="canonical" href="https://example.com/about?_sp_t=xxxx">
どのURLが正式かAIが判断できない、あるいは計測用パラメータが正規化を阻害している状態です。
関連する派生課題(301リダイレクト)
httpとhttpsの両方でサイトが生きたままになっており、301リダイレクトによる一本化ができていないケースもあります。 この場合はcanonicalタグの記述だけでなく、サーバー側のリダイレクト設定の見直しも必要になります。

第2層(Layer 2):構造化データ / 骨格

ページの意味・階層・事実情報を、機械が直接読み取れる形で明示する骨格

04

見出し構造(H1〜H6)

ページの主題や文章の階層を、H1〜H6タグを使って機械にも分かる形で示すこと。 これが無いと、AIは文章のどこが一番重要な見出しで、どこが本文なのかを推測するしかなくなります。

見出し構造とは

セマンティックHTMLの基本。H1はページ全体の主題、H2以下はセクションごとの見出しという明確な階層構造を表します。

なぜ重要か

見出しタグは「文章構造の目次」です。 CSSで文字を大きくしているだけで見出しタグが無いと、見た目は整っていてもAIにとっては「ただの文字の塊」にしか見えません。

推奨パターン
<h1>会社概要</h1>
<h2>ミッション</h2>
<h2>プロフィール</h2>
  <h3>会社名</h3>
<h2>メンバー紹介</h2>
  <h3>代表取締役</h3>
ページ全体の主題(H1)を頂点に、セクション(H2)、小項目(H3)と整然としたツリー構造になっています。
課題パターン(divタグ代用・階層崩れ)
<!-- パターンA: タグを使わずクラスだけで装飾 -->
<div class="title">会社概要</div>
<div class="text">私たちはつくります。...</div>

<!-- パターンB: 階層が飛んでいる・複数H1 -->
<h1>会社概要</h1>
<h1>メンバー紹介</h1>
<h4>代表取締役</h4>
前者は「見出しの概念が存在しない」状態。後者は1ページに複数H1があり、H2・H3を飛ばしてH4を使うなどルールが破綻しています。
05

JSON-LD(構造化データ)

サイトの情報(会社概要、記事、パンくず、FAQなど)を、人間向けの見た目とは別に、AIや検索エンジンが直接読み取れる「事実データ」として明示する仕組み。 これが不足していると、AIはページの文章から内容を"推測"するしかなく、正確な引用・要約・表示がされにくくなります。

JSON-LDとschema.orgとは

HTMLの <head> 内に <script type="application/ld+json"> というタグで埋め込むデータ形式です。 Google・Microsoft・Yahoo!などが共同策定した世界共通辞書 schema.org に従って記述します。

schema.org の型 (@type)主な用途と効果
Organization会社そのものの情報(名称・設立日・所在地・公式URL・SNS)
WebSiteサイト全体の設定(サイト名・検索ボックス等)
BreadcrumbListサイト内の現在地・階層(パンくずナビゲーション)
Article / TechArticle記事コンテンツ(タイトル・公開日・更新日・著者)
Person人物の実体情報(代表者・著者・専門家プロフィール)
AboutPage / ContactPage / FAQPageそのページ固有の役割・機能宣言

見出しタグ(H1等)との違い

H1やH2などの見出しタグが「見た目の文章に意味のラベルを付ける」ものだとすれば、JSON-LDは「見た目とは別に、事実だけを直接machine(機械)へ渡す」もの。 両方揃って初めて、AIはページを100%正確に理解できます。

提案・実務上の着眼点
ほぼすべてのサイトで何かしらの不足(Organizationの未設置、日付やSNS連携の欠如)が見つかる、最も普遍的な項目です。 診断にかければまず間違いなく具体的な指摘が出るため、改修提案の優先項目として使いやすい特徴があります。
推奨パターン(E-E-A-T補強型)
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://bennuinc.com/#organization",
  "name": "株式会社Bennu",
  "url": "https://bennuinc.com/",
  "logo": "https://bennuinc.com/logo.png",
  "sameAs": [
    "https://twitter.com/bennuinc",
    "https://linkedin.com/company/bennuinc"
  ]
}
会社の実体情報が一意の@id付きで定義され、公式SNSアカウント(sameAs)連携により信頼性が機械的に証明されています。
課題パターン(最小限すぎる記述)
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社Bennu"
}
会社名しかなく、公式URL、ロゴ、所在地、ソーシャルアカウント(sameAs)、@id識別子が欠けており、信頼性の補強になりません。

第3層(Layer 3):メタデータ

ページの「見え方」「伝わり方」に関わる、head内の付帯情報

06

html lang属性

ページ全体が何語で書かれているかを <html> タグに明示する設定。 これが無いと、AIや翻訳エンジン、音声読み上げ機能が言語を正しく判定できません。

html lang属性とは

<html lang="ja"> のように、HTMLの一番外側のタグに1つ書くだけのシンプルな設定です。

なぜ重要か

多言語サイトでは特に重要です。ページごとに言語が切り替わる場合、それぞれのページで正しいlang値(ja, en, zh-Hans, ko等)が必要です。 これが無いと、翻訳や言語別の検索結果表示に悪影響が出ます。

推奨パターン
<!-- 日本語版ページ -->
<html lang="ja">

<!-- 英語版ページ -->
<html lang="en">

<!-- 中国語(簡体字)版ページ -->
<html lang="zh-Hans">
各言語版のページで、実際のコンテンツ言語と一致したlang値が設定されています。
課題パターン(未指定・言語不一致)
<!-- パターンA: lang属性が未指定 -->
<html>

<!-- パターンB: 中国語ページなのに日本語のまま -->
<html lang="ja">
  <body>...(中国語本文)...</body>
</html>
機械翻訳や地域別AI検索で誤判定の原因になります。
07

title / meta description

検索結果やAIの回答に表示される、ページのタイトルと要約文。 これが重複していたり空欄だったりすると、どのページも同じに見えてしまい、AIも人間もページを区別できません。

title / descriptionとは

<title> タグと <meta name="description"> タグ。 検索結果の見出しとその下の説明文にそのまま使われる、最も基本的なSEO・AIO要素です。

なぜ重要か

全ページで同一のタイトルや空のdescriptionだと、AIから見て「このサイトは全ページ同じ内容なのか?」という誤解を招きます。 ページごとの違いと主題を示す最初の手がかりです。

推奨パターン
<title>会社概要 | 株式会社Bennu</title>
<meta name="description" content="株式会社Bennuは2020年設立、東京都渋谷区を拠点に最新のマーケティングソリューションを提供する企業です。">
ページ固有のキーワードを含むタイトルと、内容を具体的に要約した100〜120文字の説明文が設定されています。
課題パターン(同一タイトル・空欄)
<!-- トップページ -->
<title>Bennu</title>

<!-- 会社概要ページ -->
<title>Bennu</title>
<meta name="description" content="">
タイトルに固有性がなく、descriptionが空欄のため、AIや検索エンジンが本文から適当な文字列を切り抜くしかなくなります。
08

E-E-A-T・更新日 / 著者シグナル

そのページ・記事がいつ書かれ、いつ更新され、誰が書いた/監修したのかを示す情報。 これが無いと、AIは情報の鮮度や信頼性を判断する手がかりを持てません。

日付・著者シグナルとは

画面上に表示する <time datetime="2026-01-01"> のようなHTML表記と、 JSON-LD内の datePublished, dateModified, author といったプロパティの両方を指します。

なぜ重要か

特に金融・医療・行政情報などYMYL(お金や安全に関わる)領域で重視されます。 情報がいつのものか機械的に分からないと、AIはその情報を「古い/信頼できない」ものとして扱い、回答での引用を避ける傾向があります。

推奨パターン(HTML+JSON-LD連携)
<p>
  公開日: <time datetime="2026-01-01">2026年1月1日</time>
  更新日: <time datetime="2026-08-21">2026年8月21日</time>
</p>

<!-- JSON-LD内での指定 -->
{
  "@type": "Article",
  "datePublished": "2026-01-01",
  "dateModified": "2026-08-21",
  "author": { "@type": "Person", "name": "髙木 啓太" }
}
画面表示・構造化データの両方で、日付と著者が機械的に読み取れる形になっています。
課題パターン(未記載またはテキストのみ)
<!-- パターンA: 日付記載が一切ない -->
<article>
  <h1>2026年度の運用方針について</h1>
  <p>本文...</p>
</article>

<!-- パターンB: テキストだけでtimeタグやJSON-LDがない -->
<p>2026年1月1日 公開</p>
人間には読めても、機械(クローラー)が確実に「公開日」「更新日」としてパースできません。
09

OGP / Twitter Card

SNSでURLがシェアされた際に表示される、タイトル・説明文・画像を指定するメタタグ。 これが無いと、シェアされてもリンクだけの表示になり、クリックされにくくなります。

OGPとは

<meta property="og:title"><meta name="twitter:card"> など、<head> 内に書く一連のmetaタグです。

なぜ重要か

SNS経由での流入やブランド認知に直結します。 加えて、AIエージェントがページ概要を高速に把握する際の補助シグナルとしても参照されます。

推奨パターンの記述例
<meta property="og:title" content="会社概要 | Example Inc.">
<meta property="og:description" content="Exampleは2020年設立、東京を拠点にマーケティングを提供する会社です。">
<meta property="og:image" content="https://example.com/ogp.jpg">
<meta property="og:site_name" content="Example Inc.">
<meta name="twitter:card" content="summary_large_image">
タイトル・説明・アイキャッチ画像・サイト名・カード種別が一通り揃っています。
課題パターン(未設定・タイトルのみ)
<head>
  <title>会社概要 | Example</title>
  <!-- ogタグ、twitterタグが一切無い -->
</head>

<!-- またはタイトルだけで画像がない -->
<meta property="og:title" content="会社概要 | Example">
シェア時に画像や概要が出ず、テキストリンクだけが表示されるためCTRが大幅に低下します。

第4層(Layer 4):コンテンツの質

書かれている文章・画像そのものの、AIにとっての読み取りやすさ・引用しやすさ

10

Thin Content / 要約文欠如

見出しの直後に、その内容を端的にまとめた文章が無い状態。 AIが検索結果やチャット回答でページ内容を引用・要約する際、拾える文章が無いため、そのページが選ばれにくくなります。

AIOにおけるThin Contentとは

従来のSEOでは「本文の文字数が極端に少ないこと」を指しましたが、AIO文脈では特に、「H2見出しの直後に、AIがそのまま引用できる50〜150字程度の具体的な要約文(アンサー)があるか」 が重視されます。

なぜ重要か

AIは長大な本文を全文推論するよりも、「見出し+その直後の要約文」をセットでスキャンし、回答スニペットとして抽出します。 見出しの直後に要約文が無いと、せっかく良い情報があっても「AIに拾われない」構成になってしまいます。

推奨パターン(結論先出し型)
<h2>営業時間</h2>
<p>
  株式会社Bennuの営業時間は平日9:00〜18:00となっており、
  土日祝日は定休日をいただいております。
</p>
<ul>
  <li>平日 9:00-18:00</li>
  <li>土日祝 休み</li>
</ul>
見出し直後にAIがそのまま引用できる具体的な要約文があり、その後に詳細な箇条書きが続いています。
課題パターン(箇条書きのみ・空虚な導入)
<!-- パターンA: 見出し直後にいきなり箇条書き -->
<h2>営業時間</h2>
<ul>
  <li>平日 9:00-18:00</li>
  <li>土日祝 休み</li>
</ul>

<!-- パターンB: 中身のない空虚な導入 -->
<h2>営業時間</h2>
<p>詳細はこちらをご覧ください。</p>
AIがそのまま引用できる自然言語の要約文がありません。
11

Alt属性(代替テキスト)

画像の内容を説明するテキスト。画像が読み込めない場合や、AI・スクリーンリーダーが画像を認識する際に使われます。 これが無い/曖昧だと、画像に含まれる情報がAIに一切伝わりません。

Alt属性とは

<img src="..." alt="..."> のalt部分。画像そのものが持つ意味や情報を文章で説明します。

なぜ重要か

多くのAI検索クローラーは、ページ巡回時にピクセルデータではなくalt属性のテキストを頼りに画像を理解します。 図解や比較グラフのaltが空欄だと、画像に含まれる貴重な情報が実質「存在しないもの」として扱われます。

推奨パターン(具体的な状況説明)
<img 
  src="/images/building.jpg" 
  alt="株式会社Bennu本社ビルの外観。東京都渋谷区神宮前にあるガラス張りのオフィスビル"
>
<img 
  src="/images/chart.png" 
  alt="2024年から2026年にかけたAI検索利用率の推移を示す棒グラフ"
>
画像を見られない状況やAIクローラーに対しても、何が写っているのかが具体的に伝わります。
課題パターン(未指定・ファイル名・通し番号)
<!-- パターンA: altがそもそも無い -->
<img src="/images/building.jpg">

<!-- パターンB: ファイル名や通し番号だけ -->
<img src="/images/chart.png" alt="image_01">
<img src="/images/office.jpg" alt="オフィス">
画像が何を表現しているかがAIに一切伝わりません。
12

非記述的アンカーテキスト

リンクの文字列が「こちら」「もっと見る」など、リンク先が何なのか分からない表現になっている状態。 これが多いと、AIはどのリンクがどんな情報に繋がっているか区別できません。

アンカーテキストとは

<a> タグで囲まれた、実際にリンクとして画面上に表示される文字列のことです。

なぜ重要か

「もっと見る」「詳細はこちら」という曖昧なリンクが1ページに何十個もあると、AIにとっては「すべて同じラベルの未知のリンク」に見えてしまい、サイト内のトピックマップや親子関係を把握できません。

推奨パターン(リンク先を明記)
<a href="/services/aio-consulting">AIO対策コンサルティングの詳細を見る</a>
<a href="/services/seo-audit">サイト構造診断サービスの事例一覧</a>
<a href="/case-studies/client-a">大手ECサイトにおけるGEO導入事例を読む</a>
リンク先の内容が具体的に分かる名詞・フレーズが含まれており、AIがサイト全体の網羅構造を正確に学習できます。
課題パターン(曖昧な文言の羅列)
<a href="/services/aio-consulting">こちら</a>
<a href="/services/seo-audit">もっと見る</a>
<a href="/case-studies/client-a">詳細はこちら</a>
テキストからリンク先の内容が一切分からず、検索エンジンやAIへのコンテキスト提供になりません。

自社サイトの「4つのLayer」をチェックしませんか?

AIOGeoScanなら、URLを入力するだけで robots.txt、llms.txt、JSON-LD、見出し構造、メタデータなど、 本ガイドに登場した全12項目を数秒で自動スキャン・診断します。

無料でサイトを一括スキャンする
Editorial Trust Signals

このナレッジベースの編集方針

`AIOGeoScan Knowledge` は、Bennu Inc. が運営する AI検索・構造化データ・クローラー制御に関する実務ナレッジです。 Google Search Central、Schema.org、OpenAI などの一次情報を優先し、観測ベースの実務知見は本文中で区別して扱います。

運営主体
Bennu Inc. / AIOGeoScan
更新方針
仕様変更や検索機能の更新にあわせて都度改訂
優先ソース
公式ドキュメント・標準仕様・公式ヘルプ
補助ソース
実装観測・運用知見・再現性のある検証結果

あなたのサイト、AIに正しく伝わっていますか?

解説を読み終えたら、実際にあなたのサイトを診断してみましょう。
100項目以上の診断で、AI時代の構造課題を可視化します。

無料で診断を開始する