「HTTPステータス コード」とは、ブラウザやクローラがサーバーにリクエストを送信した（≒アクセスした）ときにウェブサーバーが返す応答に含まれる情報だ（正確には「HTTP レスポンス ステータス コード」という）。
「ステータス コード」というぐらいなので、その役割は、要求されたページや画像などの「状態」を表す。状態とは、たとえば「OK」「みつからない」といったものなのだが、HTTPステータスコードはその状態を番号（コード）で表現している。
HTTPステータスコードはサーバーからブラウザなどに送られてくる情報だ。しかしブラウザはページ上にはHTTPステータスコードを表示しない。そのため、HTTPステータスコードを確認するには、Chromeのデベロッパーツールなどを利用する必要がある。
Chromeのデベロッパーツールの［Network］タブを使えばHTTPステータスコードを調べられる
HTTPステータスコードは、大きく次の5種類に分けられる：
| 100番台（100～199） | 情報を表す |
| 200番台（200～299） | 成功を表す |
| 300番台（300～399） | リダイレクトを表す |
| 400番台（400～499） | クライアント側のエラーを表す |
| 500番台（500～599） | サーバー側のエラーを表す |
「番台」というのは、下2桁に複数の種類があることを意味する。たとえば、200～299の範囲には「200」「201」「202」など10種類の番号が標準で定義されているが、それらをまとめて「200番台」と呼ぶ（慣用的に「2xx」と表現することがある）。
2xx/3xx/4xx/5xx の最終的な扱いは基本的に同じ
2xx/3xx/4xx/5xx の最終的な扱いは基本的に同じ
HTTPステータスコードは、インターネット（ウェブ）の仕様で定義されている。技術的には番号によって表す意味は異なるが、Googleにおいては各番台はどれも同じように扱われる（一部例外あり）。
ステータスコード 2xx
- 200 (success)
- 201 (created)
- 202 (accepted)
- 204 (no content)
200 番台はどれも「成功」で、URL はインデックスの対象になる（対象となるだけで、必ずしもインデックスされるとは限らない）。
ただし、次のいずれかの場合はソフト 404 として処理される場合がある。
- 200 を返してもコンテンツがない
- 204 を返す
ソフト 404
ソフト 404 とは、ページが存在しないのにもかかわらず、その URL にアクセスしたときに 200 の HTTP ステータスコードを返す状態。コンテンツがほとんどまたはまったくないページも ソフト 404 として Google に認識される場合がある。
モバイルと PC で別々にソフト 404 を検出している
Google は現在、モバイル向けページと PC 向けページで別々にソフト 404 を検出するようになっているとのこと。
たとえば、次のような状況が発生することがありえる。
- PC 向けページ ⇒ ソフト 404 として認識する。したがってそのページをインデックスしない。
- モバイル向けページ ⇒ 正常なページとして認識する。したがって通常どおりそのページをインデックスする。
このような状況だと、PC 検索の検索結果にはそのページは表示されないのに、モバイル検索の検索結果には表示されるという現象が起こりえる。あるいは、その逆のパターンもあるだろう。
さらにややこしいことに、Search Console のカバレッジ レポートに出てくるソフト 404 はモバイル向けページで検出されたソフト 404 とのこと。PC 向けページで検出されたソフト 404 はレポートには出てこない。
つまり、PC 向けページだけでソフト 404 が発生している場合はカバレッジ レポートで知ることはできない。
ソフト 404 が PC 向けページで発生しモバイル向けページでは発生しない、あるいはその逆のパターンが起きるケースはそうそうあることではないように思えるが、デバイスに応じて異なる HTML を配信する動的な配信と別々の URL 構成では起こるかもしれない。
ステータスコード 3xx
- 301 (moved permanently)
- 302 (found)
- 303 (see other)
- 304 (not modified)
- 307 (temporary redirect)
- 308 (moved permanently)
300 番台は転送を意味する。言い換えると URL の変更（リダイレクト）。
どれも転送先の URL がインデックスの対象になる。
ただし若干の違いがあり、301 は転送先の URL が正規 URL だという強いシグナルを送る。一方で、302 が送るシグナルは弱いものになる。
最終的には、301 も 302 も転送先の URL がインデックスされる（PageRank などの評価も引き継がれる）が、処理にかかる時間の観点では 301 の方が早い。本来の定義上、301 は URL の恒久的な変更を意味するからである。
302 は一時的な移動を意味するものの、長期にわたってリダイレクトが継続すると、完全に移動したものだと Google は判断し、 301 と同じように処理する。
301・302リダイレクトはどちらもPageRankを喪失しない
一般的に言えば、301 リダイレクトと 302 リダイレクトの使い分けは次のようになる。
- 301 リダイレクト――URLを永久に変更する場合
- 302 リダイレクト――URLを一時的に変更する場合
ドメイン名の移転やHTTPS移行、完全な URL の更新は 301 リダイレクトを使うのが通常であればセオリーだった。
しかし現在の Google は 301 と 302 のどちらであっても永続的な URL の移転として処理する。
ただし、処理速度には若干の違いがある。302 はもともとは一時的な移転を意味するので、いきなり永久移転扱いするとそれはそれで問題が出てくることもある。完全な URL 変更だと決まっているなら、普通に 301 を使うべきである。
だが、301 と 302 の違いを知らずドメイン名の移転を 302 リダイレクトで実行していたとしてもそれはそれで構わないということだ。最終的には、永久的な URL 変更として Google は処理してくれる。
PageRank が失われることを恐れてリダイレクトを躊躇するのはもはや無用な心配である。
なお、307 は 302 相当で、308 は 301 相当。
また、リダイレクトが連続した場合は 10 回まで Googlebot はたどり、11 回以上リダイレクトが続くと、リダイレクトエラーになる。
なお robots.txt に関しては、リダイレクトは 5 回まで。
6 回以上のリダイレクトは 404 として処理される。
リダイレクトは半永久的に保持する必要なし
旧 URL から新 URL へ検索エンジンの評価を引き継ぐためにリダイレクトを構成する。
「リダイレクトが有効であるかぎり評価は引き継がれる」、逆に言えば、「リダイレクトを停止すれば評価の引き継ぎは止まる」、このようにサプライヤーは理解してきた。そのため、リダイレクトは半永久的に継続するのが原則であった。
リダイレクトを 1 年間 継続しておけば、リダイレクトを解除しても、旧 URL から新 URL への評価の引き継ぎは継続し、つまるところ、リダイレクトはもはや不要になる。
リダイレクト停止後の旧 URL の評価はどうなる？
1 年経過してリダイレクトを解除したとする。その後、旧 URL に新たなコンテンツを公開したら評価は新旧のどちらの URL に所属するのか？
わかりやすく、ドメイン A をドメイン B に移転したケースで考えてみる。
まず、セオリーどおり、ドメイン A からドメイン B にリダイレクトを設定する。こうすることで、ドメイン A が持っていた評価はドメイン B に受け継がれる。
1 年たったので、リダイレクトを止める。それでも、ドメイン A の評価はドメイン B に引き継がれたまま。
リダイレクトを解除したので、ドメイン A を新たなサイトとして再運用し、ドメイン B とは関係のない独自のコンテンツを公開する。リダイレクトを解除した後は、ドメイン A とドメイン B は互いに独立したサイトとして Google は認識する。
この状況では、ドメイン B はドメイン B として独自の評価を構築する。それでも、リダイレクト継続中にドメイン A から引き継いだ評価は保持する。
同じように、ドメイン A はドメイン A として独自の評価を構築していく。ところが、リダイレクトするまで培ってきた評価はドメイン B に移ってしまっており、戻ることはない。リダイレクト解除後のドメイン A は、評価ゼロからスタートする。
「1年」の補足
リダイレクトを 1 年継続する必要があるとはいえ、きっかり 1 年つまり 365 日ということではない。1 年未満でも評価が完全に移行する場合もあるが、 1 年を目安に考えておけば安心。
また 1 年はどの時点で始まるかと言うと、最初にクロールした時点（リダイレクトを認識した時点）。
旧 URL にユーザーがアクセスするならリダイレクトは保持したほうがいい
リダイレクトは 1 年間 継続しておけばいいというのはあくまでも、Google 検索の評価の観点からの話。
以前の URL にユーザーが引き続きアクセスするのであれば、移転後のページにユーザーを転送するためにリダイレクトは継続しておくべき。
また、ほかの検索エンジンはリダイレクトの継続期間をどのように処理するのかはわからない。Google 以外の検索エンジンも重要なら、安全策のためにやはりリダイレクトは継続しておいたほうがいいかもしれない。
リダイレクトの設定方法
リダイレクトの設定方法は複数ある。
Google 検索における信頼性が高い順に次のようになる。
信頼性が低いとリダイレクトとして処理されない場合がありえる。
| 恒久的なリダイレクト | 一時的なリダイレクト | |
|---|---|---|
| サーバーサイドリダイレクト |
|
|
| refreshリダイレクト |
|
|
| その他のリダイレクト |
|
– |
それぞれのリダイレクト設定方法について補足する。
サーバーサイドリダイレクト
サーバーサイドリダイレクトは、サーバー側の構成により HTTP ヘッダーで 3xx の HTTP ステータスコードを返す。
サーバーサイド リダイレクトは最も信頼性が高いリダイレクトであるため、通常、URL を変更するときなどに設定するリダイレクトでは、サーバーサイドリダイレクトが使用される。
.htaccess、または、httpd.conf へ設定を追記することで実現する。
httpd.confが親の設定ファイルで、.htaccessはhttpd.confの設定を上書きする形で反映される。
refreshリダイレクト
refreshリダイレクトの HTTPヘッダー refresh というのは、HTML の meta refresh タグを記述するのではなく HTTPヘッダーで refresh を返すやり方。
次のような指定が HTTP ヘッダーに含まれるようにする。
Refresh: 0;url=/xyz/JavaScript リダイレクト
JavaScript リダイレクトでは、window.location.href などを使う。ただし、JavaScript はサーバーサイド リダイレクトも refresh リダイレクトも使えない場合に利用する。これら 2 つと比べると信頼性が低くなる。
JavaScriptの実行をOFFにしているユーザーは、転送されない、パラメータの引き続きを意識的に設定しないと、パラメータなしで転送してしまう、などの点に注意。
window.location = "http://abc.com";
window.location.href = "http://abc.com";
window.location.assign("http://abc.com");
window.location.replace("http://abc.com");Crypto リダイレクト
Crypto リダイレクトは、ページ/サイトが移転したことをメッセージで伝えるとともに新ページへリンクしておくこと。
たとえばこんなの。
新しいホームページへ移転しました！こちらからどうぞ。
HTML コードはこんな感じ。
<a href="https://newsite.example.com/newpage.html">新しいホームページへ移転しました！こちらからどうぞ。</a>Crypto リダイレクトはほかのリダイレクトがどれも使えないときの最終手段。
信頼性が最も低く、リダイレクトとして認識される保証はない。
ステータスコード 4xx
- 400 (bad request)
- 401 (unauthorized)
- 403 (forbidden)
- 404 (not found)
- 410 (gone)
- 411 (length required)
- 429 (too many requests)
400 番台はクライアント側（ブラウザや Googlebot）のエラー。
400 番台のステータスコードを返す URL はインデックス処理が行われない（例外 は 429、後述）。
すでにインデックスされている URL が再クロール時に 400 番台を返すとインデックスから削除される。
404 と 410 は表す意味が技術的には異なっても Google 検索での処理は同じ。
なお 429 は、サーバーに過多なリクエストが発生していることを意味し、次に示す 5xx のサーバーエラーと同等に扱われる。Googlebot のクロールを抑える目的で 429 を利用できるが、429 以外の 4xx にはクロールを抑える効果はない。
ステータスコード 5xx
- 500 (internal server error)
- 502 (bad gateway)
- 503 (service unavailable)
500 番台はサーバー側のエラーを意味する。
5xx のステータスコードを Googlebot が受け取ったときは、クロール頻度を下げる。すでにインデックスされている URL はそのままの状態を保つ。とはいえ、長期にわたって 5xx を返し続けるといずれインデックスからは削除される。
サーバーのメンテナンスでサイトを一時停止するときは 503 を返すようにサーバーを構成するのが原則だが、Google 的には、500 でも 502 でも（429 でも）たいして違わない。
なお、robots.txt が 5xx を返すと Googlebot はそのサイト全体をクロールしない。robots.txt が 30 日以上 5xx を返すと、robots.txt の最後のキャッシュ コピーに従ってクロールする。キャッシュの robots.txt がない場合は制限なしにクロールする。
サイト停止時には、503のHTTPステータスコードを返すようにサーバーを構成する
次のような対応では、検索エンジンのインデックスに悪い影響を及ぼすこともある。
コンテンツページの表示内容を「メンテナンス中」に置き換えただけで、Webサーバーが返すHTTPステータスコードは普段と同じ200番（成功を示す）だった場合、Googlebotは、ページが更新されたものとして通常どおりにクロール、インデックスし、検索結果に「メンテナンス中」を表示する可能性がある。
リダイレクトした場合は、リダイレクト先ページで結局は200番を返すので、同じようにメンテナンスページが結果に出てくることがある。
万が一サーバー復旧に時間がかかってしまい404などのエラーを返す状態が続くとインデックスから消えてしまうリスクがある。
ごく短い時間であったり、クロール頻度が高いページ（たとえばトップページ）だったりすれば、ほどなくして元の状態に戻るだろう。しかし、メンテナンスなどでサイトを一時的に停止する際には、503のステータスコードを返すことが鉄則だ。Googlebotは、503を返してきたページに関しては、インデックスには手を加えず、しばらくした後に再びクロールしに来る。