Q.Studioで301リダイレクトはできますか？移管後はどこで設定すればいいですか？

Studioの301リダイレクトは、デザインエディタでリダイレクトページを作り、転送元のパスと転送先を登録して設定します。利用できるのはBusinessプラン以上で、旧プランの場合は全プランが対象です（リダイレクトページの設定方法）。設定を保存しただけでは公開中のページは変わりません。公開パネルからサイトを更新した時点で反映されます。

使う前に知っておきたい制限は次のとおりです。

• 複数ページの一括設定はできず、転送元のパスごとに1つずつ作る
• 転送元に指定できるのは、接続中のドメインのパスだけ（転送先は外部サイトのURLも可）
• 2026年1月以降、.phpで終わるパスではリダイレクトが動かない
• 2026年6月11日以降、?・&・#・%などを含むパスは新規登録できない（登録済みのパスは編集しなければ使える）
• .html・.htmで終わるパスは、拡張子以外にピリオドがなければ例外として登録できる
• 日本語URLを転送先にすると正しく動かず、動的ページは転送先に指定できない

ちなみに、独自ドメインの接続時にwwwの有無を統一したい場合は、ドメイン側のDNS設定と合わせた専用の転送機能が用意されています。大量のURL転送を一括で管理したいケースでは、Business Plus以上のプランでカスタムプロキシを追加契約し、自社で用意したリバースプロキシと組み合わせるか、外部サービスでの処理を検討するのが現実的ですね。

たとえば、同じドメインのままStudioからCloudflare Pagesへサイトを移したとします。DNSを移管先へ向け直すと、切り替えが反映された後のアクセスはすべてCloudflare Pagesへ届きます。Studio側にリダイレクト設定が残っていても、もうそこにはアクセスが来ません。旧URLの転送は、アクセスを受け取る移管先のサーバーやCDNで設定することになります。

移管先ごとの設定場所はおおよそ決まっています。Cloudflare Pagesなら_redirectsファイル、Apache系のレンタルサーバーなら.htaccess、Next.jsとVercelならnext.config.jsやvercel.json、WordPressのようなCMSなら付属の転送機能です。どれを使うかは、移管先の環境を見れば決まりますね。

一方、移転に伴ってドメイン名そのものを変更するケースでは、別の手順も選べます。変更前の旧ドメインを紐付けたStudioプロジェクトをBusinessプラン（旧プランなら全プラン）のまま残し、Studio側のリダイレクトページから新しいドメインの各URLへ301転送をかける手法です。この形であれば、旧ドメインへ訪れたユーザーや検索エンジンをStudioから新サイトへ案内し続けられます。

どの場所で設定する場合でも、URLが変わる移行なら手順は共通です。旧URLと新URLの対応表を作り、転送を有効にしてから、旧URLを開いて新しいページへ届くかテストします。

_redirectsは拡張子なしのテキストファイルで、1行に「転送元 転送先 ステータスコード」を半角スペースで区切って書きます。301で転送したいなら/old-page /new-page 301のように末尾へ301を書き足します。コードを省略すると302（一時的な転送）として扱われるので、恒久的な移転なら301を書き忘れないでください（Pagesのリダイレクト設定）。

置き場所はビルド後の出力フォルダです。Next.jsなどのフレームワークを使っている場合は、ビルド時に最終出力先へそのままコピーされる「public/」や「static/」といったフォルダ内にファイルを格納しておきます。静的HTMLで構成しているサイトなら、出力先のルート階層へ直接配置すれば問題ありません。行の先頭に「#」を置くとコメント行として認識されるので、セクションごとのメモを残す際にも役立ちますね。

ただし、Pages Functionsを使って処理しているリクエストに対しては「_redirects」のルールが適用されない仕様となっています。FunctionsのルートがURLパターンに一致する場合も同じです。Functions経由のページを転送したい場合は、コード内で直接転送処理を実装するか、該当パスをFunctionsの処理対象から外す調整を行いましょう。

1つのファイルで設定可能な上限は静的リダイレクトが2,000件、動的リダイレクトが100件で、合計2,100件までです。

