サーバー側の301が使えないとき、次に選ぶべきはどれか ── meta refreshとJavaScriptリダイレクトの判定基準を確認する13項目（2026年9月時点）

01 何が起きたか — 「301が最善」の先で、まだ選ぶことが残っている

サーバー側の301が使えない現場は、思ったより多い

URLを恒久的に変更するとき、最も確実な方法はサーバー側の301（または308）リダイレクトである。この点はGoogle公式ガイドでも明確に述べられており、サーバー側リダイレクトの実装が可能な場合は、常にそちらを選ぶべきだとされている。だが、実際のWEB制作・運用の現場では「サーバー側の設定ファイルを直接編集する権限がない」「CMSがリダイレクト機能を持たない静的な出力しかできない」「クライアントの共有サーバーで.htaccessの変更が許可されていない」という状況が、想像以上によく起きる。301という答えは分かっていても、それを実装できない現場でどうするかは、公式ガイドの中でも扱いが薄い部分であり、実務での判断材料が足りていない。

この記事が扱う範囲

301リダイレクトが被リンクの評価をどう引き継ぐか、リダイレクトチェーンがどう順位に影響するかという論点は、別の記事で詳しく扱われている。本記事はその手前、「サーバー側の301・308が使えないとき、次にどの手段を選ぶか」という判断に絞る。Google公式ガイドが示す代替手段は、meta refresh・JavaScriptリダイレクト・クリプトリダイレクトの3つで、それぞれ「Googleにどう解釈されるか」の条件が異なる。この条件を取り違えると、リダイレクトを設置したつもりで、Googleには一時的な変更としてしか扱われない、という事態が起きる。

02 なぜ・背景 — 「恒久」と「一時」の境目は、方式ではなく条件で決まる

meta refreshは「待ち時間」で解釈が変わる

meta refreshは、<meta http-equiv="refresh" content="秒数; url=遷移先">という1行で実装できる手軽さから、サーバー側の設定を触れない場面での代替として使われることが多い。だが公式ガイドは、この方式を待ち時間の長さによって恒久・一時の2通りに振り分けている。content="0; url=..."のように待ち時間が0秒の場合は恒久的リダイレクトとして解釈され、転送先が正規URLとして扱われる。一方、content="5; url=..."のように1秒以上の待ち時間を指定すると一時的リダイレクトとして解釈され、検索結果には元のURLが表示され続ける。同じmeta refreshというタグ名でありながら、秒数という1つの数字の違いだけで、Googleの扱いが正反対になる。

JavaScriptリダイレクトは「見えるかどうか」がそもそも不確実

JavaScriptのwindow.locationやlocation.hrefによるリダイレクトは、公式ガイドで最も明確に非推奨とされている手段である。公式は次のように述べている。

"Only use JavaScript redirects if you can't do server-side or meta refresh redirects."

（訳: サーバー側またはmeta refreshによるリダイレクトができない場合に限って、JavaScriptリダイレクトを使用してください。）

この非推奨には理由がある。GooglebotはクロールしたページをレンダリングしてJavaScriptの実行結果を確認する処理を行うが、公式ガイドは次のように注意を促している。

"While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed."

（訳: GoogleはクロールしたすべてのURLをレンダリングしようと試みますが、さまざまな理由でレンダリングが失敗することがあります。つまり、JavaScriptリダイレクトを設定していても、コンテンツのレンダリングが失敗した場合、Googleがそのリダイレクトを一度も認識できない可能性があるということです。）

「実装した」と「Googleが認識した」の間に、レンダリングの成否という不確実な工程が挟まる。これがJavaScriptリダイレクトの本質的なリスクであり、サーバー側リダイレクトにはこの工程が存在しない。

それでも他に手段がないときの最終手段

meta refreshもJavaScriptも実装できない、あるいはそもそもページを動的に生成する手段自体がない、という極端な状況のために、公式ガイドは最後の選択肢としてクリプトリダイレクトを挙げている。これは新しいページへのリンクと短い説明文をページに設置するだけの方法で、公式は次のように書いている。

"Don't rely on crypto redirects for letting search engines know that your content has moved unless you have no other choice."

（訳: 他に選択肢がない場合を除き、コンテンツが移動したことを検索エンジンに知らせるためにクリプトリダイレクトに頼らないでください。）

「頼らないでください」という表現からも分かるとおり、これは推奨手段の1つではなく、他の3手段がすべて使えない場合に限った回避策という位置づけである。

03 この記事で出てくる用語

301と308、302・303・307はどう振り分けられるか

サーバー側リダイレクトについても整理しておく。301・308は恒久的リダイレクトとして扱われ、転送先URLが正規URLとして扱われる。一方、302・303・307は一時的リダイレクトとして扱われ、検索結果には転送元URLが表示され続ける。本記事の主題であるmeta refresh・JavaScript・クリプトリダイレクトは、いずれもこの「サーバー側の301・308」が使えない場合の代替手段という位置づけであり、代替手段を選ぶ前提として、まず自分のサーバー環境で301・308が本当に実装不可能かを確認する必要がある。

