HTTPリダイレクトの動作とSEOの効果

公開日:2008/11/21
執筆者:阿曽 鉄之輔

スマートシステムの阿曽です。

HTTPリダイレクト(redirect,転送)について、その動作とSEOの効果についてまとめてみます。

リダイレクトとは、簡単には、あるファイルやドメインにアクセスしたときに移転したことを知らせ、別ファイルやドメインに対するアクセスするように仕向けるものです。

リダイレクト(転送)は、状況によってはほとんど無縁な方も多いものですが、工夫凝らして使うと、検索エンジンに対してフレンドリーでなくなる面があります。そういう盲点的なお話です。

結構見えにくいところなんですけど、リダイレクト(転送)をする場合、検索結果のランキングに重要な意味を持っています。

リダイレクト(転送)がSEO上重要な意味を持つ理由

検索エンジンの評価基準は多くありますが被リンクのウェートが相当高いのはご存知の通りです。

被リンクについてはページ単位でも集計されていますが、ドメイン単位で集計されている面が大きいです。そのドメイン向けにトータルでどれだけ被リンクがあるか、ということが評価になります。(議論の簡略化のために被リンクの質の話は置いておきます)

このドメインに対する被リンク量が計算によって、サイトに対する評価値になっています。(この評価値のことを「リンクジュース」とも言います)

リダイレクト(転送)は、この評価値を移転させる効果があります。だから、やり方によってはその評価がうまく移転したりしなかったり、悪用したり、などが可能になります。

簡単に覚えておくには、301転送をすると、この評価値が移転します。302転送では評価値は移転しません。meta refreshの場合は、(一応)、0秒等で転送すると301に準じるように解釈されるようですが、そうでない場合もあります。

そういう理由があるので、サイトの移転の場合は301転送をしておくと、元のドメインに貯まった評価値が新ドメインに移転できるので、したほうがいいんですね。ただ、効果は転送している間だけですので、1年以上は転送措置を取ったほうが良いとなります。

ただ、もうひとつ覚えておいて欲しいのは、301転送では評価値が移転し、302転送では移転しない、というのは原則ということです。検索エンジンの判断によってはそうならないケースがあります。そういうケースを実際に見ていますので、私たちからすると、あまり転送を凝ったことをやると、結果どうなるか分からないのでやめたほうがいいと思います。

悪用方法は、真似しないで頂きたいのですが、例えば、まず評価の高いサイトを作っておいて、そこの評価値を301転送で別なサイトに送り込むんですね。そうやると、その転送先のサイトが突然、検索結果のランキングに入ってきたりします。これはしばらくすると検索エンジンも気がつくようですので、今はあまり見かけない手法です。また、いろんなサイトから301転送したら評価値が集まるか?というと、ドラゴンボールの元気玉みたいですが(笑)、そうはならないようになっています。

このように転送はかなりダイナミックなことが出来ますので、あまり凝ったことをすると、結果がどう出るか分からない(検索エンジン側がどういう対処をするか分からない)ので、避けたいところです。

あと、この評価値ですが、外にリンクするのに配分されるものと、サイト内に配分されるものの2種類あると覚えておいて下さい。それぞれ別計算となっていて、サイト外部にリンクする分は、外にリンクするのに配分されるものが使われます。基本的には外にリンクしても、内部に配分する分は減らないと考えます。これについては別な機会に書きたいと思います。

以下は、もう少しテクニカルな内容のまとめです。

HTTPリダイレクト(redirect,転送)の一般的な使い方

使い方としては、ドメインやコンテンツページを移転させた際に、301リダイレクト(恒久的移転) を行うことがもっとも一般的なケースです。

旧ドメイン(旧コンテンツページ) ⇒301リダイレクト⇒ 新ドメイン(新コンテンツページ)

となります。

こうしたコンテンツの移転を知らせるためのリダイレクトの方法としては、HTTPリダイレクトのほかにJavascriptによるものや、metaタグによるものがありますが、サイト移転の場合は、301転送がベストです。

HTTPレスポンスコードの簡単なまとめ

ウェブサーバからブラウザへの状況を伝えるものです。ブラウザでウェブページを見るとき、ブラウザから「データ送って」とウェブサーバに送信しています。すると、サーバのほうからレスポンスコードという状態表示とデータが返信される仕組みになっています。そのレスポンスコードの代表的なところが下記です。他にも種類はありますが、とりあえず下記を押さえればokかと思います。

