ウェブマスター ツールを利用してリソースのブロックを解除しましょう

ウェブページではデザイン性や機能性を高めるため、画像、CSS ファイル、JavaScript ファイルがよく使われます。このようなリソースがクロールからブロックされると、Googlebot では検索用にページをレンダリングする際にそのリソースを使用できません。そこで Google ウェブマスター ツールでは、ウェブマスターの皆様がこのような問題を特定して解決できるよう、ブロックされたリソースのレポートを導入しました。
このレポートには、サイト上のブロックされたリソース(JavaScript、CSS、画像など)の提供元ホスト名が表示されます。行をクリックすると、ブロックされたリソースの一覧と、そのリソースが埋め込まれているページが表示されます。そこから、ページ コンテンツのクロールとインデックス登録を可能にするために何が必要かを診断、解決する手順に進むことができます。

取得してレンダリングすると、これらのブロックされたリソースがどの程度問題であるかが表示されます。URL の取得とレンダリングをリクエストすると、Googlebot としてレンダリングされたスクリーンショットと一般ユーザーとしてレンダリングされたスクリーンショットの両方が表示されます。これにより、ページが Googlebot から異なって認識されることに大きく影響する問題を、より簡単に特定できるようになります。

ウェブマスター ツールでは、ウェブマスターが関与しうると思われるホストのみを表示するため、現時点では、さまざまなサイトで使用されているホスト(一般的な解析サービスなど)は表示されません。すべての robots.txt ファイルを更新するのは時間がかかるため、ブロックされたときに表示が大きく異なってしまうリソースから開始することをおすすめします。関連する手順について詳しくは、ウェブマスター ツールのヘルプセンター記事をご覧ください。

この新機能が、ウェブサイト上のブロックされたリソースを特定してブロック解除する際に、皆様のお役に立てば幸いです。ご不明な点がありましたら、お気軽にウェブマスター プロダクト フォーラムまでお寄せください。

XML サイトマップと RSS/Atom フィードのベストプラクティス

サイトマップを送信することは、サイトを最適化する上で重要な要素の一つです。サイトマップを送信することで、あるサイトに存在するすべての URL を検索エンジンが発見できるようになり、ページの内容が変更された時に素早くダウンロードすることが可能になります。そこで今回は、サイトマップにおける重要なフィールドについて、XML サイトマップや RSS/Atom フィードはいつ使えばよいのか、また Google 検索に最適化するためにはどうすればよいか、について解説します。

サイトマップとフィード

サイトマップは、XML サイトマップ(英語)、RSS 、もしくは Atom のいずれかの形式を使用します。主な違いは次のとおりです。XML サイトマップは、あるサイトに存在するすべての URL が含まれますが、RSS/Atom フィードは、最新の更新が含まれます。つまり:
  • XML サイトマップは一般的にファイルサイズが大きくなります。一方、RSS/Atom フィードのファイルサイズは小さく、サイトの最新の更新情報のみが含まれます。
  • XML サイトマップは RSS/Atom フィードほど頻繁にダウンロードされません。
Google では、最適なクロールを行うために、XML サイトマップと RSS/Atom フィードの両方を使用することをおすすめしています。XML サイトマップによって、Google はサイト内の全ページに関する情報を取得することができ、RSS/Atom フィードによって、サイト内のすべての更新情報を取得することができるからです。両者のおかげで、Google はインデックス中のコンテンツをいつも最新の状態に保つことが可能になります。ただし、サイトマップやフィードを送信したからといって、URL のインデックスが保証されるわけではありません。

XML サイトマップの例:
<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>http://example.com/mypage</loc>
   <lastmod>2011-06-27T19:34:00+01:00</lastmod>
   <!-- optional additional tags -->
 </url>
 <url>
   ...
 </url>
</urlset>


RSS フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<rss>
 <channel>
   <!-- other tags -->
   <item>
     <!-- other tags -->
     <link>http://example.com/mypage</link>
     <pubDate>Mon, 27 Jun 2011 19:34:00 +0100</pubDate>
   </item>
   <item>
     ...
   </item>
 </channel>
</rss>