「恒久」と「一時」で何が変わるのか

恒久的リダイレクトとして扱われた場合、公式ガイドは次のように述べている。

"Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical."

（訳: Googlebotはリダイレクトに従い、インデックスパイプラインはそのリダイレクトを、転送先を正規URLとすべきというシグナルとして扱います。）

一時的リダイレクトとして扱われた場合は、次のように述べられている。

"Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."

（訳: Googlebotはリダイレクトに従いますが、インデックスパイプラインはそのリダイレクトを、転送先を正規URLとすべきというシグナルとしては扱いません。）

「Googlebotがリダイレクトに従う」ところまでは、恒久・一時のどちらも共通している。違うのは、その先のインデックスパイプラインが転送先を正規URLとして採用するかどうかである。恒久扱いにならなければ、検索結果には古いURLが表示され続ける。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どんな現場でこの判断が必要になるか

この判断が必要になるのは、主に次のような現場である。ノーコード・ローコードのサイトビルダーで、リダイレクト設定機能が用意されていない場合。静的サイトジェネレーターで出力したHTMLを、リダイレクトルールを持たないホスティングサービスにそのまま配置している場合。クライアントの共有サーバーで、制作会社側に.htaccessやサーバー設定ファイルへの書き込み権限が与えられていない場合。逆に、自社サーバーやVPS、主要なクラウドホスティングでサーバー設定を自由に変更できる環境では、この記事の判断はほぼ不要で、迷わず301・308を選べばよい。

🅱 この記事が測っていないこと・分からないこと

公式ガイドを確認しても、明確にされていない点がある。第一に、meta refreshやJavaScriptリダイレクトが恒久的として扱われた場合でも、サーバー側の301・308と完全に同じ強さの正規化シグナルになるのかは明記されていない。ガイドは「シグナルとして扱う」とまでしか述べておらず、他のシグナルとの相対的な強さの順位は公開されていない。第二に、JavaScriptリダイレクトのレンダリングが、どのくらいの頻度・条件で失敗するのか、具体的な確率は示されていない。「さまざまな理由で失敗することがある」という表現にとどまっており、自分のサイトでレンダリングが成功しているかどうかは、個別に確認するしかない。第三に、クリプトリダイレクトを設置してから、Googleが実際にリンクをたどって新URLを認識するまでの期間の目安も示されていない。

🅲 手順 — 自分の環境でどれを選ぶか

実際の判断は、次の3段階で進める。第一にサーバー側の301・308が本当に実装できないかを、もう一度確認する。CMSのプラグインやホスティングの管理画面に、リダイレクト設定機能が用意されていないか探す。第二に、meta refreshが実装できるかを確認する。HTMLの<head>内にタグを1行追加できるなら、待ち時間を0秒にして実装する。第三に、meta refreshも難しい動的な仕組みでしか遷移を制御できない場合に限って、JavaScriptリダイレクトを実装し、Search ConsoleのURL検査ツールで実際にGoogleがそのURLをどう認識しているかを確認する。この確認を怠ると、実装したつもりで何ヶ月も反映されない、という状態に気づけない。

05 明日、自分の案件で確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、環境の確認、meta refreshの実装確認、JavaScriptリダイレクトの実装確認、クリプトリダイレクトを使う場合の確認、の4つに分かれる。上から順に進め、自分の環境で使える手段が見つかった時点で、それ以降の項目は該当しない。

• 今回のケースで、サーバー側の301・308が本当に実装できないかを、CMSやホスティングの管理画面から再確認する
• 共有サーバーの場合、契約プランに.htaccessやリダイレクト設定機能が含まれていないかサポート窓口に問い合わせる
• meta refreshが実装できる場合、待ち時間を「0」に指定していることをHTMLソースで確認する
• meta refreshのURLが、絶対URLで正しく記述されているかを確認する
• JavaScriptリダイレクトを実装する場合、noscript環境（JavaScript無効時）でどう振る舞うかを確認する
• 実装後、Search ConsoleのURL検査ツールで対象URLを検査し、Googleが認識しているレンダリング結果を確認する
• URL検査ツールの「取得したページ」のスクリーンショットに、リダイレクト先のコンテンツが表示されているか確認する
• 実装から1〜2週間後、対象URLをブラウザのシークレットウィンドウで開き、意図した新URLに到達するか確認する
• クリプトリダイレクトを使う場合、リンクの近くに移転先を説明する短い文章を添えているか確認する
• クリプトリダイレクトのリンクにrel="nofollow"を誤って付けていないか確認する
• リダイレクトチェーン（元のURLから複数回の転送を経由すること）が発生していないか、実装後に確認する
• 新URLのcanonicalタグが、自分自身を指す形になっているか確認する
• 1ヶ月後、Search Consoleのページのインデックス登録レポートで、新URLの登録状況を確認する

