クロールとインデックス | SEO-LPO.net

App Indexing の実装に不可欠な 4 つのステップ

ディープリンクは、オーガニック検索内で最近見かけるようになった「新入り」ですが、目を見張るような速さで普及しています。ユーザーがログインしている場合、Android での Google 検索結果のうち、15% が App Indexing によるアプリディープリンクを表示しています。前四半期だけで、アプリディープリンクのクリック数が 10 倍に急増しました。

App Indexing を今年 6 月に公開して以来、デベロッパーの皆様からさまざまなフィードバックが寄せられました。ほとんどの実装はうまく行きましたが、うまく行かなかった実装からも多くを学ぶことができました。この記事ではそうした経験を踏まえ、App Indexing の実装を成功させるうえで欠かせない 4 つのステップについて解説します。また、アプリのパフォーマンスを把握したり、アプリの利用を促進したりするための便利な新機能も紹介します。

1. デベロッパーにウェブマスターツールへのアクセス権限を付与する

App indexing は、ウェブマスターとアプリデベロッパーが協力して取り組む必要があります。ウェブマスターツールには、デベロッパーが必要とする情報も表示されます。現時点で表示されるのは以下の情報です。

アプリ内のインデックス登録済みページのエラー
Google 検索でのアプリディープリンクのクリック数とインプレッション数（週単位）
サイトマップに関する統計情報（アプリディープリンクをサイトマップで実装した場合）

今後これらの他にもさまざまな情報を追加する予定です。

しかしながら、ウェブマスターツールへのアクセスが許可されているデベロッパーは非常に少ないようです。アプリ関連の問題の修正に必要な情報を確実に伝達するには、デベロッパーにウェブマスターツールへのアクセス権限を付与することが不可欠です。

確認済みのサイト所有者であれば、新しいユーザーを追加できます。付与したい権限レベルに応じて [制限付き] または [フル] を選択してください。

2. 検索結果からのアプリへのアクセス状況を把握する

ユーザーは、検索結果からアプリにアクセスしてくれているでしょうか。アプリディープリンクのパフォーマンスをトラッキングする方法として次の 2 つを追加しました。

ウェブマスターツールアカウントのメッセージセンターに、週ごとのクリック数とインプレッション数が送信されるようになりました。
アプリディープリンクによってどれくらいのトラフィックがアプリにアクセスしたかを、リファラー情報（具体的には ACTION_VIEW インテントのリファラー extra）を使用してトラッキングできるようになりました。将来的には、この情報を Google アナリティクスに統合して簡単にアクセスできるようにする予定です。デベロッパーサイトでは、リファラー情報をトラッキングする方法（英語）について解説しています。

3. アプリの重要なリソースがクロール可能であることを確認する

ウェブマスターツールのクロールエラーレポートで、「コンテンツの不一致」エラーが発生する大きな原因の 1 つがリソースのブロックです。クロールでは、アプリページをレンダリングするために必要なすべてのリソースにアクセスする必要があります。これにより、アプリページのコンテンツが、関連付けられているウェブページと同じかどうかを確認できます。

アプリページのレンダリングに不可欠なリソースにアクセスできない場合に、どのリソースがブロックされているかを簡単に特定できるようになりました。アプリで「コンテンツの不一致」エラーが発生した場合は、詳細ダイアログの手順 5 に沿ってブロックされているリソースの一覧を確認してください。

4. Android アプリのエラーに注意する

アプリのインデックス登録時のエラーを簡単に特定できるようにするため、検出されたすべてのアプリエラーをメッセージとして送信することになりました。また、そのほとんどがクロールエラーレポートの [Android アプリ] タブにも表示されます。

従来の「コンテンツの不一致」エラーと「インテント URI が無効」エラーに加え、以下の 3 つのエラータイプを追加しました。

APK が見つからない: アプリに対応するパッケージが見つからない
First Click Free（英語）がない: アプリへのリンクがコンテンツに直接つながっておらず、ログインしないとアクセスできない
戻るボタンの違反: アプリへのリンクをたどって移動した後、戻るボタンで検索結果に戻ることができない

これまでの経験から、エラーの大部分はアプリの一般的な設定が原因であることがわかっています（リソースがブロックされている、ユーザーが検索結果からアプリを開こうとすると地域選択のポップアップが表示されるなど）。これらの点に注意することで、関連する URI の問題をすべて解決できるはずです。

App Indexing 実装がうまく行くことを願っています。ご不明な点がありましたら、いつでもウェブマスターヘルプフォーラムまでお寄せください。

Posted by Mariya Moeva, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: The four steps to appiness

検索結果内の検索ボックスが新しくなりました

このたび、サイトリンクの検索ボックスが新しくなりましたのでお知らせいたします。この検索ボックスを使用すると、ユーザーはサイト独自の検索ページを通じて直接サイト内の特定のコンテンツに簡単にアクセスできるようになります。

この検索ボックスの仕組みと検索結果に表示されるタイミング

たとえば [ABC 出版] や [株式会社 XYZ] のように名前で会社を検索する場合、ユーザーは実際にはそのウェブサイト内の特定の情報を探しているかもしれません。今までは、Google のアルゴリズムでこのような検索キーワードが認識されると、多数のサイトリンクが表示され、その検索結果の下に追加の検索ボックスが表示されていました。ユーザーはこの検索ボックスを使用して検索結果から直接、このサイトにsite: 検索を行うことができます（例: [site:example.com 登山ガイド]）。

今回は、この検索ボックスが改良され、オートコンプリートにも対応しました。正しいマークアップが使用されていれば、ユーザーはウェブサイトの独自の検索ページに直接リダイレクトされます。

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

サイトでは、サイト固有の検索エンジンを使用している必要があります。既に使用している場合は、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

robots.txt ファイルのテストが簡単になりました

クロールするべきか、しないべきか、それが robots.txt の問題です。

正しい robots.txt ファイルを作成して維持することは、ときに難しい場合もあります。ほとんどの場合はそうではありませんが（そもそも robots.txt ファイルを必要としないサイトも多くあります）、大きな robots.txt ファイル内で個々の URL をブロックしている（またはブロックしていた）指定を見つけることは、難しい作業となる場合もあるでしょう。そこで、robots.txt ファイルの編集を容易にするために、このたび、新しい robots.txt テスターを発表いたします。

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

ここでは、現在の robots.txt ファイルの確認、および URL のクロールがブロックされているかどうかのテストを行うことができます。複雑な指定をわかりやすくするため、最終的に決定に使われた箇所がハイライト表示されます。ファイルに変更を加えてテストを行うこともできます。変更を有効にするには、変更したファイルをサーバーにアップロードしてください。Google のデベロッパーサイトでは、robots.txt の指定とファイルの処理方法について詳しく説明しています (英語)。

