リダイレクトとは？恒久か一時かで選ぶ｜自社285本の実測

「301と302、どちらを使えばいいのか」。サイトのリニューアルやドメイン変更を前に、リダイレクトの設定でつまずく方は少なくありません。間違えると検索順位が落ちると聞けば、なおさら手が止まります。

結論から言えば、判断は「URLの変更が恒久的か、一時的か」の一点でほぼ決まります。難しいのは選ぶことではなく、設定したあとに正しく効いているかを確かめることのほうです。

この記事では、6種類の違いと選び方を整理したうえで、自社メディアの公開記事285本を実測した結果を公開します。同じ301でも応答時間が7.4倍違い、設定したつもりで効いていなかったURLも見つかりました。読み終えるころには、自分のサイトの転送が機能しているかを、その場で確かめられます。

先に結論｜リダイレクトは恒久か一時かで選ぶ

リダイレクトの種類は全部で6つあります。ただ、実務で本当に迷うのは301と302のどちらを使うかという一点だけです。そしてその判断は、URLの変更が恒久的なものか一時的なものか、それだけで決まります。

この章で先に示すのは、仕組みと選び方の基準です。コードごとの細かい違いは次の章で扱います。

• リダイレクトは別のURLへ自動で送る仕組み
• 恒久的な変更なら301、一時的なら302
• 迷ったときに答える3つの質問

リダイレクトは別のURLへ自動で送る仕組み

リダイレクトとは、あるURLにアクセスした人を別のURLへ自動的に送る仕組みです。日本語では転送とも呼ばれます。

裏側で起きていることは単純です。ブラウザがサーバーにページを求めると、サーバーは「そのページはここにない、別の場所にある」という意味の返事をします。行き先のURLは、Locationという項目に入れて一緒に渡されます。

ブラウザはそれを読んで、自動的に新しいURLへアクセスし直す。この一往復が、利用者には一瞬で画面が切り替わったように見えているわけです。

HTTPの仕様書であるRFC 9110は、この一群の返事を3xxと総称し、「リクエストを完了させるために、ユーザーエージェントによるさらなる動作が必要であることを示す」と定義しています。ユーザーエージェントとは、ここではブラウザだと考えて差し支えありません。

Web担当者がリダイレクトに向き合うのは、たいてい次の4場面です。

• サイトをリニューアルしてURLの付け方が変わった
• 独自ドメインを変更した
• httpからhttpsへ切り替えた
• 似た内容の記事を1本に統合した

どれも目的は同じで、昔のURLを知っている利用者と検索エンジンを、新しいURLへ案内することにあります。

恒久的な変更なら301、一時的なら302

結論から言えば、元のURLに戻す予定がないなら301、戻す予定があるなら302です。

両者の違いは名前にそのまま表れています。301はMoved Permanently、つまり恒久的に移動したという意味。302はFound、一時的にそこで見つかったという意味です。RFC 9110の定義を並べると、性格の違いがはっきりします。

項目	301	302
規格上の意味	新しい恒久的なURIが割り当てられた	一時的に別のURIの下にある
今後どちらのURLを使うか	新しいURLを使うべき	元のURIを使い続けるべき
検索エンジンへの合図	検索結果を新しいURLに切り替えてほしい	元のURLのままにしておいてほしい
ブラウザに記憶されるか	されやすい	規格上の記載なし

この違いは検索結果の見え方に直結します。恒久的な変更なのに302を選んでしまうと、いつまで経っても検索結果が新しいURLに切り替わりません。逆もまた困ります。一時的な差し替えのつもりで301を打つと、元に戻したいときに手間が増えます。

最後の行に挙げた「ブラウザに記憶されるか」は、実務で地味に効いてくる差です。RFC 9110は各コードの説明の末尾に「この応答はヒューリスティックにキャッシュ可能である」という一文を添えることがあります。転送に使う4つで見ると、301と308には付いていて、302と307には付いていません。

実務では何が起きるか。301はブラウザに覚えられやすく、いったん設定して取り消しても、そのブラウザでは古い転送先へ飛び続けることがあります。

301を打つ前に「本当に戻す予定がないか」を確かめるべき理由は、ここにあります。

迷ったときに答える3つの質問

自分のケースで決めきれないときは、次の3つに順番に答えてみてください。上から答えていけば、たいていは2問目までで決まります。

