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

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


テーマ:

5月になってしまいましたが、新年度から新しくウェブサイトの運営の担当になったりSEOの担当になったり、はたまたSEO会社でSEOをやることになった人もいるかと思うので、自分自身も初心に立ち返る意味でもSEOで成し遂げられることってなんなの?ということをおさらししてみたいと思います。

私自身は2001年に社会人になったので社会人歴は17年目になりました。

その中で仕事としてSEOをやったのは、14年目です。

その前は前職でインハウスSEO的なこともやっていたので(SEOという言葉は知らなかったけど)実際は16年くらいSEOに携わっていると思います。

 

その中で一言で「SEO」と言ってもいろいろ変化してきて、"SEOってこういうものでしょ?"という概念的なものも、変化してきたと思います。

わかりやすく言うと、会社の偉い人がインハウスSEOの担当者へ、だったり事業者がSEO会社に発注する際に、

「SEOで◯◯な状態にしてね」とか「SEOで◯◯という数値を達成してね!」

という◯◯が変わったことと、◯◯が変わらなくても、それを実現する前提条件が変わったと思います。

 

通常SEOの概念としては現在、こういうものがベースになるはずです。

"ウェブサイトやウェブページがもつ力を最大限に引き出してGoogleに伝えること"

ですね。これがSEOの根底にある考え方です。

方法としては検索エンジンがきちんとコンテンツを読めるようにしてあげる(レンダリングできるようにする等)などがあると思います。

コンテンツの力を引き出すという意味では、コンテンツを読みやすくするための仕組みづくり、たとえば表示速度だったり、サイト内の導線の整備だったりもここに入るかもしれません。

 

ですが、かつてはこのようなものがSEOだ!と思われていたように思います。

本来そのサイトやページが持つ力を大きく見せるのがSEOだったように思います。背伸びをさせるわけですね。

例えば、人工リンク(自作自演リンク)などのスパム行為によってGoogleの評価を高めようとしたり、無理やりコンテンツを大量生成して、なおかつ読者にとって有益とは思えない情報を、検索エンジンからの評価が上がるからと(主に網羅性を高めるために)コンテンツとして追加したりしたものがこれにあたります。

今でも、SEOは上記のようなものだと思っている人はSEOに普段携わらない方の中には多いと思います。

例えば、

不十分なコンテンツなのに"SEOという魔法の杖"を使えば上がるんでしょ?

と思っている人や、

そんなものクラウドとかでコンテンツ作れば上げられるでしょ?

と思っている人は実際に結構いると思います。残念ながら。

ここから脱却できないと、Googleからペナルティ(;Googleはペナルティという言葉は使いません)を受けてランクが大幅に下がったり、先日あったオウルアップデートのように信頼性が低いコンテンツだとして評価が下がったりするわけで、結局無駄なコストを使うことになります。

(そして、おおむねその責任はSEO担当者に向けられますよね笑)

 

では、今SEOとして求めるべきものは何か?ですが、最初の図で示したような

"サイトやページ、もっと言うとコンテンツの力を100%引き出す"

ということは当たり前なんですが、それだと差別化は難しいし、巨大な資金力のあるサイトに勝てないし、何よりSEOが面白くない笑

 

なので、

こんな感じで、そもそもの力を伸ばすことがSEOになってきたと思います。

 

古いSEOでは、

本来持っていない力を持っていると見せかける

でしたが、

今目指すべきSEOは、

本来持っている力そのものを伸ばす

です。

まあ、古いSEOでも、力の捏造はスパムなのでやってはいけなかったわけですが・・・・

 

じゃあ、何をやってベースを伸ばすかですが、

・検索エンジンではなくユーザーが必要とする良質なコンテンツを追加したり、コンテンツを改善したりする

・サイトを使いやすくする(要はUXを向上させる)

に尽きると思います。

コンテンツによって捏造ではなく本質的なリンクが集まるわけですし、効果があるかどうかは別としてソーシャルでの言及(サイテーション)も増えるでしょう。

表示速度が速かったり、読みやすかったり、求めている情報にたどり着きやすしものはUXが向上して直帰率が下がったり、滞在時間が伸びたり、回遊ページ数が増えるでしょう。

これらは直接的にSEOに効果があるかどうかは別として、我々の研究結果からもGoogleの順位と非常に相関が高いものになります。(6月にそのあたりのセミナーをやりますので興味ある方は来てください。宣伝。笑。)

 