13項目の内訳と、かかる時間の目安

13項目は4つの観点に対応している。それぞれにどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

環境の確認から実装までは30分程度で終わることが多いが、反映確認は1回で終わらせず、期間を空けて複数回実施する必要がある。特にJavaScriptリダイレクトを選んだ場合は、レンダリングが失敗していないかを必ずURL検査ツールで裏取りすること。

meta refreshとJavaScriptを、同じページで併用しない

複数の代替手段を「念のため」同時に実装したくなる場面もあるが、これは避けたほうがよい。meta refreshとJavaScriptリダイレクトを1つのページに両方仕込むと、どちらのシグナルが優先されるかが公式に明記されておらず、Search ConsoleのURL検査ツールで確認したときにも、どちらの処理結果を見ているのか切り分けにくくなる。環境ごとに使える手段を1つ選び、それだけを実装する方が、後から不具合を追跡しやすい。

06 代替・他の選択肢（表で）

4つの手段を、実装条件で並べる

サーバー側の301・308が使えない場合に選べる手段を、実装条件・Googleの解釈・注意点で整理した。

「今すぐ切り替えたい」場合、どの手段も即効性は無い

meta refreshを0秒に設定しても、JavaScriptリダイレクトのレンダリングが成功しても、Googleが新URLを検索結果に反映するまでには、サーバー側リダイレクトと同様に一定の時間がかかる。「今日中に旧URLを検索結果から消したい」という要望に、即座に応えられる手段はこの4つの中にない。検索結果への出方そのものを一時的に制御したい場合は、noindexやrobots.txtという別の設定を検討することになるが、これはリダイレクトとは別の判断軸である。3つの設定を混同すると意図しない結果になる点は、当サイトの別記事noindex・nofollow・robots.txtは、それぞれ何を止めているのかで扱っている。

301リダイレクトが使える場合は、この記事の対象外

本記事はあくまで「サーバー側の301・308が使えない」という制約下での代替手段を扱っている。サーバー側の301が実装できる環境であれば、被リンクの評価をどう引き継ぐか、リダイレクトチェーンがどう影響するかという、より重要な論点に進める。この論点については、当サイトの別記事301リダイレクトは被リンクの評価を引き継ぐか？ チェーンと着地点の落とし穴で、5組の実例とともに詳しく確認している。

07 自社サイトで確認したこと — sitemap・canonical・末尾スラッシュの一貫性

リダイレクトの手段を選ぶ前に、同じ落とし穴が別の場所にもある

当サイトが公開しているブログでは、リダイレクトの実装方法とは別の場所で、URLの表記が一致していなかった事例が記録されている。サイトマップに記載したURLの末尾スラッシュの有無が、実際に配信されているURLと一致しておらず、Googleからそのページが見えていなかった、という事例である(archives/38)。この事例をきっかけに、sitemap・canonical・内部リンク・末尾スラッシュの4層が同じ形式で揃っているかを、コマンドで数分確認する手順が整理されている(archives/39)。

meta refreshやJavaScriptリダイレクトでも、この4層は同じように効く

meta refreshやJavaScriptでリダイレクトを実装した場合も、遷移先ページのcanonicalタグ・sitemapの記載・内部リンクの表記が揃っているかどうかは、サーバー側リダイレクトのときと同じだけ重要になる。「今回はmeta refreshだから、canonicalの確認は省略してよい」という理由は成立しない。むしろ、Googleの解釈が正規のリダイレクトより不確実な手段を使う場合ほど、他のシグナル（canonical・sitemap）を揃えて補強しておく必要がある。

08 このテーマの、これまで

大量のURLを一度に扱った経験から

当サイトでは、1,000件規模のページのnoindex設定を6日間で一括して見直した記録がある(archives/105)。サーバー側リダイレクトが使えない環境で代替手段を選ぶ場合、対象URLが数件であれば手作業でも確認できるが、件数が増えるほど、meta refreshやJavaScriptの実装漏れを1件ずつ目視で確認するのは現実的でなくなる。この記録は移転そのものを扱ったものではないが、大量のURLを扱うときほど、機械的に突き合わせる仕組みを先に用意しておく必要があるという点で、本記事05章のチェックリストの考え方と共通している。

「リンクが在る」と「飛び先が正しい」は別

当サイトのブログでは、リンク切れ（404）が0件であることを確認した後にさらに詳しく調べたところ、リンクは正常に機能しているのに、内部リンクの59.2%がnoindexを設定した記事への導線になっていた、という事例が記録されている(archives/134)。クリプトリダイレクトのように「リンクを設置するだけ」の手段を選ぶ場合、そのリンクが本当に正しい移転先を指しているかを、設置した時点だけでなく、時間が経った後にも確認する必要がある。