メタディスクリプションが反映されないときは？公開ページとGoogle取得版の確かめ方

設定した説明と、検索結果に出る説明を分ける

メタディスクリプションはページ側が用意する説明文です。検索結果の説明文は「スニペット」と呼ばれ、Googleが検索内容に合うように選びます。この二つが同じ文かどうかと、設定した文が公開ページに出ているかどうかは、別の確認です。

メタディスクリプションは、HTMLのheadという部分に置くページの説明情報です。通常の本文とは別の場所にあるため、ページを開いて読んだだけでは、その設定値が見えないことがあります。WordPressなどの管理画面で入力する欄があっても、実際にどの仕組みが説明文を出力するかはサイトによって違います。特定のプラグインを入れていることを、すべてのサイトの前提にはしません。

図の入力欄と公開HTMLには、同じ説明文の冒頭が示されています。Google側の取得情報は登録版か公開URLテストかで分け、検索結果の説明は検索語と時点を添えて確認します。検索結果の文が違うことだけでは、入力の保存が失敗したとは決められません。

Googleのスニペットに関する公式資料では、検索結果の説明は主にページ本文から自動で作られ、メタディスクリプションのほうがページを適切に説明できる場合に、その情報を使うこともあるとされています。検索語が違えば、同じページから異なる箇所が選ばれることもあります。

そのため、入力欄と検索結果の文が違うという観察だけでは、管理画面の保存に失敗したのか、公開ページに出力されていないのか、Googleが別の箇所を選んだのかを分けられません。まず、次の四つを区別して読めるようにします。

Search Consoleは、Google検索でのサイトの状態を確認するためのサービスです。そのURL検査には、Googleのインデックスにあるページの情報と、現在の公開URLを調べるテストがあります。インデックスとは検索に使うために保持されるページ情報で、検査に表示された内容が今の公開ページと同じとは限りません。

GoogleのURL検査の案内も、登録版の情報と公開URLのテストを分けています。「GSCのHTMLには新しい説明がある」と報告するときは、どちらで見たHTMLかまで伝えると、次に何を確かめるかを決めやすくなります。

対象URL・説明文・変更した時刻をそろえる

同じページの同じ説明文を追います。調べる完全なURL、変更前後の文、保存を確かめた時刻、HTMLや検索結果を確認した時刻をそろえてください。

トップページの説明を変えたのに記事ページの検索結果を見ている、という状態では反映を判断できません。検索結果で見える短いURL表示だけで判断せず、実際のリンク先も確かめます。wwwの有無、末尾のパス、言語違いのページ、別のページへの転送がある場合も、何のURLを確認したかを残します。

図のURLと文、28日午前9時は説明用の例です。同じURLの変更前後を比べ、公開HTMLや検索結果を見た時刻は変更時刻とは別に記録します。観察していない時刻は空欄にして、後から推測で埋めません。

新しい説明には、そのページの本文で確かめられる内容を書きます。本文にない料金、対応地域、受付時間、成果を足して検索結果だけを目立たせると、開いた人が必要な情報を見つけられません。今回の例でも、受付日時や点検内容が本文で確認できることが前提です。

日時を残すのは、「先週変えたはず」といった記憶だけで、Googleが取得した時点との前後関係を決めないためです。時刻がどの地域の表示かも確認します。保存した時点と公開ページを見た時点は別に扱い、確認していない時刻を推測で埋めないようにします。

現在のHTMLとGoogle取得版を確かめる

先に公開ページの出力を読み、次にSearch Consoleの登録版と公開URLテストを区別して見ます。いずれも、ページ全体の判定だけでなく、説明文そのものと情報の時点を確かめることが大切です。

図の公開ページでは、最初に返されたHTMLと読み込み後のDOMで異なる説明が見える場合を示しています。これはJavaScriptで変わり得る仕組みの説明例です。Googleの登録版と公開URLテストはそれぞれ別の観察として、読めた文と時点を記録します。登録版のHTMLを読めないときは、未確認のままです。

1. 公開ページが返したHTMLを確認する

   パソコン版Chromeで対象ページを開き、ページ上を右クリックして「検証」を選びます。開いた開発者ツールの「Network」を選んでからページを再読み込みし、「Doc」で絞ります。対象ページのURLに対応するリクエストを選び、「Response」で返されたHTMLを確認してください。別のファイルやページ内の埋め込みを選ばないよう、URLも見ます。

   HTML内で name="description" を検索し、対応する content の文を読みます。完全一致で見つからなくても、説明が無いとは判断しません。引用符、空白、大文字・小文字などの書き方もあるため、description や meta も手がかりに該当要素を探し、次のDOM側の確認と照らします。今回の例なら、新しい説明である「予約制の自転車点検。受付できる日時と点検内容を確認できます。」と一致するかを確かめます。語句だけを検索すると、本文やスクリプト内の同じ文を拾うことがあるため、説明用のmeta要素であることも見てください。