質問	答え	選ぶもの
元のURLに戻す予定はあるか	ない	301
	ある	302
検索結果に出したいのはどちらか	新しいURL	301
	元のURL	302
フォーム送信など入力を伴う操作の途中か	はい	307か308を検討

3つ目だけ少し毛色が違います。フォームの送信をまたぐ場面では、301と302は転送のときに送信方法を書き換えてしまうことがあり、入力内容が失われかねません。この点は次の章で詳しく扱います。

リダイレクトの種類は6つ｜301と302の違い

リダイレクトの手段は、サーバーが返すものと、ページ側に書くものの2系統に分かれます。実務で選ぶことになるのは、前者の301・302・307・308と、後者のmeta refreshとJavaScript。この6つです。

この章では、それぞれの違いと、自分のケースでどれを選ぶかを扱います。

• サーバーが返す301・302・307・308
• 307と308がメソッドを変えないとされる根拠
• ページ側で書く2つの転送方法
• 自分のケースで選ぶための早見表

サーバーが返す301・302・307・308

4つのコードは、恒久か一時かという軸と、送信方法を書き換えるかという軸の2つで整理できます。

コード	名称	恒久／一時	POSTをGETに書き換えるか
301	Moved Permanently	恒久	書き換えてよい
302	Found	一時	書き換えてよい
307	Temporary Redirect	一時	書き換えてはならない
308	Permanent Redirect	恒久	書き換えない

実務で効いてくるのは右端の列です。RFC 9110は301の注記にこう書いています。「歴史的な理由により、ユーザーエージェントは後続のリクエストで方式をPOSTからGETへ変更してもよい」。そのうえで「この動作が望ましくない場合は308を代わりに使える」と添えました。

302の注記も同じ構造です。望ましくないなら307を使え、という案内になっています。

POSTからGETへの書き換えは、何を引き起こすのでしょうか。フォームに入力した内容はPOSTで送られます。途中で方式がGETに変わると、入力内容が転送先には引き継がれないのです。問い合わせフォームや購入手続きの途中に転送が挟まる設計なら、307か308を検討してください。

307と308がメソッドを変えないとされる根拠

307については、RFC 9110の本文にはっきり書かれています。「ユーザーエージェントは、そのURIへ自動的にリダイレクトを行う場合、リクエストの方式を変更してはならない」。MUST NOTという強い語での禁止です。

ところが308は事情が違います。308を定義した節を読んでも、同じ禁止の一文は出てきません。RFC 9110の全文を通して、方式の変更を禁じるMUST NOTの明文があるのは307の節だけでした。

では308の根拠はどこにあるのか。2か所あります。

ひとつはRFC 9110の3xx全体の注記です。「307と308は、方式を保存するリダイレクトを曖昧さなく示すために後から追加された」と、追加の経緯が説明されています。

もうひとつは、308を標準化したRFC 7538の注記です。「このステータスコードは301に似ているが、リクエスト方式をPOSTからGETへ変更することを許さない点が異なる」と明記されています。なお308は2014年6月のRFC 7238で登場し、現行の定義は後継のRFC 7538にあります。

細かい話に見えるかもしれません。ただ、ここを正確に書けるかどうかで解説の信頼性は変わります。「RFC 9110が308にMUST NOTを定めている」と説明している記事を見かけますが、条文を当たると307の節にしか存在しないのです。308の根拠は、規格の注記と、元になったRFCの記述にあります。

ページ側で書く2つの転送方法

サーバーの設定に手を入れられない環境では、ページ側に書く方法があります。meta refreshとJavaScriptの2つです。どちらもGoogleは認識しますが、扱いには条件がつきます。

meta refreshは、秒数によって意味が変わるのが特徴です。ページ読み込み直後に発火する即時のものを、Googleは永続的なリダイレクトとして解釈します。任意の秒数を置いてから発火する遅延型は、一時的なリダイレクトとしての解釈です。どちらも公式ドキュメントに明記されています。0秒かそれ以外か。この一点で301相当か302相当かが分かれるわけです。

JavaScriptによる転送は、Googleがはっきり優先度を下げています。「サーバー側のリダイレクトまたはmeta refreshリダイレクトを行えない場合にのみ、JavaScriptリダイレクトを使用してください」という書き方です。

