GoogleはJavaScriptを使うページを、クロール、レンダリング、インデックス登録という段階で処理します。レンダリングは、取得したデータやプログラムを使ってページの内容を組み立てる処理です。GoogleはJavaScriptを実行できますが、必要なファイルやページがブロックされていると、想定した内容を処理できない場合があります。[1]

そこで受入検査では、「ブラウザで見える」「検索向けの取得に問題がない」「実際に登録された」を別々に記録します。公開前に確認できる実装上の問題と、公開後に追う検索側の状況を混ぜないためです。検索順位や登録日を制作会社に保証させるのではなく、確認可能な項目について完了条件を合意しましょう。

たとえばサービス詳細ページなら、直アクセスで開けること、サービス名と説明文が取得できること、一覧から詳細へのリンクが存在すること、存在しないURLでは適切なエラーを返すことを確認対象にします。どの本文を必須とするかは、広報や営業など、そのページを使う部門と先に決めておくと手戻りを減らせます。

トップページだけを確認しても、詳細ページに固有の不具合は見つかりません。サービス一覧、サービス詳細、事例一覧、事例詳細、ニュース記事など、表示やデータ取得の仕組みが異なる単位で代表URLを選びます。同じ型でも、項目数が少ないページと多いページで結果が異なる可能性があるため、入力内容の違いも含めて考えます。

実務上は、各ページの型について通常の公開ページを選び、変更した仕組みに応じて境界条件を追加する方法が取り組みやすいでしょう。たとえば一覧なら二ページ目、詳細なら関連事例がないページ、移行案件なら旧URLから案内するページです。さらに、存在しないIDや公開終了後のページについても、制作会社に検査用の条件を用意してもらいます。

各URLには「このページで必ず取得したい内容」を添えます。サービス名、対象業務、提供内容の説明、導入事例へのリンクなど、担当者が実際に識別できる項目にします。「SEO上問題がないこと」だけでは、確認する人によって判断が変わってしまいます。

公開前の検証環境と本番環境では、ドメイン、認証、APIの接続先などが異なる場合があります。検証環境で合格した項目も、本番では再確認する前提で一覧を作り、環境の違いによって未確認の部分を残さないようにします。

初期HTMLとは、ページを要求したときにサーバーが最初に返すHTMLです。一方、レンダリング後の内容には、JavaScriptによって追加・変更された本文やリンクが含まれます。初期HTMLに本文が少ないことだけを理由に、検索に対応していないと断定することはできません。差を確認したうえで、必要な内容が最終的に取得できているかを調べます。

運用担当者は、制作会社と一緒に三つの確認結果を並べると整理しやすくなります。一つ目はページの初期応答、二つ目は通常のブラウザで表示した内容、三つ目は公開後のURL検査で取得できた内容です。ページ内で固有の説明文を一文選び、それぞれの結果に存在するかを調べます。

Chromeの開発者ツールでは、Networkパネルでページ本体のリクエストを選ぶと、応答内容やヘッダーを確認できます。ページ本体と画像・APIなどのリクエストを取り違えないことが大切です。操作に不慣れなら、制作会社に対象行を示してもらい、確認手順を引き継ぎ資料に残しましょう。[2]

初期HTMLに本文がある場合も、表示処理の途中で消えたり、別ページの内容に置き換わったりしていないかを確認します。「最初に入っているから大丈夫」とそこで止めず、最終的な内容まで追うという考え方です。欠落を見つけたときは、確認に使った説明文を短く記録しておくと、制作会社も同じ文字列で調べられます。

比較では、単純な文字数の一致を求めません。画面を組み立てるための情報に文章が入っていても、閲覧可能な本文として出力されているとは限らないためです。逆に、付属する識別子やタグの差だけなら、業務上の欠落とは限りません。「サービスの説明が存在するか」「関連ページへ移動できるリンクがあるか」という内容単位で判定します。

JavaScriptサイトでは、一覧から詳細をクリックしたときと、詳細URLを新しいウィンドウに貼り付けたときで、異なる処理を通ることがあります。前者だけをテストすると、それまでの操作で読み込んだデータに助けられ、直接訪問したときの問題を見落としかねません。

代表URLでは、一覧からの遷移、URLの直接入力、そのページでの再読み込みをそれぞれ行います。戻る操作を含む主要な導線も、業務上必要な範囲で確認しましょう。検査記録には「一覧経由は正常、直アクセスでは本文が空欄」のように、操作と結果を組み合わせて残します。