2. JavaScriptで説明を設定するサイトか確かめる

   受け取ったHTMLと、読み込み後にブラウザが扱うページ構造は異なることがあります。「Elements」パネル内を選び、MacではCommand＋F、WindowsではCtrl＋Fで meta[name="description"] を探すと、現在のページ構造にある説明情報を確認できます。

   このページ構造をDOMと呼びます。JavaScriptで説明文を加えたり変えたりする実装では、最初のHTMLとDOMの両方を、どちらで見たかを添えて担当者へ伝えます。最初のHTMLに無いことだけで、Googleも説明を一切読めないとは断定しません。反対に、自分のブラウザのDOMにあるだけで、Googleが同じ状態を取得したとも決めません。

3. Search Consoleで登録版の情報を開く

   対象サイトのプロパティを選び、上部のURL検査欄へ完全なURLを入力します。「ページのインデックス登録」を開き、「前回のクロール」の日時と「Googleが選択した正規URL」を確認します。表示される場合は「クロール済みのページを表示」からHTMLを開き、説明文を探してください。

   正規URLとは、重複するページ群の中で代表として扱われるURLです。想定と異なるURLが選ばれていれば、今見ている説明と何のページの情報を比較しているのか、サイト管理者と確認します。別URLを同じものとして表にまとめないようにします。

4. 公開URLテストは別の結果として読む

   現在の取得状態も調べたい場合は、権限のある担当者が「公開URLをテスト」を実行します。テスト側のHTMLを見られたら、その文とテストした時刻を控え、登録版とは別に扱います。画面の「Googleインデックス」と「ライブテスト」を切り替えた際も、どちらの結果を読んでいるか確かめてください。

   ライブテストは転送先を調べる場合がありますが、最終的にテストしたURLが表示されるとは限りません。転送があるサイトでは、入力したURLだけで同一ページを確認できたと判断せず、公開ページの遷移や登録版の情報も担当者と照合します。

Chromeでの操作は、Networkパネルの公式リファレンスと、DOMの表示に関する公式案内に基づくものです。GoogleのJavaScript SEO資料でも、JavaScriptによるメタディスクリプションの設定・変更が説明されています。出力方式が分からない場合は、HTMLとDOMの観察をそろえて開発担当へ確認しましょう。

開発者ツールで文字を書き換える操作は、この確認には必要ありません。手元のブラウザの表示を編集して新しい文が見えても、公開サーバー側が更新されたことにはなりません。確認に不慣れな場合は無理に設定を変えず、対象URLと変更前後の文を、サイトを管理する担当者へ渡すところから始められます。

三つの例から次の確認を決める

同じ「検索結果が変わらない」でも、確認できた版によって次の作業は変わります。公開ページへ出ているのか、登録版を読めたのか、検索結果では何が出たのかを順に比べます。

ここからは、先ほどの点検予約ページで起こり得る三つの状態を比べます。同じサイトでこの順に発生したという記録ではなく、判断の分かれ目を説明する別々の例です。いずれも28日午前9時に説明を変更したことを前提とします。

図は別々の架空例です。例1では同じURLの登録版の文と取得時刻を再確認し、例2では検索結果の文と本文を照合します。「点検項目」は表示文の内容をまとめたもので、引用ではありません。例3は登録版を読めないため、文の新旧は未確認です。

三つの例に共通するのは、説明を何度も書き直す前に、判断の材料を分けることです。「GoogleのHTMLを見ました」ではなく、「登録版で古い文を読めた」「ライブテストで新しい文を読めた」「登録版は開けなかった」と伝えれば、担当者は調べ直す場所を絞れます。

直す対象と担当、再確認の順番を決める

現在の公開出力に問題があればサイト側を直し、登録版との違いが残るなら取得時点とURLを追います。検索結果だけの文の違いなら、表示内容と本文を確かめてから修正を決めます。

図は二つの別々の架空例です。入力欄は新しく公開HTMLが以前の文なら、URLと出力を保守担当へ渡します。公開側は新しく登録版が以前の文なら、文と時刻を添えて同じURLの登録版を再確認します。登録版を読めなければ未確認のまま伝えます。

