![]()
![]()
この記事を読むのにかかる時間： 約 8.5 分
[海外情報]
SEOmoz
検索マーケティングのニュース＆テクニック
この記事はパンダ・アップデートによって変化した重複コンテンツの問題を広範に扱った長文の記事で、4回に分けてお届けしている。2回目となる今回は、重複コンテンツ問題を解決する手段を見ていこう。
IV 重複問題の解決に役立つ方法
説明の順番が適当でない感じがするかもしれないが、具体例の解説に進む前に、重複コンテンツに対処する方法をいくつか紹介しておきたい。そうしておけば、各事例を修正するための適切なお薦めツールを、混乱を招くことなく紹介できるだろうから。
ここで紹介するのは、次の12種類の方法だ。
- 重複ページを削除する
- 301リダイレクト
- robots.txt
- meta robotsタグ
- URL正規化タグ（rel="canonical"）
- URLの削除（グーグル）
- パラメータによるブロック（グーグル）
- URLの削除（Bing）
- パラメータによるブロック（Bing）
- 「rel="next"」と「rel="prev"」
- link rel="syndication-source"
- サイト内リンクの構造
- 何もしない
それぞれについて詳しく解説していこう。
IV-1 重複ページを削除する
最も簡単な重複コンテンツ対処法はもちろん、該当するページを削除して404エラーを返すことだ。
そのコンテンツが本当に訪問者や検索エンジンにとって何の価値もないものなら、また重要な被リンクやトラフィックもないなら、すっきり削除してしまうのが完璧に有効な方法だ。
IV-2 301リダイレクト
ページを削除するもう1つの方法は、301リダイレクトを使うやり方だ。
404エラーと違って、301リダイレクトは訪問者に（人間でも検索ロボットでも）、該当ページが別の場所に恒久的に移動されたことを伝える。訪問者が人間の場合、ブラウザは自動的にリダイレクト先のページを表示してくれる。SEOの観点から見ると、被リンクが持つ信頼度の大部分は新しいページにも渡される。
重複コンテンツの正規URLがはっきりしていて、そのコンテンツがトラフィックや被リンクを獲得しているなら、301リダイレクトは有効な選択肢になり得る。
IV-3 robots.txt
もう1つの選択肢は、人間の訪問者には重複コンテンツが見えるようにしておくが、検索エンジンのクローラーは締め出してしまうというものだ。
これを実現する方法として最も古く、おそらく最も簡単なのがrobots.txtファイル（普通はルートディレクトリに置かれる）を使うやり方だ。たとえばこんな感じになる。
robots.txtが持つ長所の1つは、フォルダ全体、場合によってはパラメータ付きのURLさえ比較的容易にブロックできることだ。
短所は、ちょっと強力過ぎて、時には信頼性に欠けるソリューションだという点だ。robots.txtはクローラーがまだアクセスしていないコンテンツをブロックするのには効果的だが、すでにインデックス化されているコンテンツを削除する方法としては有効ではない。
主要な検索エンジンもrobots.txtの多用を嫌っているようで、一般に重複コンテンツ対策としてはrobots.txtを推奨していない。
IV-4 meta robotsタグ
HTMLの<head>要素内でmeta robotsタグ（またはmeta noindex）を使って、ページ単位で検索ロボットの行動を制御することもできる。最も簡単な指定は次のようになる。
このディレクティブは検索ロボットに対して、あるページをインデックス化しないように、あるいはそこにあるリンクをたどらないようにと指示する。ついでに、僕はこちらの方がrobots.txtよりも若干SEOと親和性が高いと思うし、プログラムで動的に生成できるので、より柔軟な使い方ができることも多い。
meta robotsタグのcontent属性値として、上の例で挙げた「noindex, nofollow」以外によく使われるのが「noindex, follow」だ。こうしておくと、そのページはインデックスに追加されないが、ページ上にあるリンクは検索ロボットにたどってもらうことができる。サイト内検索の結果表示のようなページではこれが役に立つ。検索のしかたによって何通りも生成されるURLのうち、ある形式のものはブロックすべき（これについては後で説明しよう）だが、それでも製品ページへのリンクはたどってもらわなければ困るだろう。
ここで一言。「index, follow」というmeta robotsタグをページに追加する必要はまったくない。すべてのページは、（他の方法でブロックされていなければ）何もしなくてもインデックス化され、リンクもたどってもらえるので、そうするように指示するのは無駄なのだ。
IV-5 URL正規化タグ（rel="canonical"）
2009年、検索エンジン各社が手を組んで、rel="canonical"というURL正規化タグを作り出した。単に「rel="canonical"」とか「カノニカルタグ」と呼ばれることもあるこのディレクティブを使うことで、ウェブマスターはすべてのページについて正規バージョンのURLを指定できるようになった。
このタグは（meta robotsタグと同様に）HTMLページの<head>要素内に置かれる。簡単な例を次に示そう。
検索ロボットがカノニカルタグのあるページにやってくると、そこへたどりつくのに使ったURLが何であれ、正規のURLをそのページのURLとみなす。だから、たとえば検索ロボットが上に挙げた例のようなカノニカルタグが書かれているページにたどりついたURLが「www.example.com/index.html」だったとしても、そのページのURLは正規化指定されているURLと比べると「index.html」が付いている非正規URLなのでので、検索エンジンは余計な非正規URLをインデックス化しない。流れ込んでくるリンクジュースも、通常はカノニカルタグを通じて引き渡されているようだ。
ここで指摘すべき重要な点は、ウェブサイトのあらゆるテンプレートに対して、どれが正しい正規ページなのかを明確に把握しておく必要があるということだ。サイト全体を1つのページで正規化したり、間違ったページで正規化したりすると、悲惨な結果を招く可能性がある。
重複問題の解決に役立つ方法（6～12）
IV 重複問題の解決に役立つ方法（続き）
IV-6 URLの削除（グーグル）
Googleウェブマスターツール（GWT）から、個々のページ（またはディレクトリ）をインデックスから手作業で削除するようリクエストを送信できる。［サイト設定］＞［クローラのアクセス］を選ぶと3つのタブが並んでいるので、3つ目の［URLの削除］タブをクリックすると次のようになる。
このツールはふつう、重複コンテンツの対処策としては最後の手段に用いられるものだ。というのも、削除できるのが1度に1つのURLまたはパスであり、また、決定権が完全にグーグルにあるからだ。とはいえ、ここでは選択肢をすべて取り上げておきたい。
技術的な注意点としては、URLの削除をリクエストする前に、そのコンテンツにアクセスすると404エラーが返ってくることを確認するか、robots.txtによるブロック、またはnoindexのメタタグを実施しておくといい。そうしていなくてもURLの削除をリクエストできるが、再度そのURLでクロールしてページにアクセスできた場合、削除は90日間しか続かない。
GWTを使った削除は基本的に、他の方法でグーグル側がどうにも動いてくれない場合の最終防衛策だ。
IV-7 パラメータによるブロック（グーグル）
ウェブマスターツールでは、グーグルに無視してほしいURLパラメータを指定することもできる（グーグルは基本的にこのパラメータを用いてページのインデックス化をブロックする）。
ウェブマスターツールで［サイト設定］＞［URLパラメータ］を選ぶと、次のようなリストが表示される。
リストには、すでにグーグルが検出したURLパラメータと、各パラメータがどうクロールされるべきかを決める設定が並んでいる。「Googlebotが決定」という設定は、robots.txtやrobotsのメタタグといったほかのブロック方法を反映しているものではない点に留意してほしい。「編集」をクリックすると、以下のような選択肢が表示される。
最近グーグルが変更を行ったために、新バージョンは少しわかりにくくなっている気がするが、基本的に「はい」はそのパラメータが重要でインデックス化されるべきものであること、「いいえ」はそのパラメータが重複を示していることを意味する。
このツールは効果がありそうに思える（また手っ取り早い手段にもなり得る）だろうが、優先策としてはやはり推奨できない。グーグル以外の検索エンジンには効果がないし、SEOツールやモニタリングソフトでは検出できない。それに、グーグルによる変更がいつあってもおかしくない。
IV-8 URLの削除（Bing）
Bing Webmaster Center（BWC）には、Googleウェブマスターツールととてもよく似たツールがある。実際には、Bingのパラメータブロックツールのほうがグーグルのツールより先に登場したと思う。
BingにURLの削除をリクエストするには、ウェブマスターセンターの［インデックス］＞［URLのブロック］タブで［URLおよびキャッシュのブロック］を選ぶ。次のように表示されるはずだ。
実のところ、BWCの方が選択肢が幅広く、ディレクトリやサイト全体をブロックするよう指示できる。もちろん、最後の選択肢は普通は選ばないものだ。
IV-9 パラメータによるブロック（Bing）
BWCの［インデックス］タブには［URL正規化］という項目がある。この名称からは、Bingが正規化の処理をしてくれるような気がするが、選択肢は［有効にする］［無効にする］しかない。
グーグルのツールと同じように、自動的に検出されているパラメータの一覧が表示され、そこでパラメータの追加や修正を行える。
グーグルのGWTと同じく、Bingのツールも最後の手段だと思う。総じて、僕がこれらのツールを使うとすれば、他の方法でうまく行かず、悩みの種となっている検索エンジンが1つだけという場合だけだ。
IV-10 「rel="next"」と「rel="prev"」
グーグルは2011年9月、不完全重複の一形式であるページネーション（ページ分割）された検索結果に対処するための新ツールを公開した。この問題については次のセクションでもっと詳しく説明するが、簡単に言うとページネーションされた検索結果とは、検索結果が複数の塊に分散され、それぞれの塊（たとえば10個の結果）が独自のページ/URLを持つ状況を指す。
「rel="canonical"」によく似た2つの属性を使うことで、ページネーションされたコンテンツ間のつながりをグーグルに伝えることができるようになった。「rel="next"」と「rel="prev"」だ。実装は少し厄介だが、ここでは単純な例を挙げる。
これは検索ボットが検索結果の3ページ目にやってきている場合の例だと考えてほしい。この例では、
- 2ページ目（つまり前のページ）を指す「rel="prev"」属性のタグ
- 4ページ目（つまり次のページ）を指す「rel="next"」属性のタグ
という2つのタグが必要になる。実装が厄介なのは、検索結果はおそらく1つのテンプレートから作られるので、たいていの場合、これらのタグを動的に生成する必要が生じるという部分だ。
当初使ってみたところ、これらのタグはちゃんと機能しているようだが、Bingは対応を表明しておらず、有効性に関して集まっているデータも十分ではない。ページネーションされたコンテンツについては、他の対処方法を次のセクションで簡単に取り上げる。
IV-11 link rel="syndication-source"
グーグルは2010年11月、コンテンツを配信するパブリッシャ向けに2つのタグを導入した。
メタタグによるシンジケーション・ソース（syndication-source）という指示を使うと、転載された記事の配信元を以下のように示せる。
グーグル自身による説明でも、このタグとドメイン名間の「rel="canonical"」をどう使い分けるのかが少し不明瞭だ。また、グーグルは「実験的なもの」としてこのタグを公開したが、それが正式な仕様になったというグーグルの公式な発表はされていないと思う。
さらに、グーグルが最近link rel="standout"というタグを追加したことで、混乱はさらに深まっている。独自のニュース記事を掲載する際に使うものだとされているが、これとsyndication-sourceとの相互作用がよく分からない。
注目には値するが、当てにしてはいけない。
IV-12 サイト内リンクの構造
留意すべき重要な原則がある。重複コンテンツ問題に対処する最良の策は、そもそも初めから重複コンテンツを作らないことだ。もちろん、いつでもそれが可能なわけではないが、対処すべき問題が大量にある場合、サイト内リンクの構造やサイトの構成を再検討してみる必要があるかもしれない。
301リダイレクトやURL正規化タグで重複の問題を修正したら、サイトの他の部分にもその変更を反映させることが大切だ。僕はこれまで、301や正規化タグでページの1つのバージョンを設定したのにサイト内のリンクが非正規のバーションに張られたままだったり、XMLサイトマップに非正規のURLが大量に含まれたりしている例を、驚くほどたくさん見てきた。サイト内リンクは強力なシグナルなので、混乱したシグナルを検索エンジンに送ることは問題を招くだけだろう。
IV-13 何もしない
最後になったが、検索エンジンに解決を任せるという方法もある。実際、グーグルは長年にわたってこのやり方を推奨している。だが、僕の経験から言うと、残念ながら良い結果になることはほとんどない。規模の大きなサイトだとなおさらだ。
とはいえ、重複コンテンツが必ずしも大きな問題を引き起こすとは限らないことと、グーグルが大きな影響を及ぼすことなく一部の重複コンテンツをフィルタリングできる例も確かにあることは、指摘しておくべき重要な点だろう。
単発的な重複コンテンツが少しだけあるという場合、そのままにしておくというのは十分に有効な選択肢になる。
重複コンテンツ問題に対処する手段の紹介がようやく終わった。次回（2月13日公開予定）からはこれを踏まえて、重複コンテンツの具体例と、それにどうやって対処するかを紹介しよう。
この記事に関連する他の記事を見る
※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」で公開されている記事のフィードに含まれているものです。
オリジナル記事：重複コンテンツ問題を解決する12の手段 - 重複コンテンツ対策完全ガイド #2 [SEOmoz - 検索マーケティングのニュース＆テクニック] | Web担当者Forum
Copyright (C) IMPRESS BUSINESS MEDIA CORPORATION, an Impress Group company. All rights reserved.
![]()