記事数の多いブログを移すと、_redirectsの上限である合計2,100件（静的2,000件、動的100件）を超えることがあります。その場合はCloudflareのBulk Redirectsを使いましょう。アカウント単位で大量の転送をまとめて登録できる機能で、同じアカウント内の複数ドメインにも適用できます。登録できる件数はプランで異なり、Bulk Redirectsの上限では、Freeプランでも全リスト合わせて10,000件までです。

件数はアカウント内でいちばん上のプランで決まります。Bulk Redirectsでは、転送元と転送先をまとめたCSVファイルをダッシュボードへアップロードすることで、大量の転送ルールを一括で登録できます。CSVを取り込んだだけでは転送は有効になりません。アップロード後に転送リストを呼び出すルール（Bulk Redirect Rule）を新規作成し、保存と展開の操作を完了させて初めて実際の通信へ適用されます。また、訪問者がアクセスする対象ドメインのDNSレコードがCloudflareを経由（プロキシ設定が有効）していることが動作の前提条件となります。

Bulk Redirectsは基本的に1対1の静的な転送で、文字列の置き換えや正規表現は使えません。「/blog/以下をまとめて別のフォルダへ」のようなパターン転送をしたいなら、Single Redirectsのほうが合っています。ドメインやサブドメイン単位で静的・動的な転送を書け、Freeプランでは10ルールまで。正規表現はBusinessとEnterpriseだけが対応しています。

Google検索セントラルの移行ガイドでは、リダイレクトを可能な限り長く、一般的には1年以上維持することが推奨されています。さらに、ブックマークや古いリンクから来る人のことを考えて、無期限に残すことも勧められています。1年たったら外してよいという意味ではない点に注意してください。

Search Consoleのアドレス変更機能を利用した際も、少なくとも180日間にわたって転送を継続し、旧アドレスへの検索トラフィックが残っている間はさらに維持するよう案内されています。180日は最低ラインで、削除の期限ではありません。

残しておくことのデメリットはほとんどありません。301のような恒久的なリダイレクトでPageRankが失われることはないからです。ただ、移行直後に検索順位がまったく動かないという保証ではありません。

長く残すうちに、転送がつながって連鎖することがあります。たとえば一度移行したサイトをまた移すと、最初のURLから2回、3回と転送が重なりがちです。Googlebotは最大10回まで転送をたどれますが、最終URLへ直接転送するのが理想で、どうしても無理なら5回未満、できれば3回以下に抑えます。サイト内のリンクや流入の多い外部リンクは、新しいURLへ書き換えておくと転送を通らずに済みますね。

旧URLをブラウザで開いて新しいページが表示されても、それだけでは301で転送されたとは言い切れません。302で一時的に転送されていても見た目は同じだからです。まずは少数の重要ページを対象に、Google Chromeの開発者ツールを使って直接通信を確認します。旧URLを開く前に、開発者ツールのNetworkパネルを開いておきます。アドレスバーに旧URLを入力して移動すると、通信ログの「Status」列に「301」という応答コードが表示され、最終的に新しいURLへ遷移した履歴が確認できるはずです。各通信行をクリックして「Headers」タブを見れば、レスポンスヘッダーに含まれる転送先アドレス（Location）まで詳細に照合できます。

1件ずつの確認で済まないときは、テストする旧URLの一覧を先に作ります。移行前のクロール結果、サイトマップ、アクセス解析、サーバーのログを組み合わせると、漏れが少なくなりますね。Studioのサイトマップだけでは、過去に消したページやパラメーター付きのURLまで拾えない場合があります。代表的なSEO監査ソフトである「Screaming Frog SEO Spider」では、調査モードを「List」に切り替えて旧URL一覧のファイルを読み込み、「Always Follow Redirects」の設定を有効にしてクロールを実行しましょう。スキャン完了後に「All Redirects」レポートを出力すれば、各URLのステータスコード、最終到達先、リダイレクトの回数、ループの有無などを一覧で点検できます。

確認するのは次の点です。

• 旧URLから、内容が対応する新URLへ転送されている
• ステータスコードが301か308になっている

移行後もしばらくはSearch Consoleで新旧サイトの状況を見て、予期しないクロールエラーが出ていないか定期的に調べます。