海外&国内SEO情報ウォッチ

グーグル「遅いページにはモバイル検索結果でイエローカードを出そうかな」

この記事の目次：

海外のSEO/SEM情報を日本語でピックアップ

グーグル「遅いページにはモバイル検索結果でイエローカードを出そうかな」
★★★★☆ せっせと高速化に励もう（Parmar Divyesh on Twitter）

表示速度が遅いページに警告メッセージを表示するテストを、グーグルはモバイル検索で行っているようだ。

「Slow to load」という警告マークが付いたメッセージが出ているモバイル検索結果の画面をツイートしたユーザーがいる。「Slow to load」は「読み込みが遅い」という意味だ。

Google is showing Slow to add sites first than mobile friendly sites in mobile results@rustybrick @seroundtable pic.twitter.com/wOnVbGAYDY
— Parmar Divyesh (@ParmarDivyesh86) 2015, 6月 26

実は2週間少し前に、同じニュースを筆者の個人ブログでも取り扱った。しかしその記事で見せた検索結果とは別の検索結果だ。当然、遭遇したのも別のユーザーだ。案外、幅広い範囲でテストしてるのかもしれない。

実装されるかどうかは不明だが、こうしたテストを行っているということは、モバイルユーザーが速いページを望んでいるとグーグルが認識しているからだろう。せっせと高速化に励めば、ユーザー体験を向上させられる。反対に後回しにすれば、ユーザー体験だけでなくモバイルSEOにおいてもマイナス要因を作ることになってしまいそうだ。

正規化にはrel="canonical"と301リダイレクトのどちらがふさわしいか
★★★☆☆ 根本のシステムが悪い場合はそこを修正（SEO Hangout Panel）

Google+のSEO系コミュニティで、URLの正規化ために

rel="canonical"
301リダイレクト

のどちらを使うべきかアドバイスが欲しいという相談があった。

質問者のサイトはホテルやアパートを紹介するサイトで、1つのコンテンツを公開すると異なるURLを持つ2つのページができあがるとのことである。たとえば、ブリスベンのホテル・アパートを紹介するページは次の2つのURLで公開される。中身はまったく同じだ。

domain.com/brisbane/hotel-apartments.html
domain.com/brisbane/hotel-apartments-brisbane.html

数名のコミュニティのメンバーがアドバイスしている。筆者の見解も交えて、どうすべきか考えてみよう。

根本的な問題として、システムがおかしい。1つのコンテンツで2つのURLを生成するのでは、新規コンテンツを公開するたびに重複コンテンツができあがる。このおかしな仕組みを修正し、1つのコンテンツに1つのURLを割り当てるようにするのが、最も望まれる対処だ。

重複コンテンツを防ぐいちばんの対策は、重複コンテンツをそもそも発生させないことである。

もしシステムの修正が無理なのであれば、301リダイレクトで正規化したい。301リダイレクトが使える状況ならば、301リダイレクトが正規化にはもっとも適した手段だ。

301リダイレクトの利用が困難ならば、rel="canonical"でどちらかのURLに正規化する。

ただし、注意点がある。

301リダイレクトとは異なりrel="canonical"は、あくまでも検索エンジンに対してヒントとして提示するものなので、100%正規化できるとは限らない（もっともかなり強いシグナルとして利用される）。
rel="canonical"は人間のユーザーには関係ないので、ソーシャルメディアでのシェアなどは2つのURLに分散されたままになる。

noindex robots metaタグで片方をインデックスから非表示にするという手段もとれるが、他に選択肢がないときの方法だろう。

robots.txtで片方のURLをブロックすることは勧めない。Googleは、重複コンテンツの中身も見たうえで優先するURLを判断したいからだ。

HTTPSでサーバー証明書の種類をグーグルは問題にするのか？
★★★☆☆ 今のところはどれでもいい（WebmasterWorld）

グーグルは、HTTPSのサーバー証明書の種類もランキング要因に将来的にするだろうか？

