JavaScript なしでも読めるコンテンツ

ページの主なコンテンツ — 訪問者が求めている段落、見出し、表、価格など — は、最初のリクエストでサーバーが返す HTML に含まれていなければなりません。拡張としてのは問題ありません。JavaScript 実行後にのみ表示されるコンテンツは、ほとんどの AI クローラーには見えず、したがってそれらを情報源とするアシスタントにも見えません。

本ページでは仮に、Fernwood がマーケティングサイトをシングルページアプリとして作り直したとします。ブラウザ上では見た目は完成しています。ページのソースを表示すると、ほぼ空の <div id=\"root\"></div> が見えるだけ。GPTBot、ClaudeBot、PerplexityBot などのクローラーが受け取るのは、その空の殻です。

なぜこれが効くのか

従来の検索エンジンはこの問題をかなり解決しています。つまり、Google はインデックス前に JavaScript をレンダリングします。しかし、アンサーエンジンはそうではありません。ChatGPT、Claude、Perplexity などに供給するクローラーは、通常は生の HTML レスポンスを取得した時点で処理を止めます — フレームワークのハイドレーションを待たず、バンドルを実行せず、クライアントサイドのルーティングも追いません。Silktide のクロール比較（レンダリング後のページと生の HTML の比較）もまさにこの挙動を前提にしています。詳しくはJavaScript なしのコンテンツを参照してください。

失敗は静かに、しかも全面的に起こります:

Google で上位表示されるページでも、AI の回答からは完全に消えてしまうことがあります。アシスタントが本文を一度も受け取っていないからです。
そのページに投資した他の AEO 施策 — 構造化データ、機械可読な日付、答え優先の書き方 — も、クローラーがそれらのシグナルが指し示す本文を見られなければ無意味です。
スクリプトが失敗またはブロックされた人間の訪問者にも同じ空の殻が見えますし、最終的にスクリプトが成功する場合でも First Contentful Paint は悪化します。

これはページ単位の編集ではなく、サイトのアーキテクチャの問題です。1 つの URL を手作業で直しても、その後に量産されるテンプレートは直りません。

クローラーが何を見ているかの確認方法

何かを変える前に、まず問題を確認しましょう。強力な順に 3 つの方法があります:

Silktide のチェック。 JavaScript なしのコンテンツは、レンダリング後のページの意味のある本文と、クロール時に取得した生の HTML を比較します。生の本文がレンダリング後の本文の約 10% 未満かつ絶対量としてもごく少ないページを警告します — 単なる強化ではなく、本物の空の殻です。
DevTools の Elements ではなく、ページのソースを表示。 ブラウザの「ページのソースを表示」はサーバーが送ったものをそのまま示します。Elements パネルは JavaScript 実行後の DOM を示します。記事本文が Elements にはあるのにソースにはない場合、JS を実行しないクローラーには見えません。
ブラウザを使わずに取得。 ターミナルから: curl -sL https:\/\/fernwood.example\/pricing | head。あるいはテキストブラウザを使います。その出力に料金表がなければ、クローラーにもありません。

そもそもクローラーがアクセスできるかも確認してください。完璧な HTML レスポンスでも、robots.txt で AI クローラーをブロックしていたり、実務上ファイアウォールで遮断している（実務上ブロックされている AI クローラー）なら無意味です。

解決方法

スタックに合った方法を選んでください。どれも目的は同じです。最初の HTML レスポンスに本文を含めることです。

1. サーバーサイドレンダリング（SSR）

サーバーがリクエストごとにページを HTML へレンダリングし、その後 JavaScript がインタラクティブ性のためにハイドレーションします。対応しているフレームワークではこれが標準的な道筋です:

Next.js - Server Components を使った App Router、または Pages Router の getServerSideProps／getStaticProps を利用します。マウント後に内容を取得するクライアント専用ルートを出荷しないでください。
Nuxt - （デフォルトの）ユニバーサル／SSR モードで、ssr: false にしない。
Remix、SvelteKit、Astro（SSR モード）など - 同じ発想です。ドキュメントのレスポンスに本文を含めます。

目安: useEffect／onMounted のフェッチが記事をページに載せているなら、そのデータ取得をサーバー側へ移しましょう。

2. 静的サイト生成（SSG）

公開時にプレーンな HTML としてページを事前生成します。訪問者ごとに変わらないコンテンツ（ブログ、ドキュメント、マーケページ、料金）に最適です。Astro、Eleventy、Hugo、Next.js の output: 'export'、Nuxt の generate は、クローラーが JavaScript なしで読めるファイルを生成します。

マーケ／コンテンツ系サイトでは、SSG が最も手軽で効果的なことが多いです。リクエストごとの描画コストがなく、ディスク上の HTML がそのままクローラーの取得物になります。

3. つなぎとしてのプリレンダリング

まだフレームワークを変えられない場合、プリレンダリングサービスやビルド工程でのスナップショット生成により、クローラー（しばしば初回訪問者にも）へレンダリング済みの HTML を提供しつつ、インタラクティブなセッションでは SPA を動かし続けられます。これは最終到達点ではなく“つなぎ”として扱ってください。スナップショットの鮮度、キャッシュ無効化、認証付きルートなどが保守負担になります。可能になり次第、描画方式そのものを直すことを優先しましょう。

Google 自身の JavaScript SEO に関するガイダンスや web.dev の Rendering on the Web も、SSR、SSG、プログレッシブエンハンスメントという同じ選択肢を、検索エンジン側の観点から説明しています。

最初の HTML に必ず含めるもの

すべてを含める必要はありません。引用に使われる本文を含めます:

記事／ページ本文 — 見出し、段落、リスト、表。
価格、制限、その他の事実 — アシスタントに繰り返してほしい情報。
構造化データ — 初期 HTML の <script type=\"application\/ld+json\"> ブロックで提供します。ハイドレーション後にだけ注入される JSON-LD は本文と同様に見えません。
カノニカル URL、タイトル、メタディスクリプション — <head> に。

JavaScript が担当してよいものは、メニュー、パーソナライゼーション、既存の表を強化するチャート、段階的な機能などです。Silktide のチェックは拡張に対して意図的に寛容です。本文を HTML で提供し、その上に振る舞いを重ねるページは合格します。

よくある失敗パターン

クライアント専用の SPA — Create React App、Vite の SPA など、空の殻を配信し、ルートをブラウザで取得する構成。解決策は SSR／SSG であって、クライアントコードの追加ではありません。
「Load more」やタブの背後にあり、HTML に現れないコンテンツ。 セクション 3 に到達する唯一の方法が、クリックしてフェッチすることであれば、クローラーは決してセクション 3 に到達しません。実在する URL を用意するか、最初のレスポンスにその内容を含めましょう。
「Google で動くから大丈夫」。 Googlebot のレンダリングは、AI クローラーへの可読性の代替にはなりません。Google では通り、GPTBot では失敗するという見えない分断はよくあります。
クローラーをブロックしておきながら、原因を JavaScript に求める。 このテクニックと併せて、必ず AI クローラーのアクセスと実効的な到達性を確認してください。

Silktide が支援できること

JavaScript なしのコンテンツは、レンダリング後のページに比べて生の HTML が空の殻になっているインデックス可能ページを検出します。
AI クローラーのアクセスと実務上ブロックされている AI クローラーは、関連する失敗 — クローラーが HTML をまったく受け取れない — を扱います。

Silktide が JavaScript なしであなたのコンテンツを読めないなら、あなたに引用してほしいアシスタントも読めません。