サイトのURL構造を変えるときの301リダイレクト設計｜.htaccessの書き方と旧ディレクトリの後始末

ℹ️ 本記事はアフィリエイトプログラム（エックスサーバー株式会社／A8.net）による収益を含みます。料金・仕様は変わることがあるため、申し込み前に必ず公式サイトの最新情報をご確認ください（本記事は2026年9月時点）。

この記事のポイント

• URL構造を変えるときは「洗い出し→.htaccess記述→動作確認→旧ディレクトリの後始末」の順で進めないと、検索順位が落ちたり旧URLがゾンビのように残り続ける
• .htaccessでの301リダイレクトは個別指定とディレクトリ丸ごと転送の2パターンを使い分ける
• デプロイの仕組みが「マージ」だと、消したはずの旧ファイルが本番に残り続ける事故が起きる（実体験ベース）
• サーバーを乗り換える／新規で借りるなら、月額は契約期間で大きく変わるので12ヶ月契約を基準に見積もるのが現実的
• まずは10日間の無料お試しで管理画面とSSH・SFTP周りの使い勝手を確認してから決めるのが安全

なぜ「URL構造を変える」だけで検索順位が落ちるのか

サイトリニューアル、ディレクトリ構成の見直し、WordPressから静的サイトへの移行——理由は色々あっても、URL構造を変える作業には共通の落とし穴があります。それは「旧URLへのアクセスをどう処理するか」を後回しにしてしまうことです。

旧URLには、検索エンジンが評価してきた実績（被リンク、インデックス履歴、クリック実績）が乗っています。ここで何も転送処理をしないと、旧URLは単なる404ページになり、そこに蓄積されていた評価はリセットに近い扱いを受けます。ユーザー側から見ても、ブックマークや外部サイトからのリンクを辿った先が真っ白なエラーページだと、それだけで離脱されてしまいます。

対策はシンプルで、旧URLから新URLへ「301（恒久的に移動しました）」のステータスコードでリダイレクトを返すことです。ただ、これが「言うは易く行うは難し」で、実際にやってみると、想像以上に地味な作業の積み重ねになります。

301リダイレクトの設計は「洗い出し」から始まる

.htaccessを書く前に、まず旧URLの一覧を作る必要があります。感覚で「たぶんこのページとこのページだけ」と決めつけると、必ず漏れが出ます。

洗い出しに使える情報源は主に3つです。

情報源	見るべきもの	わかること
Google Search Console	インデックス済みページの一覧、検索パフォーマンスのページ別データ	検索経由でアクセスがあるURL＝リダイレクトの優先度が高いURL
GA4（旧アクセス解析）	ページ別セッション数	実際に人が訪れているURL
既存サイトマップ（sitemap.xml）／ディレクトリ構成	全ページの網羅リスト	洗い出しの抜け漏れ確認

この3つを突き合わせて「旧URL→新URLの対応表」をスプレッドシートで作っておくと、後で.htaccessに書き起こす作業がそのまま機械的な変換作業になります。逆にこの表を作らずにいきなりコードを書き始めると、途中で「あれ、このページどこに移したんだっけ」となって手が止まります。

深掘り：全部リダイレクトすればいいわけではない

ここで一つ判断が必要になります。「アクセスがほぼゼロの古いページまで全部リダイレクトする必要があるか」という点です。答えは「基本的にはYesだが、明らかに価値がなくなったページは410（Gone）で潰す選択肢もある」というのが実務的な落としどころです。301を大量に、しかも何段階も連鎖させると（旧URL→旧URL2→新URL、のような多段リダイレクト）、クロール効率が落ちてSEO的にもマイナスになりがちです。棚卸しのタイミングで、本当に転送すべきページと、もう役目を終えたページを仕分けておくのが理想です。

.htaccessの書き方（具体例）

Xserverを含む多くのレンタルサーバー（Apache系）では、.htaccessファイルに記述することでサーバー側でリダイレクトを設定できます。プラグインに頼らずサーバーレベルで処理できるので、CMSを乗り換えたり静的サイトに移行したりしても、リダイレクトの仕組みごと引き継げるのが利点です。

個別ページを1対1で転送する場合

Redirect 301 /old-page/ https://example.com/new-page/

ディレクトリごとまとめて転送する場合（正規表現を使う）

RedirectMatch 301 ^/old-dir/(.*)$ https://example.com/new-dir/$1

例えば /old-dir/article1/ へのアクセスを /new-dir/article1/ に自動で転送してくれるので、記事数が多いディレクトリの移行では個別指定より圧倒的に効率的です。

