エンタープライズSEOを改善するレスポンスコードの基礎

レスポンスコードは、ウェブサイト上のあらゆるページ、イメージ、そして、ファイルに影響を与える。

サイトを訪れた検索エンジンは、レスポンスコードを基に何をするべきかを判断する。誤ったレスポンスコードは次のような問題を引き起こす可能性がある:

• インデックスの問題
• 重複するコンテンツ
• サイトパフォーマンスの問題
• その他のサイトが乱雑になる問題

エンタープライズ SEOにおいては、サイト全体で大きな勝利を得ることが最も重要である。

レスポンスコードはこの勝利を呼び込む。設定するのが簡単であり、広範なインパクトをもたらす。手堅い取り組みに思える。

しかし、1000を超える大型サイトをチェックしてみた結果 – 5000ページ以上持つサイト – 、レスポンスコードを正確に利用していたサイトはたった3割だけであった。

たった3割だ。

この点を考慮し、私は自分が作成したレスポンスコードを引っ張り出し、エンタープライズサイトの開発者、SEO担当者、そして、興味がある人達のために簡単なガイドラインを書いてみた:

レスポンスコードのビッグスリー

最も知っておきたいレスポンスコードを3つ挙げる:

• 404 ページが見つかりません。ファイルが単純に存在しない場合、サーバーは404ステータスを提供するべきである。グーグルボットに劣悪なURLの再試行の頻度を減らしてもらいたい場合、410レスポンスを利用することが出来る。

• 301 ページを引っ越しました。あるURLを恒久的に削除し、別のページで置き換える際は301を利用する。

• 302 ページを一時的に移動しました。何かを削除したものの、今後戻す予定なら、302を利用する。

他にもレスポンスコードはある。例えば、200は「OK」を意味する。因みにこのコードは変更しておいてもらいたい。

「ページが見つかりません」のレスポンス

ブラウザやボットがサイトを訪問し、存在しないファイルを読み込もうとしたら、404 レスポンスが与えられるべきである。これは最も重要な点である。

404は、サーバーが「そのファイルはここにはないよ」 と言う点を伝える表現である。これは必ずしも悪いことではない。リンク切れのリンクをクリックした場合、または、ただ単に存在しないページを訪れた際の適切な答えである。

削除したページのリンクのオーソリティを維持しようと試みる場合、困難な作業を要求される可能性がある。しかし、ページが見つからない場合のデフォルトの答えは404であるべきだ。

問題点: 多くのサイトは302:一時的なリダイレクト、301:恒久的なリダイレクト、さらにひどい場合だと200:OKを利用している。これは大規模なサイトの重複、そして、クロールの効率の劇的な低下を招く。サイトを訪問するボットは、価値のないコンテンツをクロールするために時間を割いてしまうためだ。

考えられる原因と解決策:

• .NETは40xのエラーの管理を引き継ぎ、フレンドリーなエラーページに302で置き換える行為を好む。親切だが、完全に間違えている。.NETの404の処理を無効にして、IISに引き継ごう。IISでも割とフレンドリーなエラーページが表示されるはずだ。
• 検討違いの開発者が、全ての「not found」エラーをホームページにリダイレクトすることで、ユーザーの役に立つと考えていた可能性がある。実際には役に立たない。これは回転ドアに入り、同じランダムな場所に戻って来るのと同じであり、混乱を招くだけである。何が失敗したかを説明し、選択肢を与えるフレンドリーな404ページを提供しよう。
• 誰かがjavascriptもしくはmetaリフレッシュを用いるリダイレクトページを設定し、ビジターを“妥当だと思える”ページに別のルートで送っている可能性がある。一つ前の項目を参考にしてもらいたい。同じ問題である。
• サイトでPHPが用いられているなら、header('location: /'); die();が利用されている可能性がある。header("HTTP/1.1 404 Not Found");等を変わりに試してみよう。
• サイトが単に200:OKコードを提供している可能性がある。理由は分からないが、100-200サイトがこのコードが利用していた。変更しよう。

410レスポンスでも問題ない。グーグルボットがインデックスからURLを削除するペースが早くなり、URLの再インデックスの頻度を下げる効果がある。4xxのコード、そして、その他のステータスコードをW3のステータスコードの定義ページで確認することが出来る。

リダイレクトの種類

リダイレクトは強力なSEOツールである。オーソリティを適切な場所に集約することが出来るためだ。しかし、やり方を間違えないように注意する必要がある。

301コードは、ページを訪れるボットやブラウザにローディングしているページが永遠に消えた点、そして、代わりのページのURLを伝えるためのコードである。301を使って、オーソリティを集約し、基本的なカノニカルの問題を解決しよう。

検索ボットは、過去のURLのオーソリティの一部を新しいURLに移してくれる。また、最終的に過去のURLの訪問をやめて、代わりに新しいURLを訪問するようになる。

302コードは、ボットまたはブラウザにローディングしているページが存在しないものの、一時的である点を伝える。ボットは古いURLに継続的に戻り、ページが戻されたかどうかを確認する。

問題点: 私の知る限り、大型サイトはランダムに302と301を混合している。場合によってはオーソリティを失っており、ボットに永久的に削除されたコンテンツを無理やり何度も何度もクロールさせている。

考えられる原因と解決策:

• IIS 6および以前のバージョンでは、「このページを301リダイレクトにしてくれ」と言う点を表現する親切且つ明瞭なボタンは用意されていなかった。その代わりに、「A permanent redirect for this resource」の欄をチェックしなければならない。デフォルトではチェックが入っていないため、デフォルトの状態では302、つまり一時的なリダイレクトが採用される。
• ウェブアプリにリダイレクトを書き込んでいるものの、スタータスコードが脱落している可能性も考えられる。一部のサーバーは、デフォルトで302の一時的なリダイレクトに設定しているため、スタータスコードを自ら301に変更する必要がある。

難しくはない

サーバーのインフラがどれだけ複雑であれ、ビッグスリーのレスポンスコード – 404、301、302 – を適切に設定することで、サイトワイドでプラスの効果を得ることが出来る。そのため、大きなサイトを運営しているなら、レスポンスコードを確認してもらい、是正してもらいたい。SEO、パフォーマンス、そして、ユーザーエクスペリエンスが改善されるだろう。

この記事の中で述べられている意見はゲストライターの意見であり、必ずしもサーチ・エンジン・ランドを代表しているわけではない。

この記事は、Search Engine Landに掲載された「The Enterprise SEO Guide To Response Codes」を翻訳した内容です。