MEDICALATTRACTCREATIVE QUEST / NAGOYACONTACT ↗
← NEWSROOM

TRANSMISSION RECEIVED

FILE / 2026091918

JavaScriptサイトの
LLMO。
本文・リンク・
描画を揃える
5つの確認

JavaScriptサイトの本文・リンク・メタデータを順番に検証するドット絵エイリアン

React、Next.js、Vueなどで作られたサイトでは、ブラウザにページが表示されていても、最初のHTTP応答には本文が少なく、JavaScript実行後に初めて記事やリンクが現れることがあります。利用者の画面だけを見て「公開できている」と判断すると、クロール時のエラー、描画待ち、リンク未検出、メタ情報の不一致を見落とします。

Googleは生成AI検索機能向けの公式ガイドで、特別なAI専用マークアップではなく、公開ページをクロール可能にし、JavaScript SEOの通常のベストプラクティスに従うよう案内しています。GoogleはJavaScriptを処理できますが、JavaScriptサイトの検索対応は一般的なHTMLサイトより複雑になり得ます。OpenAIも、ChatGPT検索の要約やスニペットにサイト内容を含めたい場合は、OAI-SearchBotをブロックしないよう案内しています。ただし、どの資料も表示、引用、順位を保証していません。

この記事では、2026年9月19日時点のGoogle、Microsoft Bing、OpenAIの公式情報をもとに、JavaScriptサイトのLLMOを、初期応答から描画後HTMLまで5つの確認に整理します。LLMOを個別の裏技として扱わず、読者が取得できるページと、各サービスが検証できるページを同じURLでそろえる実務が中心です。

前提:ブラウザ表示、初期HTML、描画後HTMLを分ける

JavaScriptサイトには少なくとも、サーバーが返す初期HTML、JavaScript実行後のDOM、利用者が操作した後の画面があります。GoogleはJavaScriptページをクロール、レンダリング、インデックスの段階で処理し、初期HTMLに本文がないアプリでは、描画後のHTMLを使って内容やリンクを確認すると説明しています。一方で、Google自身もサーバーサイドレンダリングや事前レンダリングは、利用者とクローラーの双方にとって有効であり、すべてのボットがJavaScriptを実行できるわけではないとしています。

したがって「JavaScriptだから読めない」「最新フレームワークだから読める」と一括りにしません。対象URLごとに、HTTP応答、初期HTML、描画後HTML、操作後コンテンツを分け、重要情報がどの段階で現れるかを確認します。クローラー制御の考え方はAI検索のrobots.txt、AI専用施策へのよくある誤解はLLMOの誤解5つも参考にしてください。

JavaScriptサイトのLLMOを揃える5つの確認

1.重要ページが固有URLと正常なHTTP応答を持つか

記事、サービス、事例、FAQなど、検索やAI検索から到達してほしい内容には、共有・再訪できる固有URLを用意します。画面内タブやモーダルを切り替えるだけでURLが変わらない設計では、個別の内容を直接示しにくくなります。クライアント側ルーティングでは、URL断片だけで本文を切り替えるのではなく、History API等を使い、各画面を通常のURLで取得できるようにします。

URLを開いたときは、存在するページを200、削除済みを404や410、移転を適切な3xxで返します。エラー画面なのに200を返すソフト404や、ログインしていないと本文が取得できない状態を避けます。Googleは200のページを描画キューへ送り、非200では描画を省く場合があると説明しています。ステータスコードと画面内容をセットで検証します。

2.本文と内部リンクが、操作なしで取得できるか

Googleの公式資料では、通常クロールできるリンクは、URLを持つ<a href="...">です。クリックイベントだけを付けた要素、hrefのないアンカー、スクリプト文字列だけのURLは、安定した発見経路になりません。重要ページは、一覧、カテゴリ、関連記事、本文中の文脈から通常のリンクでたどれるようにします。

本文、FAQ、出典、CTAを「クリックして展開した後だけ」「スクロール後だけ」読み込む実装にも注意が必要です。Googleは遅延読み込みについて、スクロールやクリックなど利用者の操作に依存せず、表示領域に入れば読み込める仕組みを案内しています。折りたたみUIを使う場合も、初期取得または描画処理で内容がDOMへ現れるかを確認します。

3.title・description・canonical・robotsが前後で矛盾しないか

ページごとに固有で説明的なtitleとmeta descriptionを設定し、本文の主題と一致させます。JavaScriptで変更する場合は、初期HTMLと描画後HTMLで別の記事名や古い説明文が混ざらないかを確認します。SNS用のOpen Graph情報も、記事タイトル、説明、画像、URLと同じ公開単位に合わせます。

canonicalは同一・類似ページの代表URLを示す手掛かりです。Googleは、初期HTMLにcanonicalがある場合、JavaScriptで別URLへ変更しないよう案内しています。robots metaも、初期HTMLにnoindexを入れてからJavaScriptで外す方法は、描画前に処理が止まる可能性があります。canonical、sitemap、内部リンク、リダイレクトが別々のURLを示していないかを確認します。

4.主本文と画像が、描画失敗時にも判断できるか

重要な説明を画像、動画、canvasだけに閉じ込めず、見出しと本文をテキストで用意します。画像には内容に合うaltを設定し、記事画像のURLも取得可能にします。APIエラーやJavaScript例外が起きたとき、空の枠や読み込み表示だけが残らず、最低限のタイトル、要約、本文、問い合わせ導線を返せる構成かを確認します。

