CyberAgent SEO Information  (サイバーエージェントSEO情報ブログ)

サイバーエージェントSEOグローバルイノベーションプロジェクト(SGIP)です。当ブログでは、皆様がウェブサイトを運営するにあたって必要となるSEOに関する情報をご提供して参ります。


テーマ:

久しぶりの更新になってしまいました。

その間に色々なことがありましたが、私ごとですが、 SEOラボなるものを立ち上げました。

https://www.cyberagent.co.jp/newsinfo/info/detail/id=12969

SEOラボで研究により一層力を入れるとともに、アメブロのSEOについても引き続き担当しております。

 

そのアメブロのSEOの一環として、近づいているMobile First Index(モバイルファーストインデックス;MFI)への準備を行いましたので、今回はその準備内容とその結果について書きたいと思います。
なお、この対応はアメブロに適した方法と考えて行ったものであり、すべてのウェブサイトやブログ等にあてはまるとは限りませんのでご注意ください。

 

1,モバイルファーストインデックスとは

モバイルファーストインデックスとは、Googleがこれまでデスクトップ(PC)サイトをインデックスした情報を主として評価していたものをモバイル(SP)サイトを主として評価するように変わることです。
これまではPCの評価結果がそのままSPの評価に反映されていたものが、SPの評価結果がPCに反映される形になります。

モバイルファーストインデックスがくると、モバイルサイトをメインとして評価するため、これまでPCサイトだけを検索エンジンフレンドリーにし、SPサイトでは意識していなかった場合には検索順位に悪影響が出る可能性があります。

例えば、モバイルサイトで正確にレンダリングできていないケースや、モバイルサイトをPCサイトに比べてコンテンツを少なくしているケースなどはそのリスクがあります。

一方で、レスポンシブウェブデザインを導入しているサイトはほとんどモバイルファーストインデックスにおいてのリスクはないと考えられます。

Googleがこれまで推奨してきた、ウェブサイトのスマートフォンへの対応方法は ・レスポンシブウェブデザイン ・ダイナミックサービング ・セパレート の3方式です。

 

1,レスポンシブウェブデザインとは、同じURLで同じHTMLを用いてCSS等で各デバイスに最適化されたデザインで露出することです。同じHTMLを使うため基本的に各デバイスで同じコンテンツが表示されることになります。

2,ダイナミックサービングとは、同じURLで異なるHTMLを用いて各デバイスに配信するものです。異なるHTMLを使用するため異なるコンテンツを表示することが可能です。PCに比べてSPサイトのコンテンツ量を減らしている場合にこの方法が用いられているケースがあります。

3,セパレートとは、異なるURLで異なるHTMLで配信するものです。サブドメインやサブディレクトリでPCサイトとSPサイトを分けているケースが一般的です。

 

モバイルファーストインデックスにおいては、PCとSPで内容がほとんど変わることがないレスポンシブウェブデザインはリスクが少ないとされる一方で、ダイナミックサービングやセパレートのように異なるHTMLを配信している場合は、そもそもこれまでとコンテンツが異なるためPCベースで評価がなされていたときとは、異なる評価がなされる可能性があると考えられます。

一般的に異なるPCとSPで異なるコンテンツを返している場合、PCに比べてSPのほうがコンテンツを少なくしているケースが多いため、モバイルファーストインデックスが導入されるとダイナミックサービングやセパレートでは評価が下がる可能性があると言われています。

当初危惧されていた、SPサイトは通常PCサイトに比べてサイト内リンクが少ないためクローラーがURLを発見できないのではないか?という問題については、PubSubHubbubやsitemapによってほぼ解決ができそうですし、SPでよくある、アコーディオンメニューやタブ形式のコンテンツなどはスマートフォンユーザーへのUXのために使用しているものであれば基本的に問題ないということをGoogleは発言していますので、コンテンツの問題以外ではさほど大きなリスクはないかもしれません。

しかしながら、アメブロにおいては「3」のセパレート方式であったということと、規模が大きく予想できない不具合が起きることを避けたいということからモバイルファーストインデックスについて事前にリスク回避できることはリスク回避しておくことにしました。

