Posted by Pierre Far, Webmaster Trends Analyst
Original version: Updating our technical Webmaster Guidelines

現在使われている様々な端末に対応したウェブサイトの開発方法

ところで、現在使われているすべての端末に対応したウェブサイトを開発することは難しくありません。HTML5  を使いましょう。HTML5 は、どのような端末でも表示されますし、HTML5 しか使えない端末さえあるからです。そこで、好きな種類のファイルをどのような端末でも表示できるようなサイトを作る一助になればとの思いから、最近、Google は次の 2 つのページを公開いたしました。

• Web Fundamentals （英語）: ウェブサイト作成のベスト プラクティスを集めた用例集。
• Web Starter Kit （英語）:  Web Fundamentals の用例を応用して、ウェブサイトを一から作るためのフレームワーク。

Web Fundamentals に書かれた適切な作り方に従うことで、Google が推奨している、検索に適したレスポンシブ デザイン（英語）であるサイトを作ることができます。この際、Googlebot がサイトのすべてのサブ リソース（CSS、Javascript、画像ファイル等）にアクセスできるよう robots.txt などの設定をしてください。すべてのサブ リソースにアクセスできることで、Google のアルゴリズムは、ページがレスポンシブ デザインであることを検出しやすくなり、ひいては適切に評価することができます。また、ウェブマスター ツールには、インデックスに登録するアルゴリズムがどのようにウェブサイトを認識しているかを調べるための Fetch as Google という機能があります。

ご不明な点がございましたら、ウェブマスター ヘルプ フォーラムをご利用ください。

Posted by Keita Oda, Software Engineer, and Pierre Far, Webmaster Trends Analyst
Original version: Promoting modern websites for modern devices in Google search results

（例 2） 本来対象としているサイト以外への発リンクも設置することで自然なリンクに見せかけているケースです。


最近 Google が対応を行ったケースでは、委託先 SEO 会社がリンク操作のネットワークを保有して依頼主に提供している例だけでなく、企業自身が主体となってリンク操作のためのネットワークを運用している例が見受けられました。そのような例に対して Google は、ウェブマスター向けガイドライン違反として適宜自動または手動による対策を実施しています。

ウェブマスターのみなさまには、こういった PageRank を渡すリンクの操作や売買を避けることをこれまでどおり強くおすすめします。サーチ クオリティ チームは、今後とも、ユーザーのために、検索結果からのスパムの排除に全力で取り組んでまいります。

Google サーチ クオリティ チーム

このたび、新しいウェブマスター アカデミーが 22 言語でご利用いただけるようになりました。ウェブマスター初心者の皆様には、優れたサイトを作成する方法、素晴らしいユーザー体験を提供する方法、検索結果に適切に表示されるようにする方法などの基本事項を、さまざまな言語で学習していただくことができます。既によく理解している項目については、各モジュールの最後にあるクイズで理解度をテストしてみましょう。

お好みの言語でウェブマスター アカデミーをご覧頂いたら、ぜひウェブマスター ヘルプ フォーラムでご感想をお寄せください。今年の 3 月に英語版を公開（英語）した後も、皆様からのフィードバックをいただき、参考にさせていただきました。このガイドはわかりやすく、楽しみながら読めるようになっていますので、ぜひ一通りご覧ください。きっとみなさまのお役に立てることと思います。

優れたサイトや Google 検索との相性の良いコンテンツを作成し、世界中のユーザーにアクセスしてもらいましょう。

サイトをマークアップする方法

サイトでは、サイト固有の検索エンジンを使用している必要があります。既に使用している場合は、schema.org/SearchAction （英語）マークアップの potentialAction プロパティ（英語）を使用して、ホームページを schema.org/WebSite （英語）エンティティとしてマークアップすることで Google に知らせることができます。マークアップには、JSON LD、microdata、RDFa を使用できます。実装について詳しくは、デベロッパー サイト（英語）をご確認ください。

サイトにマークアップを実装すると、ユーザーはサイトリンク検索ボックスから直接、サイトの検索結果ページにジャンプできるようになります。マークアップがない場合は、今までと同様に「site: 検索キーワード」に一致する Google 検索結果ページが表示されます。

ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムでご質問ください。

Posted by Mariya Moeva, Webmaster Trends Analyst, and Kaylin Spitz, Software Engineer
Original version: Official Google Webmaster Central Blog: An improved search box within the search results

