WordPress サイト運営

WordPress プラグインでAMPページが全滅した話

投稿日:2017年10月28日 更新日:

プラグインを入れたらAMPページ全てにエラー(致命的)が出ました。自業自得というところもあるので、今回のことを教訓として忘れないように投稿にしておこうと思います。プラグインの場合、ページ全てに影響があるので、プラグインで失敗すると全滅するというわけですね。

amp-error

※本投稿は2017年10月時点の情報をもとにしています。

AMP(Accelerated Mobile Pages)ページが全滅した経緯

”トップへ戻るボタン”を付けたくなって、プラグインを入れたところから始まりました。

いくつかのプラグインを試して、「これだっ!」と思ってそのプラグインを適用しました。翌日からAMPページへのアクセスが激減し、翌々日にはほぼ0件になりました。ほぼ0件というのはおそらくは携帯の履歴に残っていたり、ブックマークしていた方のアクセスがあったりで0件というわけではなかっただけです。

ちなみにプラグイン確認していたのはこの投稿です。急いで、書き直しました。

原因となったプラグインとその兆候

原因となったプラグインはWPFront Scroll Topでした。

WPFront Scroll Topが悪いということではありません。”トップへ戻るボタン”を付与してくれるプラグイン5つの中から、WPFront Scroll Topが一番よかったので選んだぐらいです。

兆候もあったのです。全てのプラグインで一応AMPページ表示の確認もしていましたが、他のプラグインはボタン表示もされなかったのに対して、WPFront Scroll Topはボタンが表示されていました。ここで、JavaScriptまで組み込まれているとか、ボタンのイメージ表示にimgタグが使われているとかそこまで頭が回れば、AMPページが再クロールされる前に防げたはずだったのです。

Search Consoleに出たエラー

AMPのエラーはSearch ConsoleのAccelerated Mobile Pagesに出力されます。Search Consoleは即時反映ではないので、2、3日遅れて気づくことになります。

私の場合は、Search Consoleを”ほぼ”毎日みているのですが、今回は確認するのが若干遅れたような感じです。AMPページへのアクセスが無くなって、その後に「あっ!」と思って、Search Consoleを見たら大量のエラーがありました。

Search Consoleには2種類のエラーが出ていました。

  • 同等の AMP タグがある HTML タグの使用禁止(問題の重大性: 致命的)
  • ページにユーザー作成の JavaScript がある(問題の重大性: 致命的)

この致命的というエラーが出ているとGoogle検索でAMP表示が外れて、AMPページにアクセスが来なくなります。全AMPページにこれらのエラーが出ているので、AMP対応のサイトではなくなるということです。

残念ながらというか、Googleのクロールは優秀で、直ぐにこのエラーを発見し、当日全件というわけではありませんが、2、3日で7割~8割ぐらいのAMPページの評価が無くなった感じになりました。悪いことにクロールされる投稿というのはより参照数の多い投稿ですので、サイトのAMPページ対応の意味がほぼなくなることになります。

エラー出ている状態でもAMPページへのアクセスはできるのですが、AMPページの場合はGoogle検索結果に載らないと意味なくなるのです。

それぞれのエラー内容を見ていきます。

同等の AMP タグがある HTML タグの使用禁止

こちらの方は、ボタンが画像なので”imgタグが使われた”ことが原因となります。

imgタグはAMPでは許可されておらず、amp-imgタグを使わなければなりません。どうして、他のプラグインはimgタグの表示すら省かれて、WPFront Scroll Topがそれをすり抜けたのか理由はわかりません。

ページにユーザー作成の JavaScript がある

これは単純にWPFront Scroll TopのJavaScriptが挿入されたことが原因になります。

独自のJavaScriptの記載はAMPでは許可されていません。こちらもどうして、WPFront Scroll TopのJavaScriptだけが残ったのかは不明です。

今回の対応

残念ながらWPFront Scroll Topの使用を取りやめ、To Topに切り替えました。WPFront Scroll Topのオプションでどうにかならないかいくつか試しましたがダメでした。

そして、Search ConsoleのAccelerated Mobile Pagesに出ていたエラーページを1個1個対応していこうとしました。この1個1個の対応というのはAMPテストページでAMP対応確認を行い、”GOOGLEに送信”をすることです。

AMPテストページの”GOOGLEに送信”するというのは再クロールの役割を果たしていて、実際にどの程度で行われるかわかりませんが、これで復旧されます。

しかし、AMPテストページは使い続けると徐々にロボット対策のページ(車はどれか?とか標識はどれか?とか)のチェックが厳しくなっていきます。AMP確認で1セット、GOOGLEに送信で1セットやることになります。ひどいときは、この1セットの中で4回と確認させられるので、さすがに1ページずつ対応していくのは面倒になりました。結局、最初に出ていた20件をAMPテストページで確認&GOOGLEに送信して、他はアクセス数多いページだけ対応して放置としました。放置していても、AMPページの元URLがクロールされれば、そのタイミングで同AMPページのクロールも行われるはずです。

気づいてから、4日ぐらいでほぼエラー無い状態に戻せました。

今後の対応検討

結局のところ、プラグイン入れるたびにデベロッパーツールで確認するのは難しいと思うので、新しいプラグインを入れるときにはAMPテストページで確認するしかないなと思いました。

プラグインの種類によるかもしれませんが、1ページAMPテストページで確認するだけで、今回のようなことは発生しづらくなるのではないかと思っています。

今まで10以上適用したプラグインでは発生していなかったということでもあります。今回のようなケース自体がレアなのだと信じています。

まとめ

AMP対応が終わって、ようやく安定してきたなと思った矢先にえらい目にあいました。今後は注意してやっていこうと思います。

  • プラグインによってはAMPページに影響を与えるものがある
  • プラグインを入れたら”AMPテストページ”でテストした方が良い

AMPエラーが発生している間、理論的には通常のモバイルページが検索で表示されているはずなので、機会損失のようなことは発生していないはずなのですが、全体的なアクセスは結構下がりました。

理由は説明できないのですが、ひょっとしたらエラーの多いサイトとして認識されてしまったのかもしれません。

-WordPress, サイト運営
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

関連記事

komatta_man

WordPress ショートコードをエスケープする方法

ショートコードを使っているプラグインは結構あります。Table of Contents PlusやPz-LinkCardなどがそうです。さて、これらのショートコードを投稿に載せるときにどうしていますか…

もっと見る

matches

WordPress ウィジェット表示をコントロール Widget Logic

任意のウィジェットを携帯端末からのアクセスで表示させたくない場合はありませんか?私は結構あります。例えば、Popular Postsのランキングは携帯端末で表示すると今一つという感じがします。そこで”…

もっと見る

computer_mojibake

WordPress 日本語環境で必須のプラグイン WP Multibyte Patch

WordPress環境で「なぜか文字数が合わない、揃わない」なんて経験はありませんか?これは英語ベースで作られている環境の文字(シングルバイト)と日本語(ダブルバイト)の文字の違いから来るものです。こ…

もっと見る

portsoy

WordPress リンク切れチェック Broken Link Checker

「あ、このリンク切れてた」なんてことありませんか?この Broken Link Checker はそんなリンク切れをチェックしてくれるプラグインです。入れてあげるだけで、URLや画像に対するリンク切れ…

もっと見る

サイト内の検索はこちらから

サイト内の検索はこちらから

サイト内の検索はこちらから

カテゴリー

アーカイブ

最近の投稿

RSS icon