JavaScript SEO監査：検索エンジンがクロール、レンダリング、インデックスできるものを確認する

JavaScript アプリケーションは 200 OK を返し、訪問者に完全なページを描画し、同時に検索エンジンに空のシェル、不適切なカノニカル、または追跡できないリンクを残すことがあります。 失敗は見逃しやすいです。なぜならブラウザテストは別の質問に答えるからです：モダンクライアントがアプリケーションを実行できるか？ JavaScript SEO監査は、検索処理の各段階で何が残るかを尋ねます。

Google はシーケンスを クロール、レンダリング、インデックス として文書化します。 各段階は異なる入力と異なる失敗モードを持ちます。 それらを 1 一般的な「インデックス問題」として扱うと診断が遅くなります。

DevTools を開く前に応答から開始します

初期の HTTP 応答はページのステータス、ヘッダー、ソースドキュメントを確立します。 レンダリングされた DOM を評価する前に記録します。

各代表的なテンプレートについて、次をキャプチャします：

• リダイレクト後の最終 URL
• HTTP ステータス
• robots.txt 許可
• ヘッダー、X-Robots-Tag を含む
• ソース HTML タイトル、カノニカル、robots メタ、見出し、本文コピー、リンク
• メインコンテンツをレンダリングするために必要なスクリプトとスタイルシートのURL

この最初のキャプチャは、JavaScript が信頼できる方法で修復できない失敗を特定します。 エラー状態を返すルートは、クライアントコードが親しみやすいページを描画するため、健全とはみなされません。 クロール層でブロックされたページは、優れたレンダリングを通じてインデックス可能になることはありません。 noindex ディレクティブを含むサーバー応答は、明示的なインデックス指示を作成します。

サーバーサイドレンダリングまたはプリレンダリングは、ユーザーとクローラーに即座に意味のある HTML を提供するため、強力なベースラインになることが多いです。 Google は JavaScript を実行できますが、そのドキュメントは依然としてサーバーサイドまたはプリレンダリングのアプローチを推奨しています。これらはユーザーとクローラーの速度を向上させるためです。 目標は特定のフレームワークではありません。 目標は、クライアント拡張前に有用で真実の応答です。

ソース HTML とレンダリングされたドキュメントを比較する

最も情報量の多い JavaScript SEO テストは、2 つの状態間の構造化差分です：サーバーが返したものとレンダリング後に存在するもの。

レンダリング状態が追加、削除、変更しているか確認する：

• 主見出しと主要な説明テキスト
• 製品名、価格、在庫状況、または記事内容
• Canonical と robots ディレクティブ
• 構造化データ
• 内部リンク
• 画像の alt テキストとキャプション
• ページネーションとファセット付きナビゲーションリンク

すべての差異が欠陥ではありません。 インタラクティブコントロール、パーソナライズドウィジェット、クライアントサイドの拡張は、レンダリング状態に属します。 監査は、インデックス可能な意味や発見が変わる差異をフラグ付けすべきです。

有用な証拠記録は具体的です：「初期応答にはタイトルとナビゲーションが含まれますが、記事本文はありません；本文は /api/content/123 へのクライアントリクエスト後に表示されます；そのリクエストはクリーンなクローラセッションに 401 を返します。」これにより、開発者は再現可能な境界を得られます。 「JavaScript コンテンツはインデックスしにくいかもしれません」はそうではありません。

リンクをリンクとして確認し、クリックハンドラではないことを確認する

検索発見はクロール可能なURLに依存します。 Google は解決可能な href 値を持つ標準アンカー要素を推奨します。 onclick ハンドラを備えたスタイル付き要素は、ユーザーにとってはナビゲーションのように振る舞いますが、文書内には発見可能な目的地を公開しません。

サイト全体のナビゲーション、記事カード、ページネーション、フィルター、パンくずリスト、および関連コンテンツモジュールを監査します。 重要な目的地がアンカーで表現されていること、および href が事前のアプリケーション状態なしで機能することを確認します。

シングルページアプリケーションの場合、ルート変更には History API を使用し、意味のあるすべてのビューに安定した URL があることを確認します。ハッシュフラグメントは文書内の位置に適していますが、インデックス可能なルートの代替としては不適切です。

これは内部リンク品質の問題でもあります。 説明的なアンカーテキストは目的地の文脈を提供します。 AI-search audit plan、systematic audit method、およびこのレンダリング診断を接続するクラスターは、3つの孤立したページよりもナビゲートしやすく解釈しやすいです。

視覚デザインに頼らずにエラー状態をテストします

JavaScript アプリケーションは頻繁にソフト 404 を生成します：サーバーは 200 を返し、レンダリングされたページはリソースが存在しないと表示します。 視覚的な結果は正しく見えますが、プロトコルはまだ有効なページを記述しています。

