スワイプLPはLLMOに不利?AIに読まれない3つの理由と、CVRを落とさずに対応する方法

スワイプLP（スワイプ型LP）は、LLMO、ChatGPT・Gemini・Google AI OverviewなどのAI検索で引用・推薦されるための最適化において構造的に不利です。

理由は明確で、①コンテンツが画像として書き出される、②スワイプUIがJavaScript必須でAIクローラーに読めない、③1画面1メッセージ設計でテキスト情報量が少ない、の3点です。

ただし、結論を先に言えば、LLMOのためにスワイプLPをやめる必要はありません。

スワイプLPは広告流入のCVRを最大化する装置として維持し、AIが読むための受け皿を別に用意し、LP自体も静的テキスト化で底上げする。

この役割分担が正解です。株式会社Iteraの1,459クエリ調査（AI Overview出現率78.2%・ゼロクリック率60.3%）を踏まえ、経営者・マーケターが取るべき対応を解説します。

なぜスワイプLPはAIに読まれないのか?【3つの技術的理由】

AIから見たスワイプLPは、多くの場合「ほぼ空白のページ」です。人間に効く設計と、AIが読める設計が正反対だからです。

スワイプLPは、1画面1メッセージをスワイプ操作で読み進めるLP形式です。広告からの遷移で違和感がなく、読み飛ばしを防ぎ、CVRを高めやすい。スマホ広告時代の合理的な発明です。

しかしその強みを生む実装が、そのままAIへの弱点になります。

理由①：コンテンツが「画像」で書き出されている

多くのスワイプLPは、デザイン再現性を優先して各スライドを1枚の画像として実装します。人間には美しいコピーでも、HTMLソースにはimgタグが並ぶだけで、テキストが存在しません。

AIはHTMLのテキストを読んで情報を理解するため、画像の中の訴求・価格・実績は、AIにとって存在しないのと同じです。

理由②：スワイプUIがJavaScript必須で、AIクローラーは実行しない

スワイプの挙動はJavaScriptで実装されます。ここに重大な問題があります。

GPTBot（ChatGPT）やPerplexityのクローラーなど、主要なAIクローラーの多くはJavaScriptを実行せず、静的なHTMLだけを取得します。

Googleは検索インデックスのためにレンダリングを行いますが、LLM系のクローラーに同じ前提は置けません。JS実行後に初めてスライドの中身が描画される実装では、AIが受け取るのは中身のない骨組みだけです。

理由③：1画面1メッセージ設計で、そもそも情報量が薄い

スワイプLPの原則は「1スライド1メッセージ」。キャッチコピー中心で詳細説明を削ぎ落とすことがCVRの秘訣です。

しかしAIの推薦は、スペック・価格・対象・根拠といった「照合できる情報」の量と質で決まります。人間の意思決定を後押しする削ぎ落としが、AIの照合材料の欠乏になります。

加えて運用面でも、広告用LPはnoindex設定やパラメータ付きURLで運用されることが多く、そもそもAIの参照経路から外れているケースが少なくありません。

LLMOのためにスワイプLPをやめるべきか?

やめるべきではありません。LPの仕事はCVR、LLMOの仕事は別の場所で。「1つのページに両方やらせない」が設計の大原則です。

ここで判断を誤る企業が出ます。「AIに読まれないならスワイプLPをやめて、テキストだらけのページに戻そう」。

これは広告のCVRという確実な成果を、不確実な期待と引き換えに捨てる判断です。

整理すべきは、ページの役割です。

• スワイプLP:広告をクリックした「今すぐ客」を、最短でCVに導く装置。評価指標はCVR

• LLMOの受け皿:AIと、AIに相談する「検討客」が読む情報源。評価指標はAIでの言及・引用

当社の1,459クエリ×30ジャンル調査では、AI Overview出現率は78.2%、ゼロクリック率は60.3%。広告をクリックする前の段階で、消費者の過半はAI回答の閲覧やAIとの対話で製品理解と比較を済ませつつあります。

つまり、スワイプLPが受け持つ「クリック後」の手前、「クリック前」の認知と比較がAIに移っており、ここを取りにいくのはLPの仕事ではなく、ブランドサイトと情報コンテンツの仕事です。

