Googleがスピードアップデート発表「モバイルで遅いページは順位を下げるよ!」【SEO記事11本まとめ】
グーグルは、モバイル検索の順位決定要因としてモバイル向けページの表示速度を利用する「スピードアップデート」を2018年7月から導入することを発表した。
ほかにも、Search Consoleのアカウントに関する情報、サイトマップの保存場所、AdsBotとGooglebot、hreflangに関する10のTIPSなどなど、SEOに役立つ情報を今週もまとめてお届けする。
今週のピックアップ
表示が遅いページはモバイル検索で順位を下げるよ! グーグルが“スピードアップデート”を告知
でも検索に実際に与える影響は小さそう (グーグル ウェブマスター向け公式ブログ) 国内情報
ページの読み込み速度をモバイル検索のランキング要素に組み込むことをグーグルは発表した。名称はわかりやすく、「Speed Update(スピード アップデート)」で、2018年7月に導入ということだ。
念のために繰り返しておくが、これはモバイル検索向けの話題だ。
ページの読み込み速度は、これまでも検索ランキング要因として利用されていた。これまでとスピードアップデート後の違いは次のとおりだ。
- これまで:
- デスクトップ向け検索 = デスクトップ向けページの表示速度データで判断
- モバイル検索 = デスクトップ向けページの表示速度データで判断
- スピードアップデート後:
- デスクトップ向け検索 = デスクトップ向けページの表示速度データで判断
- モバイル検索 = モバイル向けページの表示速度データで判断
グーグルのアルゴリズムアップデートと聞くとドキッとしてしまうが、目立った順位変動は実質的には起きないであろう。次のようにグーグルは説明している。
ユーザーに本当に遅い体験を提供しているようなページについてのみ影響し、ごくわずかな割合のクエリにしか影響しません。そのページがどのような技術を用いて制作されたかに関係なく、すべてのページに同じ基準を適用します。
検索意図は依然として非常に強いシグナルですので、魅力的で検索クエリと関連性の高いコンテンツは、ページの読み込み速度が遅くても高い順位に掲載される場合もあります。
つまり、「遅いページは、評価を下げる(場合がある)よ」ということだ。
具体的にどんな要素を見て速度を判断しているかにも言及していない(FCPなのかDCLなのかなど)。もっとも、そうした詳細情報が我々に必要だとは思わない。ページの表示を速くするのは、グーグルのアルゴリズムのためではなくモバイルユーザーのためだからだ。
どのようにしたら高速な体験をユーザーに提供できるかを考え、それを実現すれば結果的にグーグルのアルゴリズムで評価が下げられることはないはずだ。我々が見るべきはグーグルのアルゴリズムではなくユーザーであることを思い出そう。
先日改良されたPageSpeed Insightsなど、読み込み速度改善のために役立つツールやリソースも公式アナウンス紹介している。有効に活用しよう。
筆者のブログでもスピードアップデートに関するFAQ(よくある質問と答)を紹介しているので、そちらも参考にしていただければ幸いだ。
- すべてのWeb担当者 必見!
グーグル検索SEO情報
Search Consoleの管理者情報がわからなくなっちゃった! どうすればいい?
グーグルが新動画シリーズで解説 (SEO Snippets) 海外情報
Search Console を管理するアカウントの情報がわからなくなってしまったときに、どうすれば再びサイトの所有権を獲得できるか
そんなSearch Console所有権に関する問題を、グーグルのジョン・ミューラー氏が解説した。
Search Consoleでサイトを確認して設定を完了したGoogleアカウントのユーザー名やパスワードがわからなくなってしまうことがある。
解決策は非常に簡単だ。単に、あなたの新しいGoogleアカウントで所有者確認すればいい。確認が完了すれば、新しいGoogleアカウントでサイトの全データにすぐにアクセスできる。
Search Consoleには、Googleアカウントに紐づく情報はほとんどない。元のGoogleアカウントにアクセスできる必要はない。
Search Consoleで各サイトのデータにアクセスできるGoogleアカウントを一覧して確認することもできるので、以前の所有者がわかるかもしれない。どの確認方法を利用したかもわかるので、それを削除することもできる。
所有権を獲得したあとは、他部署の人に所有権を委任したり、外部のコンサルタントにデータの表示権限だけを与えたりすることも可能だ。
ミューラー氏が説明するように、以前の所有者がわからなくなったとしても、別のGoogleアカウントで所有者確認するだけでいい。
Search Consoleのデータはサイトに紐付いている。そのデータにアクセスできるGoogleアカウントが設定されるだけだ。したがって、だれが所有者であろうがデータは同じだ。だから、Search Consoleでサイトを確認したら、(ほとんどのレポートで)それ以前のデータにもアクセスできるのだ
レポートにアクセスできるユーザーのアカウントやそのアカウントに与えられた権限もわかる。確認済み所有者に対しては、どのような方法でサイト確認したかもわかる。
ちなみに個人的には、年に1回ぐらいはSearch Console(やGoogleアナリティクス)へのアクセス権があるユーザーの棚卸しをするのがいいと思っている。
棚卸しのタイミングで、すでに退職しているユーザーの確認に使われたmetaタグやHTMLファイルが削除されているか念のために確認するのだ。確認手段が残ったままでは、そのユーザーがSearch Consoleを完全に操作できてしまうからだ。
ちなみにこの解説は、グーグルが昨年末に始めたウェブマスター向けのショートQ&A動画シリーズからだ。
グーグルはQ&A動画シリーズを4~5年前にも公開しており、そのときはマット・カッツ氏が登場していた。カッツ氏はすでにグーグルを退職しており、新バージョンではジョン・ミューラー氏が登場している。
現在は、紹介編も含めて6本の動画が公開済みだ。
- すべてのWeb担当者が念のため知っておく
サイトマップの保存場所にベストプラクティスはあるのか?
自分が管理しやすいように (John Mueller on Twitter) 海外情報
サイトマップの保存場所について、グーグルのジョン・ミューラー氏にツイッターでフォロワーが質問した
複数のサイトマップを送信するときのベストプラクティスを教えてください。
すべてのサイトマップはルート(最上位のディレクトリ)に置かなければなりませんか? それともサイトマップインデックスファイルはルートに置いて、そのほかはサブディレクトリでも構いませんか?
ミューラー氏は次のように返信した。
自分にとって都合がいい場所に保存して構わない。
You can keep them wherever they make sense for you :)
— John ☆.o(≧▽≦)o.☆ (@JohnMu) 2018年1月17日
「サイトマップはルートディレクトリに置かなければならない」といったような決まりはない。管理しやすい場所に保存していい。
ただしサイトマップに含まれるURLは、そのディレクトリと同じ階層かそれより下の階層である必要がある。
たとえば、サイトマップを次の場所に置いたとする。
https://example.com/sitemap.xml
この場合、このサイトマップにはサイト内のどんなページのURLでも記載できる。
https://example.com/index.html
https://example.com/abc/index.html
https://example.com/abc/xyz/index.html
すべて、「サイトマップが置かれている場所または下位のパス」だからだ。
では、サイトマップを次の場所に置いた場合はどうだろう。
https://example.com/abc/sitemap.xml
この場合、このサイトマップには次のようなページのURLは記載できるが、
https://example.com/abc/index.html
https://example.com/abc/xyz/index.html
次のようなページのURLは記載できない。
https://example.com/index.html
「サイトマップが置かれている場所または下位のパス」ではないからだ。
- SEOがんばってる人用(ふつうの人は気にしなくていい)
広告品質用クローラ(AdsBot)が取得したデータは検索用クローラ(Googlebot)に共有されるのか?
両者は別々の運用 (Google Webmaster Central office-hours) 海外情報
グーグルのクローラと言えばGooglebotだが、「AdsBot」というクローラをご存知だろうか? 両社には次のような違いがある。
- AdsBot ―― Googleアドワーズ広告で使われるランディングページの広告品質をチェックするためのクローラ
- Googlebot ―― グーグルの検索サービス用のクローラ
AdsBotのクロールが急増加したサイトのウェブ担当者が、ジョン・ミューラー氏に質問した。
AdsBotがクロールで得たデータはGooglebotに共有されるのですか?
ミューラー氏は次のように説明した。
私が知る限りでは、GooglebotとAdsBotはデータを共有しない。
これは筋が通っていることで、検索に出すページがすべて広告を掲載しているとは限らないし、逆に、広告を掲載するページがすべて検索結果に出るとは限らない。
したがって、両者は別々に運用されている。
広告を掲載するページで1つ気を付けることがあるとしたら、広告で指定するトラッキングパラメータ付きのURLだ。広告キャンペーン用に動的なパラメータが付いたURLやセッションIDが付いたURLをGooglebotが発見してしまうと、そういったURLをすべてGooglebotがクロールしようとしてしまう。
そうしたURLが本当に必要なのかを検討し、必要な場合は最小限に抑えるなどして、注意して構成するといい。
検索用のクローラはGooglebotだが、グーグルはGooglebot以外にもさまざまなクローラを運用している。もっと細かく言えば、Googlebotにもウェブ検索用のGooglebotやモバイル検索用のGooglebot、画像検索用のGooglebotなど複数のGooglebotが存在する(グーグルの主要なクローラの一覧はヘルプ記事で公開されている)。
広告品質チェック用のクローラであるAdsBotが取得したデータと、検索用のクローラであるGooglebotが取得したデータは、互いに利用されることはないとのことだ。目的がまったく異なるので納得がいく。
ただし、ミューラー氏はタグ付けされた広告用ランディングページのURLの使用に注意するようにアドバイスした。そうしたURLをGooglebotが発見できてしまうと同じページに対して複数のURLが存在することになってしまう。いわゆる重複コンテンツだ。通常は問題にならないだろうが、正規URLを明確にするためにも重複コンテンツを生み出すURLを減らすに越したことはない。
canonical指定を適切にするか、どうしようもない場合はSearch Consoleの[クロール]>[URLパラメータ]で設定するといいだろう。
- SEOがんばってる人用(ふつうの人は気にしなくていい)
グローバルサイト運用者必見!hreflangに関して知っておくべきこと×10
ありがちなミスも含まれている (Gianluca Fiorelli on Twitter) 海外情報
イタリアのSEOコンサルタントであるジャンルカ・フィオレッリ氏が、多言語・多地域サイトの構成でのhreflang
指定に関する重要な注意事項を10個ツイッターで共有した。
グローバルサイトの運用者には非常に役に立つ情報なので紹介する。
I still see some confusion when it comes to hreflang and how to implement it.
— Gianluca Fiorelli (@gfiorelli1) 2018年1月15日
Let me try to clarify few things, then. pic.twitter.com/yMWKlFEYRa
サイト内の全ページにhreflangを実装することは必須ではない。たとえば、noindexページに設定するのは時間のムダだし、正規化したページには使わないでおくこともできる(これは無用なミスも防ぐ方法にもなる)。
実装するのであれば、自己参照のhreflang(自分自身のページの言語と国を指定するhreflang)も必ず実装しなければならない。そして対応する国と言語のhreflangも設定する。
自己参照のhreflangは必要ないという人もいるが、Googleは強く推奨している。
hreflangでは、言語の指定には「ISO 639-1」で定められたコードを使い、国の指定には「ISO 3166-1」で定められたコードを使い、言語と国をペアで指定する。
特定の言語には「ISO 15924」を使うこともできる。たとえば、中国語で繁体字を使用する台湾(zh-Hant-TW)や香港(zh-Hant-HK)など。
hreflangとcanonicalについて ―― ルールはシンプルで、hreflangとcanonicalは常に同一でなければならない。もし同一でないと、hreflangは無視される。国または言語が異なるページにcanonicalで正規化してはいけない。
165か国ものhreflangアノテーションを設置しないようにする(こういうサイトが実際に存在する)。
本当に重要な国に対するhreflangだけを設置し、複数言語や複数地域が混在しているような国からのトラフィックの問題を解決するようにすべきだ。
国・言語のペアになる値に関しては凡ミスを犯さないようにする。たとえば英国には「UK」ではなく「GB」を用いる。
また言語コードと国コードを取り違えてはいけない。「da」はデンマーク語だし、「DK」はデンマークの国を表す。
言語コードだけで指定することはできるが、国コードだけで指定することはできない。
「en_US」のように国・言語のペアに「_」(アンダースコア)を使ってしまうことがある。問題にならないという人もいるが、実際に問題を引き起こした例を知っている。国・言語ペアのセパレータには「-」(ハイフン)を使い、「en-US」のようにする。
hreflangは代替ページを参照する役割を果たす。したがって、次のことを覚えておく:
ページAがページBを参照しているのであれば、ページBはページAを参照し返さなければならない。
代替ページとしてhreflangがどんなURLを指し示しているかをきちんと認識しておくこと。指す先が次のようなページであってはいけない:
- 正規URL
- リダイレクトするURL
- 400番台エラーを返すURL
- robots.txtでブロックされたURL
こうしたURLを指し示すとエラーが発生するため、グーグルはそのhreflangを無視するようになる。
x-default属性値について ―― Googleはx-defaultについてあまり詳しく説明していないが、hreflangで指定していない国からのユーザーに見せたいページを推奨するために使う。たとえば、国や言語のセレクタがあるようなページがそうで、これはトップページだけになる。
したがって、内部ページのためにx-defaultを使ってはいけない。数千のリターンタグエラーが発生するだろう。
- グローバルサイトを運用する、すべてのWeb担当者 必見!
ソーシャルもやってます!