サーバーサイドレンダリングや事前レンダリングは必須ではありませんが、主要本文を初期応答へ含めると、描画に依存する工程を減らせます。クライアント側で取得する場合はHTTPで内容を取得できるフォールバック、タイムアウト時の表示、API失敗時の状態を用意します。速度改善のための遅延読込と、主本文を取得不能にする遅延読込を分けます。

5.構造化データを可視本文と一致させ、実際の取得結果で検証する

JSON-LDなどの構造化データは、ページ内容を理解する手掛かりになりますが、LLMOや引用を保証する装置ではありません。Googleは、構造化データが表示中の主内容を正しく表し、隠れた情報や誤解を招く情報をマークアップしないよう求めています。著者、公開日、更新日、画像、組織情報を入れる場合は、画面に見える情報と一致させます。

実装後はソースコードだけでなく、Google Search ConsoleのURL検査やリッチリザルトテストで、読み込まれたリソース、JavaScriptエラー、描画後HTMLを確認します。Bing Webmaster ToolsのURL Inspectionは、インデックス、SEO、マークアップ、HTTP応答を確認でき、Live URLではBingbotが取得する内容を検証できます。テストに合格しても掲載や引用は保証されないため、検証結果と実際の表示・流入は分けて記録します。

公開前後の検証を、同じURLで順番に行う

  1. ブラウザでURLを直接開き、タイトル、本文、画像、リンク、CTA、PC・スマホ表示を確認する
  2. HTTPステータス、初期HTMLのtitle、description、canonical、robots、主本文の有無を確認する
  3. JavaScript実行後のDOMで、見出し、本文、内部リンク、構造化データが欠けていないか確認する
  4. JavaScriptを待たずに取得する環境と、描画する環境の差分を記録する
  5. Google Search ConsoleとBing Webmaster Toolsで、公開URLの取得・描画・マークアップを検証する
  6. robots.txt、CDN、WAF、bot対策がGooglebot、Bingbot、必要なAI検索クローラーを意図せず拒否していないか確認する
  7. 公開後はサーバーログ、インデックス状況、参照元、問い合わせを分けて計測する

OpenAIは、ChatGPT検索向けのOAI-SearchBotがrobots.txtで拒否されているとクロールが止まると案内しています。ただし、アクセスを許可すれば必ず要約や引用へ掲載されるという意味ではありません。サービスごとの制御目的を整理し、既存のセキュリティ方針と合わせて判断します。

よくある質問

JavaScriptを使わないサイトへ作り直す必要がありますか?

一律に作り直す必要はありません。GoogleはJavaScriptを処理できます。重要なのは、URL、HTTP応答、本文、リンク、メタ情報が取得・描画できるかを実際のURLで確認することです。サーバーサイドレンダリングや事前レンダリングは、利用者と複数のクローラーに対して取得の確実性を高める選択肢です。

構造化データを増やせば、AI検索に引用されやすくなりますか?

引用増加は保証できません。構造化データは可視本文と一致する必要があり、正しく実装しても検索結果での特別表示は保証されません。まず本文、固有URL、クロール可能なリンク、更新情報、出典を整え、対応する構造化データだけを追加します。出典と更新体制はLLMOの情報更新設計で整理しています。

ブラウザで表示できれば、検証は終わりですか?

終わりではありません。ブラウザ表示に加えて、初期HTML、描画後HTML、HTTP応答、bot向けアクセス制御を確認します。さらに、Search ConsoleやBing Webmaster Toolsの取得結果と、公開後のログ・流入を確認します。AI検索の計測方法はLLMOの効果測定も参考にしてください。

まとめ:LLMOは画面の見た目と取得できる情報を揃える

JavaScriptサイトのLLMOは、特別なファイルやAI向けの文章だけで完了しません。重要ページへ固有URLを付け、正常なHTTP応答を返し、本文と内部リンクを操作なしで取得可能にし、title・description・canonical・robotsを一致させ、可視本文と構造化データをそろえます。最後に、初期HTMLと描画後HTMLの両方を実際の検査ツールで確認します。

自社サイトの取得・描画差分を、公開URLで整理したい方へ

株式会社メディカルアトラクトでは、企業・医療機関のWebサイトについて、重要URLの選定、初期HTMLと描画後HTMLの差分、内部リンク、メタ情報、構造化データ、クローラー制御、計測項目を一つの確認表へ整理します。お問い合わせページから、対象サイトのURL、利用中のCMSやフレームワーク、検索・AI検索で確認したいページをお聞かせください。初回の相談では、内容改善と技術実装を分け、社内・制作会社・開発会社のどこで確認するか、優先順位を具体化できます。LLMO支援の考え方はLLMOサービスページ、対応範囲はサービスページ、制作・運用例は制作実績ページで確認できます。

本記事は株式会社メディカルアトラクト編集部(LLMO・Web技術担当)が、Google、Microsoft Bing、OpenAIの公表資料を2026年9月19日に確認して作成しました。

参考にした一次情報

本記事は2026年9月19日時点の公表資料に基づき、一般的なWeb制作・検索運用の確認方法を説明したものです。検索順位、インデックス、AI検索での表示・要約・引用、流入、問い合わせを保証するものではありません。クローラー、検索機能、検査ツール、対応する構造化データは変更される場合があるため、実装時は各サービスの最新版をご確認ください。本記事はGoogle、Microsoft、OpenAIの提携・監修を受けたものではありません。