Atom フィードの例:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
 <!-- other tags -->
 <entry>
   <link href="http://example.com/mypage" />
   <updated>2011-06-27T19:34:00+01:00</updated>
   <!-- other tags -->
 </entry>
 <entry>
   ...
 </entry>
</feed>


"other tags" は必須タグと省略可能なタグの両方を表しており、両者はそれぞれの形式の標準によって定義されています。Google では、Atom/RSS フィードに必須タグを指定することをおすすめしています。この指定により、フィードは Google 検索だけでなく、フィードを扱う可能性のある他のプロパティでも表示することが可能になるからです。


ベストプラクティス

重要なフィールド

XML サイトマップと RSS/Atom フィードは、実際のところ、メタ データが付加された URL の一覧です。その中で、Google にとって最も重要な情報は、URL そのものとその最終更新日時です。

URL

XML サイトマップや RSS/Atom フィード内の URL は、以下のガイドラインに従ってください。
  • Googlebot が取得可能な URL であること。robots.txt によって Googlebot のアクセスを禁止している URL や、ページが存在しない URL が指定されているケースがよく見られますが、それらは間違った指定方法です。
  • 正規 URL であること。内容の重複した複数のページの URL が指定されていることがありますが、これは間違った指定方法です。そのままでは、インデックスが改善されない一方で、あなたのサーバーの負荷が増大してしまいます。

最終更新日時

それぞれの URL に対して、その URL の最終更新日時を XML サイトマップと RSS/Atom フィードに指定してください。最終更新日時とは、そのページのコンテンツが実質的に更新された最新の日時です。ある更新が検索結果に影響を与える可能性がある場合、その更新日時が最終更新日時となります。
  • XML サイトマップでは <lastmod> を使用します
  • RSS では <pubDate> を使用します
  • Atom では <updated> を使用します
最終更新日時を正しく設定、更新するには:
  • 日時を正しい形式で指定します。XML では W3C Datetime 形式 (英語)、Atom では RFC3339 形式 (英語)、RSS では RFC0822 形式 (英語)を使用します。
  • コンテンツが実質的に変更されたときのみ、日時を更新します。
  • サイトマップやフィードが取得されるたびに、現在日時を最終更新日時として指定しません。

XML サイトマップ

XML サイトマップには、サイト内のすべての URL が記載されている必要があります。一般的に、XML サイトマップはファイルサイズが大きく、頻繁には更新されません。使用の際は、以下のガイドラインに従ってください。
  • 単独の XML サイトマップの場合:(定期的に更新されるサイトの場合は、)更新は少なくとも一日一回行い、Google に ping(英語)を送信します。
  • 複数の XML サイトマップの場合:それぞれの XML サイトマップにはできるだけ多くの URL を記載します。一つの XML サイトマップは、最大 5 万 URL もしくは(圧縮されていない状態で)10 MB までとし、ファイルがどちらかの制限に達するまで URL を記載します。XML サイトマップをひとつでも更新した場合は、その都度 Google に ping(英語)を送信してください(サイトマップ インデックス ファイルを使用している場合は、一度だけ送信してください)。それぞれの XML サイトマップにごく少数の URL のみを記載しているケースがしばしば見られますが、それは間違った指定方法です。その場合、Google にとって、想定された時間内で XML サイトマップすべてをダウンロードすることが難しくなります。

RSS/Atom

RSS/Atom フィードは、サイト内の最近の更新情報を伝えている必要があります。通常、RSS/Atom フィードはファイルサイズが小さく、頻繁に更新されます。Google では、RSS/Atom フィードを以下のように設定することをおすすめしています。
  • 新たなページが追加されるか、既存のページが実質的に更新された場合、フィードにその URL と更新日時を追加します。
  • Google による更新情報の見逃しを防ぐため、RSS/Atom フィードには、少なくとも、前回の Google のクロール以降のすべての更新情報が記載されるようにしてください。Google では、そのための最適な方法として、PubSubHubbub(英語)の使用をおすすめしています。ハブが、可能な限り高速かつ効率的な方法で、関係するすべての購読者(RSS リーダーや検索エンジンなど)へフィードの内容を伝達してくれます。