理由も添えられています。Googleはクロールしたすべてのページを描画しようとするものの、さまざまな理由で描画は失敗しうる。失敗すれば、その転送は認識されません。

公式ドキュメントには、もうひとつcryptoリダイレクトという項目があります。これは転送の仕組みではなく、旧ページに「引っ越しました」と新URLへのリンクを置くだけのもの。Googleはここで「ネス湖の怪獣のように、存在の真偽が問題視される可能性がある事例が見られます」と冗談を挟んでいます。そのうえで釘を刺すことも忘れていません。「ほかに方法がない場合を除き、コンテンツを移転したことを検索エンジンに伝えるために crypto リダイレクトを使用しないでください」。

自分のケースで選ぶための早見表

Googleの公式ドキュメント「リダイレクトと Google 検索」には、永続的なリダイレクトと一時的なリダイレクトの手段を並べた表があります。見落とされがちなのですが、この表は掲載順そのものに意味を持たせた作りです。

公式の説明にはこう書かれています。「次の表は、永続的なリダイレクトと一時的なリダイレクトを設定するためのさまざまな方法を、Googleによって正しく解釈される可能性が高い順に説明しています」。上に書かれている手段ほど、意図どおりに伝わりやすいという意味です。

公式の表には303やHTTP refresh、cryptoリダイレクトも並んでいます。ただ実務で検討するのは、先に挙げた6つです。

順位	恒久的に変えたいとき	一時的に見せたいとき
1	HTTP 301	HTTP 302
2	HTTP 308	HTTP 303
3	meta refresh（0秒）	HTTP 307
4	HTTP refresh（0秒）	meta refresh（0秒超）
5	JavaScript	HTTP refresh（0秒超）
6	cryptoリダイレクト	—

Googleは推奨も明言しています。「検索エンジンの結果に表示されるページのURLを変更する必要がある場合は、可能な限りサーバー側の永続的なリダイレクトを使用することをおすすめします。これは、Google検索とユーザーを確実に正しいページに導くための最善の方法です」。

まとめると順序はこうなります。迷ったらサーバー側の301か308。それができない環境ならmeta refresh。どちらも無理なときの最後の手段がJavaScriptです。

自社285本を実測してわかった3つのこと

自社メディアの公開記事285本すべてにリクエストを投げた結果、3つのことが分かりました。表記ゆれの301は例外0件で正規形へ飛ぶこと。同じ301でも応答時間に7.4倍の差があること。そして、大文字にしたURLだけは転送されていなかったことです。

ここまでは規格と公式ドキュメントの話でした。ここからは実際に測った話に移ります。

• 表記ゆれの301は285件すべて正規形へ飛んだ
• 同じ301でも応答時間が7.4倍違った
• 大文字にしたURLだけ転送されなかった
• 自分のサイトで同じことを確かめる方法

表記ゆれの301は285件すべて正規形へ飛んだ

まず基本の確認から。公開記事285本について、末尾のスラッシュを外したURLにリクエストを投げました。

結果は285件すべてが301。転送先を示すLocationの値も、285件とも元の正規URLと一致していました。例外はゼロ件です。httpで始まる形とwww付きの形も、それぞれ60本ずつ調べて全件301でした。

同じ計測を2026年8月21日に265本で行ったときも、例外は出ていません。記事が20本増えた状態でも崩れていない、ということになります。

チェーンの長さも測りました。http・www付き・末尾スラッシュなし、この3つを同時に満たす最悪のURLを30本つくって追跡したのです。結果は30本すべてが2ホップで正規形に到達。3ホップ以上は発生しませんでした。

Googleは公式ドキュメントで「デフォルトでは、Google のクローラーは最大 10 回のリダイレクト ホップを追跡します」と書いています。ただし特定のプロダクトのクローラーでは制限が異なる場合がある、という留保も付いています。いずれにせよ2ホップなら余裕の範囲です。

同じ301でも応答時間が7.4倍違った

最初の計測では、301のほうが正規URLの200より遅いという妙な結果が出ました。順番による影響を疑い、記事ごとに計測順を入れ替える方式で40本を測り直しています。

アクセスした形	返ってきたコード	応答時間の中央値
httpで始まる形	301	48.4ミリ秒
末尾スラッシュなし	301	357.9ミリ秒
www付き	301	356.5ミリ秒
スラッグを大文字に	200	404.1ミリ秒
正規URL（比較用）	200	408.7ミリ秒

