• AMP pageは速さのために本文を減らさずcanonical pageと同じ判断材料を残す

AMP pageは速さのために本文を減らさずcanonical pageと同じ判断材料を残す

公開日: 執筆:佐藤

AMP pageを作るなら、表示を速くするために、読者の判断に必要な本文や条件まで減らしません。canonical pageとAMP pageは、同じ記事やserviceを伝える二つの入口です。片方にだけ価格、対象、申し込み方法、本文の結論があれば、検索から来た人は内容を読み直すためにもう一度移動します。速さと情報量を引き換えにしないことが先です。

Googleは11月16日、検索でAMPとして扱うpageについて、AMP pageの内容が元のcanonical pageと近い内容であることを求める方針を案内しました。重要な内容が一致しないAMP pageは、AMPを必要とする検索機能の対象にならない場合があります。AMPは検索順位を直接変えるsignalではないとも説明されています。AMPを作る目的を検索の見た目だけに置かず、読者がどちらのpageを開いても同じ判断をできるようにします。

短くしてよい部分と残すべき内容を分ける

AMPではlayoutやscriptの扱いが通常のpageと違います。しかし、技術上の制約を理由に、記事の結論やserviceの条件を省いてよいわけではありません。短くできるのは、同じ説明の繰り返し、読者の判断に関係しない飾り、pageを開いてから出す必要のない要素です。残すべきなのは、何を提供するか、誰が対象か、費用や期間に条件があるか、次にどこへ進むかです。

仮に、serviceの説明pageをAMPでも出す場合を考えます。通常のpageに料金の範囲、対応地域、問い合わせformへのlinkがあるなら、AMP pageにも同じ判断ができる情報を置きます。AMPではformを省き、通常pageへのlinkだけを置く判断もあります。その場合でも、何を問い合わせられるのか、どこへ進むのかを読めるようにします。これは実在siteの構成ではなく、比較する箇所を示す仮例です。

二つのpageを比べるときは、文字数だけを数えません。見出し、本文の結論、画像の説明、価格や条件、著者や会社名、問い合わせ先、関連記事へのlinkを並べます。AMP pageに画像が少ないこと自体は問題ではありません。しかし、画像にしか書いていない条件があるなら、読者が内容を理解するための材料が欠けます。画像を軽くする作業と、説明をなくす作業を同じにしません。

比べるもの canonical page AMP pageで確認すること
本文の結論 読者へ最初に伝える答え 同じ結論を読めるか
条件 価格、対象、期間、例外 判断に必要な条件が残るか
次の行動 問い合わせ、購入、関連記事 読者が進む先を選べるか
更新情報 変更日と更新した内容 古い案内だけが残っていないか

pageを作る人と内容を確認する人を分ける

AMPのtemplateを作る人は、表示速度、画像、markup、errorを確認します。一方、事業者や内容の担当者は、価格、受付条件、在庫、連絡先、文章の意味を確認します。どちらかだけが確認すると、技術的にはvalidでも、読者へ必要な案内が足りないpageになります。AMPの実装を委託しても、公開する説明の責任まで委託先だけへ渡しません。

更新の手順も二つのpageを一組として扱います。canonical pageの本文を直したら、AMP pageも同じ日に確認します。AMP templateを直したら、通常pageで示している条件が抜けていないかを見ます。片方だけを更新する状態が続くと、どちらが正しい案内なのか、社内でも分からなくなります。作業の速さより、更新の正本と確認するURLを明確にする方が先です。

articleを増やすsiteでは、templateだけでなく個別の入力内容も比べます。短い記事、長い記事、表を含む記事、画像に説明を付けた記事を一つずつ選びます。すべて同じtemplateから出力されていても、見出しが長い記事や画像が多い記事では、省かれる箇所が変わることがあります。pageの型と入力内容の両方を確認してから、AMPの公開範囲を広げます。

広告や計測tagも、速さを理由に無条件で消したり足したりしません。AMP pageへ必要な計測を置くなら、通常pageと何を同じに数え、何が別の閲覧なのかを決めます。本文が同じでも、URL、計測の設定、広告の表示まで同じ意味になるとは限りません。表示を速くする変更と、数字の意味を保つ変更を分けて記録します。

修正後には、AMP testing toolでpageを確認し、実際の公開URLも開きます。toolでerrorが出ないことは、読者が内容を理解できることの確認とは別です。検索結果、testの画面、公開pageは役割が違います。toolはtechnicalな問題を見つけるために使い、公開pageでは本文、条件、link、問い合わせ先を読むために使います。

teaser pageにして読者を二度動かさない

Googleの案内は、短い概要だけを載せ、続きのためにもう一度clickさせるAMP pageを悪い体験の例として挙げています。途中まで読ませて通常pageへ移動させる構成は、PVを増やすように見えても、読者の手間を増やします。読者が必要な内容をAMP pageで読めるようにし、通常pageへ移る理由は、詳細な操作、会員向けの機能、購入や問い合わせの手続きのように、別の役割へ限ります。

記事の場合は、結論だけでなく、その結論になる条件と例外をAMP pageへ残します。service pageの場合は、魅力的な見出しだけでなく、対象外の条件や連絡方法も残します。短いpageを作ることは悪くありません。ただし、別pageへ誘導するためだけに要点を抜くなら、AMPの速さを読者の理解へつなげられません。

最初の一手は、canonical pageとAMP pageを一組選び、読者が判断に使う情報を五つ並べることです。その五つが両方のpageで読めるなら、表示の違いがあっても案内の目的は保ちやすくなります。AMPは本文の要点を隠すための短縮版ではありません。読者が早く開き、同じ内容を確かめられるようにするためのpageです。

戻る