また、古いバージョンの robots.txt を確認したり、サーバー側の問題によってクロールがブロックされている状況を確認したりすることもできます。たとえば、robots.txt ファイルが Googlebot に対して 500 サーバーエラーを返している場合、通常そのサイトのクロールは一時停止されます。

既存のサイトでエラーや警告が表示される可能性もあるため、robots.txt ファイルをよく確認することをおすすめします。また、robots.txt テスターをウェブマスターツールの他の機能と組み合わせることも可能です。たとえば、新しい Fetch as Google を使用してウェブサイトの重要なページをレンダリングした際、ブロックされた URL が見つかったら、robots.txt テスターを使って、その URL をブロックしている指定を見つけて修正することができます。CSS、JavaScript、モバイルコンテンツをブロックする古い robots.txt ファイルが原因で問題が発生することはしばしばありますので、そのような問題は、修正すべき箇所がわかれば簡単に修正できます。

今回更新したツールを使うことで robots.txt のテストとメンテナンスが容易になれば幸いです。何かご不明な点がある場合や、robots.txt の指定の作成についてアドバイスが欲しい場合などは、ぜひウェブマスターヘルプフォーラムをご利用ください。

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

Android の App Indexing が誰でもご利用いただけるようになりました！

もしあなたがウェブサイトと Android アプリを両方持っているのなら、それらを連携させることで、スマートフォンやタブレットから Google で検索しているユーザーにとって、検索結果からアプリへの起動を非常に簡単にすることができるようになりました。

検索結果に表示されるアプリのディープリンクは、あなたのアプリが既にインストールされている端末の検索結果において、アプリ内のコンテンツへのアクセスをより容易にします。ウェブサイトのページを対応するアプリ側の部分へと接続することで、サイトオーナーとして、適切なコンテンツを、適切なタイミングでユーザーに見せることができるようになります。

いくつものアプリが既に App Indexing を実装しています。今週の Google I/O で、ディープリンクの設定、サイトのアプリへの接続、パフォーマンスやエラーのトラッキングといった一連のプロセスをより容易にするための機能を発表いたしました。

簡単に始められます

このたび、アプリのディープリンクをインデックスさせるために必要なプロセスを大きく簡易化しました。アプリが既に HTTP によるリンクをサポートしているのであれば、

あなたの URL 群がインデックスされると共に、Google はアプリとサイトの繋がりを発見し、検索結果でディープリンクを使用したアプリへの直接的な遷移を可能にします。

アプリのディープリンクの発見とインデックス作業を Google に任せることもできますが、あなた自身がこれらのディープリンクを埋め込み、公開することをおすすめします。もしあなたのアプリがカスタムディープリンクスキームをサポートしている場合は特にそうです。そのためには、2 つの方法があります:

各ウェブページに対して、rel="alternate" 属性を持った link 要素を <head> 部分に埋め込むか、サイトマップを利用して android-app URI を指定する。デベロッパーサイト上で実装方法を確認できます。
App Indexing API （英語）を利用する。

また、このたび、アプリページをインデックスする際に発生した問題について報告を行う新しい機能をウェブマスターツールに追加しました。ここでは、各アプリページとウェブページのペアについて検知されたエラーと、デバッグのためのサンプルアプリ URI確認することができます。

また、それぞれの問題について、その詳細なデバッグ方法も確認することができます。アプリのディープリンクの QR コードも含まれていますので、携帯電話やタブレットで簡単にリンクを開けます。エラーが検知された場合、ウェブマスターツール上でメッセージもお送りいたします。

App Indexingは既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。

クックパッド、ヤフオク、楽天市場、Hot Pepper Gourmet、タウンワーク、pixiv、 WEAR

ぜひ App indexing をお試しください。何かご質問があれば、ウェブマスターヘルプフォーラムへ！

Posted by Mariya Moeva, Webmaster Trends Analyst
Original version: Android app indexing is now open for everyone!

サイトの移転をより容易に

ウェブマスターの皆様にとって、サイトの移転ほど厄介で悩ましい問題はないかもしれません。このたび Google では、スムーズなサイト移転をサポートすることを目的に、Googlebot と相性の良い移転の方法についての詳細なガイドを作成しました。では、サイト移転とは正確には何であり、それを適切に行うにはどうすればよいのでしょうか。

サイト移転の基本

一般的に、サイト移転とは、以下のいずれかの方法でコンテンツを移動させることです。

URL を変更せずにサイトを移転する: URL 構造には変更を加えずに、ウェブサイトをホストしている基底のインフラストラクチャのみを変更します。たとえば、www.example.com を、同じ URL とサイト構造を維持したまま別のホスティングプロバイダに移行する場合などがこれにあたります。
URL を変更してサイトを移転する: この場合、ウェブサイトの URL の変更にはさまざまなパターンがあります。

プロトコル: http://www.example.com を https://www.example.com に変更する
ドメイン名: example.com を example.net に変更する
URL のパス: http://example.com/page.php?id=1 を http://example.com/widget に変更する

サイトの移転が適切に行われていないケースや、サイトの移転を問題なく完了するうえで非常に重要となる手順が踏まれていないケースも多く見られます。そこで Google では、ウェブマスターの皆様が適切にサイトの移転を計画、実施できるよう、ヘルプセンターのサイト移転ガイドラインを更新しました。また同時に、このガイドラインに沿ってサイトの移転が行われた場合にサイトの移転を検出して処理できるよう、クロールとインデックス登録のシステムの改良も続けています。

レスポンシブウェブデザインへの変更

モバイル用の URL を別に設定している場合や動的配信を行っている場合にウェブサイトでレスポンシブウェブデザインを使用するよう変更するにはどうすればよいか、といった質問も増えつつあります。この設定の変更について詳しくは、スマートフォン向けサイトの推奨事項についてまとめたサイトに新たに追加されたこちらのページをご覧ください。

ご不明な点がある場合はウェブマスターヘルプフォーラムで質問してみてください。

Posted by Pierre Far and Zineb Ait Bahajji, Webmaster Trends Analysts
Original version: Official Google Webmaster Central Blog: Making site moves easier

Fetch as Google でページをレンダリングできるようになりました

ウェブマスターツールの Fetch as Google 機能を使用すると、Googlebot がどのようにページを取得しているかを確認できます。ここで表示されるサーバーヘッダーや HTMLは、技術的問題やハッキングの影響を診断するのに役立ちますが、その理解が難しい場合もあるでしょう。「このコードの意味は何？」、「本当に自分のブラウザで見ているのと同じページなんだろうか？」「今日の昼ごはんはどこで食べよう？」...。昼ごはんをどこで食べるかについてはお助けできませんが、他の問題を解決するために、このたび Google はウェブマスターツールを拡張し、Google がページをどのようにレンダリングしているかを確認できるようにしました。

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