Google の JavaScript SEO ドキュメントは、可能な場合は実際の 404 ステータスを返すことを推奨しています。 クライアントルーティングがサーバーステータスを変更できない場合、慎重に適用された noindex はエラー表示がインデックスに入るのを防げますが、それは包括的な回避策ではなく、意図的なアーキテクチャ上の決定であるべきです。

少なくとも次の状態をテストします：

1。有効なルート 2。存在しないルート 3。削除されたリソース 4。認証が必要なリソース 5. API タイムアウトまたはコンテンツリクエスト失敗 6。無効なパラメータを持つルート

HTTP ステータスとレンダリングされた指示の両方を記録します。 間違ったステータスで正しいエラーメッセージは、依然として監査の発見です。

レンダリング全体でカノニカルと robots の安定性を確認します

ロード後に変更されるメタデータは矛盾する証拠を生む可能性があります。 レンダリングされたDOMと利用可能な場合はGoogleの検査結果に、canonicalとrobotsの値を取得します。

canonicalは現在のコンテンツの優先バージョンを識別する必要があります。 一般的なアプリケーションシェルを簡潔に指摘し、クライアントリクエスト後に変更しないでください。 クライアントナビゲーション中に前のルートのURLを継承しないでください。 ローカライズされたルートは、意図した言語バージョンを消去するcanonicalに縮小されないようにしてください。

Robotsの取り扱いも同様に注意が必要です。 Googleは、初期のnoindexを除去するためにJavaScriptに依存することを警告します：指令が観測された場合、レンダリングがスキップされる可能性があります。 レスポンス契約にインデックス可能性を組み込み、クライアントコードがそれを逆にすることを期待しないでください。

ブロックされたリソースを観測可能な依存失敗として扱う

重要なJavaScriptまたはAPIリソースがブロックされた場合、Googleは通常の匿名訪問者が見るものをレンダリングできません。 robots.txtルール、CDN動作、ボット保護、クッキーブリッジ、認証、およびプライマリコンテンツを構築するリソースのリクエストヘッダーを監査する。

これはプライベートAPIを公開する許可ではありません。 パブリックインデックス可能ページは、パブリックレンダリングパスを通じてパブリックコンテンツを生成できる必要があります。 ページが保護されたリクエストに依存している場合、アーキテクチャはインデックス可能コンテンツをプライベート境界の背後に配置しています。

失敗したリソース、レスポンスコード、イニシエーター、および可視結果を記録する。 テンプレート到達度で優先順位を付ける。 5,000ページで共有される1つの失敗したコンテンツエンドポイントは、1記事で装飾ウィジェットが失敗するよりも重要です。

フィールドパフォーマンスとレンダリング完了度を分離する

レンダリングとパフォーマンスは相互作用するが、同一ではありません。ページはすべてのコンテンツを遅くレンダリングするか、重要なコンテンツを省略して高速にレンダリングすることができます。 両方を監査する。

フィールドデータを使用して実際のユーザーのCore Web Vitalsを評価する。 ソース/レンダリング比較を使用して検索完了度を評価する。 大規模なクライアントバンドルはインタラクションレイテンシを悪化させ、コンテンツを遅延させる可能性があります。証拠は両方の結果を示し、一般的なパフォーマンススコアに圧縮しないでください。

このチャートはイラスト的な優先順位モデルであり、SEOReportの顧客データではありません。 監査結果にスコープが必要な理由を示しています。 低価値のエッジルートで深刻な問題が発生すると、すべての製品または記事ページで中程度の問題が繰り返される可能性があります。

各発見を再現可能な修復契約に変換する

すべてのJavaScript発見にはURL、テンプレート、観測された応答、レンダリング状態、影響を受ける要素、再現手順、範囲、および期待される修正後の動作を含める必要があります。 これにより、開発者またはAIコーディングエージェントがハンドオフを利用できるようになります。

例として：

記事ルートでは、ソース応答に空のmain要素が含まれています。 記事本文はハイドレーション後にクライアントリクエストから到着します。 初期のHTMLでタイトル、要約、canonical、および完全な記事本文を返します。クライアントの拡張を保持します。 クリーンリクエストでソースHTMLとレンダリングされたHTMLが同じ主要コンテンツを含むことを確認します。

これはフレームワーク移行を推奨するよりも正確です。 それは外部から観測可能な契約を定義し、実装の選択肢をシステムを所有するチームに委ねます。

最終検証は、コードが配信されたことを単に確認するのではなく、元のキャプチャを繰り返すべきです。 ステータス、ソースHTML、レンダリングされたHTML、メタデータ、リンク、および関連するパフォーマンス証拠を比較します。 JavaScript SEOは、各ステージが独立して測定され、修復が失敗が発生した同じ境界で証明されるときに管理可能になります。