AMP testing toolの検索結果previewはmarkupの確認と分けて読む

AMP testing toolで有効なpageを検査すると、Google検索結果での見え方を示すpreviewが表示される場合があります。previewは、markupが読めたページの表示内容を確かめる手がかりです。検索結果へ掲載されることや、特定の検索語で上位になることを示す画面ではありません。

AMP pageを作ると、速度、markup、検索表示を一つの結果として見たくなります。しかし、直すべき場所は同じではありません。markupの問題はtestのsource行から直します。previewの内容はtitleや本文、構造化データを見直す手がかりにします。掲載状況は公開後のSearch Consoleで確認します。

previewを見たときに最初に確かめるのは、派手に見えるかどうかではありません。検索した人が、pageの内容を想像できるかを見ます。記事のtitleが途中で意味を失っていないか、説明に本文と違う約束が混ざっていないか、画像が主題と関係なく目立っていないかを確認します。page内で伝えていないことを検索結果だけで約束しても、開いた人は判断を続けられません。

titleを短くすればよい、説明を長くすればよい、という単純な決め方もできません。検索した人が知りたいことと、pageが答えることが同じかを先に見ます。たとえば設定方法を探す人へ、機能の宣伝だけを見せても、クリック後に必要な手順がなければ役に立ちません。previewの文面を直すときは、通常pageとAMP pageの本文、見出し、次に進むlinkも一緒に確認します。

previewが答える問いと答えない問いを分ける

説明用の仮例として、記事のtitleを直したあとにAMP pageを検査する場合を考えます。previewでtitleや説明の見え方を確認できても、特定の検索語で何位になるかは分かりません。検索語、競合page、Googleが実際に表示する内容は別に動きます。previewが整っていることを、検索順位の根拠にしません。

反対に、previewが出ないことだけでmarkup errorと決めることもできません。先にtestの結果でAMP markupとstructured dataの問題を確認します。問題がなければ、通常pageとの内容、公開状態、Search Consoleで見える状況を別に調べます。表示の有無だけから、原因を一つに決めません。

previewが表示されたとしても、その内容を固定の広告文のように扱いません。Google検索で実際にどの表示が選ばれるか、どの検索語で表示されるかは、testing toolの画面だけでは確認できません。testのpreviewは、公開前にmarkupが読めるpageの内容を点検するために使います。公開後に見るべきなのは、Search Consoleで見えるpageの状態と、実際に検索から来た人が必要な内容へ進めているかです。

説明用の仮例で、記事の冒頭に短い結論だけを書き、詳しい条件を通常pageだけに置いている場合を考えます。AMP pageのpreviewは簡潔に見えるかもしれません。しかし、検索からAMP pageへ来た人が条件を確認できず、通常pageへのlinkも見つけられなければ、内容は完結しません。previewを整える作業は、短く切り取られた表示だけを直す作業ではなく、検索後に読むpageの案内をそろえる作業でもあります。

修正の順番を逆にしない

検索結果の見た目を先に整えようとして、AMP markupの問題を後回しにすると、どこで止まっているか分かりにくくなります。修正は次の順に進めます。

1. AMP testing toolでmarkupとstructured dataを確認する。
2. 問題があればsourceまたはtemplateを直す。
3. 同じURLをもう一度検査する。
4. previewが表示される場合は、意図した内容と合っているかを確認する。
5. 公開後はSearch Consoleのreportでpageの状態を確認する。

たとえば、templateの見出し出力を直したなら、一記事だけを再検査して終わりにしません。同じtemplateから出る代表pageも確認します。個別記事のtitleを直したなら、同じ問題がほかの記事にあるとは限りません。修正した場所に応じて、再検査する範囲を変えます。

修正前と修正後を比べるときは、同じURLで行います。別の記事を検査して有効になっても、元のURLの問題が直った証明にはなりません。templateを替えた場合は、問題が出たURL、画像がないURL、長いtitleのURLなど、条件の違うpageを選びます。個別の入力を直した場合は、記事の保存内容とAMP pageの出力が一致するかを確認します。修正した場所と確認するURLを対応させると、再検査の漏れを減らせます。

制作を依頼するときは、previewのスクリーンショットだけを渡して終わらせません。検査したURL、testの結果、直したい内容、共通templateを直してよいか、確認を担当する人を渡します。検索結果の見た目だけを求める依頼では、本文やmarkupを変えてよい範囲が分からず、必要な情報まで削られることがあります。依頼する作業と、公開後の掲載確認を誰が行うかを分けます。

掲載を急ぐあまり、previewに合わせて本文の意味を変える必要はありません。商品やサービスの条件、対応できる範囲、問い合わせの入口は、読者が判断するための情報です。previewで見えにくいからといって本文から外せば、検索後のpageは弱くなります。まずmarkupを有効にし、読者へ伝える内容をそろえ、その後に公開後の状態を確認する順番を守ります。

最初の一手は、AMP pageを一つ選びます。markupの検査結果、previewの表示、公開後の掲載状況を別の欄へ記録します。見え方を確認できても、掲載状況まで確認したことにはなりません。