Googlebot は、ページをレンダリングする際、そのページに関係するすべての外部ファイルをできるだけ見つけて取得しようとします。その際、画像、CSS、JavaScript ファイルだけでなく、CSS や JavaScript によって間接的に埋め込まれるファイルも取得した上で、Googlebot のページ認識のプレビュー画像を描画することになります。

Fetch as Google 機能は、ウェブマスターツールの [クロール] セクションにあります。[取得してレンダリング] をクリックして URL を送信して処理が完了するのを待ちます（ページによっては少し時間がかかる場合があります）。処理が完了したら、表示された行をクリックして結果を確認します。

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

Googlebot は、すべてのファイルを robots.txt の指示に従って取得します。クロールを許可していないファイルがある場合（または、Googlebot のクロールが許可されていないサードパーティサーバーからファイルを埋め込んでいる場合）、そのファイルはレンダリング時に利用できません。同じように、サーバーが応答しない場合やエラーが返された場合も、それらのファイルを利用することはできません（こうした問題の詳細は、ウェブマスターツールの [クロールエラー] セクションで確認できます）。こうした問題が発生した場合は、プレビュー画像の下に詳細が表示されます。

サイトに表示されるコンテンツやそのレイアウトに大きく影響する埋め込みリソースについては、Googlebot がアクセスできるかどうかを確認しておくことをおすすめします。Fetch as Google が使いやすくなるだけでなく、Googlebot がそれらのコンテンツを見つけてインデックスに登録することが可能になります。サイトに表示されるコンテンツやそのレイアウトにあまり影響しない一部のコンテンツタイプ（ソーシャルメディアボタン、フォント、ウェブサイト分析スクリプトなど）は、クロールできない状態のままでも構いません。詳しくは、以前ブログに投稿した「ウェブページをより深く理解するようになりました」という記事をご覧ください。

今回のアップデートによって問題の診断が容易になり、誤ってクロールがブロックされていたコンテンツが発見され、クロールされるようになることを願っております。ご不明な点やご意見などありましたら、ウェブマスターヘルプフォーラムまでお寄せください。

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

ウェブページをより深く理解するようになりました

Google のサーバーが Susan Wojcicki のガレージで動いていた 1998 当時は、JavaScript や CSS はあまり気にかける必要もありませんでした。それらはあまり使用されておらず、JavaScript はページ要素にちょっとした動きなどを加えるために使用されてるだけでした。そのときと今では状況が大きく変わりました。今やウェブの世界は、JavaScript を最大限に活用したリッチでダイナミックで魅力的なウェブサイトであふれています。今回は、よりリッチなウェブサイトをレンダリングする Google の能力についてご紹介します。Google は現在、最新のウェブブラウザに近いコンテンツの表示、外部リソースの追加、JavaScript の実行、CSS の適用を実現しています。

以前は、HTTP レスポンスのボディから取得されるテキスト形式のコンテンツだけが認識されており、JavaScript が動作する一般的なブラウザにどのようなコンテンツが実際に表示されているかを解釈することは行っていませんでした。JavaScript を使用した時にのみ表示される価値のあるコンテンツを表示するページ群が登場しても、検索ユーザーにそのコンテンツの情報を伝えることはできませんでした。これは検索ユーザーとウェブマスターの両方にとって悲しい結末です。

この問題を解決するために、Google では JavaScript を実行してページを把握する方法を試すことにしました。現在のウェブの規模でそれを行うことは困難ですが、やるだけの価値はあると判断したのです。これを実現するため、Google のシステムは、時間をかけて徐々に改良されてきました。ここ数か月間、Google のインデックス登録システムは、かなりの数のウェブページを JavaScript が有効な一般ユーザーのブラウザのようにレンダリングしています。

場合によっては、レンダリング時の処理が完全にはうまくいかないこともあり、皆様のサイトの検索結果に影響を及ぼす可能性があります。その場合の考えられる原因と、その問題の回避方法（可能な場合）の例を以下にご紹介いたします。

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

現在 Google ではデバッグがより簡単にできるように、ウェブマスターの皆様が Google によるサイトのレンダリング状況を詳しく把握できるようなツールの開発に取り組んでおります。近いうちにウェブマスターツールで皆様にご提供する予定です。

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

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

海外のユーザーに適したホームページの作成

複数の国で事業を行っている場合や複数の言語をターゲットとしている場合は、それぞれの国または言語をターゲットとする URL に応じたコンテンツを含むサイトまたはセクションを別個に提供することをおすすめします。たとえば、ターゲット地域を米国に、ターゲット言語を英語に設定したページと、ターゲット地域をフランスに、ターゲット言語をフランス語に設定したページを用意します。多地域、多言語のサイトの処理について別の記事でご説明していますが、ホームページはやや特別です。この記事では、言語や地域に応じてユーザーにふさわしいコンテンツを提供できるよう、ウェブサイトに適切なホームページを作成する方法について解説します。

ユーザーがアクセスしたときのホームページ/リンク先ページの動作を設定する場合、次の 3 つのパターンがあります:

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

それぞれの設定について詳しく見ていきましょう。

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

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

注: 別の地域のユーザーや別の言語を設定しているユーザーに対し、より適切なバージョンのコンテンツが用意されていることを知らせるバナーをページに表示することができます。

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

この設定では、ホームページ/汎用 URL で国選択ページを提供し、ユーザーが国と言語に応じて表示したいコンテンツを選択できるようにします。その URL を入力したすべてのユーザーは同じページにアクセスすることになります。

国際化したサイトでこのシナリオを実装する場合は、国選択ページに x-default rel-alternate-hreflang アノテーションを必ず使用するようにしてください。このアノテーションは、特にこのようなページで使用する目的で作成されています。x-default 値は、1 つの言語または地域に固有ではないページを Google が認識しやすくするためのものです。

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

この 3 番目のシナリオでは、ユーザーの地域や言語設定に応じて、適切な HTML コンテンツを自動的に配信します。このシナリオの実装は、サーバーサイドで 302 リダイレクトを使用するか、適切な HTML コンテンツを動的に配信することで実現できます。

ホームページ/汎用ページでは必ず x-default rel-alternate-hreflang アノテーションを使用してください（汎用ページが、ユーザーが直接アクセスできないリダイレクトページである場合も同様です）。

