SalesDockが自社サイトで実施したLLMO対策と計測方法

LLMO対策の事例には、AIに引用された画面だけを示すものもあります。しかし一度の回答は、質問や検索機能、日時が変われば再現しないことがあります。SalesDockでは、成功例を並べる前に、何を行い、何がまだ分からないかを残しています。

最初に、確認済み・観測中・未検証を分けた

この区分を置かないと、サイトへ実装した事実が、そのままAI回答や商談の成果として報告されてしまいます。

1. クローラー、インデックス、配信を確認した

AI検索の前に、主要ページが正常に配信され、検索エンジンが取得できる状態を確認しました。公開時にはページ、canonical、サイトマップ、noindex、構造化データを読み返します。

robots.txtでは、検索結果の取得に使われるクローラーと、モデル学習に使われるクローラーを同じものとして扱いません。OpenAIの場合はOAI-SearchBotとGPTBotを分けて判断します。

2. 会社・代表・サービス情報の食い違いを減らした

会社名、所在地、代表者、提供サービス、問い合わせ先がページごとに違わないよう、共通データから出す範囲を増やしました。WebSite、Organization、Person、ProfessionalServiceの構造化データも、画面に表示する内容と合わせています。

構造化データを入れればAIに選ばれるわけではありません。読者が見る本文と違う内容をマークアップしないことを優先しています。

3. 一般論より、判断条件と一次情報を記事へ足した

記事の冒頭で結論と適用条件を示し、制度や統計を使う場合は公表元へリンクします。顧客事例は、本人から聞いた内容、自社で試した内容、未検証の仮説、公開許可を得た内容を分けます。

記事を増やす前に、本番記事、未公開の変更、検索結果を照合します。同じ問いへ答えるページがある場合は、新規記事ではなく既存記事の修正や統合を選びます。

4. AI経由の訪問と問い合わせを別々に集計した

GA4では、参照元として判別できたAIサービスからのセッションを集計しています。ただし、Directや参照元不明の訪問をAI流入へ推定配分しません。

検索、AI回答、引用と正確性、訪問、資料請求・問い合わせ、実施済み商談は別の現象です。上流が増えても、下流が同じ割合で増えるとは限りません。

5. 診断結果と改善履歴を分けて管理した

検索意図、競合、記事構成、既存記事の不足を確認する診断結果と、対象記事、確認日、次の作業、次回確認日、公開後の結果を残す改善履歴は分けて管理します。詳しい診断値は元の分析画面で確認し、改善履歴には判断と次の行動だけを残します。

6. 公開後14日・28日の見直しを続けている

公開直後は配信と表示、7日前後はインデックス、14日・28日はGSCとGA4の確定データを確認します。GSCには遅れがあるため、公開翌日に成果を0と判断しません。

変更履歴には、実施日、変更内容、期待する変化、判定日を残します。評価期間中に同じ記事を何度も変更すると、どの修正が関係したか分からなくなるためです。

実施しても、まだ断定できないこと

• llms.txtを置いたことがAI回答への掲載を増やしたかどうか。
• 構造化データの追加が引用を増やしたかどうか。
• 記事の冒頭回答がAI経由の問い合わせを増やしたかどうか。
• 観測したAI経由セッションが個別施策によって増えたかどうか。

これらは、実装済みと成果確認済みを分けて追います。施策を行った時刻、対象ページ、同時に変えた内容が分からなければ、因果を断定しません。

同じ方法を自社へ当てるときの記録項目

1. 顧客が生成AIへ尋ねる質問。
2. 対象AI、検索機能、日時、試行回数。
3. 回答に出た会社名、商品名、競合。
4. 引用・参照されたURL。
5. 会社情報やサービス説明の正誤。
6. 直すページ、担当者、公開日。
7. 同じ条件で測り直す日。

基本から確認したい方は中小企業のLLMO対策、大阪・関西の依頼先を比較したい方はLLMO対策会社を選ぶ7項目へ進んでください。

一次情報・公式情報

• Google Search Central「生成AI機能向け最適化ガイド」
• OpenAI「Publishers and Developers FAQ」
• SalesDockのllms.txt

よくある質問