役割分担の結論はこうなります。スワイプLPはCVR装置として磨き続ける。

AIに読ませる情報は、クロール可能な受け皿ページに置く。そしてスワイプLP自体にも、CVRを損なわない範囲の技術的底上げを施す。以下、後者2つを具体化します。

対応①:スワイプLP自体を「CVRを落とさずに」AI可読にする

見た目を変えずにできる技術改善が4つあります。実装は制作会社への指示書レベルで完結します。

1. スライドの文言を「実テキスト」でDOMに含める

スライドを画像で書き出す場合も、同じ内容のテキストをHTML内に持たせます。

方法は2つあり、

(a)画像をやめてHTML+CSSでデザインを再現する

(b)画像は残しつつ、全スライドの文言を静的HTMLとしてソースに含める(適切なマークアップで検索エンジン・AIに読める形にする)。

少なくともalt属性に各スライドの要点を記述することは最低ラインです。

2. JSなしでも中身が見える「静的HTML」を出力する

スワイプの動きはJSのままで構いません。重要なのは、JSが実行されなくても全スライドのコンテンツがHTMLソースに存在することです。

SSR(サーバーサイドレンダリング)や静的生成に対応したLPツールを選ぶ、または書き出し設定を見直すことで対応できます。

確認方法は簡単で、ページのソースを表示し、スライドの文言が検索できるかを見るだけです。

3. JSON-LDの構造化データを実装する

Product(商品名・価格)・Offer・FAQPage・Organizationの構造化データは、JSON-LDとして静的にheadへ記述できるため、スワイプUIと干渉しません。

画像主体のLPでも、構造化データだけはAIに確実に情報を渡せる伝達経路になります。

4. LP下部に「詳細情報セクション」を通常HTMLで追加する

最終スライドの下に、商品詳細・スペック・FAQ・会社情報を通常のテキストHTMLで置きます。

スワイプ体験を終えたユーザーの後押しにもなり、AIには照合材料になります。CVRへの影響が心配なら、ファーストビューから見えない位置に置けば体験は変わりません。

対応②:AIが読む「受け皿」をドメイン全体で設計する

AIはLP単体ではなく、ブランドに関するWeb全体の情報から回答を作ります。LPの外に、引用される情報資産を積みます。

やるべきことは3つです。

第一に、ブランド・商品の公式情報ページです。広告用LPとは別に、商品の正式名称・スペック・価格・比較情報・開発背景を網羅した、クロール可能な公式ページをサイトに置きます。AIが「この商品は何か」を答えるときの一次情報の置き場です。

第二に、検討段階の質問に答えるコンテンツです。「〇〇(カテゴリ) 選び方」「△△と□□の違い」といった、広告クリック前のユーザーがAIに聞く質問への回答記事を用意します。ここで引用されるブランドが、スワイプLPに流入する前の候補形成で優位に立ちます。

第三に、第三者の言及とレビューです。AIは自社発信だけでなく、レビュー・メディア掲載・SNSでの言及を信頼材料にします。広告出稿と並行して、引用される外部実績を計画的に作ることが、LP流入の質も引き上げます。

イメージとしては、D2Cのサプリメントブランドなら次の構成です。広告→スワイプLP(CVR装置)という既存動線はそのまま。並行して公式サイトに、成分・含有量・製造工場・比較表を載せた商品公式ページ、「〇〇成分の選び方」の解説記事、レビューまとめを整備する。

AIが「〇〇 サプリ おすすめ」に答えるとき読むのは後者であり、そこで言及されたブランドの指名流入がスワイプLPのCVRをさらに押し上げる広告とLLMOが競合せず補完する設計です。

縦長LPとスワイプLP、LLMO観点ではどちらを選ぶべきか?

縦長LPが自動的に有利なわけではありません。判断基準は形式ではなく「静的テキストの有無」です。

「スワイプLPが不利なら縦長LPに戻すべきか」という質問には、前提の修正が必要です。

縦長LPでも、全面画像で書き出された実装ならAIには同じく空白です。逆にスワイプLPでも、静的HTMLにテキストを持つ実装なら読まれます。

形式の選択はCVR・商材・流入経路で決めるべきで、LLMOは実装品質で決まる。この切り分けが正確な理解です。