注: 特定のバージョンを用意していないユーザー層のリダイレクトについても考慮する必要があります。たとえば、英語、スペイン語、中国語のバージョンが用意されているウェブサイトにフランス語を使用するユーザーがアクセスしたとします。この場合は、最も適切であると思われるコンテンツを表示することになります。

いずれの設定を選択した場合でも、国や言語の選択ページを含むすべてのページが次の条件を満たしている必要があります:

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

注: 冒頭で述べたように、国や言語のバージョンごとに別個の URL を用意する必要があります。

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

どの方法を選択したかにかかわらず、必ずすべてのページにアノテーションを追加してください。アノテーションにより、検索エンジンで適切な結果がユーザーに表示される可能性が大幅に高くなります。

国選択ページ、リダイレクトまたは動的に配信されるホームページでは必ず x-default hreflang を使用する必要があります。これは、自動的にリダイレクトされるホームページや国選択専用のアノテーションです。

最後に、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

App Indexing の最新情報

昨年、検索結果から Android アプリへ直接つながるディープリンクが Google の検索結果に表示される App Indexing を米国で提供を開始したことをこちらのブログでもお知らせしました。Google では今回、新たに 20 を超えるアプリを追加で有効にし、間もなく検索結果にアプリのディープリンクが表示されるようになります。また、英語のコンテンツへのアプリのディープリンクを全世界でご利用いただけるようになりましたことを、お知らせします。

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

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

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

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

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

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

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

インデックスステータスのデータがサイトのバリエーションに対応し、より正確に

Google ウェブマスターツールのインデックスステータス機能では、Google によってインデックスされた、サイトのページ数がレポートされます。以前は、HTTPS サイトのインデックスステータスのデータは独立して表示されず、HTTP サイトのレポートにすべて含まれていました。しかし、ここ数か月の間に、ウェブマスターツールを使用してウェブサイトのセクション（HTTPS を使用している場合など）ごとにインデックス登録された URL を追跡したいとのご意見をウェブマスターのみなさまからいただきました。

現在、URL 全体の約 10% が既に安全な接続を使用して HTTPS 経由でデータ転送を行っていることがわかっています。今後は、より多くのウェブマスターの方々がウェブサイトを HTTP から HTTPS に移行することを期待しています。Google では、サイトのインデックスステータスのデータに関してウェブマスターツールでの表示方法を改善しました。インデックスステータス機能では、プロトコル（HTTP と HTTPS）別や、確認済みのサブディレクトリレベルでインデックス登録されたサイト URL を追跡できるようになりました。

これにより、サイトの異なるセクションを簡単にモニタリングできるようになります。たとえば、次の URL は、それぞれ別々に確認を行った場合、ウェブマスターツールのインデックスステータスレポートでデータが区別されて表示されます:

HTTP	HTTPS
http://www.example.com/	https://www.example.com/
http://example.com	https://example.com
http://www.example.com/folder/	https://www.example.com/folder/
http://example.com/folder/	https://example.com/folder/

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

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

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

ファセットナビゲーションは、検索結果を色や価格帯でさらに絞り込む仕組みです。ユーザーにとって便利な機能ですが、重複するコンテンツを持つ URL の組み合わせが数多く生成されてしまうと、検索に悪影響を及ぼすことがあります。例えば、コンテンツが追加されたり更新されたりした際クロールに時間がかかったり、あるいは、複数の重複 URL にシグナルが分散した結果、インデックス登録が正しく行われなかったり、といったことが起こる可能性があります。ここでは、これらの問題を解消し、ファセットナビゲーションサイトを可能な限り検索エンジンと相性の良いものにする方法を以下のとおり説明します。

ファセットナビゲーションでフィルタを選択すると URL の組み合わせが多くなる
例: http://www.example.com/category.php?category=gummy-candies&price=5-10&price=over-10

背景

サイトを構築する場合、個別のコンテンツ（つまり 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" を追加します）。その際に、検索ユーザーのエクスペリエンスを損なわない（各ページがすばやく読み込まれるなど）よう注意してください。
rel="next" と rel="prev" でページ指定をマークアップして、リンクなどのインデックス登録のプロパティを構成ページ/URL からシリーズ全体に統合します。

コンテンツの並べ替え、フィルタリング、非表示を、URL の更新ではなく JavaScript で動的に行う場合でも、クロールやインデックス登録の対象となるメインのカテゴリページや商品ページの URL はユーザーにとって有用な情報です。JavaScript でコンテンツを動的に変更する場合は、サイト全体を表す URL としてホームページのみ（つまり 1 つの URL のみ）を使用することは避けてください。これでは検索ユーザーが、1 つの URL でサイト内のすべてのコンテンツにアクセスすることになってしまいます。また、動的なフィルタリングによってパフォーマンスが低下することがありますので注意してください。これにより、ユーザーエクスペリエンスが損なわれる可能性があります。

サイトマップには canonical URL のみ含めるようにしてください。

サイトに既にファセットナビゲーションが実装されている場合のベストプラクティス

前のセクションで説明したベストプラクティス（たとえば不要な URL の rel="nofollow"）は、既存のサイトのファセットナビゲーションを大幅に再設計する場合にも適用できます。ただし、既存のファセットナビゲーションの場合は、検索エンジンが認識したクロール領域が既に大きくなっているケースが多いようです。したがって、Googlebot によりクロールされる不要なページを増やさないようにすることと、インデックス登録のシグナルの統合を検討することが重要になります。

可能な場合は、標準のエンコードとキー=値ペアによるパラメータを使用します。
ページコンテンツを変更しない値（セッション ID など）は、ディレクトリではなく標準のキー=値ペアとして実装されていることを確認します。
特定のカテゴリ/フィルタに商品が存在しない場合には、クリック可能なアンカーを使用しないようにします（つまり、フィルタを実行して該当するアイテムが見つからない場合には、クリックされたり、URL が生成されたりしないようにします）。
URL パラメータが論理的に表示されるようにします。

値を次々と追加するのではなく、不要なパラメータを削除するようにします（例: example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&item=swedish-fishのような URL は避けます）。

検索ユーザーにとって有用なパラメータを先に記述し、関連性の低いパラメータ（たとえばセッション ID）を後に記述します。URL が検索に表示されることもあるため、パラメータの順序に一定のルールを設けユーザーエクスペリエンスを高めます（例: example.com/category?session-id=123&tracking-id=456&category=gummy-candies&taste=sour& ではなく example.com/category.php?category=gummy-candies&taste=sour&session-id=123&tracking-id=456とします）。

