検索での見え方を定義するAMPと構造化データ

WordPressのAMP対応プラグイン「AMP」を導入

unprotected
HTTPS化されていないサイトを開いたとき表示される警告

2014年にGoogleが検索順位の評価にHTTPS化(常時SSL化または通信暗号化)の有無が影響すると発表してから、今ではChromeでHTTPS化していないサイトを開くとびっくりマーク付きで「保護されていないページです」と表示されるようになりましたが、これはサイト上の「お問い合わせフォーム」や「サイト内検索」などユーザーが入力した情報の保護だけでなく、HTTP通信上でのCookie(Webサイトがユーザーのブラウザを通じて訪問回数、ユーザーID、パスワードなどデータを書き込んで保存する仕組み)の改竄を防止するという点で妥当性がありました。

ただネット上に公開している限りセキュリティの問題は必ずついてまわるもので、家の玄関に南京錠だけをかけるのか電子ロックをつけるか、セコムと契約してセキュリティをより安全に確保するかは地域の環境、個人の経済状況、考え方によって違ってくるのと同じ様に、HTTPS化するかしないかもサイト運営者の判断であり、Chromeでも「保護されていない」という敢えて柔らかい表現が使われています。

現在のSEO関連の話題はサイトのモバイルフレンドリー化についての議論が多くなっており、WEBアクセスのスマホ比率が6割以上を占めるのが普通になった今、WordPressテーマがレスポンシブ化(PC、タブレット、スマホなど端末ごとに最適化されたデザイン)されているのは常識になり、去年2016年くらいからの話題の中心はAMP(Accelerated Mobile Pages)になっていましたが、訪問ユーザーの8割以上がPCという当サイトの状況から特にAMP対応の必要性も感じませんでした。

ただ世の中あまりにもエーエムピー、エーエムピーと騒がしいので、4月2日の深夜にAMPプラグインを導入してみたところ、Search Console上で「AMP ページが Google のガイドラインに準拠していないのでGoogle検索のAMP関連機能に表示されない」という理由で400個もAMPエラーが出てしまいました。

  1. プラグインAMPでAMP対応のページを生成しました。
  2. 出力された情報が標準ページと異なっている箇所があります。
  3. Googleでは標準ページとAMPページとのコンテンツは基本一致する必要があるのでエラー

というのがエラーの理由らしいので、AMP表示をカスタマイズするためのプラグインGlue for Yoast SEO & AMP(SEOプラグインYoast SEOのアドオンなので事前にこれもインストールが必要)の機能として、AMPページのメタデータを修正する機能があるということで、4月6日にインストールしたところエラー数が一気にV字下降し、4月18日にはとうとう0個になりました。

エーエムピー(AMP)対応は本当に必要なのか?

AMPは2016年頃から本格的に普及したばかりの新しい流れなので、技術的な仕様として何が正解か決まっておらず、現段階ではAMP対応したほうがいいサイトも必要ないサイトもあると思いますが、Googleによる「インターネット利用者の利便性を高める」という目的自体は明確です。

  1. スピード重視か個性重視か
    WordPressにプラグインAMPを導入すると、「投稿」のURLのうしろに「amp」を追加することで、HTMLタグやCSS、JavaScriptが制限されたAMP用のシンプルなページが高速で表示されますが、サイトの味とか個性とか一切無視したスピード重視が、本当にGoogleの目指すユーザーの利便性向上に合致するのか疑問が残るところです。
  2. 検索結果にどのような基準で通常のURLとAMP用URLが表示されるのか
    基本は検索結果としてPCからは通常のURLが表示され、スマホからはAMP用URLが優先的に表示されるということでしょうが、スマホユーザーが本当にAMPサイトを見たいか、またサイト運営者がAMPサイトを見せたいかという問題があります。
  3. Google上でのカルーセル表示はいつまでつづくのか
    SEOの観点からサイトをAMP対応する場合のメリットは、スマホ上でのGoogle検索結果のカルーセル(サイトのトップに画像を大きく横並びにして視覚に訴えるデザイン)に表示されることが挙げられるようですが、検索順位の評価方法自体が変化し続けているGoogleのカルーセル表示という仕様が、この先変更になる可能性もあります。

HTML内の情報に意味を持たせ検索エンジンに伝える構造化データ

ところが今度は構造化データのエラーが300件超まで爆増しており、もともと3月25日はWordPressのテーマを変更した日であり、この日を境に180個ほど出現した構造化エラーに加えて、AMP対応した4月2日以降に新たに100個ほど増加しており、原因はこのテーマのどこかで使っているmicroformatsという構造化データのボキャブラリー(タグのライブラリー)の中にあるhentryというのが問題を起こしているようです。
structure_error

新しいテーマは検索結果にリッチスニペット(パンくずリストや写真・画像、レビュー・評価などの追加情報)を表示させるために構造化データのボキャブラリーとしてmicroformatsとdata-vocabularyとschemaという3つを使っており、今回爆増しているエラーはそのうちのmicroformatsのhentryというマークアップ(クラス)がらみばかりです。error

エラーはすべて個別投稿で発生しており、どこかの部分でhentryという構造化データ使おうとしているわけですが、一方的に「authorがありません」「entry-titleがありません」「updatedがありません」と怒られており、「entry-titleとupdatedはあるがauthorがない」エラーの元となる構造化データは以下のように出力されていました。

error
hentryを使っているのにauthorを送信していない

Codexによるとテンプレートタグpost_classでは自動的にhentryクラスをつけて出力するようです。

post_class() が出力する CSS クラスは、投稿が表示されているページの種類(概ね、条件分岐タグに対応)に応じて決まります。

  • フロントページ
    投稿がブログのフロントページにある場合(固定でもそうでなくても):post post-(投稿 ID) hentry
  • 単一の投稿
    単一投稿のページを表示しているとき:post post-(投稿 ID) hentry

テンプレートタグpost_classが使われているのはsingle.php、archive.php、search.php、index.phpの4つなので、すべてに対して記事の著作者を含むタグ、タイトルを含む見出しタグ、更新日を含むタグの情報を追加する必要があります。

ただし自分の場合どうもエラーがうまく消えないので結局子テーマのfunctions.phpに以下のフィルターフックを追加しhentryクラス自体を消してしまいました。

WordPressのプラグインHatom/hentry remover (Fixes errors in Google Webmaster Tools)で同じ様にhentryクラスを消すこともできるようですが、今後出てくる新しいテーマは構造化データのボキャブラリ関連のエラーは出ないと思いますのでこれも一時的な対処になります。

4月22日に修整後、構造化エラー数は下がり続けており、クローラーの巡回周期にもよりますがすべて解消されるにはしばらく時間がかかると思われます。

こんな投稿も読まれています