2,アメブロにおいてモバイルファーストインデックスで考慮したリスクと対応方針

先述の通り、アメブロはセパレートURLでした。

 

PCサイトは、"ameblo.jp/ID"

SPサイトは、"s.ameblo.jp/ID"

 

となっており、

"s."というサブドメインでPCとSPのURLが異なるものとなっていました。

アメブロの仕組みは複雑であり、またPCとSPが常時同じコンテンツであることがUX上必ずしも最適であると考えなかったことから、今回レスポンシブデザインを採用することは見送りました。

一方で、URLが分かれていることについては下記のようなリスクを想定しました。Googleが問題ないと断言しているものも含まれており、"万一Googleにバグが起こったら"ということを考慮しました。 また、正規化の属性を万一運用上のミスで抜いてしまった場合などもあわせて考えました。

 

1,セパレートの場合、通常のalternate,canonicalの関係が逆になることが気持ち悪い

PC URL --- alternate ---->  SP URL

PC URL <-- canonical -----  SP URL

となるわけですが、今回評価として「正」となるのは、alternateが向けられているSP側であり、canonicalが向けられているつまりはHTML上で正規と示しているPCではありません。Googleは特別な処理を入れるので問題ないということでしたが、万一短期的でもこの処理にバグが起こったら・・・ということをリスクとして考えました。

2,リンクの力が正常に統合されるのかどうか?

万一、セパレートの場合にリンクの力が分散もしくは数%であっても分散してしまようなことがあったら・・・というリスクを回避したかったということがありました。

これはモバイルファーストインデックスに限ったことではありませんが、万一にもうまく処理されなかったら・・・ということを考えました。

3,URLが重複してインデックスされてしまったら

運用ミスによってcanonicalやalternateを記述するのを忘れてしまったり、万一Googleが正規化をうまくできずにPCとSPのURLを重複してインデックスしてしまった場合、重複コンテンツとして見られてしまうリスクを考慮しました。

4,そもそもなぜ別URLなのか?

アメブロは芸能人の方にも使っていただているため、紙媒体などにもURLを記述していただくことがあります。このときに、まれに"s.ameblo.jp"側を記載していただいていることがあります。

TwitterやFacebookなどのソーシャルメディアなどでも"s.ameblo.jp"からはじまるSP URLを引用していただいているケースが多々あり、それを見るたびに多少違和感を感じていたのも事実でした。(もちろんPCでアクセスしてもリダイレクトされるわけですが・・・・)

記事本文以外は多少コンテンツが異なるものはあるものの、基本同じものが配信されているにも関わらず別のURLである必要はないと考えました。

あわせて、上記「3」にも記載したように、運用のミスが起こりやすかったり、やや大きな改修をするたびに、title,meta,alternate,canonicalの関係性をチェックしなければいけないという工数的な問題があったりと運用上の問題もありました。

 

上記から、 ・URLはSPとPCで統一して、"ameblo.jp"とする ・記事本文はデバイス間で差はないが、ナビゲーションや広告枠、各ブログトップページに差異をつけたかったことからSPとPCでは別のHTMLを配信する という"ダイナミックサービング"を採用することにしました。

 

3,行った社内調整

ブログチーム、SEOチームとの合意は案外すんなりといきました。リスクに対して可能な限り対応しておこうということ以外に選択肢はなかったためです。ただし、ここから弊社ならではの社内調整が必要になりました。

Amebaはアメブロ以外にも様々なサービスがあり連携しあっている部分があります。また、表示されている広告の一部は社内独自のアドネットワークです。そのほかアメブロにはアプリもあります。これら連携しているサービス類にはURLを参照してごにょごにょしているものもあったため関係各所に影響の確認と、影響がある場合には対応のお願いをしていきました。想定していたよりは少なかったものの、いくつかのサービスでは仕様変更が発生しました。

ただ、ここでははじめから"相談"ではなく「MFI対応のためSPのURL変えるから影響でるならそちらも変えてね」という"お願い"の形でのぞんでいたので、特段大きな問題は発生しませんでした。

