衝撃の試算! ECサイトをAMP対応するだけでアクセス数110%・CV率120%になる!?【SEO記事12本まとめ】

今週のピックアップ

衝撃の試算! ECサイトをAMP対応するだけでアクセス数110%・CV率120%になる!?
予測モデルだがスゴイ （Google Developers Japan） 国内情報

illustration by つきのあめだま

ECサイトをAMP対応すると、売上はどれぐらい増えるのか？

グーグルは、AMP対応しているウェブ会社4社への聞き取り調査をもとに、AMP実装後3年間で得られる結果を予測するモデルを作成した。大手のリサーチ／コンサルティング会社のForrester Consultingに依頼して進めたプロジェクトだ。

月間400万件のアクセス10%の利幅があるECサイトを想定すると、次のような予測が出たとのことだ。

• 6か月以内に AMP 実装の費用を取り戻し、黒字となり始める
• 販売コンバージョン率が 20% 増加
• AMP サイトのトラフィックが前年比 10% の増加
• 訪問 1 回あたりの参照ページ数が 60% 増加
• 合計 210,827 ドルの投資に対して 3 年間で 1,005,447 ドルの利益が見込め、377% の ROI を達成

この予測の精度が高いとしたら、かなりの効果だ。

うまくでき過ぎている気がしないわけでもないが、モバイル利用が劇的に多くなっている現在、検索結果ページ上部での露出や表示速度改善によるUX向上をふくめると、あながちおかしな試算だとも思えない。

また、この効果は広告出稿によって得るものではないため、追加の費用なしに永続的に続く点も強い（グーグルのアルゴリズムやユーザー行動が変わらない限り）。

AMPは今やECサイトでも立派に利用できるテクノロジーになったことは間違いない。AMPが見事にはまれば、こうした結果に実際なるのかもしれない。

グーグル検索SEO情報

MFI情報をドイツからお届け
移行通知がSCに届くらしい （サイバーエージェントSEO情報ブログ） 国内情報

SEO関連のカンファレンス「SMX」がドイツのミュンヘンで3月21日～22日に開催された。日本から参加していたサイバーエージェントの木村氏が、グーグルのジョン・ミューラー氏のセッションをレポートしている。

モバイルファーストインデックス（MFI）に関する情報が中心だ。すでに明らかになっている情報が主だが、確認のために一読しておくといい。

ちなみにその後にグーグルは、MFIへの移行開始を正式に発表している。木村氏がレポートしているように、ウェブサイトをモバイルファーストインデックスに移行する際に、Search Consoleに通知が届くことも正式に発表された。

グーグルの公式情報と、Web担編集部コラムでの解説を紹介しておくので、あわせてチェックしてほしい。

• モバイル ファースト インデックスを開始します（Google ウェブマスター向け公式ブログ）
• グーグルがMFIへの切り替えを正式に開始！ 準備ができたサイトから順次。SCへの通知も（Web担編集部コラム）

「AMPストーリー」をグーグルが発表、ビジュアルに訴えるAMPの新たな形
視覚指向のフォーマットを簡単に作成 （Google Developers Japan） 国内情報

AMPの新しい機能「AMP Story（AMPストーリー）」をグーグルが発表した。

ストーリーとは、あたかも本をパラパラとめくるようにして物語風に一連の情報を閲覧できる仕組みだ。文字ではなく、画像や動画をふんだんに使ったビジュアルさに特徴がある。

いくつかのパブリッシャーが試験運用に参加している。g.co/ampstories にアクセスすると試験用のGoogle検索が表示されるので（※スマホまたはモバイル端末をエミュレートしたブラウザで閲覧のこと）、ふだんのように「CNN」や「The Washington Post」で検索してほしい。カルーセル形式で掲載されるAMPストーリーを体験できる。

インスタグラムやフェイスブック、スナップチャットにも「ストーリー」があって人気だが、AMPのストーリーはそれらのように24時間で消えるというものではない。あくまでも「ストーリーを伝えるためのAMP技術」だ。

AMPストーリーがほかのサービスと決定的に異なるのは、HTML（AMP HTML）で作成できるオープンな規格であることだ。専用のアプリだけで再生できるのはなく、アプリのインストールは不要でブラウザがあればどんな端末でも再生できる。

詳しいことは公式アナウンスとチュートリアル、ドキュメントを参照してほしい。

過去のURLが原因の404エラーにはどう対処すべき？
アクセスもリンクもなければ対処不要、それ以外は…… （SEO Snippets） 海外情報

グーグルのジョン・ミューラー氏がシリーズ配信しているショートQ&A動画が1本新たに公開された。

今回取り上げられたのはこんな質問だ。

Search Consoleに404クロールエラーがレポートされています。

でもそれは、かなり昔の時代に使っていたページが原因で、いまそのURLは使っていません。

こうした404エラーには、どのように対処すべきでしょうか？

ミューラー氏は次のように説明した。

サイトを長く運営していると、サイト内のページのURLを変えることがある。

ウェブサイトのURL構造を変えるときは、私たちは次のようにすることを推奨している。

