301リダイレクトを整理して、サイトの読み込み時間を改善する

検討を始める前に、これを考え始めたきっかけを話しておきたい。僕は、あるクライアントと開発関係の打ち合わせをしていた。この打ち合わせはSEO業務とは何の関係もなかったが、いつものように、話題はすぐにSEOに関するものに移っていった。

このクライアントは家庭用品のメーカーで、サイトの読み込み時間にとても気を使っている。それも当然のことだ。サイトで高解像度の画像を使用しているため、読み込み時間ができるだけ短くなるように可能な限り対策を講じなければならないのだ。

読み込み時間を減らすために提案された戦略の1つが、すべての301リダイレクトを削除することだった。これが僕の注意を引いた。

これを見過ごしにはできない。リダイレクトには絶対に必要なものもあることが僕にはわかっていたからだ。

……いや、まてよ。リダイレクトがどれほど価値のあるものなのか、リダイレクトにアクセスする人がどのくらいいるのかは、はっきり分かっていない。主張の支えとなるべき定量的なデータを僕は何も持っていなかった。

僕は、実効性のある解決策を講じるまでは、すべてのリダイレクトをそのままにしておくよう説得した。301リダイレクトがどれほど重要になりうるかを示すデータを集める必要があるのは当然だ。だが、残すべきリダイレクトを特定するには、どうすればよいのだろうか。

僕は、開発やITの領分には踏み込まず、（マーケターおよびアナリストとして）簡単に入手できる形でデータを提供できる方法を見つけたかった。

うってつけの選択肢が、Googleアナリティクスだった。

僕は、「リダイレクトの削除」という難題の解決策を徹底的に話し合うなかで（詳細はこの記事の3番目のセクションを読んでほしい）、サイトの読み込み時間に影響を与える要素が他にいくつかあることに気がついた。失効したURL（当時301リダイレクトされていたURL）へのリンクや、301リダイレクトされたURLが設定されている「rel="canonical"」属性などだ。

要するに、起こりうるリダイレクト関連の問題のすべてだ。

結果として、こうした問題を修正することにより、サイトのリダイレクトにかかる時間を効果的に削減できた。

開発チームは感激し、SEOチームは（必要な）301を残したことを、おおいに喜んだ。そして、クライアントは、読み込み時間が短くなったことに満足だった。

この変更を実施したのは、2015年7月から8月の間だった。結果は下の図を見れば自ずと明らかだろう。

Googleアナリティクスの「サイトの速度」における、モバイルの「平均リダイレクト時間」の推移

リダイレクトがSEOの取り組みを損なう可能性があるケースは、次の4つだ。

1. リダイレクトチェーンがある
2. 内部リンクがリダイレクトを経由している
3. 不要な301がある
4. 301リダイレクト先を示す「rel="canonical"」タグがある

それぞれについて解説していこう。

1. リダイレクトチェーンがある

まずは、簡単な定義から始めよう。「リダイレクトチェーン」とは、あるURLから別のURLに転送するリダイレクトが繰り返されることを意味する言葉だ。

リダイレクトチェーンが引き起こす問題とは、ユーザーや検索エンジンが最終のリダイレクト先に到達するまで待たされることだ。

たとえば、次のようなリダイレクトだ。

www.mysite.com/responsive

www.mysite.com/responsive-web-design

www.mysite.com/rwd

もちろん、周知のように、ここにはオーソリティの引き継ぎの問題が含まれている。リダイレクトチェーン内での転送1回につき、オーソリティはおよそ10％失われる。

また、リダイレクトがページの読み込み時間を大幅に遅くし、サイトの全体的な質を大きく下げるおそれがあることも忘れるわけにはいかない。転送が1回の標準的なリダイレクトでさえ読み込み時間に影響を与えるというのに、そのうえ複数のリダイレクトによって、1つのURLを呼び出すためだけに転送が繰り返されているかもしれないなんて。

長い間に301が積み重なり、こうしたチェーンが作られてしまうことは、驚くにはあたらない。1人がリダイレクトを設定したのに、同僚が別のリダイレクトを作成し、数か月後にまた別のリダイレクトが重なるといった具合だ。ありがちなことだ。

では、このようなチェーンを見つけるにはどうすればよいだろうか。幸いなことに、Screaming Frogにいるわれわれの友人が、あきれるほどシンプルな機能を同社のツールに組み込み、リダイレクトチェーンを特定してレポートに出力できるようにしてくれた。

使い方は次のとおりだ。

• Screaming Frog SEO Spiderでサイト全体をクロールする。
• Screaming Frogのメニューで、［Reports］>［Redirect Chains］の順に選択する。

手順は本当にこれだけだ。

ただし、修正が必要なリダイレクトがどれなのかを分析する作業は、レポートの生成より少々複雑だ。

この作業を難しいものにしている唯一の理由は、サイト上のすべてのリンクが含まれていることにある。つまり、リンク先の外部サイトにあるチェーンも同じように検出してしまうのだ（下のスクリーンショットの赤いセル）。

このデータでよく見かけるのは、ソーシャルメディアでの共有するためのURLだ。この手のURLは頻繁に変更されるため、レポートから取り除く必要がある。B列で自サイトのドメイン名（緑色のセル）を探し、それ以外の行はすべて削除しよう。