XML サイトマップと RSS/Atom フィードの両方を使用することで、Google や他の検索エンジンによるクロールをうまく最適化することができます。その際に重要な情報は、正規 URL と最終更新日時です。これらを適切に設定し、サイトマップの ping や PubSubHubbub を通して Google などの検索エンジンに伝えることで、クロールを最適な状態で行うことが可能になり、意図した通りに、ウェブサイトが検索結果に反映されるようになります。

ご不明な点がありましたら、この記事にコメントいただくか、ウェブマスター ヘルプ フォーラムのサイトマップ カテゴリまでいつでもお寄せください。

地域対応ページのクロールとインデックス登録

地域対応ページでは、ユーザーの言語や検出された地域に応じてコンテンツが変更されます。Googlebot は通常 Accept-Language HTTP リクエスト ヘッダーを設定せずにページをリクエストし、米国からと判定される IP アドレスを使用するため、地域対応ページのすべてのコンテンツが正しくインデックス登録されるとは限りません。

このたび Google では、リクエストの言語や地域に基づいて配信コンテンツを変更していると判断されたページに対応するため、新しい地域認識クロール設定を Googlebot に追加しました。
  • 地域分散クロール: Googlebot は、米国からと判定される現在の IP アドレスに加え、米国外からと判定される IP アドレスも使用します。
  • 言語依存クロール: Googlebot は、リクエスト内で Accept-Language HTTP ヘッダーを使用してクロールします。
これらの新しいクロール設定は、地域対応ページが検出されると自動的に有効になるため、CMS やサーバー設定を変更しなくても、サイトのクロール方法や Google の検索結果での表示の変化にお気付きいただけることでしょう。

この新しい設定が追加された後も、地域ごとに rel=alternate hreflang アノテーションで別々の URL を使用することを引き続きおすすめします。ユーザーの操作やコンテンツの共有を円滑に行うために、そして地域別のコンテンツを可能な限りインデックス登録してランキングの精度を向上させるために、Google では今後も別々の URL の使用を推奨いたします。

ご不明な点やご意見・ご感想などありましたら、ウェブマスター ヘルプ フォーラムにてお聞かせください。

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

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

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

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


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

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


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


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

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

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

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 の指定の作成についてアドバイスが欲しい場合などは、ぜひウェブマスター ヘルプ フォーラムをご利用ください。

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は既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。


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

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

ウェブマスターの皆様にとって、サイトの移転ほど厄介で悩ましい問題はないかもしれません。このたび 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 を別に設定している場合や動的配信を行っている場合にウェブサイトでレスポンシブ ウェブ デザインを使用するよう変更するにはどうすればよいか、といった質問も増えつつあります。この設定の変更について詳しくは、スマートフォン向けサイトの推奨事項についてまとめたサイトに新たに追加されたこちらのページをご覧ください。

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

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 がそれらのコンテンツを見つけてインデックスに登録することが可能になります。サイトに表示されるコンテンツやそのレイアウトにあまり影響しない一部のコンテンツ タイプ(ソーシャル メディア ボタン、フォント、ウェブサイト分析スクリプトなど)は、クロールできない状態のままでも構いません。詳しくは、以前ブログに投稿した「ウェブページをより深く理解するようになりました」という記事をご覧ください。

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

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

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 によるサイトのレンダリング状況を詳しく把握できるようなツールの開発に取り組んでおります。近いうちにウェブマスター ツールで皆様にご提供する予定です。

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

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

複数の国で事業を行っている場合や複数の言語をターゲットとしている場合は、それぞれの国または言語をターゲットとする 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 アノテーションを使用してください(汎用ページが、ユーザーが直接アクセスできないリダイレクト ページである場合も同様です)。

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

いずれの設定を選択した場合でも、国や言語の選択ページを含むすべてのページが次の条件を満たしている必要があります:
  • 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 検索結果でより関連性の高い結果をユーザーに提供できるようになります。ご不明な点やご意見・ご感想などありましたら、ウェブマスター  ヘルプ フォーラムにてお聞かせください。


App Indexing の最新情報

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


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