モバイルファーストインデックス発表後、関係がありそうなチーム(計測、広告等含む)との調整を約1週間程度で行ったうえでいよいよモバイルファーストインデックスのためのURL統合作業に入っていきました。

4,実際に行った作業

アメブロはすでに10年以上運用しているサービスであることから、この統合作業も若干複雑になりました。詳細は割愛しますが、

1,SPで"ameblo.jp"でも表示できるようにする

まずは、これまで"ameblo.jp"にSPのUserAgentでアクセスがあった場合は、"s.ameblo.jp"にリダイレクトしていたわけですが、

これを"s.ameblo.jp"と同じコンテンツを"ameblo.jp"で表示できる

ようにしました。

この時点で"ameblo.jp"から"s.ameblo.jp"へのalternateを外し、"s.ameblo.jp"から"ameblo.jp"のcanoincalを残しています。

2,"s.ameblo.jp"から"ameblo.jp"にリダイレクトする

じつは「1」が終わった時点でジリジリと"s.ameblo.jp"のトラフィックは減っていき、"ameblo.jp"のトラフィックが増えていき順調に移行されている様子でした。 が、今回は"URL統合"が目標なのでここからURLを一本化していきます。

12/8(木)の18:00頃に「1」を実施し、クロールの状況にも内部の状況にも問題がないこともわかったため12/13(火)には"s.ameblo.jp"へのアクセスは"ameblo.jp"へリダイレクトさせるようにしました。

 

一部SPにしか存在していないURL群もあるため、これらはまだ"s.ameblo.jp"が残っていますが、大半のURLは無事に統合されました。

モバイルファーストインデックスの発表があってから実質1ヶ月半でこの大規模サイトのURL統合を行えたのは個人的もやや驚きました。

5,統合した結果

"モバイルファーストインデックスがまだ導入されていない段階として"ということにはなりますが、特に問題はありませんでした。スマートフォンで検索した際にインデックスされているURLも概ね入れ替わり狙った通りになっています。

アクセス数

PCとSPを合計したトラフィックには変化なし。あわよくばドカンと上がらないかな?とほんのわずかに期待していましたが、さすがにそうはなりませんでした(笑) それでも、一時的にはダウンする可能性もあるかもしれないと心配はしていましたので、それは起こらず安堵しました。

 

(s.ameblo.jpの10月半ばからの検索トラフィック数)

(ameblo.jpの10月半ばからの検索トラフィック数)

インデックス数

canonicalや301でのリダイレクトをしたからといって、インデックス数がみるみる減っていくということはないようで徐々に減っているという感じです。

(s.ameblo.jpのindex数)

クロール量

クローラーが"ameblo.jp"に一気におしよせてリソースを圧迫し、レスポンスが悪くなることで評価が下がる可能性は多少考えていました。

が、"s.ameblo.jp"へのクロールがきれいに減っていく一方で、"ameblo.jp"へのクロールは特に変わりませんでした。

「少しくらい増えてくれてもいいのに・・・」とは思いましたが・・・。

(ameblo.jpのクロール量)

 

結果として現時点では「何も変わっていない」という状況です。これは我々にとってはポジティブで、大規模サイトのため少しの変更で大きく数値が落ちることもあるため数値が下がらなかったことはある意味で最良の結果でした。

6,反省点と今後について

今回はモバイルファーストインデックスへの対応を目的に動いたので、あくまでモバイルファーストインデックスが導入されたときにネガティブにならないことを目的としていました。

が、かなり大きな仕様変更を行ったことからいろいろなところに手を入れたわけで、ひょっとしたらそこで同時にできるSEOの施策がほかにあったのではないだろうか?というのは個人的な反省です。

モバイルファーストインデックスに気をとられすぎて俯瞰して見られなかったなあとは思います。 一方で、この規模のサービスの非常に大きな仕様変更を短期間でできたことは、手前味噌ながら結構すごかったのではないかと。

意思決定に1日 → 社内調整に5日 → 施行に約40日

