JavaScriptで表示する本文・リンクの検索確認｜初期HTMLとGoogleの検査を分ける

JavaScriptで表示する本文がブラウザーに見えることと、Googleがその内容を取得・処理したことは別の確認です。制作会社が検収する際は、初期の応答、ブラウザーで生成された画面、Googleの検査結果を分け、どのURLのどの情報が欠けるのかを具体化します。

この記事は、企業サイトを実装する制作会社と、技術調査を依頼するWeb担当者向けです。サービスや製品の説明と、その次のページへのリンクが取得できるかを確かめ、必要な修正を判断する手順を整理します。

1．検索から来た人へ届ける情報を先に選ぶ

対象URLごとに、何のページか、読者が判断するために必要な説明、次へ進むリンクを挙げます。タイトル、サービスの対象と内容、製品名、利用条件、関連する詳細への案内などです。装飾が動いたことだけで、必要な本文が届いたと扱いません。

検収する本文とリンクを、具体的な場所へ落とす

会員や個人向けの非公開情報を検索へ出す必要はありません。公開したい範囲と、検索へ出す対象をサイト管理者と合意し、今回の調査を理由に公開範囲を拡大しないでください。

2．初期HTMLと、実行後のDOMを別の証拠にする

初期HTMLは、URLへの応答として受け取った内容です。JavaScript実行後のDOMは、ブラウザーで処理された結果です。本文が最初から含まれるページと、後から取得して表示するページでは、調べる経路が異なります。ページのソースだけ、見える画面だけのどちらか一つで結論を出さないでください。

Google公式は、JavaScriptページの処理をクロール、レンダリング、インデックス登録に分けています。必要なリソースを取得できるかも確認対象です。初期HTMLに本文がないことだけで登録できないと断定せず、その後の処理を調べます。（JavaScript SEOの基本）

記録にはURL、取得日時、ログイン状態、ページ版、応答と実行後の本文、使用したブラウザーを残します。表示条件や公開版が違えば、同じURLでも比較が成立しない場合があります。調査用資料に認証情報や個人情報を必要以上に含めないようにします。

Chromeで読み取る場合は、次のように証拠を分けられます。操作名や画面は使用中の版で確認してください。

1. DevToolsのNetworkを開いて対象URLを読み込み、文書のリクエストを選びます。Responseで受け取ったHTMLを読み、期待する本文が含まれるかを記録します。
2. 公開画面の対象本文を右クリックして検証し、Elementsで実行後の要素を読みます。必要ならパネル内を検索して、本文の一部とリンク先の属性を確認します。
3. 同じURL・版・ログイン状態で結果を残します。ブラウザー内でHTMLを編集して見えた状態は、公開版の取得結果にしません。

NetworkとElementsの操作は、Chrome公式の通信確認とDOMの閲覧方法で確認できます。この手順は通常ブラウザーの証拠を作るもので、Googleの取得結果を代替するものではありません。

3．クリックできることと、抽出できるリンクを分ける

画面上でクリックして移動できても、リンク先がHTMLのリンクとして表現されていない場合があります。Googleは通常、href属性を持つa要素からリンクを抽出します。JavaScriptで追加するリンクも、この形式で実際のWebアドレスへ解決できるかを確認します。（Googleのクロール可能なリンク）

実装を読むときは、たとえば<a href="https://example.com/products/">製品一覧</a>のように、移動先と説明が確認できる形を見ます。これは説明用のコード例です。hrefのないクリック処理だけを、同じリンクだと扱わないようにします。

画面の操作と、リンク先の値を一組で確認する

本文内のサービス案内、製品詳細、ページ送り、関連記事などで、生成後の要素とリンク先、リンクの説明を見ます。クリック処理だけでURLを作っている場合は、制作担当へ現在の実装を確認してください。すべてのボタンをリンクへ変えるという意味ではありません。送信や画面内の開閉など、操作の役割は別です。

リンク先を直接開いても、必要な本文が表示されるかを確認します。一覧からの画面遷移だけで成功し、詳細URLの直接アクセスでは失敗するなら、その条件を再現手順へ書きます。外部公開してよいURLか、存在しない対象をどう扱うかも合わせて整理します。