Tips その 2:
ウェブマスター ツールはハッキングからサイトを守る上でも役立ちます。使っていない方はぜひ登録を。お友達にもお知らせください。

Tips その 3 :
Google アラートを設定してハッキングの兆候をいち早くつかもう。

Tips その 4:
ソフトウェアは常に最新のものにアップデートしておこう。

Tips その 5:
ユーザーから寄せられたベスト投稿を発表！（各言語でベスト投稿を発表しました）

世界中から寄せられた投稿のご紹介

• ブラジルの Pablo Silvio Esquivel さんは海賊版ソフトウェアを使うことがハッキング被害の危険性につながることを紹介してくれました。
  https://plus.google.com/+PabloSilvioEsquivel/posts/9ahpESFwuac
• オランダの Rens Blom さんは、パスワードを複数のアカウントで使いまわさず定期的に変更すること、そして 二段階認証 などのセキュリティ機能も使うことをおすすめしてくれました。
  https://plus.google.com/+GoogleNederland/posts/48e3VAsxddS
• ロシアの Дмитрий Комягин さんは、日頃からサイトへのトラフィックや、検索クエリ、ランディング ページなどをモニターし、数値の想定外の急上昇などがないか把握しておくという方法を投稿してくれました。
  https://plus.google.com/+googleru/posts/CYwe6xf3Xvm
• 日本の工務店コンサルタントさんは、実際に被害に遭われた際のレポートとそこから得た教訓として、ハッキング対策を適切に行っているホスティングを選ぶこと、ウェブマスター ツールのメール転送機能を設定しておくことなどを詳しくご紹介してくださいました。
  https://plus.google.com/+Asanoyukinobu/posts/hsKmoc2v2cZ
• ポーランドの Kamil Guzdek さんは、WordPress をインストールした際に、table prefix をデフォルトのものからユニークなものへ変更することで、データベースがハッキングされるのを防ぐという tips を紹介してくれました。
  https://plus.google.com/+KamilGuzdek/posts/Gu63giLNTiZ

今回、世界同時でキャンペーンを行ったこと、そして、世界中のユーザーからサイトの不正なハッキング対策が多く寄せられたことからもわかるように、サイトの不正なハッキングの問題は全世界的に広がりを見せています。どうぞ今回ご紹介した Tips と共に以下のサイトも参考にし、ご自身のサイトの設定をもう一度確認してみてください。
ハッキングされたサイトに関するウェブマスター ヘルプ
http://www.google.co.jp/webmasters/hacked/

これからも全世界で Tips を共有し、サイトのハッキングと闘いましょう！ #NoHacked のハッシュタグはこれからもご利用ください。また質問がある際はウェブマスター ヘルプ フォーラムをご利用ください（ハッキングに関するカテゴリも用意しています）。

Google では今後もユーザー、ウェブマスターのみなさまのお役に立てる情報をどんどん発信していきたいと思っておりますので、ぜひ Google Webmasters ページ、Google Japan ウェブマスター コミュニティをフォローしてみてください。

Posted by your friendly #NoHacked helpers

こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。

• 必要な証明書タイプを決定します: シングル、マルチ ドメイン、ワイルド カード
• 2048 bit の証明書を使用します
• 同じ安全なドメイン上にあるリソースには相対 URL を使用します
• 他のすべてのドメインにはプロトコル相対 URL を使用します
• サイトのアドレスの変更方法について詳しくは、サイト移転に関するヘルプ記事をご覧ください
• robots.txt を使用して HTTPS サイトへのクロールをブロックしないでください
• 可能な限り検索エンジンがページをインデックス登録できるようにします。Noindex メタタグの使用は避けます。

新しいテスターは、ウェブマスター ツールの [クロール] セクションにあります:


Posted by Asaph Arnon, Webmaster Tools team
Original version: Official Google Webmaster Central Blog: Testing robots.txt files made easier

• リターン リンクの欠落: アノテーションは、そのアノテーションが参照しているページから確認する必要があります。ページ A がページ B にリンクしている場合、ページ B からもページ A にリンクしていなければなりません。そうでない場合、アノテーションが正しく解釈されない恐れがあります。
  この種のすべてのエラーについて、検出した場所と日時、リターン リンクが配置されるべき場所が表示されます。

