WEBサイト・SEO

検索の画面確認で本文が見えない?JavaScript表示を調べる順番

自転車点検店の担当者が制作担当と、URL検査での見え方とHTML・描画について資料を見比べるイメージ。

ブラウザでは商品一覧が見えるのに、Google Search ConsoleのURL検査では画面が空に見える。そんなときは、画面の見た目だけで「Googleに本文が読めない」と決めず、同じURLについて、ページの元のHTML、ブラウザで描画した後の内容、Googleが検査で取得したHTMLを順に比べます。取得できなかったファイルと検査時刻も控え、確認できた事実を制作担当へ渡しましょう。

この記事では、架空の自転車店の点検予約一覧 https://example.com/bicycle-check/ と詳細 /bicycle-check/spring/ を例にします。実際の検索結果や特定のサイトの測定結果ではありません。

画面とHTMLを分けて確認する

下の図では、同じ文言を画面・ソース・読み込み後のDOMで探し、Google側の検査はまだ未確認として分けています。

架空の点検予約一覧で、画面・ページソース・読み込み後DOM・Google側の検査HTMLを分けて春の自転車点検を確かめる図。ソースとDOMに差があってもGoogleが読めないと決めず、検査HTMLの種類や画面・資源を照合する。

この例では画面とDOMに文言があり、ソースの検索では見つかりません。Google側の結果は未確認なので、その差だけで検索側の読み取りを決めず、次の検査へ進みます。

まずブラウザで対象URLを開き、「春の自転車点検」という一覧の文言と、詳細ページへのリンクが見えるか調べます。URL、確認日時、見えた文言を控えます。次に、同じページのソースを表示し、同じ文言を検索します。ソースはサーバーから受け取ったHTMLを確認する場所です。一方、開発者ツールのElements(要素)には、JavaScriptによる変更後を含むブラウザのDOMが表示されます。

ソースに文言がなくDOMにある場合、ブラウザで表示する過程に違いがあることは分かります。それだけではGoogleが読めないとは言えません。検索側の検査結果を続けて確かめます。

同じURLと時点をそろえる

図の架空例では、一覧と詳細を別のURLとして扱い、修正を公開した時刻と検査した時刻を分けて記録します。

架空の点検予約一覧と詳細ページは別URLであり、修正前後を同じ一覧URLで比較する図。修正公開時刻と各検査の時刻、登録版とライブを分け、転送の前後も確認する。

修正前後は同じ一覧URLを比べます。図の28日9時は説明用の公開時刻で、登録版とライブの確認時刻とは別です。

一覧ページと詳細ページ、末尾スラッシュの有無、スマートフォン向けの別URL、ログイン前後を混ぜると比較できません。URL検査の入力欄に、ブラウザで確かめたURLをそのまま入れ、検査日時を記録します。リダイレクトがあれば移動前と移動後のURLも残します。

修正の前後で比較する場合は、公開した日時と、各検査を行った日時を分けて書きます。ページが更新されている間は、違う時点の結果が違っても不思議ではありません。

URL検査で登録情報とライブテストを見る

下の図では、同じ一覧URLの登録情報と公開URLテストを、架空の時刻で分けて示しています。

架空の点検予約一覧について、以前取得した登録情報のクロール時刻と、公開URLテストの時刻・HTML・画面・取得情報を別に確認する図。読めないHTMLは未確認で、テスト結果は登録や順位を保証しない。

図の前回クロールは27日18時、ライブテストは28日11時です。古い取得情報と現在のテストを同じ時点の結果として扱わず、HTMLが読めないときは未確認のまま残します。

Search Consoleで対象プロパティを選び、上部のURL検査に完全なURLを入力します。最初に表示される登録情報は、Googleが以前に取得・処理した情報です。現在の公開状態を調べるには「公開URLをテスト」を使います。テスト終了後に利用できる「テスト済みのページを表示」などから、HTML、スクリーンショット、ページの取得に関する情報を確認します。詳細データが表示されるのはテストの状態によって限られ、スクリーンショットは公開テストで取得できた場合に利用できます。表示できなければ、まずテストの取得状態を確認します。

公開URLテストで問題が見つからなくても、インデックス登録や掲載順位が保証されるわけではありません。登録情報とライブテストの日時と結果は別々に記録します。

検査のHTMLで本文とリンクを探す

図の架空例で、一覧に表示された文言と、検査で表示されたHTMLの文言・リンク先を見比べます。

架空の点検予約一覧の文言と、検査で表示されたHTMLの文言と詳細リンク先を確認する図。HTMLの種類や画面・リソースも照合し、見つからなくても描画後の不在を断定しない。

この図では文言と詳細へのリンク先がHTMLにあります。見つからなかった場合も、そのHTMLだけで描画後に存在しないと決めず、画面やリソースも照合します。

検査で確認できるHTMLを開き、「春の自転車点検」という文言を探します。詳細へのリンクも、リンク先のURLを含む<a href="…">があるか確認します。通常のブラウザで見える本文と、検査で表示されたHTMLにある本文を照合します。Googleの資料にはライブテストのHTMLを未加工のHTMLと説明する箇所と、レンダリングされたHTMLの確認を案内する箇所があります。表示されたHTMLだけで描画後の状態と決めず、スクリーンショットやリソース情報も併せて確認し、判断できない場合はそのまま制作担当に伝えます。

本文がHTMLにあるのにスクリーンショットでは見えない場合は、まず表示位置や画面の大きさ、表示のためのCSSなど、画面の差を調べます。本文が表示されたHTMLにない場合は、それだけで描画後の本文もないとは決めず、取得・描画に必要なリソースや本文を生成する条件を調べます。どちらも、この段階では原因の確定ではありません。