サイトでの URL パラメータの動作について十分に理解している場合は、ウェブマスターツールの URL パラメータを設定します（この場合でも、個別のアイテム/記事へのクリックパスを明確にする必要はあります）。たとえば、ウェブマスターツールの URL パラメータを使用すると、パラメータ名、ページコンテンツに対するパラメータの効果、Googlebot がパラメータを含む URL をクロールする方法などを一覧表示できます。

ウェブマスターツールの URL パラメータを使用すると、サイトのパラメータに関する情報や Googlebot の動作に関する推奨事項を確認できる

rel=”canonical” を使用して、個々のコンテンツのインデックス登録を望ましいページに統合します。rel="canonical" は、ホスト名やドメインにまたがって使用できます。

ページ指定されたコンテンツ（たとえば「グミ」カテゴリの page=1、page=2）のインデックス登録を、以下のいずれかの方法で改善します:

シリーズを構成する各ページに、カテゴリの「すべて表示」ページへの rel="canonical" を追加します（例: 「グミ」カテゴリの page=1、page=2、page=3 に category=gummy-candies&page=all への rel="canonical" を追加します）。その際に、検索ユーザーのエクスペリエンスを損なわない（各ページがすばやく読み込まれるなど）よう注意してください。
rel="next" と rel="prev" でページ指定をマークアップして、リンクなどのインデックス登録プロパティを構成ページ/URL からシリーズ全体に統合します。

サイトマップには canonical URL のみ含めるようにしてください。

シンプルなままにしておけるなら、それがベストであるということは覚えておいてください。ご不明な点がありましたら、ウェブマスターヘルプフォーラムまで質問をお寄せください。

Written by Maile Ohye, Developer Programs Tech Lead, and Mehmet Aktuna, Crawl Team
Original version: Faceted navigation best (and 5 of the worst) practices

検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

ご自身のサイトのニュースフィードやピンボードで、ユーザーの利便性を考えて無限スクロール（英語）を使用している方もいらっしゃるでしょう。しかし、Googlebot に対してとなると話が変わってきます。無限スクロールでは、クローラーがユーザーの行動（スクロールやボタンを押してさらにアイテムを読み込むなど）を常にエミュレートできるとは限らないため、フィードやギャラリー内のすべてのアイテムにアクセスできないことがあります。クローラーがアクセスできないコンテンツは、検索結果に表示されることもないでしょう。

無限スクロールページからリンクされている個別のアイテムを検索エンジンがクロールできるようにするには、無限スクロールを分割した一連のページ群を生成するようにしましょう。

無限スクロールページは、分割された一連のページ群に変えることで検索エンジンとの相性が良くなります。それぞれのページには類似の <title> が含まれ、 <head> では rel=next/prev の値が宣言されています。

Google のウェブマスタートレンドアナリストである John Mueller が作成したページ指定された無限スクロールサイトのデモで、実際の挙動を確認できます。このデモは、検索エンジンとの相性を考慮する上で重要なポイントを示しています:

対象範囲: すべての個別のアイテムがアクセス可能。従来の無限スクロールでは、最初のページ読み込み後に表示された個別のアイテムをクローラーが見つけることはできません。
重複なし: 各アイテムは一連のページ指定したページで一度だけ指定（つまり、アイテムの重複はありません）。

検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

はじめる前に:

無限スクロールページのコンテンツを、JavaScript が無効でもアクセス可能な形で、複数のページに分割します。
各ページに含めるコンテンツの量を決定します。

検索ユーザーが直接このページにアクセスしても、探しているアイテムが簡単に見つけられるようにします（たくさんスクロールしなければコンテンツを見つけられないようなことは避けます）。
適当なページの読み込み時間を維持します。

コンテンツを分割し、それぞれのページ間で重複が発生しないようにします（バッファリングを除きます）。

検索エンジンと相性が良い例を左に、そうでない例を右に示します。右側の例では、コンテンツのクロールとインデックス登録にそれぞれ重複が発生する可能性があります。

検索エンジンが処理する無限スクロール用の URL を構成します。

コンポーネントを構成する各ページには完全な URL を含めます。このケースでは、構成エラーを避けるために完全な URL を使用することをおすすめします。

好ましい例: example.com/category?name=fun-items&page=1
好ましい例: example.com/fun-items?lastid=567
好ましくない例: example.com/fun-items#1
ユーザーが各ページ（の URL）から直接コンテンツにアクセスできること、および同じ Cookie やユーザー履歴のないブラウザからでもアクセス/参照可能であることを確認します。

URL パラメータのキー/値が次のベストプラクティスに従うようにします:

URL が概念上は今から 2 週間後でも同じコンテンツを表示するようにします。

相対時間に基づいた URL パラメータの使用は避けます:
好ましくない例: example.com/category/page.php?name=fun-items&days-ago=3

検索ユーザーにとってコンテンツの内容が想像できる価値のあるパラメータを設定します。

コンテンツにアクセスする主な手法として、検索ユーザーにとって価値のないパラメータを使用することは避けます:
好ましくない例: example.com/fun-places?radius=5&lat=40.71&long=-73.40

各ページで、<head> 内に rel=next と rel=prev の値を含めるページ指定を行います。<body> 内のページ指定の値は、ウェブマスターが意図しないところで、ユーザー生成コンテンツによっても挿入される場合があるため、Google のインデックス登録では無視されますので、ご注意ください。
無限スクロールページに replaceState/pushState を実装します。どちら（あるいは両方）を採用するかはあなた（のサイトのユーザーの行動）次第ですが、Google では、次のような場合には pushState を（単独または replaceState と併せて）含めることをおすすめします:

クリックや実際にページをめくるようなユーザーの行動がある場合
ページ指定したコンテンツが表示されるたびに閲覧履歴に保存できるようにする場合

テストを行います。

ユーザーが上下にスクロールする際に URL の中のページの値が調整されることを確認します。John Mueller のページ指定された無限スクロールサイトのデモでは、上下のスクロールの挙動を示します。
範囲外のページが 404 レスポンスを返すことを検証します（つまり、example.com/category?name=fun-items&page=999 では、コンテンツ内に 998 ページしかない場合に 404 レスポンスを返す必要があります）。
無限スクロールの実装によって引き起こされる可能性があるユーザーの利便性の問題（英語）を調べます。

この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Written, reviewed, or coded by John Mueller, Maile Ohye, and Joachim Kupke
Original version: Infinite scroll search-friendly recommendations

リダイレクト発生時のクロールエラーの表示に関する改善について

これまで、ウェブマスターツールで報告されているクロールエラーに関して、ウェブマスターの皆さまの間に混乱が見られることがありました。今回の改善は、この点をより明確にし、エラーの診断をより容易にするものです。従来報告に表示されていたのはリダイレクト元の URL でしたが、この変更により、リダイレクト先の、実際にエラーコードを返している URL が表示されるようになります。