• 不適切な hreflang 値: hreflang 属性の値は、ISO 639-1 形式で指定した言語コード（「es」など）か、国コード（ISO 3166-1 Alpha 2 形式で指定）と言語コードの組み合わせ（「es-AR」など）のいずれかである必要があります。
  Google のインデックス登録システムがこれらの形式以外で指定された言語コードや国コードを検出した場合は、URL の修正例が表示されます。

この新機能が、サイトでの rel-hreflang 実装に関する問題を解決する際の一助となりましたら幸いです。この機能についてご不明な点やご意見、ご感想などがありましたら、ウェブマスター ヘルプ フォーラムにご投稿ください。

Posted by Gary Illyes, Webmaster Trends
Original version: Official Google Webmaster Central Blog: Troubleshooting hreflang annotations in Webmaster Tools

レンダリングされたページを表示する

robots.txt によってブロックされたリソースの取り扱い

Posted by Shimi Salant, Webmaster Tools team
Original version: Official Google Webmaster Central Blog: Rendering pages with Fetch as Google

• 別々のファイルにある JavaScript や CSS などのリソースが（robots.txt などにより）Googlebot をブロックしている場合、Google のインデクシング システムは、そのサイトを一般ユーザーと同様には認識できません。皆様のコンテンツをインデックス登録できるように JavaScript や CSS の取得を Googlebot に許可することをおすすめします。これは、モバイル向けのウェブサイトでは特に重要です。あるページがモバイル向けに最適化されているかを Google のアルゴリズムが識別するうえで、CSS や JavaScript などの外部リソースが必要になるためです。
• ウェブ サーバーが一定数のクロール リクエストを処理できない場合、ページをレンダリングする Google の機能に影響を及ぼす可能性があります。Google がページをレンダリングできるかどうかを確認したい場合は、ご利用のサーバーでリソースのクロール リクエストを処理できるかどうかをご確認ください。
• 常に有効なのは、JavaScript 非対応の環境にも対応しておくことです。この方法を使えば、ユーザーのブラウザが互換性のある JavaScript を実装していなくてもコンテンツを表示できます。JavaScript が無効またはオフになっていても、JavaScript をまだ実行できない検索エンジンでも大丈夫です。
• 場合によっては、JavaScript が複雑すぎたり特殊すぎたりして、Google で実行できないこともあります。このような場合は、ページを完全に正しくレンダリングすることはできません。
• JavaScript によっては、コンテンツを追加するのではなく削除するものもあります。こういった場合、コンテンツのインデックス登録はできなくなってしまいます。

Posted by Erik Hendriks and Michael Xu, Software Engineers, and Kazushi Nagayama, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Understanding web pages better

• すべてのユーザーに同じコンテンツを表示する。
• ユーザーが選択できるようにする。
• ユーザーの地域と言語に応じたコンテンツを配信する。

世界中のユーザーに同じコンテンツを表示する

このシナリオでは、ある 1 つの国/言語に固有のコンテンツをホームページ/汎用 URL（http://www.example.com）で配信します。このコンテンツは、ブラウザでその URL に直接アクセスしたユーザー全員と、その URL を指定して検索したユーザー全員に表示されます。上で述べたように、それぞれの国と言語のバージョンもそれぞれ固有の URL でアクセスできるようにする必要があります。

ユーザーがローカル バージョンと言語を自由に選択できるようにする

ユーザーの地域や言語設定に応じて、ユーザーを自動的にリダイレクトする、または適切な HTML コンテンツを動的に配信する

• rel-alternate-hreflang アノテーションを使用している。
• Googlebot がアクセスしてクロールおよびインデックス登録できる: ローカライズされたページのクロールおよびインデックス登録がブロックされないようにしてください。
• ユーザーが必ずローカル バージョンまたは言語を切り替えることができる: たとえばプルダウン メニューを使用して、これを実現できます。

rel-alternate-hreflang アノテーションについて

• アノテーションは、他のページにおいても確認する必要があります。ページ A がページ B にリンクしている場合、ページ B からもページ A にリンクしていなければなりません。そうでない場合、アノテーションが正しく解釈されない恐れがあります。