順序の影響は消えました。そして、予想していなかった差が残りました。

末尾スラッシュとwwwの301が約357ミリ秒かかるのに対して、httpからhttpsへの301は48.4ミリ秒。同じ301という応答なのに7.4倍の開きがありました。

手がかりはレスポンスヘッダにありました。ページ本体とは別に、サーバーが付けてくる説明書きのようなものです。

速いほうの301には、Cache-Controlという項目が付いていませんでした。これはブラウザにどれくらい覚えておいてよいかを伝える項目です。一方、遅いほうの301には「max-age=0, no-cache」という値のCache-Controlが付いていました。

この値は、WordPressが通常のページで返す200とまったく同じ内容です。

ここから読み取れることがあります。httpからhttpsへの転送はWebサーバー側で返っていて、末尾スラッシュとwwwの正規化はWordPress本体まで処理が届いてから返っている。その可能性が高そうです。ただしサーバーの設定を直接確認したわけではないので、断定はできません。

実務に引き寄せると、意味はこうなります。表記ゆれの正規化をどこで処理するかによって、待たされる時間は変わる。同じ「301を返している」でも中身は同じではない、ということです。

大文字にしたURLだけ転送されなかった

今回いちばん意外だったのがこれです。スラッグを大文字にしたURLは、60本すべてが200を返しました。301を返しません。

1本を詳しく調べてみました。

• リクエストしたURLのまま最終URLも大文字で、転送は起きていない
• 本文の長さは112,465バイトで正規形と完全に一致。H1も同じ
• ただしcanonicalタグは、大文字でアクセスした場合も小文字の正規形を指していた

この結果を「重複コンテンツが放置されている」と読むのは早計でしょう。canonicalが正規形を指している以上、Google側で正規化される見込みがあります。事実として言えるのは、301を返さず200で同じ本文が返り、canonicalは正規形を指していた、というところまで。

とはいえ実務的な教訓ははっきりしています。末尾スラッシュ・www・httpの3つは正規化の設定が効いていたのに、大文字だけは対象外でした。301を設定したから正規化は万全、とは言えないのです。手を入れていない変形は、そのまま素通りします。

自分のサイトで同じことを確かめる方法

ここまでと同じことは、自分のサイトでも確認できます。特別な道具は要りません。

ちなみに表記ゆれは、リンク切れとは別の形でも顔を出します。2026年8月20日時点で自社メディアの記事内リンクの宛先URLを数えたところ、234件はすべて200でリンク切れは0件でした。ところが正規化すると233件に減っています。表記が違うだけの同じ宛先が、2件に見えていたわけです。転送が必要になるのは、リンクが壊れたときだけではありません。

方法	やること	向いている場面
curlコマンド	curl -I 確認したいURL と打つ	1本を正確に。コードとLocationがそのまま出る
ブラウザの開発者ツール	ネットワークタブを開き、転送を追わない設定にする	実際の画面と一緒に確認したいとき
Search Console	ページのインデックス登録レポートを見る	サイト全体の傾向をつかみたいとき

ひとつ注意点があります。Googleの検査ツールは、リダイレクトを追跡しません。Search ConsoleのURL検査ツールもここに含まれます。これはGoogleが公式に明記していることです。検査ツールで見て思った結果にならなくても、転送が効いていないという意味ではないので、慌てないでください。

SEO評価の引き継ぎ｜公式の記述は変わっている

結論を先に言えば、301などの永続的なリダイレクトでPageRankが失われることはない、とGoogleが公式に明記しています。ただし302については、現行の記述から外れました。

リダイレクトで最も心配されるのが、この評価の引き継ぎでしょう。やっかいなのは、公式ドキュメントの文章が過去に書き換えられていて、書き換え前の内容がいまも解説記事の中で生き続けていることです。

• 現行のGoogle公式ドキュメントが書いていること
• 2025年12月版までは302も含まれていた
• 反映までの時間と維持すべき期間
• リダイレクトでペナルティはどこまで本当か

現行のGoogle公式ドキュメントが書いていること

「サイトを移転する方法」という公式ドキュメントに答えがあります。日本語版の記述はこうです。「301やその他の永続的なリダイレクトによってPageRankの損失が生じることはありません」。