www有無やhttps化とセットで書く場合（mod_rewrite）

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

ポイントは、記述する順番です。.htaccessは上から順に評価されるため、個別指定のリダイレクトはディレクトリ丸ごと転送のルールより上に書く必要があります。順番を間違えると、個別に例外扱いしたいページまで丸ごとルールに巻き込まれて意図しない転送先に飛んでしまいます。

➡

📝 .htaccess記述 個別→丸ごとの順で

➡

✅ 動作確認 ステータスコード確認

➡

🗑️ 旧ディレクトリ 削除は慎重に判断

旧ディレクトリは「消せば終わり」ではない——実際にハマった話

ここからが本題です。301リダイレクトを正しく書けても、それだけでは終わりません。私自身、真策堂の自社サイト（shinsakudo.com）をWordPressから静的サイト（Astro）へ移行したとき、まさにこの「後始末」でつまずきました。

移行にあたっては、旧URLから新URLへの301リダイレクトを.htaccessに自動生成する形で組みました。ビルド時に旧URLと新URLの対応リストからルールを吐き出す仕組みにしたので、記事数が多くても手作業でのミスは防げました。ここまでは順調です。

問題はデプロイの仕組みの方にありました。私はSFTPでdist/フォルダをまるごと本番に同期するスクリプトを使っているのですが、この同期は「マージ」であって「置き換え」ではありません。つまり、ローカル側でファイルを削除しても、本番サーバー上の対応するファイルは自動では消えないのです。

その結果何が起きたかというと、WordPress時代のディレクトリ構造がサーバー上にそのまま残り続け、301リダイレクトを設定したはずの旧URLに、リダイレクトが効かない別のキャッシュ経路や、削除しきれていない静的ファイルが混ざって、しばらく古いURLがインデックスされ続けるという状態になりました。旧WordPress一式はpublic_html.wp-backup-日付という名前のフォルダに退避して数ヶ月様子を見る形にしたのですが、その判断自体は正解だった一方で、「デプロイ＝マージだから消えないファイルがある」という前提を最初から意識していれば、もっと早く綺麗な状態にできたはずです。

この手のデプロイの仕組みそのものについては、以下でもう少し詳しく整理しています。

レンタルサーバーへのSFTP自動デプロイの組み方｜鍵認証・ステージング・同期の落とし穴

深掘り：旧ディレクトリを消すタイミングの判断基準

「いつ消せばいいのか」に絶対の正解はありませんが、目安として次の2つを両方満たしてから削除するのが安全です。

1. Search Consoleで旧URLへのクロールリクエストが十分に減っている（数週間〜1、2ヶ月単位で見る）
2. アクセス解析で旧URL直打ちのアクセスがほぼゼロになっている

この確認を飛ばしていきなり物理削除すると、301の設定ミスに気づかないまま「旧ページも新ページも両方404」という最悪の状態になりかねません。301を設定した後もしばらくは旧ファイルを残しておく（ただし公開はリダイレクトで塞ぐ）くらいの慎重さがちょうど良いと感じています。

サーバー側の機能が地味に効いてくる理由

URL構造の変更やサイト移行の作業は、失敗したときにすぐ元に戻せるかどうかが精神的な負担を大きく左右します。ここでサーバー側の機能が効いてきます。

エックスサーバーの場合、Web・メールデータ、MySQLデータベースともに過去14日分の自動バックアップが標準で付いています（公式：機能一覧）。.htaccessの書き換えで万一サイト全体がエラーになっても、直近2週間以内であれば復元できる余地があるのは、作業中の安心材料になります。SSH／SFTP接続にも対応しているので、管理画面からファイルマネージャーで一つずつ触るのではなく、鍵認証でスクリプト化してデプロイを回すという運用もできます。私も接続はパスワードではなく秘密鍵認証で行っています。

もう一点、1つの契約で複数サイトを運用している場合は、URL構造の変更作業でドキュメントルートを取り違えるリスクにも注意が必要です。デプロイ先のパスを間違えると、意図しないサイトに旧ディレクトリのファイルが撒かれてしまい、しかも同期がマージ動作だと気づかないまま残り続けます。この事故と防ぎ方については、以下で具体的に書いています。

1つのレンタルサーバーで複数サイトを運用するときの事故と防ぎ方｜デプロイ先の取り違えとファイルの残骸

無料独自SSLについても、Xserverは無料・無制限で使えますが、Cloudflareなどの外部CDNをProxied設定で挟んでいる場合は更新に失敗して90日後に静かに切れることがあります。URL構造の変更と一緒にSSL周りの構成も見直すタイミングなら、こちらも合わせて確認しておくと安全です。