作業を依頼するときは、「メタディスクリプションが反映されない」という大きな依頼だけにしないことが有効です。どこまで読めて、何が違うのかを一緒に渡します。次の分け方なら、編集、サイト保守、検索確認の担当が同じ作業を繰り返しにくくなります。

WordPressで編集している場合も、入力欄が正しいだけでは確認は終わりません。テーマ、SEO設定、個別ページの設定など、どこが実際の説明を出しているかを保守担当と特定します。同じページに説明用のmeta要素が複数見つかった場合は、どの仕組みから出ているかを調べます。検索結果の違いを見ただけで、プラグインを無効化したり、テーマ全体を変更したりする必要はありません。

修正後は、まず公開URLで目的の文を読めるかを確認します。その後の登録版と検索結果の観察は、別の結果として残してください。複数のページや設定を一度に変えると、何が直ったのかを説明しにくくなります。今回の対象URLで確認した差分から進め、共通設定を変える必要が判明したら、影響する他のページも保守担当と確認します。

この報告なら、公開側を再び書き直す依頼ではなく、登録版との差を追う依頼だと分かります。登録版を読めていない場合は、最後の部分を「登録版のHTMLを開けず、文は未確認です」に変えます。分からない部分を短く明示するほうが、推測で原因名を付けるより調査を進めやすくなります。

文の反映と検索・問い合わせの成果を分ける

説明文が公開HTMLに出たこと、検索結果で選ばれたこと、クリックや問い合わせが増えたことは別々に確認します。文が一致しただけで集客成功とせず、文が違うだけで失敗とも決めません。

図の点検予約ページは架空例です。公開HTMLの文が一致したことと、同じページ・検索語・期間・国・端末・検索タイプをそろえた検索の観察は別に読みます。相談先へのクリック、受付完了、有効な相談、商談も分けて確認し、未測定を0件にせず、テスト送信を実相談に数えません。

反映の確認では、これまで見てきたURL・文・版・日時を使います。検索からの集客を見るときは、同じページと検索語に対し、比較する期間、国、端末、検索タイプをそろえます。ページ全体のクリック数と、ある検索語だけのクリック数を混ぜないことが大切です。

Search Consoleの検索パフォーマンスの案内では、クリック数、表示回数、CTR、平均掲載順位を確認できます。CTRは表示回数に対するクリック数の割合です。平均掲載順位は集計値で、すべての利用者に常に同じ順位や説明が出たという意味にはなりません。

たとえば説明変更の前後でクリック数が増えても、表示回数、順位、検索語の構成、曜日などが違えば、説明文だけの効果とは言い切れません。変更日を残し、条件をそろえて傾向を見ます。少ない表示回数の変化を大きな成果に見せたり、まだデータが無い期間を0件として扱ったりしないようにします。

問い合わせまで確かめる場合は、記事から相談先へ進んだクリック、フォームの受付完了、有効な相談、商談を区別します。クリックは問い合わせの受付完了ではなく、動作確認の送信は実際の相談ではありません。どの段階をどう記録しているかが決まっていなければ、「問い合わせ効果はまだ確認できない」と報告します。

ここで見る成果も、今回説明した架空ページの実績ではありません。自社の計測と受付記録を照合して初めて判断できます。検索語ごとの順位や問い合わせとのつながりが未取得なら、説明文の採用状況とは別に、その不足を残してください。文面の小さな変更だけで順位1位や相談増加を約束することはできません。

まとめ：同じURLの、どの版で読んだ文かを確かめる

メタディスクリプションが反映されないように見えたら、公開ページの出力、Search Consoleの登録版、公開URLテスト、検索結果を分けて見ます。次の作業を決める基準は、設定欄を書き直した回数ではなく、どこで何を確認できたかです。

図は、確認できた文と不足を分ける架空のメモです。公開HTMLに新しい文を読めても、登録版の文とクロール時刻は未確認のままです。次は同じURLの登録版を確認し、公開側も確認時刻を記録して見直します。

• 対象URL、変更前後の文、変更と確認の日時をそろえる。
• 公開側では、返されたHTMLと読み込み後のDOMを区別する。
• 登録版のHTMLと前回のクロールを確認し、ライブテストの結果で代用しない。
• 取得できなかった情報は未確認のまま残し、古い文や空の文と推測しない。
• 検索結果の文が違う場合は、実際のURLと本文を見て、誤りがある箇所から直す。

例1なら登録版との差を追い、例2なら検索語に対する表示内容を確かめ、例3なら不足する確認を担当者へ渡します。状態に合う一手を選ぶことで、同じ説明文を何度も書き直す前に、確かめる場所を絞れます。