ログイン状態や以前の選択内容が影響しそうなら、普段使っている画面だけでなく、新しいブラウザプロファイルなどでも確認します。ただし、特定のブラウザ条件をGoogleの環境と同一だと扱ってはいけません。これは利用者側の再現条件を切り分ける検査であり、Google側の取得確認は別に行います。

たとえば一覧で選んだサービスの情報が詳細画面に引き継がれる一方、直接開くと共通の説明しか出ない場合は、詳細URL単独で必要なデータを取得できているかを制作会社に確認します。「JavaScriptをやめるべき」と結論を急ぐより、壊れる入口を特定したほうが調査を進めやすくなります。

一覧のカードやメニューは、クリックすると移動できるだけでは検査が終わりません。Googleは通常、href属性を持つa要素からリンクを抽出します。クリックイベントだけで移動する要素などは、URLを確実に取り出せるとは限りません。JavaScriptで後から追加するリンクも、適切な形式であればクロール可能です。[3]

受入検査では、重要な詳細ページへ向かうリンクを、リンク元のレンダリング後のHTMLで確認します。制作会社には「画面上のカードがどのURLをリンク先として持っているか」を示してもらいます。見た目がボタンでも問題はありません。ここで確認するのは装飾ではなく、移動先の情報です。

「もっと見る」や絞り込みを使う一覧も注意点です。検索から訪問してほしい詳細ページが、何度も操作しないと現れない場所にしかないなら、どこからそのURLへ到達できる設計なのかを確認します。単に件数を増やすのではなく、重要ページへの発見経路を説明できる状態にしましょう。 Googleはページ上でボタンを押すなど、利用者の操作を前提とした読み込みを行うわけではありません。操作に依存するコンテンツは、Googleの遅延読み込みに関する注意点も踏まえて検査します。[4]

APIは、ページが必要とする情報を別の処理から取得する窓口です。たとえば本文や事例一覧をAPIから取得する構成では、ページの枠が表示されても、データ取得に失敗すると重要な内容だけが欠けることがあります。画面全体が開いたという判定と、本文がそろったという判定を分ける必要があります。

まず正常時に、どのAPIが主要本文を供給しているかを制作会社に整理してもらいます。そのうえで、取得の成功、内容が存在しない場合、一時的な通信失敗を別々の条件として扱います。実際に存在しないデータと、存在するが一時的に取得できないデータを、同じ「該当なし」として表示していないかも確認します。

異常系の試験は、本番のAPIを止めるのではなく、制作会社が用意した検証環境や安全なテスト方法で行います。公開サイトへの負荷や利用者への影響を避けながら、エラー表示、再試行の導線、主要本文の残り方を確認しましょう。運用担当者が独断でアクセス制御を変える必要はありません。 記録には、APIの失敗だけでなく、結果として欠けた内容を添えます。「関連事例だけが表示されない」のか、「サービス説明を含む本文全体が表示されない」のかで、対応の優先度は変わります。逆に、画面に赤いエラーがあるという理由だけで、検索への影響が大きいと決めつけることも避けます。

共有する証跡は必要最小限にします。通信記録には認証情報や個人情報が含まれる場合があるため、ログ全体をそのままメールに添付せず、制作会社と安全な共有方法を決めてください。公開URL、発生時刻、失敗した処理、本文の欠落箇所だけで、調査の入口を作れることもあります。

HTTPステータスは、要求に対してサーバーがどのように応答したかを示す情報です。ページが見つからない場合の404や、サーバー側のエラーを示す5xxなどがあります。画面に「ページがありません」と書かれていても、応答自体は成功を示す200になっている場合があるため、見た目だけでは判断できません。

Googleは200などの成功応答を受け取っても、インデックス登録を保証しません。また、成功応答なのに内容が空白やエラーを示す場合には、soft 404と判断されることがあります。正常ページとエラーページの両方を検査する理由はここにあります。[5]

実務では、公開中の正常な詳細URL、存在しない詳細URL、公開を終了したURLについて、想定する応答を制作会社と確認します。一時的な障害と恒久的な削除を同じ扱いにするのではなく、各状態で利用者に何を示し、サーバーからどう返すかを設計として説明してもらいましょう。

このとき、APIが404だったという結果を、ページ本体も404だったという意味で記録しないようにします。ページ本体は200、APIは404、画面は空欄という組み合わせも検査対象です。報告欄を「ページ本体の応答」「APIの応答」「画面の内容」に分けると、どこで異なる結果になったかが伝わります。