この作業が終われば、後はきわめて簡単で、301リダイレクトを見直して不要な転送を削除すればいい。ただし、その結果を開発チームやITチームに送るのはもう少し待とう。この記事を読み進めて、もっと役立つノウハウを手に入れてほしい。

2. 内部リンクがリダイレクトを経由している

リダイレクトがSEOの取り組みを損なう可能性のある2つ目のケースは、別の場所にリダイレクトされているURLに飛ぶ内部リンクだ。

サイトで何が起きているのかを理解するには、次の簡単な手順を実行してほしい。

1. Google Search Consoleにアクセスし、内部リンクの全リストをダウンロードする。

   ［検索トラフィック］>［内部リンク］の順に選択し、「このテーブルをダウンロード」ボタンをクリックすればいい。

2. ダウンロードしたCSVファイルを開き、Excelの結合機能を使って、各URL文字列の先頭に自サイトのドメイン名を追加する。

   

   ExcelのCONCATENATE関数を使って、パスをフルURLにする

3. 完全なURLの列が完成したら、リスト全体をクリップボードにコピーし、その情報をもとに、Screaming Frog SEO Spiderにクロールさせる。

Screaming Frog SEO Spiderでの作業方法は次のとおりだ。

1. メニューバーの［Mode］を［List］に変更する。次に［Upload List］と［Paste］をクリックする。これで、内部リンクレポートからのURLのみのクロールが実行される。

2. 作業が完了したら、ステータスコードの列をチェックし、301がないかどうかを確認する。

3. 301が見つかったら、そのURLを選択し、Screaming Frog SEO Spiderの左下にある［Inlinks］タブに移動する。

4. すると、そのリダイレクトしているURLへのリンクを含むすべてのページが表示される。

リダイレクトしている内部リンクをすべて特定できたら、更新用リストをまとめて開発チームに送ろう。

3. 不要な301リダイレクトがある

ウェブサイトでは、長い年月の間に301リダイレクトが増えていく傾向にある。にもかかわらず、だれも本腰を入れてその状況をきれいに整理しようとはしないものだ。

しかし、.htaccessファイルによって制御すべきリダイレクトの数が増えると、読み込み時間に悪い影響を及ぼす。URLがブラウザから呼び出されるたびに、リダイレクトが1つ1つチェックされ、要求されたURLをどこか別の場所に転送する必要があるかどうかが確認されるからだ。この動作が、読み込みにかかる時間を間違いなく長くする。

だが、このようなリダイレクトのうち、本当に必要なものがどれなのかを特定するにはどうすればよいだろうか。そこで、Googleアナリティクスの「utm_」系のトラッキングパラメータの出番だ。

リダイレクトの転送先URLにトラッキングパラメータを追加すると、実際に301リダイレクトが使われているかどうかを簡単に調べられる。

以下は、僕が利用しているタグ設定の例だ。

/old-page

/new-page?utm_medium=301&utm_source=direct&utm_campaign=/old-page

これによってリダイレクトにアクセスがあるたびにデータがGoogleアナリティクスに送信され、utm_mediumやutm_campaignに含めたリダイレクトされたアクセスの状況を集計できるようになる。

Googleスプレッドシートで作った僕のutm付きリンク先URL生成シートを開き、Googleスプレッドシートのメニューで［ファイル］>［形式を指定してダウンロード］>［Microsoft Excel（.xlsx）］を選んでダウンロードして使ういい。

僕は年に2回、Googleアナリティクスにアクセスして「参照元/メディア」レポートを確認し、インラインフィルタで「301」という文字列がある行に絞り込んで調べている。

これで、実行されたリダイレクトをリストアップし、.htaccesファイルの301のリストと比べればいい。アクセスされていないリダイレクトは削除しよう。

4. 301リダイレクト先を示す「rel="canonical"」タグがある

これは基本的にはリダイレクトチェーンがある場合と同じなので、少し説明が必要かもしれない。

リダイレクト先のURLを示すcanonicalタグは不要だろう。

そこで、このようなcanonicalタグを特定するために、Screaming Frog SEO Spiderでクロールしてから、［Directives］タブに移動する。右方向にスクロールして、「Canonical Link Element 1」という列が表示されたら、そのリストをコピーしよう。

「List Mode」でコピーしたリストをもとにサイトをクロールさせ、ステータスが301になっているものを見つけ出す。

おまけ：301経由でリンクを再獲得する

大規模なサイトや、長年にわたってURLの構造が少ししか変わっていないサイトを運営しているなら、無効になったURLに張られていた上質なリンクを獲得できる大きなチャンスがある。

Open Site Explorerのレポートを実行して、ターゲットURLのリストを取得しよう。

前述の「Upload List」と同じ方法を使って、このリストをScreaming Frog SEO Spiderに貼り付ける。「Status Code」列に何らかのエラーが示された場合は、そのURLへの301リダイレクトが行われていることになる（念のために、これらのリンクの状態と質を最初にチェックしておこう）。

このリストに加えるべき他のリダイレクト関連の問題があるという方や、ここで取り上げたような問題を特定して解決する別のやりがあるという方は、コメント欄で行われている議論に参加してほしい。