一例を見てみましょう:

A は B にリダイレクトしていますが、B はエラーを返しています。リダイレクトの種類やエラーの種類自体はここでは重要ではありません。

これまで、ウェブマスターツール上では、URL A の方をクロールエラーとして表示してきました。これからは、表示されるのは URL B の方になります。これにより、表示されているクロールエラーの診断がより容易になるでしょう。cURL やオンラインのサーバーヘッダーチェッカーなどのツールを利用して、URL B から実際にエラーが返されていることを確認することができます。

この変更が、全体のエラー数に影響を与える場合もあるでしょう。あなたのサイトが新しいドメインに移行した場合、リダイレクトが正確に行われていれば、これらのエラーは新しいドメインのウェブマスターツールでのみ確認することができるようになります。これにより、全体のエラー数が大きく変化する可能性があります。

この変更は、ウェブマスターツールでどのようにクロールエラーが表示されるかということにのみ影響するということにご注意ください。また、エラーを返すべき（例えば、存在しない） URL でクロールエラーが発生することによって、同一サイト内の他のページのインデクシングやランキングに影響が与えられることはありません（英語ですが、こちらの Google+ 上の投稿もご参照ください）。

この変更が、クロールエラーの診断をより容易にすることを願っています。気づいていなかったエラーが発生していたら、ぜひ直してあげてください。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by John Mueller, Website Error Analyst
Original version: Changes in crawl error reporting for redirects

より多くの言語にサイトを対応させるには（動画）

今日は、あなたのサイトをより多くの言語や言語のバリエーション（アメリカ英語、イギリス英語、オーストラリア英語、のようなケース）にサイトを対応させる方法について動画で詳しくご紹介します。具体的には rel=”alternate” hreflang と、多言語、および/または多国籍のサイト上でのその実装方法についての詳細を説明します。

日本語に訳したスライドはこちらからご覧ください。

こちらから見たいセクションにスキップできます。

hreflang に関するその他の情報はこちら：

ヘルプ記事

「rel="alternate" hreflang="x" について」

ブログ記事

Webmaster discussion forum FAQ on internationalization （英語）

Webmaster discussion forum for internationalization （英語）

あなたのサイトの多言語化がうまくいきますよう、願っています！

Posted by Maile Ohye, Product Manager
Original version: Video: Expanding your site to more languages

アプリもウェブサイトと同じようにインデックスに登録されるようになります

本機能の日本での提供予定は未定ですが、日本のウェブマスターのみなさまから高い関心が寄せられましたので、その概要をご紹介したいと思います。

スマートフォンで検索をしていると、スムーズな利用を妨げるような場面に遭遇することがあります。たとえば、ウェブページからアプリへの切り替え、あるいは逆にアプリからウェブページへの切り替えが必要になることがありますが、その際にリダイレクトやポップアップダイアログが出現して、余計なスワイプやタップが要求されることが多々あります。もし、ウェブサイト上のコンテンツであろうと、アプリ内のコンテンツであろうと、あなたが提供するコンテンツについて、ウェブサイト上で閲覧するか、アプリ上で閲覧するかユーザーが検索結果上で直接選べるようになったら良いと思いませんか？

Google は先日、Google 検索の新機能「App Indexing」を発表しました。この機能は、ウェブマスターからの技術的なインプットを活用して、ウェブサイトとモバイルアプリケーションをシームレスに横断するユーザーエクスペリエンスを実現します。

今回、これまでウェブサイトをクロールしてインデックスに登録してきたのと同じように、Android アプリ内のコンテンツも Googlebot がインデックスに登録することが可能となりました。ウェブマスターは、どのアプリコンテンツを Google のインデックスに登録させたいかを、現在ウェブページで行っているように、既存のサイトマップファイルやウェブマスターツールを通じて指定できます。ウェブページコンテンツとアプリコンテンツ両方がインデックスに登録されると、検索クエリと関連性があると思われ、ユーザーが対象アプリをインストールしている場合、アプリコンテンツに直接つながるディープリンクが Google 検索の検索結果上に表示されるようになります。ユーザーがディープリンクをタップすると、アプリが起動し、対象のコンテンツに直接移動します。たとえば、カリフォルニア州マウンテンビューの不動産物件（home listings）を検索した場合、次のようになります。

Google では現在、デベロッパーグループと App Indexing のテストを行っています。今後数週間のうちに、米国で Android 搭載端末を使用するログインユーザーを対象として、アプリコンテンツのディープリンクが Google 検索の検索結果に表示される予定です。提供している Android 向けアプリをインデックスに登録するための手順は簡単です。

まずは興味があることを Google にお知らせください（英語）。
Google では、この新機能を数多くのウェブサイトとアプリに普及させようと取り組んでいます。ぜひご協力ください。
提供しているアプリで、ディープリンクを有効にしてください（英語）。
サイトマップファイルか、サイトページのリンク要素を利用して、代替アプリ URI に関する情報をご提供ください。

実装や登録の詳細については、Google デベロッパーサイト（英語）をご覧ください。

Posted by Lawrence Chang, Product Manager
Original version: Indexing apps just like websites

rel=canonical 属性に関する 5 つのよくある間違い

ウェブページで rel=canonical 属性を指定することは、検索エンジンが重複ページの中からどのページをインデックスに登録するかを判断する上で重要な手がかりとなります。Yahoo!、Bing、Google など複数の検索エンジンがこれに対応しています。rel=canonical 属性は、重複ページから、外部からのリンクなどのインデックス登録に関連する属性を集約するとともに、検索結果に表示させたい URL を指定します。しかし、このように便利な rel=canonical 属性ですが、設定する際には少し注意が必要です。

検索エンジンは、右側のソースコードにあるように「blue velvet（ブルーベルベット）」カップケーキのページへの rel=canonical を優先的に表示させたいページとして認識するので、左側の「red velvet（レッドベルベット）」カップケーキのページは検索結果には表示されないことになります。このように、rel=canonical の設定の方法により検索結果に大きな影響を与えます。

この記事では、rel=canonical を使用する上での推奨事項をご紹介します。:

重複ページに含まれるコンテンツの大部分を含むページを canonical ページとしましょう。

ここで、コンテンツが自分の知らない言語で書かれていると仮定してみましょう。重複ページと canonical ページを左右に並べて見たときに、重複ページ内の文字の大部分が canonical ページにもあるでしょうか？その言語を理解できる人でなければ 2 つのページが類似していると判断できない場合、たとえば扱っている内容は類似しているけれども文章自体はさほど似ていないという場合は、canonical 指定をしても検索エンジンで無視される可能性があります。