そのうえで傾向を言えば、縦長LPはテキスト量を確保しやすく、既存実装でもHTMLテキストで組まれていることが多いため、平均的にはAI可読性が高くなります。

新規制作時は、どちらの形式でも「静的HTML出力・構造化データ・詳細情報セクション」を要件定義に含めることを推奨します。

この3点を制作会社への発注要件に入れるだけで、形式を問わずLLMOの土台が確保できます。

対応③:自社ブランドがAIにどう語られているか計測する

LP中心のビジネスほど、AI上の情報は空白か誤情報になりがちです。まず現在地の計測から始めてください。

スワイプLPと広告で成長してきた商材は、Web上のテキスト情報が薄いため、AIが回答を作れない、あるいは古い情報や第三者の不正確な情報で回答する状態に陥りやすい構造です。

ブランド名・商品名でAIに質問したとき何が返るか、カテゴリの推薦クエリで自社と競合がどう言及されるかを、定点観測してください。

追うべき指標は3つです。

1. 指名クエリでの回答の正確性(誤情報の有無)

2. カテゴリクエリでの言及・推薦率と競合比較

3. 指名検索数とAI経由流入のCVR。

当社観測では、施策の改善傾向の確認に約3か月、投資判断には約6か月が目安です。手動確認は再現性に欠けるため、複数のAIエンジンを横断して自動計測するツールの利用が現実的です。

よくある質問(FAQ)

Q1. スワイプLPは本当にAIに読まれないのですか?

実装によります。スライドが画像書き出しで、JS実行後にのみ中身が描画され、静的HTMLにテキストがない実装なら、主要なAIクローラーからはほぼ空白に見えます。逆に、静的HTMLに全スライドの文言と構造化データを持つ実装なら読まれます。まずページのソース表示で、スライドの文言がテキストとして存在するかを確認してください。

Q2. LLMOのためにスワイプLPをやめるべきですか?

不要です。スワイプLPは広告流入のCVR装置として維持し、AIに読ませる情報は受け皿ページと公式サイトに置く役割分担が合理的です。CVRという確実な成果を捨てる必要はありません。やるべきは、LP自体の静的テキスト化・構造化データという「CVRを落とさない底上げ」です。

Q3. 広告用のLPにもLLMO対策は必要ですか?

LP単体の露出獲得は目的にしなくて構いません。ただし、LPしか情報がないブランドはAI上で情報空白・誤情報になりやすく、指名検索時の回答品質(ブランド保護)に影響します。最低限、構造化データと詳細情報セクション、そして公式サイト側の情報整備は必要です。

Q4. 画像主体のLPをAIに読ませる最短の方法は?

優先順位は、①全スライド文言の静的HTML化(またはalt記述)、②JSON-LD構造化データの実装、③LP下部の詳細情報セクション追加、の順です。いずれもデザインとスワイプ体験を変えずに実装でき、制作会社への指示で完結します。

Q5. 何から始めればいいですか?

2つの確認からです。①自社LPのソースを表示し、スライド文言がテキストで存在するか確認する。②ChatGPTやGeminiに自社ブランド名・商品名を質問し、回答の有無と正確性を確認する。この2つで、実装の問題と情報空白の問題のどちらが大きいかがわかり、打ち手の優先順位が決まります。

まとめ:LPはCVRのために。LLMOは受け皿と計測で

AI Overview出現率78.2%、ゼロクリック率60.3%。広告クリックの手前にある認知と比較の工程は、AIとの対話へ移りつつあります。

スワイプLPの価値、クリック後のCVR最大化は変わりませんが、その手前でAIに語られないブランドは、LPに流入する母数そのものを失っていきます。

対応の設計はシンプルです。スワイプLPは磨き続ける。静的テキストと構造化データで底上げする。AIが読む受け皿をドメイン全体で用意する。そして、自社がAIにどう語られているかを計測する。

順序を間違えないでください。施策の前に、まず現状把握。ブランド名とカテゴリの主要クエリで、AIが何を答えているか。

LLMOチェキ(itera-llmo.com)では、複数のAIエンジンでの自社の言及・引用状況を自動で定点観測できます。まずは現在地の計測から始めてみてください。