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 つの状態間の構造化差分です：サーバーが返したものとレンダリング後に存在するもの。 レンダリングされた状態が追加、削除、または変更するかどうかを確認する：

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

すべての差異が欠陥ではありません. インタラクティブコントロール、パーソナライズドウィジェット、クライアントサイドの拡張は、レンダリングされた状態に属します. 監査は、インデックス可能な意味や発見が変わる差異をフラグ付けすべきです. 有用な証拠記録は具体的です：「初期応答にはタイトルとナビゲーションが含まれますが、記事本文はありません；本文はクライアントが /api/content/123 にリクエストした後に表示されます；そのリクエストはクリーンなクローラセッションに 401 を返します。」これにより、開発者は再現可能な境界を得られます。 「JavaScript コンテンツはインデックスしにくいかもしれません」はそうではありません。

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

検索発見はクロール可能なURLに依存します. Google は解決可能な href 値を持つ標準アンカー要素を推奨します。 onclick ハンドラを備えたスタイル付き要素は、ユーザーにとってはナビゲーションのように振る舞い、文書内に発見可能な目的地を公開しません。 サイト全体のナビゲーション、記事カード、ページネーション、フィルター、パンくずリスト、および関連コンテンツモジュールを監査します. 重要な目的地がアンカーで表現され、href が事前のアプリケーション状態なしで機能することを確認します。 シングルページアプリケーションでは、ルート変更に History API を使用し、意味のあるすべてのビューに安定した URL があることを確認します。ハッシュフラグメントは文書内の位置に適していますが、インデックス可能なルートの代替としては不適切です。 これは内部リンク品質の問題でもあります. 説明的なアンカーテキストは目的地の文脈を提供します. AI検索監査計画、体系的監査手法、およびこのレンダリング診断を結びつけるクラスターは、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要素が含まれています。 記事本文はハイドレーション後にクライアントリクエストから届きます. タイトル、要約、canonical、および完全な記事本文を初期のHTMLで返します。クライアントの拡張機能を保持します。 クリーンリクエストでソースHTMLとレンダリングされたHTMLが同じ主要コンテンツを含むことを確認します。

これはフレームワーク移行を推奨するよりも正確です. それは外部から観測可能な契約を定義し、実装の選択肢をシステムを所有するチームに委ねます. 最終検証では、コードが配信されたことを単に確認するのではなく、元のキャプチャを繰り返す必要があります. ステータス、ソースHTML、レンダリングされたHTML、メタデータ、リンク、および関連するパフォーマンス証拠を比較します。 JavaScript SEO は、各ステージが独立して測定され、修復が失敗が発生した同じ境界で証明されるときに管理可能になります.