こんな質問がWebmasterWorldフォーラムに投稿された。

今のところ、サーバー証明書の種類をグーグルは考慮していない。公開鍵長に2048 bitを推奨してはいるが、 1024 bitだからといって評価しないわけではない。

また、より厳格な審査のもとに発行されるEV証明書だからといって評価を高めることもない。

現状ではHTTPSでありさえすればいいのだ。もしかすると、信頼されていない証明機関（CA）から発行されたサーバー証明書を使っていたとしても評価対象になるのかもしれない（未確認だが）。

とはいえ、今後サーバー証明書の強度を判断材料として使うようになることもありうる。ユーザーに対するセキュリティを高めるためにも、新規にサーバー証明書を取得する際には強度が弱いものを選ばないように注意したほうがいい。

少し別の話題になるが、サーバー証明書の署名アルゴリズムにSHA-1を使っているサイトをChromeで閲覧すると、URL欄のセキュリティ鍵マークに×印の警告が標示される。セキュリティが確保されていることを示すはずの鍵マークがこんなふうでは、かえってユーザーを不安にさせてしまうだろう。

強度が弱いSHA-1署名を使っているためにChromeで警告が出るサイトの例

たかがSSL、されどSSLだ。わからなければ、インフラに詳しい人に効くようにしておこう

次のパンダアップデート更新はまもなく実行される
★★★☆☆ 予告した2～4週間は過ぎている（Gary Illyes on Twitter）

パンダアップデートの次の更新を、2～4週間ほどで実行するだろうと、グーグルのゲイリー・イリーズ氏は1か月前に開催されたSMX Advanced 2015で予告していた。

ところが、1か月が経過したがいまだにその気配はない。

「まだなのか？」というツイッターでの問いかけに対して、イリーズ氏は次のように返答した。

ってな風になるから、予定期日を言うのは、やめておくべきなんだよね。そうだね、僕が知るかぎりではもうすぐだよ。

@DanHowdle @Marie_Haynes And that's kids, why I should stop giving timeframes :) Yes, it's coming soon as far as I know.
— Gary Illyes (@methode) 2015, 6月 26

具体的な日程を約束してまうと、もしそれを守らなかった場合ウソつき呼ばわりされてしまうことだってありそうだ。なのでイリーズ氏はあえて具体的に言わず、2～4週間の幅をもたせたのだろう。

とはいえ、そろそろ来てもいい頃だ。パンダの更新は週末に実行されることが多い。ひょっとしたら週明けは、パンダ更新のニュースで持ち切りかもしれない。

Fetch as GoogleのURL送信を毎日実行する必要なし
★★★☆☆ サイトマップとRSSフィードを送信すればいい（John Mueller on Twitter）

Fetch as GoogleでのURLのインデックス送信に関して、1週間に500回という制限についてツイッターで質問されたグーグルのジョン・ミューラー氏は、次のように返信した。

（わざわざ毎回Fetch as Googleを使って）そんなに大量にURLを送信する必要はないだろう。（インデックスの促進には）サイトマップかフィードを使うことを勧める。

@RiaLolwut @googlewmc There shouldn't be any need for that many submissions regularly -- I'd recommend using sitemaps or feeds instead.
— John Mueller (@JohnMu) 2015, 6月 24

Fetch as GoogleのURL送信機能は、すぐにでもクロールさせたいページに対して使うことを想定している。たとえばコンテンツを更新しすみやかに検索結果に反映させたい場合だ。

日々の新しいコンテンツを公開するたびに使うものではない（使ってはいけないというわけではないが）。通常は、サイトマップやRSS/Atomフィードを送信してクロールを促進するほうが適切だ。

なお質問者は毎日URLを送信したくて質問したようではなかったようだ。Fetch as GoogleのURL送信には上限数があり、そのサイクルを知りたかったのだ。

こちらについては、グーグル社員のヘルプフォーラムでの説明をピックアップしたことがある。