Moz - SEOとインバウンドマーケティングの実践情報

リダイレクトをキャッシュするうまい方法はないものか?

サイト構造を変更すると必要になるリダイレクト。しかし、その重要性を理解していない企業は多い
Distilled
SEOmozは英国Distilled社と提携し、検索エンジン市場のニュースと情報を提供している。この記事はDistilled.co.ukに勤務する協力者から提供されたもので、内容はすべて筆者自身の見解であり、SEOmozの見解を反映しているとは限らない。

Distilled社では現在、大手クライアントのプロジェクトを2つ手がけているんだけど、その過程で、ある扱いにくい問題について考えさせられることがあった。この問題は、特に大企業のSEOプロジェクトで直面するものだ。

というのも、大規模なクライアントがWebサイトを大幅に変更しようとする場合、僕らの経験からすると、提案書のなかの「301リダイレクト」と題されたセクションは、ほぼ間違いなくざっと読まれて、すぐに検討対象から外されてしまうんだ。

僕らは、SEOに際してコンテンツのURLが変わった際に施すべき恒久的リダイレクトの重要性に関して、それを大企業にきちんと理解してもらうためには、こちらから強く働きかけなければならないことを学んできた。

僕らが現在取り組んでいる2つのプロジェクトでは、次のように、トラフィックの多いWebサイト上で適切にリダイレクトを指定する最も安価かつ効率的な方法を考える必要があった。

  1. 新聞社のWebサイトのリニューアルを支援するにあたり、僕らは301リダイレクトのスコープ(有効範囲)をかなり大幅に変更するよう強く要請し、リニューアルサイト公開日に間に合うよう、旧サイトの全ページを301リダイレクトさせた。

  2. あるFortune 100企業のWebサイトで大きなサブセクションの移転を検討するにあたり、この企業には旧セクションから移転を実行しリダイレクトを構築するのに必要なリソースがないことがわかった。

第1のケースでは、担当する開発者たちは極めてタイトなスケジュールを組み、標準フレームワークとコンテンツデリバリネットワーク(CDN)とパーソナライズ機能用のJavascriptをうまく組み合わせて、スケーリングの問題を解決していた。

第2のケースでは、僕らは(半分冗談で)クライアントが旧サブドメイン名を僕らのサーバーにリンクさせて、僕らがリダイレクトエンジンを作るという方法を提案しようかと思った(これも同じようなスケーリングの問題が出てくるだろうけど)。

どちらにも共通する問題は、リダイレクトをキャッシュするソリューションが存在しないことだ。現状のウェブのキャッシュの仕組みは、HTMLページ以外のものをうまくキャッシュできるように設計されていない。

詳細に入る前に、CDN(コンテンツ配信ネットワーク)について簡単に説明しておこう。利用者の多いWebサイトや、動画およびストリーミングコンテンツを大量に提供しているWebサイトなどでは、次の2つのタスクが分離されている。

  • Webサイトを構築するタスク
  • サイトをどこでも誰でも必要に応じて利用できるようにするタスク

CDNの目的は、後者の問題に対処するために、複雑な情報を処理して管理する必要のあるメインサーバーとは独立した形でコンテンツ配信用のサーバーを追加することだ。実際にどういうことが行われるかというと、まず企業側はWebサイトをCDNに組み込めるようにする。すると、CDN側ではそれを複製して、ユーザーに提供する。こうすることで、基盤のホスティングサーバーに変更を加えることなく、数百万人規模のユーザーにも対応することが可能になる。

CDNはSEOの取り組みに対してどのような障害を引き起こすか

僕らは先週、(少なくとも一部の)CDNがキャッシュするHTMLページは、HTTPステータスコードとして「200 OK」を返すページだけだということに気づいた。これはつまり、アーキテクチャを広範囲で変更する場合にCDNはあまり役に立たない、ということだ。なぜなら、(SEOに配慮した場合は)小さな大元サーバーから大量の301リダイレクトを返すか、もしくは(こちらの方が大いにありそうだが)404エラーが大量に発生するか、どちらかの事態を招くことになってしまうからだ。後者のケースでは、CDNはHTTPステータスコードが200のページをキャッシュしていなかったため、ページが存在しないものだと考える。その結果、301リダイレクトが適切に行われないんだ。

こうしたことが起きるのには、ちゃんとした意味がある。CDNには配信に成功したページしかキャッシュさせず、エラーが生じた場合はメインサーバーをチェックする必要があることは、きっと理解できるはずだ(特にロールアウト時は、たとえばGoogle Analyticsの404エラーページ追跡機能など使って、404エラーを徐々に捕捉、修正し、その修正をCDNで配信されるバージョンに反映させたいと思うだろう)。そう考えていくと、なぜCDNが200ステータスでないページをキャッシュしなくなったのかは比較的容易に理解できる。けれど、これはSEOの目的には決して望ましいものではないんだ。

しかし、事態はさらに深刻だ。主要なフレームワークに組み込まれたキャッシュソリューションを調べてみると、その大半がリダイレクトをきちんとキャッシュできるように設計されていないことがわかる。存在しないページへのリクエストを受け取ると、キャッシュをチェックしないだけでなく、「いや、確かにページは存在しません」(または「こちらに完全に引っ越しました」)という確たる結果が返ってくるまで、データベースをくまなく探し回り、大量のクエリを発生させてしまう。

これほどの規模でリダイレクトを検討する場合、必然的にデータベース駆動型のCMSからリダイレクトを実行することを考えることになる。Apacheはハードコーディングしたリダイレクトなら迅速に対応できるが、サイト構造を大規模に変更する場合には、設定を変更するだけでは決して問題を解決できない。いずれにしてもこのような状況では、ルールに基づくリダイレクトが必要になるはずだ(それをApacheの設定ファイルで正規表現を使って行うなんて、考えただけでも冷や汗が出る)。

そんなわけで、存在しないページを探すビジターが百万人単位でやって来ても対処できるシステム(上で述べたような、もうじき廃止されるサブドメイン名をホスティングするのに必要)を見つける必要は(今のところはまだ)ないものの、僕らは次のような思いを抱くようになった。

200ステータスでないページを、配信に成功したHTMLページをキャッシュするシステムと同じくらい効率的にキャッシュする良い方法はないだろうか?

だれか答を知らないだろうか? その答えが見つかるまでの間、願わくはこの記事が、フレームワークとCDNからなる大規模かつ複雑なシステムで「旧ページすべてを新規ページに恒久的にリダイレクトする」という1行の仕様を実現するのに何が必要かを、立ち止まって考える契機になりますように。

用語集
HTML / Java / SEO / キャッシュ / ドメイン名 / リダイレクト / リンク / 検索エンジン
この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アクセシビリティ
広義には、障害者、高齢者を含むすべての人間が、同じレベルでサービスや機器、施設を ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]