PageRankとは、Googleがページの重要度を測るために使う指標のひとつ。他のページからどれだけリンクされているかをもとに計算されます。この値が失われないということは、リンクで積み上げた評価が転送先へ引き継がれる、という意味になります。

引き継がれるのはPageRankだけではありません。ただし前提があります。同じページは「リダイレクトをできるだけ長く保持します（一般的には 1 年以上）」と書いたうえで、その期間のうちにすべてのシグナルを新しいURLへ転送できるという説明です。古いURLを指す他サイトのリンクの再クロールと割り当て直しも、この期間に含まれます。

2025年12月版までは302も含まれていた

ここが本題です。いま引用した一文は、少し前まで違う書かれ方をしていました。

英語版の更新日	書かれていた内容	302の扱い
2025年3月6日	301、302、およびその他のサーバーサイドリダイレクトはPageRankの損失を引き起こさない	含まれていた
2025年12月18日	同上	含まれていた
2026年3月27日	301およびその他の永続的なリダイレクトはPageRankの損失を引き起こさない	外れた
2026年8月20日（現行）	同上	外れたまま

表の日付は英語版の更新日です。日本語版の記述も同じ内容で、こちらの最終更新は2026年6月24日でした。2025年12月の版までは、302が名指しで対象に含まれていました。それが2026年3月の更新で「永続的なリダイレクト」に絞り込まれ、302が消えています。

つまり「302でもPageRankは失われない」という説明は、かつて公式に書かれていた内容。現在形で語ることはできません。

とはいえ逆の断定も避けるべきでしょう。Googleが「302はPageRankを渡さない」と明言したわけではないからです。現行のドキュメントが302に触れていない、というだけ。ここを混同すると、今度は別の誤情報を広めることになります。

反映までの時間と維持すべき期間

301を設定すれば即座に検索結果が切り替わる、ということはありません。Googleの説明では、中規模のサイトでほとんどのページの移転が反映されるまでに数週間、大規模ならそれ以上かかるとされています。

速度を決めるのはURLの数とサーバーの速度。固定のクロール頻度はないとも明記されており、移転はURL単位で進みます。一斉に切り替わるのではなく、少しずつ入れ替わっていくわけです。

論点	Googleが示している目安
検索結果に反映されるまで	中規模のサイトで数週間、大規模ならそれ以上
転送を維持する期間	できるだけ長く、一般的には1年以上
旧URLが検索結果に残ること	正常。利用者が慣れるにつれて自然に消える

では、いつまで転送を維持すべきか。公式の答えは明快でした。「リダイレクトをできるだけ長く保持します（一般的には 1 年以上）」。

この期間があることで、他サイトからのリンクの再割り当てまで含めてシグナルが移りきる、という理屈です。

転送したあとも旧URLは残り続けます。当社の運用でも、リダイレクト設定済みのURLや404のURLが、サイトマップに載せていないURLとしてSearch Console上に現れ続けています。

検索結果に旧URLが顔を出すこともあるでしょう。ただGoogleはこれを異常とみなしていません。「リダイレクトと Google 検索」によれば、転送元と転送先の両方を記録しており、片方が正規版、もう片方は代替名として扱われます。利用者が古いURLのほうを信頼しそうな検索のときには、代替名が表示されることがある、という説明です。

ドメインを変更した直後に旧URLが出るのは正常。利用者が新しいドメインに慣れるにつれて自然に消えていく、とも書かれています。

リダイレクトでペナルティはどこまで本当か

リダイレクトを設定するとペナルティを受ける。そんな話を見て不安になった方もいるかもしれません。この不安には、Googleのウェブ検索のスパムに関するポリシーが直接答えています。

ポリシーには「不正なリダイレクト」という項目があり、こう定義されています。「ユーザーと検索エンジンに異なるコンテンツを表示したり、ユーザーの本来のニーズを満たさない想定外のコンテンツを表示したりすることを目的に、悪意を持ってこれを行うこと」。

そのうえでGoogleは、はっきり続けます。「不正なリダイレクトはスパムの一種ですが、正当な理由で、あるURLから別のURLにリダイレクトする、スパムではないものも多数あります」。正当な例として挙げられているのは次の3つです。

• サイトを新しいアドレスに移転する
• 複数のページを1つに統合する
• ログイン後にユーザーを内部のページにリダイレクトする