• アノテーションは自分に対しても向いていなければなりません。ページ A で、そのページ自身をリンク先とした rel-alternate-hreflang アノテーションを使用する必要があります。
• rel-alternate-hreflang アノテーションは、HTTP ヘッダー、HTML の head セクション、またはサイトマップ ファイルで指定できます。シグナルの不整合やエラーを回避するために、アノテーションを実装する際は 1 つの方法で行うことを強くおすすめします。
• hreflang 属性の値は、言語については ISO 639-1 形式で、地域については ISO 3166-1 Alpha 2 形式で指定する必要があります。地域のみの指定はサポートされていません。サイトに国のみを設定したい場合は、ウェブマスター ツールの地域ターゲティング機能を使用してください。

これらの推奨事項に従うことで、ローカライズされたコンテンツが Google で認識されやすくなり、Google 検索結果でより関連性の高い結果をユーザーに提供できるようになります。ご不明な点やご意見・ご感想などありましたら、ウェブマスター  ヘルプ フォーラムにてお聞かせください。


Posted by Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts.
Original version: Official Google Webmaster Central Blog: Creating the Right Homepage for your International Users

Posted by Aaseesh Marina, Search Quality Team
Original version: Webmaster Guidelines for sneaky redirects updated

ぜひウェブマスター向け公式 Google+ ページをフォローして日々更新される情報をチェックしてみてください！

Google では引き続き、すべての言語のサイト運営者様にご参加いただきたいと考えています。提供している Android アプリでディープ リンクをサポートしていない場合や、ウェブサイトやサイトマップでこのようなリンクをまだ指定していない場合は、ぜひ対応していただき、こちらの フォーム（英語）から Google までお知らせください。

サイトマップやウェブサイトにディープ リンクを追加する際に、考慮すべきベスト プラクティスをいくつかご紹介します。

• アプリのディープ リンクは正規 URL にのみ含めるようにしてください。
• ホームページにおいてもアプリのディープ リンクを指定することをお忘れなく。
• サイトマップに含まれているすべてのウェブサイト URL に対応するアプリのディープ リンクを設定する必要はありません。提供しているアプリでサポートされていないディープ リンクを含めないようにしてください。
• ニュース サイトでニュース サイトマップを使用されている場合は、通常のサイトマップと同様に、ニュース サイトマップにもディープ リンクのアノテーションを含めるようにしてください。
• ネイティブ ARM コードを実行するディープ リンクのアノテーションを指定しないでください。これにより、すべてのプラットフォームで App Indexing が有効になります。

アプリのコンテンツがインデックスに登録されると、提供しているアプリは、通常の動作の場合と同様に HTTP  リクエストを送信する必要があります。これらのリクエストは、サーバー上では Googlebot から送信されたように表示されます。そのため、これらのリクエストを許可できるようにサーバーの robots.txt ファイルを設定する必要があります。

最後に、アプリの戻るボタンをクリックした場合に、必ず検索結果ページに直接戻ることを確認してください。

実装の詳細については、最新のデベロッパー ガイドライン（英語）をご覧ください。この記事に関するコメントやご質問は、ウェブマスター ヘルプ フォーラムまでお寄せください。

Posted by Michael Xu, Software Engineer
Original version: App Indexing updates

サイトの URL に HTTPS を使用している、または確認済みのサブディレクトリ（https://example.com/folder/ など）があるウェブマスターには、改善されたデータが表示されます。サブディレクトリのデータは、同じホスト名とプロトコルの上位レベルの確認済みサイトに含まれます。

ウェブサイトが HTTPS を使用している場合や一部のコンテンツが別のサブドメインでインデックス登録されている場合は、対応するインデックス ステータス レポートに変更内容が表示されます。下のスクリーン ショットは、HTTP と HTTPS のサイトのインデックス ステータスのグラフの例を示しています:



上の図を見ると、インデックス ステータス グラフに「更新情報」（Update）という注釈が付いています。これは、このデータの収集の開始日を示しています。この変更によって、URL のインデックス登録方法や、ドメイン レベルでインデックス登録された URL の総数が影響を受けることはありません。ウェブマスター ツールに表示されるデータのレポートが影響を受けるだけです。

データを正確に表示するには、Google ウェブマスター ツールでサイトの既存の類似パターンすべて（www. あり、www. なし、HTTPS、サブディレクトリ、サブドメイン）に対して確認を行う必要があります。Google では、優先するドメインや正規 URL を適宜設定することをおすすめします。

