AMP pageは公開前にSearch ConsoleのAMP testing toolでmarkupを確認する

AMP pageを公開する前に、Search ConsoleのAMP testing toolでURLごとのmarkupを確認します。ブラウザーで表示できることと、GooglebotがAMPとして有効に読めることは別です。このtoolは実際のGooglebotでAMP markupとstructured dataを検査し、問題があればsourceの該当行を示します。公開前に一ページずつ確認すると、入力の問題とtemplateの問題を分けられます。

testで有効と出たことは、検索結果での表示や流入を約束するものではありません。ここで確かめるのは、AMPとして必要なmarkupが読めるかどうかです。検索結果の見え方、通常ページとの内容、広告やフォームの導線は、それぞれ別に確認します。

AMP pageの確認を、通常pageの表示確認だけで済ませることもできません。通常pageのheaderやfooterにある案内がAMP pageで抜ける場合があります。本文が読めても、問い合わせ先、料金の条件、次に読むpageへのlinkがなければ、検索から来た人は判断を続けられません。AMP用の出力を軽くすることと、必要な情報まで削ることは別です。検査toolの結果と、実際に読める内容を並べて見ます。

逆に、AMP pageへ通常pageと同じすべての仕組みを無理に持ち込む必要もありません。動かないscriptや複雑な入力画面をそのまま再現しようとすると、markupの問題だけでなく、利用者の操作も不安定になります。AMP pageで何を読んでもらい、どのpageまたは連絡先へ進んでもらうかを決めます。通常pageへ戻るlinkを置くなら、そのlinkが読者に分かる位置にあるかを確認します。

一ページの検査と共通templateの修正を分ける

説明用の仮例として、WordPressの記事templateからAMP pageを出す場合を考えます。一記事だけで画像や見出しが崩れていれば、まずその記事に入力した内容を確認します。同じ種類の記事で同じ行の問題が出るなら、記事を一件ずつ直す前にtemplateを確認します。URL単位のtestは、全体を直したことの証明ではなく、共通の原因を見つける入口です。

structured dataも同じです。一記事で必要な情報が足りないなら、記事の入力を確認します。すべての記事で同じ種類の問題が出るなら、templateがその情報を出していない可能性があります。個別のURLが有効になっただけで、同じtemplateから出るほかのページまで有効になったと考えません。

同じtemplateを使うpageでも、入力内容は同じではありません。画像がない記事、著者名が入っていない記事、短い本文だけの記事が混ざれば、代表pageだけの検査では拾えない問題があります。公開前に代表URLを選ぶときは、最も整った記事だけでなく、画像がないもの、長い見出しがあるもの、特殊なlinkを含むものも一つずつ含めます。templateの問題か入力条件の問題かを分けるには、違う条件のpageを比べる必要があります。

検査結果に示されたsource行を直すときは、どのfileからその部分が出ているかを確認します。WordPressでは、theme、plugin、本文のshortcode、AMP用の処理が同じHTMLへ関わることがあります。表示された行だけを削れば一時的に検査を通る場合でも、必要な画像や情報を消していれば目的を果たしません。何を出すためのmarkupなのかを確認してから、個別入力か共通templateかを直します。

修正前後で同じURLを検査する

検査は、問題を見つけるためだけではありません。直した結果が本当に変わったかを確かめるためにも使います。公開予定のURLを一つ選び、次の順で進めます。

1. 通常pageとAMP pageを開き、読める本文、画像、リンク先を比べる。
2. AMP testing toolでAMP markupとstructured dataを検査する。
3. 問題が出た場合は、表示されたsource行とURLを残す。
4. 問題を個別入力、共通template、structured dataの三つへ分ける。
5. 修正後に同じURLを再検査し、ほかの代表pageにも同じ問題がないか確認する。

検査結果のsnapshotは共有できます。制作担当へ依頼するときは、「AMPがだめだった」とだけ伝えません。検査したURL、問題の行、通常pageかtemplateか、修正後に再確認する人を渡します。修正する人がURLを開けず、問題を再現できない状態では、原因を探す時間だけが増えます。

依頼する内容には、修正してよい範囲も書きます。たとえば、記事一件の画像を直す依頼なのか、全記事に共通するtemplateを直す依頼なのかで、確認すべきpage数と公開時の影響が変わります。共通templateを直す場合は、AMP pageだけでなく、通常pageの表示にも影響しないかを確認します。制作作業を頼むことと、変更の範囲を決めることは別です。

検査を通ったURLは、確認した日と一緒に残します。再びtemplateを替えたとき、以前に有効だったpageが同じ状態とは限りません。新しい記事を公開するたびに全URLを一から調べる必要はありませんが、templateを変えたときは、代表pageをもう一度検査します。site全体の問題を一URLの合格で済ませず、変更の大きさに合わせて確認範囲を決めます。

エラーが出ない場合にも、公開を急がない方がよいことがあります。通常pageの本文とAMP pageの本文が大きく違う、問い合わせへ進むlinkがない、画像の説明が意味を失っているなら、markupだけが有効でも読者への案内は不足しています。検査toolは必要な確認の一つですが、公開判断を一つの表示に任せないようにします。

最初の一手は、公開予定のAMP pageを一つ選ぶことです。そのURLをtestし、出た問題を個別記事、template、structured dataへ分けます。ページが一つ有効になってから、同じ実装を広げる範囲を決めます。