判定の基準も明示されています。「リダイレクトが不正なものかどうかを調べる場合は、リダイレクトがユーザーまたは検索エンジンを欺くことを意図したものかどうかを確認してください」。

見られているのは手段ではなく意図です。リダイレクトを使ったこと自体が問題になるわけではありません。記事の統合を検討している方にとっては、統合が正当な例として名指しされている点が安心材料になるはずです。

リダイレクトしない判断｜404と410の使い分け

すべてのURLを転送すればよい、というものではありません。転送すべきでない場面が確かにあります。

そこを間違えると、読者にも検索エンジンにも誤った情報を伝えることになってしまう。この章では、その線引きを扱います。

• 転送が最優先で直せないものだけ404にする
• 404と410は規格では違うが処理は同じ
• URLを残す必要があるならnoindex
• 削除したあとに見る4つのタイミング

転送が最優先で直せないものだけ404にする

当社がデータベース型のサイトを作るとき、URLごとの扱いは判定の順番を固定して決めています。最初に見るのは、一意の正規URLへ直せるかどうか。直せるものは永久転送に回し、直せないものだけが404に落ちるという順番です。

状況	返すもの	対象になるURLの例
内容を引き継げる代替ページがある	301（永久転送）	旧スラッグ／条件の順序違い／完全な重複／1ページ目を示すパラメータ
恒久的に消す。代替もない	410	期間限定で終了した企画ページなど、意図して消したもの
URLは残す必要がある	200＋noindex	内部リンクや被リンクを受けているページ／一時的に中身が空になっただけのページ
対応する実体がそもそも存在しない	404	定義されていない値／両立しない条件の組み合わせ／存在しないページ番号

この順番で考えると、リダイレクトと404は別々の判断ではなくなります。同じ判定の枝分かれになる。よくある「とりあえずトップページに転送する」「とりあえず404にする」は、どちらもこの順番を踏まないまま結論に飛んだ結果です。

ひとつ補足を。内容の違うページへまとめて転送するのは避けてください。読者は求めていたものと違うページに着いてしまい、結局そこで離脱します。

もうひとつ、転送を重ねないことも大事です。AをBへ、あとからBをCへと足していくと、A→B→Cの数珠つなぎができあがります。あとから足すときは、Aの転送先も直接Cへ向け直してください。

行き先が輪になってしまう事故もあります。RFC 9110は「クライアントは循環するリダイレクト、つまり無限のリダイレクトループを検知して介入すべきである」と書いており、規格の側もこれを想定しています。なお回数の上限は現行の規格では定められていません。よく見かける「最大5回」は1997年のRFC 2068の旧推奨で、いまの要件ではない点に注意してください。

404と410は規格では違うが処理は同じ

削除したページをどう扱うか。ここで404と410の使い分けが問題になります。理解のコツは、規格とGoogleの処理を分けて考えることです。

まず規格の側。RFC 9110を読むと、両者ははっきり別物でした。

観点	404 Not Found	410 Gone
意味	現在の表現が見つからない	アクセスできなくなった
一時的か恒久的か	区別しない	恒久的である可能性が高い
使い分けの基準	恒久かどうか分からないとき	恒久だと分かっているとき
意図の有無	問わない	意図的に利用不可にしたことを伝える

ところが、Googleのクローラーの処理はこれと違います。公式ドキュメントには「429 を除くすべての 4xx エラーは同じように扱われます」と明記され、404と410は同じ枠にまとめて書かれているのです。処理の中身は、コンテンツが存在しないと次の処理系に伝え、すでにインデックスにあれば削除し、クロール頻度を徐々に下げるというもの。

日本語のSEO記事では「410のほうが早くインデックスから消える」という説明をよく見かけます。ただ、現行の公式ドキュメントにその記述はありません。むしろ同じ扱いだと書かれています。

410を選ぶ理由があるとすれば、Googleの処理速度ではないでしょう。意図的に消したことを規格に沿って明示できる、という点にあります。

URLを残す必要があるならnoindex

転送も削除も選べない場面があります。次のようなURLです。

• 他のページから内部リンクが張られている
• 外部サイトからの被リンクがある
• 社内の資料や手順書に載っている

こうしたURLをいきなり404にすると、たどってきた人が行き止まりに突き当たります。

この場合はページを残したままnoindexを使う、という選択になります。検索結果には出さず、URLとしては生かしておく方法です。