サイトマップを送信する場合は、対応する URL を使用してウェブサイトの優先する類似パターンに対して確認を行う必要があります。なお、robots.txt ファイルはプロトコルやホスト名ごとに区別されて読み取られます。

今回の更新がウェブサイトのインデックス登録に関する問題の解決に役立てば幸いです。詳しくは、インデックス ステータスに関するヘルプセンターの記事をご覧ください。また何かご不明な点がありましたら、お気軽にウェブマスター ヘルプ フォーラムをご利用ください。

Posted by Zineb Ait Bahajji, WTA, thanks to the Webmaster Tools team.
Original version: More Precise Index Status Data for Your Site Variations

Posted by the Google App Engine Team
Original version: App Engine IP Range Change Notice

大好きなバンドを Google で検索したとき、ナレッジグラフが表示され、そのバンドに関する情報が一覧できることに気づいた方もいるかと思います。この中には、コンサートのスケジュールに関する情報も含まれています。このスケジュールが正しく、完全であることはファンにとってもアーティストにとっても重要です。そこで、この表示に関して新しいアプローチをはじめることにしました。これからは、アーティストの公式ウェブサイト上に構造化データのマークアップが存在する場合、そこから直接その情報がナレッジグラフ内に表示されることになります。

1. schema.org マークアップをサイト上で実装する。 RDFa や microdata に加えて新しくサポートされた JSON-LD フォーマットを利用すれば、今までにない簡便さでこれが実現できます。
2. もっと簡単な方法は、 Bandsintown や BandPage、ReverbNation、Songkick や GigPress といった、既に構造化データマークアップが埋め込まれているイベントウィジェットを利用することです。
3. また、ウェブマスター ツールのデータ ハイライターを利用すれば、マウスだけであなたのサイト上のイベントをラベリングすることができます。

Posted by Justin Boyan, Product Manager, Google Search
Original version: Musical artists: your official tour dates in the Knowledge Graph

5 つのワースト プラクティス

ベスト プラクティス

• ファセット ナビゲーションの新規作成または再設計
• 既存のファセット ナビゲーション実装

背景

サイトを構築する場合、個別のコンテンツ（つまり 1 つの商品/記事、または 1 つの商品/記事カテゴリ）にアクセスするための URL は 1 つだけ、というのが理想的な状態です。このような URL であれば、特定のコンテンツにアクセスするためのクリック パスやルートは明確で、ホームページやカテゴリ ページからクリックすることでアクセスできます。

検索ユーザーにも Google 検索にも理想的な状態

• すべての商品/記事ページにアクセスできる明確な動線
  
  
  
  左側はサイトでのユーザーの動線（つまりクリック パス）、右側はアクセスするページです。
  
  
  
• 個々のカテゴリ ページを表す URL は 1 つ
  http://www.example.com/category.php?category=gummy-candies
  
  グミのカテゴリ ページ
  
  
• 個々の商品ページを表す URL は 1 つ
  http://www.example.com/product.php?item=swedish-fish
  
  魚形グミの商品ページ
  
  

ファセット ナビゲーションが原因となる望ましくない重複

• 同じ記事/商品の URL が複数存在する
  
  

  カノニカル	重複
  example.com/product.php? item=swedish-fish	example.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10

  魚形グミの同じ商品ページに複数の URL でアクセスできてしまう
  
  
• 検索ユーザーや検索エンジンにとってほとんどまたはまったく価値のないカテゴリ ページが大量に存在する
  
  

  URL	example.com/category.php? category=gummy-candies&taste=sour&price=5-10	example.com/category.php? category=gummy-candies&taste=sour&price=over-10
  Issues	[sour gummy candy price five to ten dollars] で検索するユーザーがほとんどいないとすれば何の付加価値も提供しない。 検索エンジンのクローラに何の付加価値も提供しない（「gummy candies」でも「sour gummy candies」でも同じ商品（「fruit salad」）が見つかる）。 同じカテゴリがいくつものバージョンに分かれているため、インデックス登録のシグナルが分散してしまい、サイト所有者に悪影響を及ぼす。 新しいページや更新されたページではなく重複したコンテンツに帯域幅やクローラの処理を費やすことになり、サイト所有者に悪影響を及ぼす。	検索エンジンに何の価値も提供しない（404 ステータス コードを返すべき）。 検索ユーザーに悪影響を及ぼす。