取得できなかったものを確かめる

架空例のファイル取得エラーを、確認できた事実と、まだ分からないことに分けてみます。

架空のschedule.js取得エラーを記録し、点検予約の文言欠落との関連と原因は未確定として、URL・検査日時・エラーを制作担当に渡して調べる図。

図のschedule.jsは例示です。取得エラーは記録できますが、そのファイルが本文に必要か、文言の欠落に関係するかは制作担当との確認が必要です。

ライブテストのページ情報に、読み込めなかったリソースが示されていれば、ファイル名、URL、エラー内容を記録します。JavaScriptやCSSが対象でも、そのファイルが本文に必要かどうかは制作担当に確認します。エラーがあるだけで原因と決めつけず、本文やリンクの欠落と関連するかを調べます。

robots.txtによる制限、サーバーの一時的な応答、認証が必要な資源などは確認候補です。どれに当たるかは対象サイトと検査結果で異なります。検査ツールの制限もあるため、表示が異なることだけで通常のクロール結果と同じだと断定しません。

二つの結果から次の確認先を選ぶ

次の図は、通常のブラウザで文言が見える二つの架空例です。検査HTMLで文言が見つかった場合と見つからない場合の次の確認先を比べます。

通常ブラウザで点検予約の文言が見える架空例で、検査HTMLに文言と詳細リンクがある場合と見つからない場合の次の確認先を示す図。HTMLの種類と画面・資源を照合し、描画後の不在や原因を断定しない。

文言とリンクがあれば検査画面の表示位置などを調べ、見つからなければHTMLの種類と表示に必要な処理を確認します。どちらも順位や原因の確定ではありません。

架空の一覧ページで、ブラウザには「春の自転車点検」が見えるとします。検査HTMLにも同じ文言と詳細リンクがあれば、画面で見えない箇所や取得できなかったCSSを調べ、登録情報の時点も確認します。HTMLに本文が見つからない場合は、その文言がどの処理で出るか、関連ファイルやデータが取得できたかを制作担当と確認します。

どちらのケースでも、検査HTMLだけから順位を判断しません。検索結果の表示や登録状況は、対象URLと時点を添えて別に観察します。

制作担当へ事実と未確認を渡す

図は、架空の一覧URLを10月29日に検査した場合の引き継ぎ例です。確認したことと、まだ判断できないことを分けています。

架空の点検予約一覧について、確認できた画面・文言・取得エラーと、エラーとの関連や描画後の状態が未確認であることを制作担当へ渡す図。

通常画面とDOMで文言を確認できた事実と、取得エラーとの関連が未確認であることを一緒に渡します。画像を共有する前には顧客情報やログイン情報が写っていないか確かめます。

問い合わせには、対象URL、検査日時、ブラウザで見えた文言、ソース・DOM・ライブテストHTMLでの有無、取得できなかったリソースとエラーを添えます。スクリーンショットは必要な範囲に絞り、顧客情報やログイン情報が写っていないか確認します。

例えば「10月29日、一覧URLの通常表示とDOMには文言あり。ライブテストHTMLには見つからず、指定のJavaScriptファイルの取得エラーを確認。エラーと文言欠落の関連は未確認」と伝えれば、事実と仮説を分けられます。

修正後は同じ条件で再確認する

図の架空例では、修正前後で同じ一覧URLと文言を追い、確認場所とそれぞれの日時をそろえます。

架空の点検予約一覧について同じURL・文言・検査方法で修正前後の画面、ソース、DOM、ライブHTMLと取得失敗を確認し、登録情報は別時点として扱う図。

画面・ソース・DOM・ライブHTML・取得失敗を再確認し、変化と未確認を分けます。ライブテストの変化だけでは、登録情報も更新されたとは限りません。

修正の公開日時を控え、同じURL、同じ文言、同じ検査方法で確認し直します。ブラウザとソース、DOM、ライブテストHTML、失敗リソースを比較し、どの差が解消したかを記録します。登録情報は別の時点の情報なので、ライブテストの結果だけで更新済みと判断しません。

登録状況はURL検査で追い、検索パフォーマンスは同じ検索語・ページ・期間・国・端末の条件で比較します。Search Consoleの平均掲載順位は期間内の平均であり、常にその順位にいることを示す数字ではありません。問い合わせへの影響も実際の完了データを別に確認します。

今日の一歩:一つの文言を追う

最後に、架空の一覧ページの一文言を3か所で追う例を見てみましょう。

架空の点検予約一覧の一文言をソース、DOM、ライブテストHTMLで追い、未確認をなしとせず画面・資源などを照合して制作担当へ渡す図。

この例ではソースの検索で見つからず、DOMには文言があります。ライブテストHTMLは未確認なので、なしと記録せず、画面と資源も照合します。

まず対象URLを一つ選び、本文中の短い文言と確認日時を記録してください。その文言をソース、DOM、URL検査のライブテストHTMLで順に探し、見つかった場所と見つからなかった場所を分けます。原因がまだ不明でも、取得エラーとともに制作担当へ渡せる確認結果になります。確認の切り分けに迷う場合は、個人情報やログイン情報を除いたURLと結果を整理し、Webサイトと検索からの集客について相談することもできます。

参考(2026年10月29日確認):Google 検索に関する JavaScript の問題を解決する、Google Search Console URL 検査ツール。

仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。

AI・DXとマーケティングを一体で相談

KEEP EXPLORING

次のヒントを、もうひとつ。

すべての記事を見る

LET’S CONNECT THE DOTS.

次の一歩を、
一緒につくる。

業務も、AIも、集客も。
課題がまだ整理できていなくても、ご相談ください。

AI・DXとマーケティングを一体で相談