レンタルサーバーの無料SSLがCloudflare経由だと更新に失敗する｜90日後に切れる前の確認手順

他の選択肢との比較——プラグイン任せでいいのか

WordPressを使い続けるなら、リダイレクト管理プラグインで301を設定する方法もあります。どちらが良いかは状況によります。

方法	仕組み	向いているケース	注意点
.htaccess（サーバー側）	Apacheが直接処理	CMSを乗り換える、静的サイト化する、大量のディレクトリを丸ごと転送する	書き方を間違えるとサイト全体がエラーになるリスクがある
リダイレクト管理プラグイン	WordPress側で管理画面から設定	WordPressを使い続ける、更新頻度が高く非エンジニアが管理する	プラグインの処理が挟まる分、.htaccessより応答が一段階遅くなることがある
CDN／DNS側のリダイレクト	Cloudflareなどのレイヤーで設定	ドメイン自体を変える大規模な移行	サーバー移行前提の記事の範囲を超えるため個別に検討が必要

CMSを乗り換える、あるいは静的サイトへ移行するようなケースでは、CMS側の機能に依存しない.htaccessでの実装が理にかなっています。逆に、WordPressを使い続けて日常的に記事の統廃合が発生するサイトなら、プラグインで管理画面から都度設定できる方が、非エンジニアの担当者でも運用を回しやすいと思います。

向いている人・向いていない人

向いている人	向いていない人
サイトリニューアルやCMSの乗り換えでURL構造が変わる予定がある	URL構造を変える予定が当面ない（この記事の対象外）
制作会社に任せきりでも、サーバーの中身（.htaccessやSFTP）を自分でも把握しておきたい事業者	サーバー管理を完全に外部に委託し、中身に一切触れる予定がない
複数サイトを1契約で運用していて、デプロイ・リダイレクトの仕組みを自前で組みたい制作者・運用者	単一の静的な数ページのサイトで、そもそも構造変更の予定がない
これから新規でサーバーを借りる、または他社から乗り換える予定がある	現在契約中のサーバーを更新するだけで、新規契約の予定はない

実務での具体的な使い方

例えば、コーポレートサイトの「サービス紹介ページ」を/service/から/services/に変更する、あるいはブログを/blog/からカテゴリ別のディレクトリ構成に再編する、といった作業は実務でよくあります。この場合、対応表をスプレッドシートで作り、RedirectMatchでディレクトリごと転送するルールを1〜2行書けば済むケースがほとんどです。

一方、WordPressから静的サイトジェネレーターへの移行のように、URLの生成ロジック自体が変わる場合は、ビルドプロセスの中で対応表から.htaccessを自動生成する仕組みを組んでおくと、記事が増えても手作業でのリダイレクト漏れを防げます。私が今運用している仕組みもこの形で、旧URLと新URLの対応をコード側で持たせて、ビルドのたびに.htaccessが最新化されるようにしています。手作業に依存しない、というのがミスを減らす一番の近道だと感じています。

デメリット・注意点

正直に書くと、301リダイレクトを設定したからといって、検索順位がすぐに元通りになるわけではありません。Googleが新URLを再クロールして評価を移行するまでには数週間から、場合によっては数ヶ月かかることもあります。「今日リダイレクトを設定したのに、今週も旧URLが検索結果に出てくる」という状態は珍しくなく、ここで焦って何度もURLを変更し直すと、かえって評価の移行が遅れます。

また、.htaccessの記述ミスは影響範囲が大きい点も注意が必要です。正規表現のパターンを一つ間違えるだけでサイト全体が500エラーになることもあるので、必ずステージング環境や、公開前のテスト環境で動作確認をしてから本番に反映する運用をおすすめします。

「意味ない?」への実態ベースの回答

「.htaccessでリダイレクトしても意味がないのでは」という声を見かけることがありますが、これは半分正しく半分誤解です。正しいのは「リダイレクトだけで魔法のように順位が上がるわけではない」という点。誤解なのは「リダイレクトしなくても大差ない」という考え方で、実際には旧URLを放置すると404の山ができ、被リンクの評価もクロールの効率も損なわれます。リダイレクトは「順位を上げる施策」ではなく「積み上げてきた評価を失わないための保険」だと捉えるのが実態に近いと思います。

サーバーの契約期間と料金——乗り換えるならいつ・どのプランか

URL構造の変更をきっかけに、サーバー自体の乗り換えや新規契約を検討している方向けに、料金の実際も触れておきます（公式：料金ページ）。