サイトマップやウェブサイトにディープ リンクを追加する際に、考慮すべきベスト プラクティスをいくつかご紹介します。
  • アプリのディープ リンクは正規 URL にのみ含めるようにしてください。
  • ホームページにおいてもアプリのディープ リンクを指定することをお忘れなく。
  • サイトマップに含まれているすべてのウェブサイト URL に対応するアプリのディープ リンクを設定する必要はありません。提供しているアプリでサポートされていないディープ リンクを含めないようにしてください。
  • ニュース サイトでニュース サイトマップを使用されている場合は、通常のサイトマップと同様に、ニュース サイトマップにもディープ リンクのアノテーションを含めるようにしてください。
  • ネイティブ ARM コードを実行するディープ リンクのアノテーションを指定しないでください。これにより、すべてのプラットフォームで App Indexing が有効になります。
アプリのコンテンツがインデックスに登録されると、提供しているアプリは、通常の動作の場合と同様に HTTP  リクエストを送信する必要があります。これらのリクエストは、サーバー上では Googlebot から送信されたように表示されます。そのため、これらのリクエストを許可できるようにサーバーの robots.txt ファイルを設定する必要があります。

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

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

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

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 ファイルはプロトコルやホスト名ごとに区別されて読み取られます。

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

ファセット ナビゲーションのベスト プラクティスと 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-fishexample.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10
    魚形グミの同じ商品ページに複数の URL でアクセスできてしまう

  • 検索ユーザーや検索エンジンにとってほとんどまたはまったく価値のないカテゴリ ページが大量に存在する

    URLexample.com/category.php? category=gummy-candies&taste=sour&price=5-10example.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-idcategory-idpage などが考えられます。
    • 検索ユーザーにとって価値があるパラメータはどれか、クロールやインデックス登録において重複の原因になるだけの不要なパラメータはどれかを特定します。グミの例では、たとえば「taste」パラメータは検索ユーザーにとって有用です。[sour gummy candies] で検索すると、結果として example.com/category.php?category=gummy-candies&taste=sour が表示されます。一方、「price」パラメータは、category=gummy-candies&taste=sour&price=over-10 のような重複の原因になるだけです。以下に一般的な例を示します:
    • 検索ユーザーに有用なパラメータ: item-idcategory-idnamebrand...
    • 不要なパラメータ: session-idprice-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-10rel="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 の動作に関する推奨事項を確認できる

  • コンテンツの並べ替え、フィルタリング、非表示を、URL の更新ではなく JavaScript で動的に行う場合でも、クロールやインデックス登録の対象となるメインのカテゴリ ページや商品ページの URL はユーザーにとって有用な情報です。JavaScript でコンテンツを動的に変更する場合は、サイト全体を表す URL としてホームページのみ(つまり 1 つの URL のみ)を使用することは避けてください。これでは検索ユーザーが、1 つの URL でサイト内のすべてのコンテンツにアクセスすることになってしまいます。また、動的なフィルタリングによってパフォーマンスが低下することがありますので注意してください。これにより、ユーザー エクスペリエンスが損なわれる可能性があります。
  • 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 のみ含めるようにしてください。
  • シンプルなままにしておけるなら、それがベストであるということは覚えておいてください。ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムまで質問をお寄せください。


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

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

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


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

    Google のウェブマスター トレンド アナリストである John Mueller が作成したページ指定された無限スクロール サイトのデモで、実際の挙動を確認できます。このデモは、検索エンジンとの相性を考慮する上で重要なポイントを示しています:
    • 対象範囲: すべての個別のアイテムがアクセス可能。従来の無限スクロールでは、最初のページ読み込み後に表示された個別のアイテムをクローラーが見つけることはできません。
    • 重複なし: 各アイテムは一連のページ指定したページで一度だけ指定(つまり、アイテムの重複はありません)。

    検索エンジンとの相性を考慮した無限スクロールのベストプラクティス
    1. はじめる前に:
      • 無限スクロール ページのコンテンツを、JavaScript が無効でもアクセス可能な形で、複数のページに分割します。
      • 各ページに含めるコンテンツの量を決定します。
      • 検索ユーザーが直接このページにアクセスしても、探しているアイテムが簡単に見つけられるようにします(たくさんスクロールしなければコンテンツを見つけられないようなことは避けます)。
      • 適当なページの読み込み時間を維持します。
    2. コンテンツを分割し、それぞれのページ間で重複が発生しないようにします(バッファリングを除きます)。


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

    4. 検索エンジンが処理する無限スクロール用の URL を構成します。
      • コンポーネントを構成する各ページには完全な URL を含めます。このケースでは、構成エラーを避けるために完全な URL を使用することをおすすめします。
      • 好ましい例: example.com/category?name=fun-items&page=1
      • 好ましい例: example.com/fun-items?lastid=567
      • 好ましくない例: example.com/fun-items#1
      • ユーザーが各ページ(の URL)から直接コンテンツにアクセスできること、および同じ Cookie やユーザー履歴のないブラウザからでもアクセス/参照可能であることを確認します。
    5. URL パラメータのキー/値が次のベストプラクティスに従うようにします:
      • URL が概念上は今から 2 週間後でも同じコンテンツを表示するようにします。
      • 相対時間に基づいた URL パラメータの使用は避けます:
        好ましくない例: example.com/category/page.php?name=fun-items&days-ago=3
    6. 検索ユーザーにとってコンテンツの内容が想像できる価値のあるパラメータを設定します。
      • コンテンツにアクセスする主な手法として、検索ユーザーにとって価値のないパラメータを使用することは避けます:
        好ましくない例: example.com/fun-places?radius=5&lat=40.71&long=-73.40
    7. 各ページで、<head> 内に rel=next と rel=prev の値を含めるページ指定を行います。<body> 内のページ指定の値は、ウェブマスターが意図しないところで、ユーザー生成コンテンツによっても挿入される場合があるため、Google のインデックス登録では無視されますので、ご注意ください。
    8. 無限スクロール ページに replaceState/pushState を実装します。どちら(あるいは両方)を採用するかはあなた(のサイトのユーザーの行動)次第ですが、Google では、次のような場合には pushState を(単独または replaceState と併せて)含めることをおすすめします: 
      • クリックや実際にページをめくるようなユーザーの行動がある場合
      • ページ指定したコンテンツが表示されるたびに閲覧履歴に保存できるようにする場合
    9. テストを行います。

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

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

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

    一例を見てみましょう:

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

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

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

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

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

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

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

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

    こちらから見たいセクションにスキップできます。
    hreflang に関するその他の情報はこちら:
    • ヘルプ記事
  • ブログ記事
  • Webmaster discussion forum FAQ on internationalization (英語)
  • Webmaster discussion forum for internationalization (英語)
  • あなたのサイトの多言語化がうまくいきますよう、願っています!

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

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


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

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

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



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

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

    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 を記述してしまう




    <link> タグでは、他の多くの HTML タグと同様に、相対 URL と絶対 URL のどちらも使用できます。相対 URL とは、リンク元のページを基準とした「相対的な」パスのことです。たとえば、「images/cupcake.png」は、リンク元ページと同じディレクトリの中にあるサブディレクトリ「images」の中にある「cupcake.png」を指します。絶対 URL は、「http://」といったスキームを含めたパス全体を記述したものです。

    <link rel=canonical href=“example.com/cupcake.html” />(「http://」が付いていないため相対 URL です)と指定すると、canonical URL としては、実際にはそのような意図でないことがほとんど確実であっても、「http://example.com/example.com/cupcake.html」と指定していると見なされてしまいます。このような場合、Google のアルゴリズムでは rel=canonical の指定が無視されることがあります。どのような意図でこのように rel=canonical を指定したとしても、結果的に目的を達成できないことになります。

    間違い 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 の指定は1ページで1つとし、かつページの <head> タグ内で指定する。
    • rel=canonical のリンク先が、有効なコンテンツが含まれている URL であること(404 やソフト 404 ではないこと)を確かめる。
    • 特集記事が検索結果に表示させたい URL と見なされてしまうため、ランディング ページまたはカテゴリ ページで特集記事への rel=canonical リンクを指定することは避ける。
    ご質問がありましたら ウェブマスター ヘルプフォーラム にお寄せください。

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

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

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

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

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

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