とくにブログのエンジニアチームには迷惑かけましたが、このスピードでやりきってくれたことは感謝しています。内輪ネタで恐縮ですが。

 

今後は、いよいよモバイルファーストインデックスが到来するわけですが、そのときに本当にマイナスにならないのかは注意深く見守っていきたいと思います。 また、もう少し時間があるわけなので、"コンテンツレベル"でのリスクがないかを再確認していきたいと思っています。実際にモバイルファーストインデックスが導入された際には再度ご報告できればと思います。

 

木村 賢

いいね!した人  |  リブログ(0)

テーマ:
アメブロがAMP対応してからしばらくが経ちました。

今回はその"AMP"に対応した結果どうなったのか?
という、効果について簡単に書きたいと思います。

ここ最近ブロガーさん向けの記事が多かったので、今日は珍しくSEOネタっぽいやつです。

さて、アメブロでは3/10より順次AMP対応しています。
スマートフォンでGoogle検索をした際に、

ユニクロ検索結果

このような表示がされることがあります。
これは実際に「ユニクロ」で検索した結果の一部です。

このマーク
AMPロゴ
が表示されているものはAMP対応となり、

AMPページ
このように簡易的なページが表示されます。

AMPページはGoogleからの検索の場合はGoogle側にキャッシュされる形になることもあり、
いろいろな制約があります。
例えば、
・広告の掲載に制約がある
・画像の使い方に規則がある
・使えるHTMLタグに制約がある
などです。

HTMLタグなどは、AMPページを作る段階で注意すべきことなのでよいと思いますが、
我々としてもAMP対応するにあたり広告の掲載に制約がある点は懸念事項でもありました。

ご存知の通り我々のような"メディア"は基本広告料で成り立っています。
その広告収益が減ることは死活問題であり、AMP導入に関しては(弊社にしては珍しく)慎重な意見も出ました。
広告収益を減らさないためには、

・PVやトラフィックが落ちないこと
・クリック率が下がらないこと

が重要になります。
もちろんどちらかでカバーすることができてトータルでプラスになれば基本問題はありません。

さて、実際にどうなったかですが、
まずトラフィックに関してです。


AMPトラフィック

上下動ありますが、(具体的な数字はお出しできませんが)0が4つのレベルではトラフィックが安定的にきています。(なお、すべてのブログやページをAMP対応させているわけではないので、全ページ対応すればさらに増加すると思います。)

話題性があるキーワードでAMP枠が表示される関係上、突如跳ね上がるような日も見られました。
若干懸念していた、「通常のオーガニックがAMP側に流れることがあるのではないか?」という懸念も数値上はほぼないように思われます。
もちろん、現状の数値レベルではAMPが全体の比率に対して小さすぎて分からないというのはあります。
AMPは基本的にどのキーワード表示され、流入が来たかがGoogle Analyticsなどログ解析では分かりません。
Search Consoleでもアメブロの場合はgamp.ameblo.jpというサブドメインにしていますが、このページにSearch Consoleを設定して、検索アナリティクスを見たとしても分かりません・・・・と書くつもりだったのですが、
このブログを書くためにSearch Consoleを見てみたら、数字が出ていました!

AMP Search Console

数値が徐々に上がっているところを見ると順次反映されているのではないでしょうか?
最新の数値はほぼAnalyticsで見るものと同じなので、ここに表示されるものは正しいデータになる気がします。

ここに表示されているキーワード(一部は諸事情により隠させて頂いていますが)、例えば「地震」などは本来オーガニック枠でアメブロが表示されるキーワードではありませんので、
このキーワードからの流入は純増と見てよさそうです。
AMP対応するメディアが増えれば、AMP流入は減少する恐れはありますが、"トラフィック"という観点ではAMP対応することはメリットがありそうです。

トラフィック以外では、我々はPVや広告収益に関しても若干の不安がありました。
ここでは具体的な数字はお出しできませんが、

・AMP経由での離脱が大きいということは特になさそう
です。
AMPの表示速度が早すぎて、通常のウェブページへ遷移する際にもたつきを感じて離脱が増えるのではないか?とか、AMPページのルール上、誘導導線が目立つ部分に設置できないため回遊ページ数が著しく落ちるのではないか?との懸念もありましたが、現時点ではさほど問題はないように思います。