契約期間	スタンダード	プレミアム	ビジネス
3ヶ月	1,320円/月	2,640円/月	5,280円/月
6ヶ月	1,210円/月	2,420円/月	4,840円/月
12ヶ月	990円/月	1,980円/月	3,960円/月
24ヶ月	836円/月	1,672円/月	3,344円/円
36ヶ月	693円/月	1,386円/月	2,772円/月

「990円から」という表記をよく見かけますが、これは12ヶ月契約時の月額です。3ヶ月契約だと同じスタンダードプランでも1,320円/月と、1.3倍以上の差になります。今すぐサーバーを本格運用する予定があるなら、短期契約で様子見するより、12ヶ月契約を基準に見積もる方が総額でも有利です（3ヶ月契約は初期のお試し程度に留め、本格運用は6ヶ月以上・実質は12ヶ月を軸に考えるのが現実的です）。

いきなり長期契約を決める前に、まずは10日間の無料お試しで実際の管理画面やSSH・SFTPまわりの使い勝手を確認してから判断するのが安全です。エックスサーバー公式サイトから申し込み内容と無料お試し期間を確認できます。

法人でこれから複数サイトを一括管理したい、あるいはアクセス増に備えて余裕を持ったプランにしたい場合は、ディスク容量やバックアップ内容がそのままの上位プラン（プレミアム・ビジネス）も選択肢に入ります。ディスク容量はスタンダード500GB、プレミアム600GB、ビジネス700GB（いずれもNVMe）で、独自ドメインは各プラン2つまで永久無料が付きます。

よくある質問

Q. 301リダイレクトと302リダイレクトの違いは？どちらを使うべき？ 301は「恒久的な移動」、302は「一時的な移動」を意味するステータスコードです。URL構造を恒久的に変える場合は301を使ってください。302のままにしておくと、検索エンジンが評価を新URLに移行せず、旧URLの評価を持ち越したまま放置される可能性があります。

---

Q. .htaccessを直接編集できないサーバーでもリダイレクトはできる？ サーバーによっては.htaccessの編集自体は可能でも、書き方に制約がある場合があります。Apache系のレンタルサーバーであれば基本的には本記事の書き方が使えますが、nginxベースのサーバーだと設定ファイルの記法自体が異なるため、事前にサーバーの仕様を確認してください。

---

Q. 旧ページを削除したあとも301の設定は残しておくべき？いつまで？ 残しておくべきです。目安としては、Search Consoleで旧URLへのクロールリクエストがほぼゼロになるまで（数週間〜数ヶ月）は301を維持し、その後もリンク切れ対策として長期間残しておいても実害はありません。

---

Q. サブディレクトリを丸ごと別の場所に引っ越すときの.htaccessの書き方は？ RedirectMatch 301 ^/old-dir/(.*)$ https://example.com/new-dir/$1 のように正規表現でディレクトリごとまとめて転送するのが効率的です。個別ページの例外指定がある場合は、この丸ごと転送ルールより上に書いておく必要があります。

---

Q. サーバーを乗り換えるタイミングでリダイレクトミスが起きやすいのはなぜ? サーバー移行とURL構造の変更が同時に発生すると、確認すべき項目（DNS切り替え、SSL設定、.htaccessの反映、旧ディレクトリの後始末）が一度に重なるためです。移行作業はステージング環境で事前に動作確認をしてから本番に切り替える、という手順を踏むとミスを減らせます。

---

Q. WordPressのリダイレクトプラグインとサーバー側の.htaccess、結局どちらが良い? WordPressを使い続けるなら管理画面から設定できるプラグインが手軽ですが、CMSを乗り換える予定がある、または複数サイトをまとめて運用しているなら、CMSに依存しない.htaccessでの実装の方が長期的には扱いやすいです。

まとめ

URL構造を変えるときの301リダイレクトは、「.htaccessの書き方」自体はそれほど難しくありません。難しいのは、旧URLの洗い出しを丁寧にやることと、リダイレクトを設定した後の旧ディレクトリの後始末を最後まで面倒がらずにやりきることです。私自身、デプロイの同期がマージ動作だったために旧ファイルが本番に残り続けた経験から、この「後始末」の工程を軽視すると後で余計な手間になることを実感しました。

これから新規でサーバーを借りる、あるいは他社から乗り換えてサイトリニューアルに合わせてURL構造も整理したいという方は、まず10日間の無料お試しで管理画面やSFTP・SSH周りの使い勝手を確認し、本格運用するなら12ヶ月契約を基準に見積もっておくのが現実的だと思います。エックスサーバー公式サイトで、料金プランと無料お試しの詳細を確認してみてください。