かつてSEOでやれたことが今でもやれると思っていると、誤った方向に進んでしまう可能性があります。

SEOはGoogleをハックすることだと思っていた人は一度その考えを捨てて、いかにウェブサイトの本来の本質的な力を伸ばせるかに注力し、SEOの担当者はその力をつけるサポートをしつつ、その力を最大限に引き出せるようにして欲しいと思います。
(偉そうですいませんが、SEO歴で言えば日本でもかなり長いほうなので、老人の戯言と思ってお許しください)

 

なお、私が主に見ているような超大規模サイト&CGMでは、一言で力を引き出すと言って、

・クローラーの動きをどうコントロールするのか?

・複雑に絡み合った仕組みの中で、検索エンジンにはきちんと情報を伝達しながらどうやって表示速度を最速にするか?

とか、

・検索エンジンから評価されない(もしくはマイナスにとられる)投稿をどうコントロールするのか?

というマニアックな知識や技術が必要となります。

このあたりの話は、基本的にまったく一般受けしませんのでブログには書きませんので、偶然居酒屋で隣の席になるなどして頂ければと思います。(どうやってや??)

 

(自分も含め)SEOに携わられる方の未来が明るいものになることことを願ってやみません。

 

 

木村 賢 (@kimuyan)

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

テーマ:

アメブロをお使いいただいている皆様。いつもありがとうございます。 
 
アメブロのURLがHTTPSになったこと、およびAMP(Acceralated Mobile Pages)に対応したことをふまえて、 ブロガーのみなさんが検索エンジンからの流入をより詳しくみられるようにするSearch Consoleの設定追加のご案内をさせていただきます。 
 
4/6(木)のアメブロHTTPS化に伴い、アメブロには 
http://ameblo.jp/ブロガー様のID/ 
https://ameblo.jp/ブロガー様のID/ 
http://gamp.ameblo.jp/ブロガー様のID/ 

https://gamp.ameblo.jp/ブロガー様のID/
の4種類が存在することになります。

ややこして申し訳ないのですが、世の中の流れとして、HTTPSによるセキュリティの強化とスマートフォンでの迅速な表示という意味でのAMPは避けて通れないものとなっているためご理解いただければと思います。 
(サブドメインにしなければいいじゃないか!というご意見があるかもしれませんが、皆様のブログのトラフィックを低下させないためにはサブドメインがベストな選択となっていることをご理解ください。) 
 
現在、画面からSearch Consoleを設定していただく際は、 
アメブロ>設定・管理>外部サービス連携>Search Consoleを選択していただき、そこにSearch Consoleで表示された”google-site-verification タグ”内の”content=“英数字”の英数字部分を入力していただく形になっています。 

URLが増えても、この入力を複数していただく必要はなく、Google Search ConsoleはアメブロのこれらURLのケースでは、1つのコードの設定で対応が可能です。 
 
一方で、Search Console側では「プロパティの追加」をしていただく必要があります。 
画面右上の「プロパティの追加」をクリックしていただくとURLの入力を求められますので、ここで 
http://ameblo.jp/ブロガー様のID/ 
https://ameblo.jp/ブロガー様のID/ 
http://gamp.ameblo.jp/ブロガー様のID/ 

https://gamp.ameblo.jp/ブロガー様のID/ 
ここで4種類のURLをそれぞれ追加していただく必要があります。

(・https://gamp〜は存在はしていますが、当面は検索には反映されない可能性があります。
・すでにhttp://ameblo.jp/ブロガー様のID/を登録してある場合は不要です。
・新規で登録される際にはアメブロ側にmetaタグが追加されるのに約1日のタイムラグがありますのでご了承ください。)

 
 こちら自動的に認証されますので、URLを登録したらSearch Cosoleのトップに戻っていただきプロパティが登録されているかどうか確認してください。 
こちら登録が完了されると、 
検索トラフィック>検索アナリティクス 
でそれぞれのURLへの検索流入が確認できます。 

また、Search Consoleの「セットを作成」を使っていただくと、セットに登録したプロパティをまとめて見ることができます。 

複数のURLになることで検索エンジンからの流入を意識されるブロガー様には大変お手数をおかけして恐縮ですがご理解いただけますと幸いです。 
引き続きアメブロを宜しくお願いいたします。

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

テーマ:

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

その間に色々なことがありましたが、私ごとですが、 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)