また、最も懸念していた広告についてですが、

AMP 広告

下部ではありますが、このような形で表示され、

・AMPページのクリック率は思っていたほど悪く無い
という感想です。
さすがに位置の制約を受ける分、通常のウェブページのほうが良いですが、
通常のウェブページを10とした場合にCTRの比率としては8~9という感じで、
予想以上に良いという数字になりました。

さらに現在広告の読み込みがかなり遅い印象があるにもかかわらずその数値ですので、
今後もし広告の読み込みが早くなるようなことがあれば、さらにCTRは伸びるかもしれないと考えています。
なお、Search Consoleを見てもAMP流入の主力は通常オーガニックで出ていないキーワードであることを考えると現時点では、AMP分はほぼ"純増"と捉えています。

もちろん、今後AMP対応ページを増やしていくにあたって、通常のウェブページと競合するようなケースもあるとは思いますが、現時点でのCTRと"出さないデメリット"(="他サイトに流れていくというデメリット")を考えると、AMP対応によって広告収益が下がる可能性は低いと考えています。

このようにAMP対応において懸念していた事項については、ほぼ問題はなかったという結果になりました。
途中バグが発生しておかしな表示が出てしまったり(そしてそれに対応するのに工数がかかったり)、AMPの仕様に対応するのに四苦八苦したり(そしてそれに対応するのに工数がかかったり)した分を考えると、まだ元がとれているとは言い難いかもしれませんが(笑)、社内としても対応して良かったという感想を持っています。

現時点でAMPは「ニュース」「ブログ」にしか対応していない状況ですが、今後広がることを考えてそれ以外のサイトもAMP導入の可能性を探ってみるのも良いかもしれません。

木村 賢 (@kimuyan)
いいね!した人  |  リブログ(0)

テーマ:
サイバーエージェントは、Google が主催する Advanced Hosting Meetup プログラム に参加しました。本プログラムは、健全なウェブのエコシステム構築を目指すもので、今回、ホスティング サービスを運営する他の企業と共同で、以下のスパム サイト対策を新たに開始します。

● 【スパム サイト情報の相互共有】 本プログラムに参加したホスティング サービスを運営する企業(以下、プログラム参加企業 ※)は、各サービス上のスパム サイトに関する情報(例えば Google が Search Console 上の手動対策ビューアで提供しているスパム サイトの情報等)をプログラム参加企業間で共有します。情報を相互に共有することで、各サービス上のスパム検知や対策の精度向上を目指します。また、スパム サイトの情報に加え、各社で発見したスパムの最新の傾向や対策法などについても知見を共有します。
● 【アフィリエイト プログラムの悪用抑止】アフィリエイト プログラムを悪用したスパム サイトの作成抑止および、より迅速な対策を目指し、プログラム参加企業は、楽天アフィリエイト プログラムを悪用したスパム サイトを発見した場合、その情報を、楽天アフィリエイトに提供します。楽天アフィリエイトは、提供された情報をもとに調査を実施し、必要な場合、悪質なアフィリエイト ID に対する対策を実施します。

※ プログラム参加企業一覧 (敬称略・50 音順、カッコ内は主な提供サービス名)
● NTTレゾナント株式会社(gooブログ)
● 株式会社サイバーエージェント(アメブロ、 Ameba Ownd 等)
● シーサー株式会社(Seesaaブログ)
● GMO ペパボ株式会社(JUGEM、ロリポップ!レンタルサーバー等)
● 株式会社はてな(はてなブログ)
● ピクシブ株式会社(pixiv)
● ヤフー株式会社(Yahoo!ブログ)
● 楽天株式会社(楽天ブログ、楽天市場等)

詳細は Google 公式ウェブマスター向けブログの記事をご覧ください。
http://googlewebmastercentral-ja.blogspot.jp/2016/05/advanced-hosting-meetup-report.html
いいね!した人  |  リブログ(0)