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

英グーグル社員が語る5つの最新SEO

この記事の目次：

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

英グーグル社員が語る5つの最新SEO
★★★★★ すべて確実に実行したい（Pierre Far）

英グーグルのピエール・ファー氏が、「Search London」というイベントで講演した際のフォローアップを個人ブログに投稿した。講演の概要ではあるが、すべて確実に押さえておきたい内容なので紹介する。

ページのレンダリング

一般的なブラウザのようにGooglebotがウェブページをレンダリング（表示）できるようになったことを、グーグルは昨年の5月に発表した。それ以降、よく見る間違いが2つある。

リソースのブロック ―― ページのレンダリングに必要なJavaScriptやCSSのクロールをブロックしているサイトがたくさんある。解決策は簡単で、それらのリソースへのGooglebotのクロールを許可することだ。CDNのように異なるサーバーでサイトをホストしていても適用できる。問題ないかどうかは、Fetch as Googleの「取得してレンダリング」で確認できる。
リソースの動的配信 ―― 増えてきている問題だ。JavaScriptやCSSをユーザーエージェントに基づいて動的に配信する仕組みは、トラブルを起こしやすいので使う必要はない。どうすべきかはGoogle+で説明したことがある。

モバイル向けサイト

モバイルサイトの必要性について話した。最も重要なコンセプトは、「目的を達成できるか」だ。PC向けサイトでできることはモバイル向けサイトでもできなければならない。私はこれを「目的達成の同等性」と呼んでいる。シンプルだが非常に影響力がある考え方だ。

モバイルサイトの構築に役立つリソースは次の2つ。

ウェブマスター向けモバイルガイド
Web Fundamental（英語）

App Indexing

App Indexingを使えば、スマートフォンを使っているユーザーがグーグルで検索したときに、アプリでコンテンツを開くためのリンクを検索結果に表示できる。

JavaScriptやCSSのときと同じように、アプリのリソースをブロックしてはいけない。Android アプリのエラーを確認しておくこと。

構造化データ

構造化データテストツールと構造化データのガイドライン（英語）を刷新した。またJSON-LDのサポート範囲を拡大した。

ローカル検索向け情報は“NAP”だけでは不十分。営業時間も忘れずに。

ローカル検索では、一般的に「NAP」と略されている「Name（名称）」「Address（住所）」「Phone（電話番号）」の情報だけでは十分ではない。営業時間の検索も多いからだ。「Opening hours」（営業時間）も付け加えて、「NAPO」と呼ぶようにするほうがいいかもしれない。

NAPOの指定に関してはこちらのドキュメント（英語）を参照するといい。

ペンギンアップデート更新はもうアナウンスなし？
★★★☆☆ 小さな更新ならいちいちしないっぽい（Google Webmaster Central office-hours）

1月27日に開催された英語版オフィスアワーで、参加者の1人がグーグルのジョン・ミューラー氏に次の質問を投げかけた。

今後、ペンギンアップデートを更新したときはアナウンスがありますか？それともペンギンアップデートはアナウンスなしの毎月の更新へと移行するのでしょうか？

ミューラー氏の回答はこうだ。

概して言えば、以前よりも更新のサイクルを若干速くしている。とはいえ、毎月の更新だというわけではない。
更新のタイミングには多少の変更や違いがあるだろうが、前回の更新のときよりは短い間隔になるはずだ。
期待したような回答ではないかもしれないが、結論としては、更新を少しだけ速くする方向に進めている。
アナウンスするともしないとも言えない。更新の間隔が空いたり、より大きな変更があったりすれば、必ずアナウンスするつもりだ。しかし、長い時間をかけて起こる小さな更新なら個々についてはおそらくアナウンスしないだろう。

最新のペンギンアップデートは継続的な更新へと仕組みを変えている。小規模な更新は以前よりもずっと短い間隔で繰り返し実行されているらしい。検索結果に与える影響が大きい更新でない限りは、これからは特別なアナウンスはなさそうだ。

5か月間に渡る403エラーでも順位は元に戻る
★★★☆☆ でもユーザーは戻らないかも（Webmasters Stack Exchange）

SEO系フォーラムに次の質問が投稿された。

リニューアル中のサイトが5か月間、403エラーを返していた。オンラインに戻ったのだが、検索順位は元に戻るだろうか？

グーグルのジョン・ミューラー氏がコメントを書き込んだ。

時間を短縮するために、Fetch as Googleの「URLをインデックスに送信」を使うことができる。通常は数日でURLがインデックスに戻ったことを確認できるだろう。ひょっとしたら今ごろはもう検索結果に出ているかもしれない。
ただし過去の元の順位に戻るにはしばらく時間がかかるかもしれない（グーグルのアルゴリズムは絶えず変化しているので、元とまったく同じ順位とも限らない）。

5か月間もの長い間Googlebotがアクセスできなかったとしても、元の状態に復活できるようだ。

「403」は「アクセス禁止（アクセス権なし）」を意味するものなので、たとえば「以前は会員限定公開のコンテンツだったが、方針を変更してだれでもコンテンツを閲覧できるようにした」といった状況を考えると、グーグルがこのように処理していることは納得だ。

とはいえ、意図せず（ミスで）こんなに長期間サイトが利用不可能な状態にしておくのは避けたい。検索エンジンの評価は取り戻せたとしても、ユーザーの信頼を失ってしまいそうだ。

410を返すとインデックスから永久的にページを削除するのか？
★★★☆☆ 404と同じように再クロールすることがある（John Mueller (@JohnMu) on Twitter）

Webサーバーが返すHTTPステータスコードの1つとして、「410」がある。「410」は「もうそのページは存在しない」ことを示すものと定義されている。

この410を返したURLをグーグルがどう処理するかについてジョン・ミューラー氏がツイッターで質問された。

410はインデックスから永久的にページを削除しますか？

ミューラー氏は次のように返信した。

（前略）クロールして410が返ってきたら、かなり早くインデックスから削除する。

@gerdnaschenweng Permanently is a long time (maybe it'll reappear next year?), but we do drop them fairly quickly once recrawled.
— John Mueller (@JohnMu) 2015, 1月 28

HTTPステータスコードとしては、404と410は異なる。違いを簡単にいうと次のようになる。

404（Not found） ―― リクエストされたURLに関して「コンテンツが見つからない」を意味する。ページを意図的に削除した意味は含まない。
410（Gone） ―― リクエストされたURLに関して「もうそのコンテンツは存在しないし、転送先アドレスも不明」で、その状態が今後もずっと変わらないことを意味する。意図してページを削除した意味を含む。

しかしグーグルは両者をほぼ同等に扱う。410のほうが若干インデックスからの削除が速くなるくらいの違いだ。たとえ410を返したURLであっても再びクロールすることがありえる。404と410のグーグルの処理については以前に解説したことがある。興味があれば読み返すといいだろう。