ファセット ナビゲーションのワースト・プラクティス

ワースト プラクティス 1: パラメータに標準的でない URL エンコードを使用している（「キー=値」ペアではなくカンマやかっこなどを使用している）

ワースト プラクティス:

• example.com/category?[category:gummy-candy][sort:price-low-to-high][sid:789]
• キー=値ペアに = ではなく : が使用されている
• 複数のパラメータが & ではなく [ ] で追加されている
• example.com/category?category,gummy-candy,,sort,lowtohigh,,sid,789
• キー=値ペアに = ではなく , が使用されている
• 複数のパラメータが & ではなく ,, で追加されている

ベスト プラクティス:

example.com/category?category=gummy-candy&sort=low-to-high&sid=789

人間であれば「,,」のような非標準の URL パラメータを解読できますが、クローラがこのような URL パラメータを解釈するのは難しくなります。Google のクロール チームのソフトウェア エンジニアである Mehmet Aktuna は、「標準以外のエンコードを使用するのは、わざわざ災難を招いているようなものだ」と述べています。キー=値ペアには等号（=）を使用し、複数のパラメータの追加にはアンパサンド（&）を使用してください。

ワースト プラクティス 2: ページ コンテンツを変更しない値を、パラメータではなくディレクトリやファイル パスとして追加する

ワースト プラクティス:

example.com/c123/s789/product?swedish-fish
（/c123/ がカテゴリ、/s789/ がセッション ID だがページ コンテンツは変更されない）

グッド プラクティス:

example.com/gummy-candy/product?item=swedish-fish&sid=789（ディレクトリ /gummy-candy/ によってページ コンテンツが意味のある形で変更される）

ベスト プラクティス:

example.com/product?item=swedish-fish&category=gummy-candy&sid=789 （URL パラメータにしたことで柔軟性が増し、検索エンジンが効率的にクロールできる）

有用な値（たとえば「gummy-candy」）と有用でない値（たとえは「sessionID」）をパスに直接記述した場合、自動化されたプログラム（たとえば検索エンジン クローラ）がそれらを区別することは困難です。一方、URL パラメータを使用すれば検索エンジンにとって柔軟性が増し、クローラが各値のすべてのパターンにアクセスする必要があるかどうかを判断しやすくなります。
ページ コンテンツを変更せず、URL パラメータとして設定されるべき一般的な値には次のものがあります:

• セッション ID
• トラッキング ID
• リファラー ID
• タイムスタンプ

ワースト プラクティス 3: ユーザー生成値を、クロールもインデックス登録も可能だが、検索結果では有用でない（場合によっては無限の）URL パラメータに変換する。

ワースト プラクティス（例: 緯度/経度、「～日前」といったユーザーごとに変動する値を含む URL をクロールとインデックス登録の対象にする）:

• example.com/find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
• example.com/article?category=health&days-ago=7
  

ベスト プラクティス:

• example.com/find-a-doctor?city=san-francisco&neighborhood=soma
• example.com/articles?category=health&date=january-10-2014

ユーザーごとに変動する値を含む URL をクロールするようにしても、処理が無限になる可能性があるだけで、検索ユーザーにとってはほとんど価値がありません。それよりも、最も一般的な値のカテゴリ ページを公開して追加情報を含めるようにすると、通常の検索結果ページより多くの付加価値を提供できます。ユーザー生成値を使用する場合は、生成値を別のディレクトリに格納し、robots.txt がそのディレクトリをクロールしないように設定します。

• example.com/filtering/find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
• example.com/filtering/articles?category=health&days-ago=7

robots.txt を使用する場合:

User-agent: *
Disallow: /filtering/

ワースト プラクティス 4: URL パラメータの追加に論理性がない

ワースト プラクティス:

• example.com/gummy-candy/lollipops/gummy-candy/gummy-candy/product?swedish-fish
• example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&cat=gummy-candy&item=swedish-fish

ベター プラクティス:

example.com/gummy-candy/product?item=swedish-fish

ベスト プラクティス:

example.com/product?item=swedish-fish&category=gummy-candy