200 …成功 データがブラウザに送ってきます。通常のページを表示するケースです。

301 …Moved Permanently 恒久的移転の意。移転したよということで、移転先URIとともに伝えられます。重要。

302 …Found 以前はMoved Temporarily 一時的移転の意。一時的に移転したよということで、移転先URIとともに伝えられます。重要。

307 …Temporary Redirect HTTP1.1で規定された一時的移転の意。なので、307転送を使うのもアリながら、検索エンジンの解釈が変わると困るので、302を使うのが無難。

404 …Not Found ファイルが見つからないときに返されます。400系はエラーを表します。

HTTPリダイレクトの動作の実際

ブラウザでHTTPリダイレクトがされているサイトにアクセスすると、あっという間に転送されて違うページ、ドメインに移ってしまうため分かりにくいのですが、ウェブサーバとブラウザの間で下記のような通信をしています。

(リダイレクトがない通常のケース)

ブラウザ→サーバ:  サーバhttp://www.samplesite.jp/にデータを送ってと送信

サーバ→ブラウザ: ステータスコード200(成功)  要求されたページのデータをブラウザに送信 

(301リダイレクトのケース)

ブラウザ→サーバ: サーバhttp://www.samplesite.jp/にデータを送ってと送信

サーバ→ブラウザ: ステータスコード301(恒久的に移転) http://www.samplesite2.jp/に移転したよとブラウザに送信

ブラウザ→移転先サーバ: 移転先のhttp://www.samplesite2.jp/のデータを送ってとサーバに送信

移転先サーバ→ブラウザ: ステータスコード200(成功) 要求されたページのデータをブラウザに送信

(301リダイレクトを具体的にリクエスト・レスポンスヘッダで見てみると)

・ブラウザ→サーバ

GET / HTTP/1.1 ←★データ暮れの意
Host: samplesite.jp ←★対象となるドメイン
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9) Gecko/2008052906 Firefox/3.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

・サーバ→ブラウザ

HTTP/1.1 301 Moved Permanently ←★これがHTTPレスポンスコード★
Date: 日付
Server: Apache/1.3.36 (Unix) PHP/4.4.2 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a
Location: http://www.samplesite2.jp/ ★移転先URI
Keep-Alive: timeout=10, max=127
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

これを受けてブラウザは、通知された移転先URIを読み込みにかかります。これが転送動作というわけです。

余談 こういうパケットキャプチャして見る理由

私たちの場合、お客さんから相談を受けるケースがあって、一体このサイトはどういう動作をしているんだろう?というところから入るので、パケットキャプチャして転送動作を確認するんですね。普通にSEOしてたら不要だと思います。

持ち込まれる時点で、かなり普通と違う設定がされていることがあり、それが不具合の原因だったりするわけですが、お客さんにヒアリングしてもサーバ担当でないので分からないケースも多くて、外側から問題点を割り出すために必要だったりする次第です。

こういう動作を見るのはパケットキャプチャソフトを使うと見ることが出来ます。vectorなどにあります。私が使ってるのはSPMというソフトです。
http://www.vector.co.jp/soft/winnt/net/se308001.html

あと、ヘッダーをいろいろな設定に書き換えるソフトがあると便利です。Firefoxでは、Modify Headersというアドオンツールです。UAを切り替えられるアドオンのUser Agent switcherはラクですけど、全部書き換えは出来ないので使い分けてます。

ケータイブラウザとPCブラウザをUAで判別するサイトや、ブラウザの日本語設定と英語設定を判別して転送するサイトで転送動作を確認するのに便利でした。

どちらのケースもSEO的には有利とは言えない設定だった記憶があります。転送は使い方が難しいので出来れば使わないほうが安全だと思います。せっかくのドメインの評価値をサイト内にうまく受け渡せてない状態になることもあるのです。

この記事が良かったと思ったらSphinn Japanへ投稿/投票お願いします。

この記事へのコメント

3 Comments »
    Comment by sugane
    2008/11/21@3:10 PM

    これ、すごい詳しく書かれてますね。永久保存版。有難うございます。

    Comment by シロウト
    2008/11/24@4:32 PM

    ブクマさせて頂きました。

    Comment by ta2masaru
    2008/11/29@1:13 PM

    HTTPのヘッダを見るのであれば、Firefoxのアドオン「LiveHTTPHeaders」がおススメです。
    https://addons.mozilla.org/ja/firefox/addon/3829

Leave a comment