4．Googleの検査は、ブラウザーの表示と別に読む

Google公式のJavaScript問題の調査ガイドは、URL検査やリッチリザルトテストで、読み込まれたリソース、JavaScriptの出力・例外、レンダリングされたDOMなどを確認する方法を案内しています。（検索関連のJavaScriptの問題を解決する）

利用できる検査は、権限と対象URLを確認して行います。検査日時、対象、検査の種類、本文とリンクの有無、取得できなかったリソースを記録してください。ツールの画面で合格と出たことだけで、すべての本文や実際の検索表示を保証しません。

現在の試験結果と、登録済み情報を取り違えない

ライブの確認と、過去に処理された登録情報では確認時点が異なります。結果を引用するときはどちらを見たかを明記し、対象サイトのURL、検査日時、表示した画面、取得結果を組にして残してください。

確認できない場合は、ツールの権限不足、取得失敗、対象の非公開などの理由を未確認として残します。未確認を「Googleは読めている」あるいは「JavaScriptが原因」と読み替えないでください。

5．欠ける場所から、原因候補と修正対象を絞る

本文が欠けるなら、本文を取得する通信、依存するスクリプト、実行時の例外、表示条件を調べます。リンクだけが欠けるなら、生成する要素やリンク先の値を調べます。ログイン後や特定の操作後にだけ表示する情報を、一般の閲覧者に必要な公開本文と混同しないようにします。

サーバー側での表示や事前生成など、情報を届ける方式は複数あります。特定方式へ変えれば順位が上がるとは約束せず、欠落の原因、運用するデータ、更新、性能、費用から比較します。robotsやインデックス、URLの変更は、この確認とは別の承認対象として扱います。

6．実装の検収表へ、取得結果と未確認を残す

制作会社の検収票には、対象URL、必要な本文・リンク、初期応答、ブラウザーDOM、Googleの検査、操作試験、残課題を載せます。静止画でデザインを確認したことと、本文・リンクを取得できたことを別項目にしてください。

WordPress実装の依頼資料と検収表へ、本稿の取得確認を追加できます。支給原稿や一覧・詳細の仕様が変わった場合は、検査した版も更新します。以前の版での合格を、新しい本文の合格として流用しません。

修正後は同じURLと条件で再確認し、PC・スマホで必要な表示と操作が維持されたかを見ます。試験結果が揃っても、公開版の反映確認は必要です。差分、原本、戻し方、担当、承認を用意して反映し、実際の公開本文とリンクを読み直します。

7．取得の改善と、検索・相談の結果を分けて観察する

必要な本文とリンクを取得できたことは技術上の確認です。検索の表示回数・クリック、問い合わせの受領、受注、顧客の解決は別の記録です。改修した直後に、まだ観測していない検索や営業の成果を作らないでください。

変更履歴に、狙いと確認できた差を書く

変更日、URL、欠けていた内容、変更箇所、狙い、前後の条件、確認結果、未確認を残します。順位だけが動いた場合は、技術修正の効果と断定せず、同時期の変更や検索条件も調べます。取得できているページを、短い変動に合わせて毎日作り直す運用は避けます。

確認を効率化するなら、まず重要な本文とリンクの所在、対象URL、失敗時の担当を決めます。検査を大量実行した件数より、欠落を見つけて直し、利用者が判断・行動できる情報を維持できるかを評価します。

8．Acquaへ渡す資料と、依頼の完成条件をまとめる

制作会社の方は、対象URL、期待する本文・リンク、取得結果、再現条件、構成、既存実装、公開担当をまとめて実装・保守の案内から相談できます。特定フレームワークへの一律対応を約束せず、現行構成と資料を見て、調査・修正・試験・納品の範囲を確認します。

企業の方はWeb制作・運用の案内から、読者へ届けたい情報と気になるURL、制作側から受け取った検査結果を伝えてください。専門的な原因を事前に断定する必要はありません。

支援後は、公開範囲に合った本文とリンクを確認でき、検査した版、未確認、次の担当と戻し方を説明できる状態を目指します。必要な実務と費用を相談したい場合はお問い合わせへ状況をお知らせください。