Search ConsoleのURL検査には、Googleが把握しているインデックス側の情報と、現在の公開ページを調べるライブテストがあります。修正直後に古い情報が表示されていても、それだけで修正失敗とは判断できません。最終クロール日時と公開・修正日時を照合し、どの時点の状態を見ているかを確認します。[6]

ライブテストでは、取得できたHTML、スクリーンショット、リソースやJavaScriptの情報を確認します。画面上部の判定だけを保存するのではなく、事前に決めた主要本文が含まれるかを調べてください。スクリーンショットの印象とHTML上の内容が食い違うときは、両方を証跡として残します。[7]

ライブテストで問題が出なかったことは、登録や検索掲載の保証ではありません。逆に、未登録というだけでJavaScriptの実装不良と決めることもできません。「取得時に主要本文が欠けている」という観測と、「検索にまだ登録されていない」という状態を別々に管理します。

なお、ログインが必要な検証環境を、そのまま公開URLと同じ方法で検査することはできません。検査のためだけに未公開情報の保護を外さず、公開前は制作会社による確認結果を残し、公開後に本番URLで確認する項目を明示しておきます。

調査依頼で役立つのは、「Googleに認識されません」という大きな結論より、再現できる事実です。対象URL、実施日時、操作、期待する内容、実際の結果、添付した証跡をまとめれば、制作会社は入口をそろえて調べられます。日時にはタイムゾーンも付けておくと、ログとの照合がしやすくなります。

たとえば、架空のサービス詳細ページの報告なら、次のように整理できます。「一覧からの遷移では説明文が表示されるが、新しいウィンドウで直接開くと説明文がない。ページ本体は200。主要データの取得は失敗している。期待結果は、直接訪問した場合もサービス名と説明文が表示されること」。これは実績ではなく、報告の書き方の例です。

比較対象の時刻もそろえます。午前中の画面と午後のライブテストの間に公開内容が変わっていれば、同じ実装を比べたことになりません。更新日時や対象リリースを添え、修正前の証跡を残したうえで、修正後は同じ手順を実行します。検査結果を上書きするだけでなく、どの変更で差が解消したかを追えるようにしておきましょう。

Google側の結果もあるなら、「ライブテストのHTMLにも対象の説明文がない」と追記します。ただし、手元のブラウザで起きたAPIエラーがGoogle側の原因でもある、と確認前に結び付けないでください。観測した差分と、まだ検証していない仮説を分けるだけで、調査依頼の精度が上がります。

修正依頼には、原因の説明だけでなく再検査対象も含めます。同じ仕組みを使う別の詳細ページ、一覧からの遷移、直アクセス、異常時の応答を確認してもらい、修正した一ページだけで完了にしない運用にします。

公開前は、運用担当者が必須の本文と代表URLを選び、制作会社が初期応答、画面遷移、リンク、異常時の処理を確認します。公開時には、本番の直アクセスと主要本文の表示を確かめ、公開後にURL検査の結果を記録します。未確認項目が残る場合は、確認する人と次に見る条件を決めて引き継ぎます。

優先度は影響範囲で判断しましょう。主要ページが直接開けない、重要な説明文が広く欠落する、といった問題は先に扱います。一方、補助的な情報だけの欠落は、利用者への影響と修正範囲を確認して順番を決めます。この区分は社内の運用判断であり、検索順位への影響を数値で断定するものではありません。

完了記録には、修正前の結果、修正内容、修正後の同条件での結果を残します。検索側の再取得を待つ必要がある場合は、「実装修正は確認済み」「検索側の更新は未確認」と状態を分けます。担当者の交代後も、何が終わり何が残っているかを追える形にすることが大切です。

canonicalタグの使い方｜重複URLを整理して正規ページを伝える方法
XMLサイトマップの作り方と送信方法｜Search Consoleで更新ページを伝える運用
ホームページ制作の検収｜公開前の受け入れ確認で見るべき項目と進め

公式資料の確認日 2026年10月20日
[1] GoogleのJavaScript SEO資料 
[2] Chrome DevToolsの公式資料 
[3] Googleのリンクに関する公式資料 
[4] 遅延読み込みコンテンツの公式資料 
[5] HTTPステータスに関するGoogleの公式資料
[6] URL検査ツールの公式ヘルプ 
[7] JavaScriptの問題を調べる公式手順