関連性の低い URL パラメータを追加しても、重複が増えてクロールやインデックス登録の効率が下がるだけです。URL を生成する前に、不要な URL パラメータを削除してサイト内を「整理整頓」しましょう。ユーザー セッションに必要なパラメータが多い場合は、cat=gummy-candy&cat=lollipops&cat=gummy-candy& ... のように次々と値を追加するのではなく、Cookie を使って情報を保持するようにします。

ワースト プラクティス 5: 該当する検索結果のない絞り込み条件が表示されている

ワースト プラクティス:

該当する商品が 1 つもない絞り込み条件が選択可能になっている。

該当する結果がない絞り込み条件（この例では price=over-10）が選択できる状態になっています。これではユーザーがイライラし、検索エンジンで無用な問題が発生する原因にもなります。

ベスト プラクティス:

ユーザーの選択が妥当な場合（つまり商品が存在するとき）にのみリンク/URL が生成されるようにします。該当する商品がないフィルタ条件はグレー表示されるようにします。使い勝手をさらに向上させるには、各フィルタ条件の横に該当する商品数を表示することも検討してください。

検索結果がゼロになる絞り込み条件（ここでは price=over-10）が選択できないようになっています。これにより、ユーザーが無駄なクリックをする心配がなく、検索エンジンのクローラが不要なページにアクセスすることもありません。

無用な URL をなくしてクロール領域を最小にするには、商品が存在するときにのみ URL が生成されるようにします。これにより、商品が存在しないページが表示されなくなり、ユーザー エクスペリエンスが高まるだけでなく、クローラが認識する URL の数も最小限に抑えることができます。また、ページの商品が一時的に在庫切れになっているわけではなく、今後もそのページに有益なコンテンツが掲載される可能性が低い場合は、404 ステータス コードを返すことを検討してください。404 を返すことで、ユーザーに対して他のナビゲーション オプションを示すダイアログを表示したり、関連商品を見つけるための検索ボックスを表示したりできます。

ファセット ナビゲーションを新規作成/再設計する際のベスト プラクティス

これからサイトにファセット ナビゲーションを実装する場合は、独自のコンテンツ ページの「クロール領域」（Googlebot がサイト内で認識するすべての URL）を最適化し、重複するページのクロールを減らし、インデックス登録のシグナルを統合するための方法を検討しましょう。以下のようにいくつかの方法があります:

• クローラがすべてのコンテンツ ページをクロールするのに必要な URL パラメータ（たとえば、アイテムごとに少なくとも 1 つのクリック パスを作成するために必要なパラメータ）を特定します。必要なパラメータとしては、item-id、category-id、page などが考えられます。
• 検索ユーザーにとって価値があるパラメータはどれか、クロールやインデックス登録において重複の原因になるだけの不要なパラメータはどれかを特定します。グミの例では、たとえば「taste」パラメータは検索ユーザーにとって有用です。[sour gummy candies] で検索すると、結果として example.com/category.php?category=gummy-candies&taste=sour が表示されます。一方、「price」パラメータは、category=gummy-candies&taste=sour&price=over-10 のような重複の原因になるだけです。以下に一般的な例を示します:
• 検索ユーザーに有用なパラメータ: item-id、category-id、name、brand...
• 不要なパラメータ: session-id、price-range...
• 不要なパラメータが含まれている URL の場合は、以下のいずれかの設定オプションを実装することを検討してください。なお、不要な URL パラメータは、クローラや、個別の商品にアクセスするためのユーザーのクリック パスでは必要ありません。
  
  
  • オプション 1: rel="nofollow" 内部リンクを使用する

    すべての不要な URL へのリンクに rel="nofollow" を追加します。このオプションを追加すると、クローラによって不要な URL がクロールされるのを最小限に抑えることができ、ファセット ナビゲーションによってクロール領域（クローラが認識する URL の領域）が極端に大きくなるのを防ぐことができます。なお、rel="nofollow" は不要な URL のクロールをブロックするわけではありません（クロールをブロックできるのは robots.txt の disallow だけです）。ただし、不要な URL へのクロールを許可することで、それらの URL からのインデックス登録のシグナルを、ユーザーにとって有用な URL に統合することもできます。それには、不要な URL に上位の URL への rel="canonical" を追加します。たとえば、example.com/category.php?category=gummy-candies&taste=sour&price=5-10 に rel="canonical" を追加し、上位 URL として example.com/category.php?category=gummy-candies&taste=sour&page=all）（すっぱいグミをすべて表示するページ）を指定します。

  • オプション 2: Robots.txt の disallow

    不要なパラメータを含む URL に、robots.txt でクロールをブロックする /filtering/ ディレクトリを含めます。これにより、すべての検索エンジンが有用なコンテンツを自由にクロールできるようになりますが、不要な URL のクロールはブロックされます。たとえば、有用なパラメータが item、category、taste で、不要なパラメータが session-id と price だとします。例:
    example.com/category.php?category=gummy-candies
    このような URL を、別の有用な URL パラメータ（たとえば taste）にリンクさせることができます。
    example.com/category.php?category=gummy-candies&taste=sour.
    ただし、不要なパラメータ（たとえば price）を追加する場合は、URL に定義済みのディレクトリ /filtering/ を含めます:
    example.com/filtering/category.php?category=gummy-candies&price=5-10
    これでこの URL は、robots.txt によってクロールがブロックされます。
    

    User-agent: *