• 古いURLを新しいURLをにリダイレクトする
• 古いURLに向いているリンクを新しいURLに直接向くように更新する

しかしながら、メンテナンスに手間がかかったり、単純に忘れてしまったりして、時間がたつとリダイレクトをなくしてしまう場合がある。

すると、古いURLへのアクセスに対してWebサーバーは404を返すことになり、Search ConsoleでそのURLがクロールエラーとして記録されるというわけだ。

無効なURLにアクセスがあった場合に「404 ページが見つかりませんでした」のエラーをWebサーバーが返すのは、正しい動作だ。

では、どう対処すればいいのだろうか？

まず、アクセス解析ツールやWebサーバーログファイルを使って、404を返しているURLにトラフィックがあるかどうかを調査する。もしトラフィックがないなら、何も気にしなくていい。

次に、そうしたURLに張られているリンクがないか調査する。Search Consoleの［検索トラフィック］にある［内部リンク］や［サイトへのリンク］を使うといいだろう。404を返す古いURLへのリンクが何もないなら、何も気にしなくていい。

トラフィックとリンクのどちらかに特別何も問題がなければ、古いURLがが404を返していいても、まったく問題なしだ。

そもそもSearch Consoleのクロールエラーで示される404エラーは、基本的に気にしないでいい。しかし、上記の調査でトラフィックやリンクが見つかった場合はどうだろう。

もし、404を返している古いURLに対してトラフィックやリンクがあるようならば、対処するほうがいいだろう。

具体的には、そのトラフィックやリンクがどこから来ているのかを調べて、代わりに新しいURLに向くようにする。

あるいは、そうしたURLにトラフィックやリンクがたくさんあるなら、元のようにURLを戻したほうがより効果的かもしれない。

このような対処は、クロールエラーが出ているURLが少ない場合には適しているだろうが、そうしたURLが大量にある場合には、1つず確認していられない。どうすればいいのだろうか？

Search Consoleを使えば簡単だ。Search Consoleはクロールエラーを優先順位付けして表示してくれている。つまり、上に表示されているもののほうが、対処の優先度が高いとグーグルが判断しているものだ。

先頭に来ているエラーが気にしなくていいものであれば、リストのそれより下には、もっと重大なエラーはないはずだ。安心していい。

インデックスさせたくない404ページに対するクロールエラーは、検索においてはほかのページに悪影響を与えることはない。なので、自分にとって有益な別のことに時間を使ってほしい。

ポイントをまとめると次のようになる。

• アクセスもないしリンクもないURLの404には対処不要
• たくさんのアクセスがあったりたくさんのリンクが張られたりしているURLが404を返すようならば、対処が必要（新しいURLにリダイレクトするなど）
• Search Consoleのクロールエラーレポートは重要度順に並んでいる。前のほうに表示されているのが大切なURLなので、上から確認していって、放っておいても問題がないページが出てきたら、それ以上は気にしなくていい
• 問題のない404は検索に悪い影響を与えない

Googlebotのrobots.txtはキャッシュされている、更新は1日1回
強制更新はrobots.txtテスターから （Reddit） 海外情報

「robots.txt」は、サイトに自動アクセスして情報を取得していくGooglebotのようなプログラムに対して、そのサイト内での動きを制御する指示を書いてあるテキストファイルだ。Web担当者が作成してサイトにアップロードしておく。

GooglebotがURLをクロールするときは、そのサイトのrobots.txtを参照する。いまからクロールしようとしているURLに対するクロールが禁止されていないかを確認するためだ。

もしクロールが禁止されているURLであれば、Googlebotはクロールしないというわけだ。

ただし、ここで1つ注意点がある。

「クロールするときにrobots.txtを確認する」といっても、1つのURLにアクセスしようとするたびにrobots.txtを確認するわけではないという点だ。robots.txtを何度も確認しなくてもいいように、Googleはrobots.txtの内容をキャッシュしている。

そうすることで効率的にクロールを進められるのだ。

しかしこれは、robots.txtの取得のタイミングによっては、最新のrobots.txtがクロールに反映されない可能性があるということを意味する。

Googlebotの場合、いったん対象Webサーバーからrobots.txtを取得したら、次にrobots.txtをとりにいくのはだいたい1日後だ。

ということは、Googlebotがrobots.txtを取得した直後にrobots.txtの内容を変更しても、Googlebotは1日ほど古いrobots.txtの内容に基づいて動くということだ。つまりその間は、新しいクローラーへの指示は反映されない。

では、クロールされるとまずいURLへのクロールをブロックするといった「すぐにクロールの動作に反映してもらわないと困る」変更をrobots.txtに加えた場合にも、同様に1日待つしかないのだろうか？

実はそうした場合に使える方法がある。

robots.txtの変更を直ちにクロールに反映させたい場合は、Search Consoleの［クロール］＞［robots.txtテスター］を利用する。

この画面で送信ボタンをクリックする。

また、この画面ではGoogleに現在認識されているrobots.txtを確認することもできる。

すると、次のような画面が表示されるので、「Google に更新をリクエスト」を実行（送信）する。

このコラムで数回伝えたことがある仕組みだが、確認のために再び取り上げた。