[レベル: 初・中・上級]
Googleは、ウェブマスター向けガイドラインを大幅に改定しました。
この記事では、主だった変更点を抽出して解説します。
認識しておきたい変更点が数多くあります。
新しいウェブマスター向けガイドラインの主だった変更点
セクション分け
以前は、次の3つのセクションに大きく分かれていました。
- デザインとコンテンツに関するガイドライン
- 技術に関するガイドライン
- 品質に関するガイドライン
現在は、2つに分かれています。
- 一般的なガイドライン
- 品質に関するガイドライン
内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。
「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。
- Google がページを検出できるよう手助けする
- Google がページを理解できるよう手助けする
- 訪問者がページを利用しやすいよう手助けする
新規追加
まったく新たに追加された項目があります。
重要なコンテンツのデフォルト表示
「Google がページを理解できるよう手助けする」セクションに次が加わりました。
サイトの重要なコンテンツをデフォルトで表示します。Google はタブや展開するセクションなどのナビゲーション要素内に含まれる非表示の HTML コンテンツをクロールできますが、こうしたコンテンツはユーザーがアクセスしにくいものとみなされ、また、最も重要な情報はページの表示時にデフォルトで閲覧可能となっているものと解釈されます。
タブ切り替えや展開ボタンなどによってデフォルトで隠されているコンテンツの重要度を下げる場合があることに、Google社員はたびたび言及してきました。
検索からやってきたユーザーが、求めていた情報をすぐには見つけられない可能性があり、ユーザー体験を損ねるからです。
- タブ切り替え式デザインを推奨しない理由はSEOではなくUXの観点からだった
- 展開ボタンやタブに隠れたコンテンツは無視され検索結果の対象にならないかもしれない
- [続報] 重要なコンテンツならタブや展開ボタンで隠さないほうがいい
重要なコンテンツをデフォルトで表示しておくようにという推奨がガイドラインで今回新たに明文化されました。
ちなみに、まさにウェブマスター向けガイドラインのページそのものが、展開形式でコンテンツが隠されています。
言っていることとやっていることが……。
【UPDATE】
なお、モバイル向けページでの展開型UIは通常は問題になりません。
モバイル対応
「訪問者がページを利用しやすいよう手助けする」セクションにモバイル対応の項目が加わりました。
パソコン、タブレット、スマートフォンを含む、あらゆる種類やサイズの端末向けにサイトをデザインします。モバイル フレンドリー テスト ツールを使用してモバイル端末でのページの動作をテストし、修正の必要な箇所についてのフィードバックを得ます。
驚くことでもなんでもないですね。
むしろ追加が遅すぎたくらいです。
HTTPS
HTTPSの推奨も「訪問者がページを利用しやすいよう手助けする」セクションに加わりました。
可能であれば、HTTPS を使用してサイトの接続を保護します。ウェブ上の通信ではユーザーとウェブサイトとの間のやり取りを暗号化することが適切です。
モバイルと同じく、これも時代の流れを反映していますね。
アクセシビリティ
アクセシビリティに関係する要件も「訪問者がページを利用しやすいよう手助けする」セクションに追加されています。
視覚障害のあるユーザーにも利用しやすいページにします。たとえば、スクリーンリーダーによるユーザビリティをテストします。
障害者や高齢者に対する配慮も大切です。
修正・追加・削除などの変更
元からあったものの修正や追加、削除などの変更点です。
リンク
リンクに関する説明が変わりました。
【以前】
わかりやすい階層とテキストリンクを持つサイト構造にします。各ページには、少なくとも 1 つの静的なテキストリンクからアクセスできるようにします。
【現在】
サイト上のすべてのページが、検出可能な別のページからのリンクでアクセスできることを確認します。参照リンクには、ターゲット ページに関連するテキストまたは alt 属性（画像の場合）のいずれかを含める必要があります。
ガラッと変わりました。
「わかりやすい階層」はわかりやすくない表現だったのか、なくなりました。
画像リンクのalt属性が加わりました。
サイトマップ
サイトマップの説明は次のように書かれています。
サイト上の重要なページへのリンクを含んだサイトマップ ファイルを用意します。また、そのようなページへのリンクの一覧を人が読める形式で記載したページ（「サイト インデックス」や「サイトマップ ページ」とも呼ばれます）も用意します。
※強調は僕による
以前は、検索エンジン用のサイトマップの説明だったのですが、現在は人間のユーザーのためのサイトマップも用意するように指示しています。
しかも「Google がページを検出できるよう手助けする」のセクションのなかです。
「訪問者がページを利用しやすいよう手助けする」のセクションではありません。
昔ならいざしらず、Google向けにHTMLサイトマップは今は不要でしょう。
検索エンジンのためにHTMLサイトマップは必要ないとGoogle社員が言っているくらいです。
ついでに触れただけかもしれませんが、違和感を僕は覚えます。
サイトがある程度の規模を超えたら、サイトマップを作っても大きくなりすぎて利用に耐えられなくなるようにも思います。
疑問が残る変更です。
1ページのリンクの数
以前は次のように書かれていました。
1 ページのリンクを妥当な数に抑えます。
今はこうなっています。
1 ページのリンクを妥当な数に抑えます（最大で数千個）。
※強調は僕による
その昔は100未満でした。
これは技術的な制約があったからです。
100個を超えるくらいになるとページのサイズが大きくなり、それより先のリンクをGooglebotがクロールできなくなるかもしれなかったのです。
今はそんな制約はありません。
1,000でも10,000でも100,000でも大丈夫でしょう。
でもだからといって、ヘルプにあるような1ページに数千個もリンクを貼るのはどうでしょう？
見せ方にもよるでしょうが、多すぎませんかね。
「妥当な数」が曖昧なので数字を出したのだとしても、もっと別の言い方がなかったのでしょうか。
robots.txt
robots.txtの使用に関する説明が変わりました。
【以前】
ウェブサーバーの robots.txt ファイルを活用します。このファイルでは、クロールを実行するディレクトリと実行しないディレクトリを指定できます。誤って Googlebot クローラがブロックされることのないよう、このファイルにサイトの最新の状態が反映されていることを確認してください。サイトへのロボットによるアクセスを制御する方法については http://code.google.com/web/controlcrawlindex/docs/faq.html をご覧ください。Google Search Console の robots.txt 分析ツールを使用して、robots.txt ファイルを正しく使用しているかどうかをテストできます。
【現在】
ウェブサーバー上の robots.txt ファイルを使用して、検索結果ページなどの無限のスペースのクロールを制限することによって、クロールの割り当てを管理します。robots.txt ファイルは常に最新の状態に保ちます。robots.txt ファイルでクロールを管理する方法をご覧ください。robots.txt テスターツールを使用して、robots.txt ファイルの指定内容や構文をテストします。
以下が削除されました。
robots.txt を使用して、検索結果ページや、検索エンジンからアクセスしたユーザーにとってあまり価値のない他の自動生成ページをクロールしないよう制御します。
サイト内検索の結果ページをrobots.txtでブロックすべき理由が、以前は「価値がない」からだったのですが、現在は「無限のスペースのクロールを制限する（ページが無制限に生成されることによるクロール効率の低下を防ぐ）」ためとなっています。
また自動生成ページのブロックする指示はなくなってしまいました（依然としてブロックしたほうがいいはずです）。
ちなみに、”クロールの割り当て”は、英語版ページでは”crawling budget”という用語が使われています。
SEOの業界では普通に使う用語ですが、僕はGoogle検索の公式ドキュメントで”crawling budget”という用語が使われたのを初めて目にしました。
以前にGoogleの社員さんに「クロール バジェットについて質問があるのですが…」と尋ねたら、「クロール バジェットって何ですか？」と逆に聞き返されて、そんなものは存在しないような雰囲気だったのです。
これで堂々と使えます。（笑）
アセットのブロック禁止
JavaScriptやCSS、画像などのアセット（リソース）をrobots.txtでブロックしないようにとの指示が変わりました。
【以前】
Google がサイトのコンテンツを完全に把握できるように、サイトのアセット（CSS や JavaScript ファイル）がすべてクロールされるようにしてください。Google インデックス登録システムは、ページの HTML やそのアセット（画像、CSS、JavaScript ファイル）を使用してウェブページをレンダリングします。
【現在】
Google がサイトのコンテンツを完全に把握できるよう、サイトにおいてページのレンダリングに大きく影響するアセット（ページの把握に影響する CSS や JavaScript ファイルなど）がすべてクロールされるようにしてください。Google インデックス登録システムは、画像、CSS、JavaScript ファイルを含めて、ユーザーが実際に閲覧する場合と同じようにウェブページをレンダリングします。
※強調は僕による
以前は、何であろうとJavaScriptはブロックしてはいけないような書き方でした。
そのため、拡大解釈してJavaScriptファイルをブロックすると順位が下がったりペナルティを受けると誤解する人が出てきたほどです。
適切な評価の妨げになるから、ページにある大切なコンテンツのレンダリングに必要なリソースをブロックしてはいけないということであって、ありとあらゆるリソースを絶対にクロールさせないと恐ろしことが起こるぞという脅しでは決してありません。
有効なHTML
文法的に正しいHTMLを記述することに対する説明が変わりました。
【以前】
無効なリンクがないかどうか、HTML が正しいかどうかを確認します。
【現在】
すべてのリンクが実際のウェブページにアクセスできることを確認します。有効な HTML を使用します。
「有効な HTML」はW3Cの マークアップ バリデーション ツール にリンクしています。
「有効なHTMLを使用します」と書かれると、HTMLの文法が間違っていると評価が下がると勘違いしてしまいそうです。
ですがそういうことではありません。
変更の背景を、John Mueller（ジョン・ミューラー）氏が英語版オフィスアワーで説明しました。
要約すると次のようになります。
HTMLが正しいかどうかは直接のランキング要因ではない。正しいHTMLではなかったからといって、検索結果から削除するという意味ではない。そんなことをしたら、空っぽの検索結果がたくさんできてしまうだろう。
だが、HTMLの正しさが本当に関係してくる状況がいくつかある。
めったにないことだが、HTMLが完全に破綻していたとしたら、コンテンツをクロール・インデックスすることが難しくなる。
あと2つある。
1つは構造化データだ。HTMLが完全に無効なら構造化データを取得するのが本当に困難になる。
もう1つはモバイル端末と一般的なブラウザのサポートだ。HTMLがおかしかったら、正常にレンダリングできないかもしれない。
HTMLが文法的に間違っていると次のような問題が発生する可能性があることをミューラー氏は指摘しました。
- Googlebotがコンテンツをクロール、インデックスする妨げになることがある
- 構造化データを正しく取得できないことがある
- スマホやブラウザの種類によっては正しく表示できないことがある
少しくらいのHTMLミスであれば、問題になりません。
バリデーションで100点を取ったからといって評価は上がらないし、60点だからといって順位が下がることもありません。
ですが、たとえば <head>タグの 閉じタグ「>」を書き忘れたとしたら、きっとそのページは検索結果には出てこないでしょうね。
ブラウザ表示も真っ白です。
これは極端な例ですが、HTMLが極端に破損していれば検索に悪影響が出ることがありえます。
（【UPDATE】記事公開時、HTMLミスの例が不適切だったので修正しました）
構造化データは正しくないとたしかにダメでしょうね。
microdataやRDFaでは、HTMLタグの中に構造化データを記述していきます。
文法ミスがあると、コンテンツ評価とレンダリングには影響がなかったとしても、構造化データとしては正しく認識されないことが十分に予測されます。
通常は、構造化データテストツールに合格している必要があるでしょう。
ブラウザには、種類によっては特殊な“癖”を持つものもあります（例えば、IEとかIEとかIEとかw）。
AndroidデバイスとiOSデバイスとでは表示が異なってくることだってありますね。
つまり主要なモバイル端末とブラウザでページが正しく表示させるという意味も、「有効なHTML」には含まれているようです。
細かな変更点はまだまだたくさんあります。
ですが、僕の目にとまったのは以上です。
ウェブマスター向けガイドラインは、SEO上級者であろうがSEO初級者であろうが、SEOに関わりを持つのであれば熟知しておくべきものです。
ユーザーとGoogleと相性が良いサイトを作るために重要なことが書かれています。
反対に、やってはいけないことも書かれています。
大幅改定した新しいウェブマスター向けガイドラインを、「後で読む」のではなく「今すぐ読む」ことを強く推奨します。