Disallow: /filtering/

  • オプション 3: ホストを別々にする

    CDN を使用していない場合（CDN を使用しているサイトでは、上記のようなウェブマスター ツールの柔軟な機能を利用することはできません）は、不要なパラメータを含む URL を別のホストに配置することを検討してください。たとえば、メイン ホスト www.example.com とサブ ホスト www2.example.com を作成します。サブ ホスト（www2）では、ウェブマスター ツールのクロール速度を低く設定します（メイン ホストはできるだけ高く設定したままにします）。これにより、メイン ホストの URL は完全にクロールされますが、不要な URL が Googlebot によってクロールされる可能性が低くなります。
    

    • メイン ホストのすべてのアイテムに、1 つ以上のクリック パスがあることを確認してください。
    • インデックス登録のシグナルを統合したい場合は、サブ ホストからメイン ホストの上位 URL への rel="canonical" を追加することを検討してください（例: www2.example.com/category.php?category=gummy-candies&taste=sour&price=5-10 に rel="canonical" を追加し、上位 URL として www.example.com/category.php?category=gummy-candies&taste=sour&page=all（すっぱいグミをすべて表示するページ）を指定します）。

• 特定のカテゴリ/フィルタに該当商品がない場合はリンクをクリックできないようにします。
• URL パラメータが論理的に表示されるようにします。
• 値を次々と追加するのではなく、不要なパラメータを削除するようにします。
• 悪い例
  example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&item=swedish-fish)
• 検索ユーザーにとって有用なパラメータを先に記述し、関連性の低いパラメータ（たとえばセッション ID）を後に記述します。URL が検索に表示されることもあるため、パラメータの順序に一定のルールを設けユーザー エクスペリエンスを高めます。
• 悪い例
  example.com/category.php?session-id=123&tracking-id=456&category=gummy-candies&taste=sour
• rel=”canonical” を使用して、個々のコンテンツ ページのインデックス登録を望ましいページに統合します。rel="canonical" は、ホスト名やドメインをまたがって使用できます。
• ページ指定されたコンテンツ（たとえば「グミ」カテゴリの page=1、page=2）のインデックス登録を、以下のいずれかの方法で改善します:
• シリーズを構成する各ページに、カテゴリの「すべて表示」ページへの rel="canonical" を追加します（例: 「グミ」カテゴリの page=1、page=2、page=3 に category=gummy-candies&page=all への rel="canonical" を追加します）。その際に、検索ユーザーのエクスペリエンスを損なわない（各ページがすばやく読み込まれるなど）よう注意してください。
• コンテンツの並べ替え、フィルタリング、非表示を、URL の更新ではなく JavaScript で動的に行う場合でも、クロールやインデックス登録の対象となるメインのカテゴリ ページや商品ページの URL はユーザーにとって有用な情報です。JavaScript でコンテンツを動的に変更する場合は、サイト全体を表す URL としてホームページのみ（つまり 1 つの URL のみ）を使用することは避けてください。これでは検索ユーザーが、1 つの URL でサイト内のすべてのコンテンツにアクセスすることになってしまいます。また、動的なフィルタリングによってパフォーマンスが低下することがありますので注意してください。これにより、ユーザー エクスペリエンスが損なわれる可能性があります。
• サイトマップには canonical URL のみ含めるようにしてください。