タグ: 上級者向け

• 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 に変更する

• viewport を設定する: viewport メタ タグが指定されていないページは、最新のモバイル ブラウザではモバイル非対応ページとみなされてデスクトップ向けのビューポートとして処理され、さらにはフォント拡大が適用される可能性もあるため、意図したとおりのページ レイアウトで表示されないことがあります。モバイルに適したサイトにするためには、まず viewport の設定で width=device-width を使用しましょう。
• コンテンツのサイズを viewport に合わせる: ユーザーは、モバイル サイトは横ではなく縦にスクロールするものと思っています。viewport を設定したら、ページのコンテンツがその viewport の幅に収まっていることを確認してください。その際、携帯端末の幅は機種によって異なることに注意が必要です。
• 読みやすいフォント サイズを使用する: ユーザーがスマートフォンで記事を読むときに拡大しないと文字が読めないとしたら、それはモバイルに適したサイトとは言えません。PageSpeed Insights では、大部分のユーザーにとって読みやすい大きさの文字かどうかをチェックします。
• タップ ターゲットのサイズを適切に調整する: 携帯電話やタブレットのタッチスクリーンでボタンやリンクをタップしようとして、間違えて誤ったターゲットをタップしてしまうことがあります。これは、パソコンのマウス カーソルと比べて指の腹の方が大きいためですが、とても煩わしいものです。モバイル サイトのタッチスクリーンのタップ ターゲットは押しやすいように十分大きくするようにしてください。
• プラグインを使用しない: ほとんどのスマートフォンでは、Flash などのブラウザ プラグインをサポートしていません。そのため、モバイル サイトでもプラグインを使用しないようにします。

• 「Google ウェブマスター向け公式ブログをフランスでも開設しました（英語）」といった公式ニュースやお知らせ
• 404 の適切な扱い方（英語）などのサイト運営上のちょっとしたヒント
• リアルタイムでみなさんからのご質問に社員がお答えするウェブマスター オフィスアワー
• Googlebot-kun の冒険（英語）の投稿のような独占裏情報

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

• ファセット ナビゲーションの背景と潜在的な問題
• 5 つのワースト プラクティス
• ベスト プラクティス

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

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

背景

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

• すべての商品/記事ページにアクセスできる明確な動線
  
  
  
  左側はサイトでのユーザーの動線（つまりクリック パス）、右側はアクセスするページです。
  
  
  
• 個々のカテゴリ ページを表す 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 ステータス コードを返すべき）。 検索ユーザーに悪影響を及ぼす。

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

ワースト プラクティス:

• 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 は、「標準以外のエンコードを使用するのは、わざわざ災難を招いているようなものだ」と述べています。キー=値ペアには等号（=）を使用し、複数のパラメータの追加にはアンパサンド（&）を使用してください。

ワースト プラクティス:

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
• タイムスタンプ

ワースト プラクティス（例: 緯度/経度、「～日前」といったユーザーごとに変動する値を含む 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/

ワースト プラクティス:

• 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 を使って情報を保持するようにします。

ワースト プラクティス:

該当する商品が 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 パラメータが論理的に表示されるようにします。

• 値を次々と追加するのではなく、不要なパラメータを削除するようにします。

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

• 悪い例
  example.com/category.php?session-id=123&tracking-id=456&category=gummy-candies&taste=sour

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

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

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

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

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

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

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

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

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

• モバイルのユーザー エージェントからのアクセスに対して余分なウィンドウを表示しない | Google の推奨事項、記事（英語）

• 簡単に閉じることのできない JavaScript ポップアップ。
• 特にアプリをダウンロードするためのオーバーレイ表示（iOS 6 以降の Smart App Banner（英語）またはそれに相当するバナー、サイド ナビゲーション、メール マーケティングなどの使用を代わりにご検討ください）。
• タスクを完了する前のアンケートの表示。

• 端末に適した機能を提供する

• ユーザーの端末で使用できないプラグインや動画を必要とする機能を削除します（たとえば、Adobe Flash は iPhone や Android バージョン 4.1 以降では再生できません）。| ビジネス ケース
• タブレット ユーザーにはデスクトップ バージョン（可能な場合はタブレット バージョン）を配信します。| 研究・調査（英語）
• デスクトップ バージョンの機能が携帯端末でもすべて利用できることを確認します。ユーザーがデスクトップ バージョンでの表示を選択した場合には、セッション中はすべてデスクトップ バージョンが保持されるようにします（つまり、各ページが読み込まれた後でユーザーがデスクトップ バージョンを選択しないで済むようにします）。| 研究・調査（英語）

• トラフィックが多くユーザー エクスペリエンスが悪いモバイル向けページを改善する

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

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

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



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


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

• SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
• DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

User-agent: Googlebot
Disallow: /

User-agent: Googlebot-Mobile
Disallow: /

• 携帯端末に最適化されたウェブサイトの構築方法に関する Google の推奨事項
• Googlebot のクロールとインデックス登録
• Google のウェブマスター ヘルプフォーラムへの投稿

モバイル向けに別の URL を用意する場合のベスト プラクティス

• 携帯端末に最適化されたウェブサイトの構築方法を参照する

• デスクトップ向けサイトの側では、対応するモバイル向け URL へ向いた link rel=”alternate” タグを設置してください。これは、Googlebot があなたのモバイル向けサイトを発見する助けになります。
• モバイル向けサイトの側では、対応するデスクトップ向け URL へお向いた rel=”canonical”  タグを設置してください。
• ユーザー エージェントに応じて自動的にサーバー側でリダイレクトを行なっている場合は、HTTP Vary: User-Agent ヘッダーを利用してください。