rel=canonical のリンク先ページが確かに存在すること（エラーやソフト 404 ページではないこと）を確認しましょう。
rel=canonical のリンク先ページに noindex メタタグがないことを確認しましょう。
検索結果に表示させたいページが（重複 URL の方ではなく）rel=canonical で指定する URL であることを確認しましょう。
rel=canonical リンクをページの <head> タグ内または HTTP ヘッダー内に入れましょう。
rel=canonical を 1 つのページで 2 つ以上指定することは避けましょう。2 つ以上指定されていると、すべての rel=canonical が無視されます。

間違い 1: 複数ページにまたがるコンテンツの 1 ページ目を rel=canonical のリンク先とする

次のような複数ページにまたがる記事があるとします:

example.com/article?story=cupcake-news&page=1
example.com/article?story=cupcake-news&page=2
以降同様

2 ページ目（またはそれ以降のページ）に 1 ページ目への rel=canonical リンクを指定するのは rel=canonical の正しい使用法ではありません。このようなページは重複ページではないからです。このように rel=canonical を使用すると、2 ページ目以降のコンテンツがまったくインデックスに登録されなくなってしまいます。

複数ページにまたがるコンテンツの 2 ページ目以降に 1 ページ目への rel=canonical リンクを指定すると、良いコンテンツ（例: 2 ページ目と 3 ページ目のコンテンツ）が登録されなくなってしまいます。

ページ指定されたコンテンツの場合は、記事全体を 1 ページにまとめたページへの rel=canonical リンクを各分割ページに指定するか、ページ指定マークアップ rel="prev" と rel="next" を使用することをおすすめします。

全体表示ページへの rel=canonical リンクを各分割ページに設定

ページ指定されたコンテンツで全体表示ページへの rel=canonical リンクを指定しない場合、マークアップ rel=”prev” と rel=”next” を使用できます。

間違い 2: 絶対 URL のつもりで相対 URL を記述してしまう

間違い 3: rel=canonical を意図しない形で指定している、または 2 つ以上指定する

時々、意図した結果ではないと思われる rel=canonical の指定が見られることがあります。単純なタイプミスもごくまれにありますが、よくあるのはページテンプレートの rel=canonical のリンク先を変更し忘れたまま使用しているケースです。この場合、サイト運営者のページにテンプレート作成者のサイトへの rel=canonical リンクが設定された状態になってしまいます。

ソースコードから、プラグインがどのように HTML に反映されたかをチェックし、意図しないrel=canonical リンクが無いことを確認します。

間違い 4: カテゴリページまたはランディングページで特集記事への rel=canonical リンクを指定する

たとえば、デザートについてのサイトを運営していると想定します。そのサイトでは「pastry」（ペストリー：ケーキなどのお菓子類）や「gelato」（ジェラート）といったカテゴリページがあり、それらのカテゴリページでは日替わりで特集記事を紹介しています。たとえば、「pastry」のランディングページで「red velvet cupcakes」（レッドベルベットカップケーキ）を紹介するとします。「pastry」カテゴリページには「red velvet cupcake」のページと同じコンテンツがほとんど全部含まれているため、カテゴリページにその特定の特集記事への rel=canonical リンクを追加したとします。

仮にこの rel=canonical 指定が Google で認識されるとすると、「pastry」カテゴリページは検索結果に表示されないことになります。rel=canonical を指定することで、重複ページの代わりに canonical URL を検索結果に表示させたいという意思を示すことになるからです。これに対して、カテゴリページと特集記事のどちらも検索で見つかるようにしたい場合は、カテゴリページにそのページ自身をリンク先とした rel=canonical を指定するか、あるいは rel=canonical をまったく指定しないかのどちらかにするのがベストです。

canonical として指定すると、表示させたい URL を指定することになる点にも注意が必要です。カテゴリページまたはランディングページで特集記事への rel=canonical リンクを指定することは避けましょう。

間違い 5: <body> タグ内に rel=canonical を入れる

rel=canonical 属性タグは、HTML ドキュメントの <head> タグ内にのみ記述します。さらに、HTML の構文解析時に問題が発生しないようにするには、<head> タグ内の上部に、rel=canonical を配置し、できるだけ早い段階で読み込まれるようにしましょう。rel=canonical の指定が <body> タグ内にあると Google では無視されます。

この間違いは簡単に修正できます。rel=canonical リンクが必ずページの <head> タグ内にあることと、できるだけ早い段階で出現することを念入りに確認します。

rel=canonical 指定は <head> タグ内では認識され、<body> タグ内では認識されません。

まとめ

有益な rel=canonical 指定を行うには:

重複ページの本文コンテンツのほとんどが canonical ページにもあることを確認する。
rel=canonical の指定は１ページで１つとし、かつページの <head> タグ内で指定する。
rel=canonical のリンク先が、有効なコンテンツが含まれている URL であること（404 やソフト 404 ではないこと）を確かめる。
特集記事が検索結果に表示させたい URL と見なされてしまうため、ランディングページまたはカテゴリページで特集記事への rel=canonical リンクを指定することは避ける。

ご質問がありましたらウェブマスターヘルプフォーラムにお寄せください。

Written by Allan Scott, Software Engineer, Indexing Team

検索の仕組み: 毎日の莫大な数の検索に一瞬で答えを出すために

みなさんが情報を探そうと Google にアクセスしたとき、少しでも簡単に、直感的に検索できるようにしたいと Google は考えています。質問を入力すると答えが表示されますが、この間、見えないところで多くの Google のテクノロジーが動いています。Google ではユーザーの意図をより正確に把握し、探しているものをお届けできるよう、常にこのテクノロジーの向上に努めています。Google 検索を支えているテクノロジーについては、たくさんご質問をいただきます。それにお答えするために、この度 Google では、検索の仕組みに関する新しいウェブサイトを公開しました。

このサイトにアクセスすると、ウェブから始まって、クロール、インデックス、アルゴリズムに基づいたランキングと検索結果の配信、ウェブスパム対策まで、1 つの検索キーワードがたどるサイクルを知ることができます。このサイトは、このブログ、ヘルプセンター、ヘルプフォーラム、ウェブマスターツール、詳細な研究報告書（英語）といった既存の資料を補完する内容となっています。

たとえば、次のような情報をご覧いただけます:

Google 検索に関するインタラクティブな図解（英語）
主な検索アルゴリズムと検索機能に関する詳しい説明
検索結果の評価方法を説明した 43 ページのドキュメント（英語）
最近対策を行ったスパムサイトのライブスライドショー
ウェブスパムの問題とその対策について示すグラフ
法的な理由による削除など、コンテンツの削除に関するポリシーのリスト