非表示ツールで消す手もあるでしょう。ただしGoogleは、非表示ツールで行われたリクエストは約6か月間有効だと明記しています。恒久的に検索結果から外したいなら、内容そのものを削除するか、パスワードで保護するか、noindexを付けるか。この3つのいずれかを取るよう案内されています。

あわせて「ページをブロックする目的で robots.txt を使用しないでください」という注意も添えられていました。

404を過度に恐れる必要はありません。当社がインデックスの状況を見るときの優先度では、最優先で対応するのはクロール済みでインデックス未登録のページ。404やnoindexに起因するものは、優先度が低い分類に置いています。意図して除外したURLが404になっているのは、むしろ健全な状態です。

削除したあとに見る4つのタイミング

転送や削除は、設定して終わりではありません。当社では記事を整理するとき、一度に手を付けるのは10本から20本程度にとどめ、次の4つのタイミングで結果を確認しています。

時期	見るもの
削除直後〜1週間	想定していなかった404やエラーが出ていないか
1か月後	クロールが一巡し、評価が動き始めたか
3か月後	サイト全体への影響
6か月後	中長期の傾向

この間隔には根拠があります。Googleは移転の反映について、中規模のサイトで数週間、大規模ならそれ以上かかるとしており、固定のクロール頻度はないとも書いていました。1週間で結論を出そうとしても、まだ何も動いていないのです。

最後に、忘れられがちな後処理をひとつ。サイトマップの掃除です。

当社が運営するデータベース型のサイトでは、サイトマップに載せる条件を機械的に判定しており、転送されるURL・404のURL・noindexのURLは掲載対象から外しています。転送を設定した旧URLをサイトマップに残したままにすると、Googleに「このURLをクロールしてほしい」と伝え続けることになるからです。

リダイレクトについてよくあるご質問

リダイレクトはいつまで維持すればよいですか

Googleの公式ドキュメントは「リダイレクトをできるだけ長く保持します（一般的には 1 年以上）」としています。この期間があることで、他サイトからのリンクの再割り当てまで含めてシグナルが新しいURLへ移りきります。利用者の視点では無期限の保持も検討してよい一方、往復が1回増えるぶん表示は遅くなるため、自サイト内のリンクは新しいURLへ書き換えておくのが望ましいです。

設定したのに転送されません。何を見ればよいですか

まず確かめるのは、設定した条件と実際のURLが一致しているかどうかです。当社が自社メディアの公開記事285本を実測したところ、末尾スラッシュ・www・httpは転送されていたのに、スラッグを大文字にしたURLだけは301を返さず200が返りました。手を入れていない表記の変形は転送されません。なおGoogleの検査ツールはリダイレクトを追跡しないため、URL検査で見ても意図した結果は見えません。

リダイレクトを解除するとどうなりますか

旧URLは、転送を外した時点で元の状態に戻ります。中身が残っていれば200、消していれば404です。ただし痕跡はすぐに消えません。301はブラウザに記憶されやすく、設定を取り消しても、一度アクセスしたブラウザでは古い転送先へ飛び続けることがあります。Googleは転送を一般的に1年以上維持するよう推奨しているため、解除は期間を満たしてから判断してください。

広告で別サイトへ飛ばされるのもリダイレクトですか

仕組みとしては同じ転送ですが、Googleのスパムポリシーが定める「不正なリダイレクト」に当たる場合があります。ポリシーは、利用者と検索エンジンに異なる内容を見せたり、本来のニーズを満たさない想定外の内容へ送ったりすることを悪意を持って行う行為と定義しています。判定されるのは手段ではなく意図です。サイト移転やページ統合のための転送は、正当な例として公式に明示されています。

まとめ

リダイレクトの選択は、URLの変更が恒久的か一時的かでほぼ決まります。恒久的なら301、一時的なら302。フォーム送信をまたぐ場面だけ、308や307を検討してください。

ただし設定した時点では、まだ半分です。今回の実測では、末尾スラッシュもwwwもhttpも正しく転送されていたサイトで、大文字にしたURLだけが素通りしていました。手を入れていない変形は転送されません。

まずは自分のサイトの主要なURLに対して、表記を変えた形でアクセスしてみてください。コマンド1行で確かめられます。大量のURLを移行する予定があり、設計から相談したい場合は、お気軽にお問い合わせください。