この新しいサイトをご覧いただければ、検索結果が表示されるまでのほんの一瞬の間に起きていること、仕組みについてご理解いただけることと思います。アニメーションを用いたサイトは英語版のみですが、テキストバージョンは 43 か国語でご利用いただけます。

Posted by Jake Hubert、プロダクトマネージャー
Original version: Billions of times a day in the blink of an eye

ウェブテストが Google 検索に与える影響

最近、ウェブテスト（A/B テストや多変量テストなど）は検索結果に影響を与えるのか、というご質問をいただくことがあります。質問があるということは、ウェブテストをしている方が多いということで、喜ばしく思っています。A/B テストと多変量テストは、サイトがユーザーにとって本当に魅力的であるかを確認するとても効果的な手段です。

検索に与える影響を詳しく述べる前に、ウェブテストについて簡単に説明します。
ウェブテストとは、実際にパターンの異なるいくつかのウェブサイト（またはその一部）を試して、それぞれのパターンに対してユーザーがどのように反応したかをデータとして収集します。ソフトウェアを使用して、どのパターンが最も頻繁に、ユーザーから期待どおりの反応を得たかを記録します。つまりどのパターンが、商品の購入やメールニュースの購読登録、または他の目標とする行動に一番結びつくかを知ることができます。テスト後は、テストで一番優秀だったパターン、つまり最も効果的なコンテンツ構成を使用してウェブサイトを更新できます。

A/B テストは、固有の URL を持つ複数のパターンのページでテストする方法です。ユーザーがオリジナル URL にアクセスすると、リダイレクトによって異なるパターンのページの URL に振り分けられます。そしてユーザーの行動履歴を比較することで、最も効果的なページを調べます。

多変量テストは、ページを表示する際にソフトウェアによってウェブサイトのいくつかのセクションを即座に変更して行うテストです。ヘッダー、写真、「カートに入れる」といったボタンなど、ページの複数のセクションをテスト対象にできます。それぞれのセクションのすべてのバージョンの組み合わせをソフトウェアによってユーザーに表示し、統計分析により最も効果的な組み合わせを見つけます。URL は常に 1 つで、各パターンは動的にページに挿入されます。

では、これらのテストは、サイトを訪れる Googlebot にも影響するのでしょうか？複数パターンのコンテンツを提供することは掲載順位に影響するのでしょうか？以下では、効果的なテストを行いながらも、サイトの検索結果に与える影響を最小限にとどめる方法をいくつかご紹介します。

クローキングをしない
クローキング（ユーザー向けと Googlebot 向けとで異なるコンテンツを表示すること）はウェブマスター向けガイドラインに違反する行為です。これはテストであってもそうでなくても同様です。ユーザーエージェントによって、テストを行うのか、あるいは別のコンテンツを返すのかを切り替えないでください。例えば、ユーザーエージェント「Googlebot」に対して常にオリジナルページを返すといったことはしないでください。ガイドラインに違反した場合は、検索結果の掲載順位が下がったり、検索結果に表示されなくなったりしてしまう可能性があります。そもそもテストを行った目的と、正反対の結果になってしまいかねないのでご注意ください。

rel=“canonical”を使う
複数の URL を用いた A/B テストを行っている場合は、各パターンの URL にリンク属性 rel=“canonical" を使用して、オリジナル URL が優先する URL であることを示すことができます。なぜ noindex メタタグではなく rel=“canonical” の使用をお勧めするかというと、その方がテストをおこなっている状況を適切に示すからです。例えば、ホームページのパターンをテストしているとします。この場合理想的な状況は、ホームページが検索エンジンのインデックスに登録されないことではなく、各テスト URL がオリジナル URL の非常に似かよった複製、あるいはオリジナル URL の別バージョンであることを検索エンジン側に示し、オリジナル URL が優先する URL として扱われることでしょう。こういった場合に、rel=“canonical” ではなく noindex を使用すると予想外の結果になる場合があります（例：なんらかの理由でパターンページの URL が優先する URL として処理された場合、オリジナルの URL が複製として扱われてインデックスから除外されるということが起こりえます）。

301 ではなく、302 を使う
A/B テストでユーザーをオリジナルの URL からテスト用の複数パターンの URL にリダイレクトしている場合は、301 （永続的）リダイレクトではなく、302 （一時的）リダイレクトを使います。これにより検索エンジンはリダイレクトが一時的なもの（テスト期間中のみ）であり、オリジナル URL をリダイレクト先（テストページ）で置き換えるのではなく、オリジナル URL をインデックスに保持します。また、JavaScript によるリダイレクトを使用することも問題ありません。

テスト期間は必要な期間だけにする
信頼のおけるテストに必要な期間は、サイトのコンバージョン率やトラフィック量などによって変わります。そのため、良いテストツールは、信頼のおける結果を得るために必要なデータが集まったらユーザーに知らせてくれるでしょう。テストを終わらせたら、サイトを望ましいパターンのコンテンツで更新し、テストに関係するすべての要素（複数パターンの URL、テスト用のスクリプトやマークアップなど）を速やかに削除します。必要以上に長くテストを行っているサイトは、検索エンジンを欺いているとみなされ、ウェブマスター向けガイドライン違反となるかもしれません。1 つのテスト用コンテンツのパターンを多くのユーザーに表示し続けている場合は特にそうみなされます。

上記のような方法を参考にすれば、テストが検索結果に与える影響を最小限またはゼロにできることでしょう。また、テストしているコンテンツの種類によっては、たとえ Googlebot がいくつかのパターンコンテンツをクロールまたはインデックスに登録したとしてもまったく問題がない場合もあります。ボタンや画像のサイズ、色、位置の変更、またはユーザーに行動を促すための「カートに入れる」や「今すぐ購入」といったテキストのような変更は、ユーザーの行動には非常に大きく影響しますが、多くの場合、検索結果のスニペットや順位にはほとんど影響しません。さらに、テスト中のサイトが検出されてインデックスに登録されるほど頻繁にクロールされているなら、テスト後に更新されたサイトもすぐにインデックスに登録されることでしょう。

ウェブテストについての詳細はこちらの記事をご参照ください。Google アナリティクスで無料のテストツールもご利用になれます（Google アナリティクスのウェブテストツールでは現在多変量テストの機能は提供しておりません）。ウェブテストに関するご質問はアナリティクスヘルプフォーラム、検索エンジンに与える影響に関するご質問はウェブマスターヘルプフォーラムまでお寄せください。

Posted by Susan Moskwa, Webmaster Trends Analyst
Original version: Website testing & Google search

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

1. デベロッパーにウェブマスター ツールへのアクセス権限を付与する