このページはApacheのmod_rewriteと.htaccessが有効な環境の例です。Nginxにはそのまま適用できません。変更前のファイルを保存し、まず検証環境で302転送を試してから恒久移転に301を使います。サーバー設定そのものを本記事で変更することはありません。
WordPressサイトの移転や構成変更に伴い、「特定のURLだけを別ドメイン・別パスへリダイレクトしたい」というケースはよくあります。
本記事では、.htaccess を使ったリダイレクトの基本と実践的な書き方を、WordPress特有の注意点も含めて解説します。
この記事でわかること
.htaccessを使ったリダイレクトの基本- WordPress環境でリダイレクトを書くときの注意点
- サブディレクトリ単位でのリダイレクト方法
- 親（ルート）
.htaccessにまとめて書く方法 - SEOを考慮した 301 リダイレクトの使いどころ
前提：WordPressと.htaccessの関係
WordPressでは、パーマリンクやURLルーティングのために.htaccess に mod_rewrite を使ったルールが自動生成されます。
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressリダイレクトの基本（301 / 302）
| 種類 | 用途 |
|---|---|
| 301 | 恒久的なURL変更（恒久移転を通知） |
| 302 | 一時的な転送（テスト・期間限定） |
本記事では 恒久移転を前提に 301 リダイレクトを使用します。
方法①：サブディレクトリの .htaccess に書く
サブディレクトリから別ドメイン、別ドメインのサブディレクトサイトへの移転時によく使います。
想定ケース
https://example.com/figma/
↓
https://new-site.com/figma/書き方（/figma/ ディレクトリ内 .htaccess）
<IfModule mod_rewrite.c>
RewriteEngine On
# 管理画面・ログインは除外
RewriteCond %{REQUEST_URI} !^/figma/wp-admin(?:/|$) [NC]
RewriteCond %{REQUEST_URI} !^/figma/wp-login\.php(?:/|$) [NC]
# /figma/ 以下を別ドメインへ転送
RewriteRule ^(.*)$ https://new-site.com/figma/$1 [R=301,L]
</IfModule>
ポイント
- サブディレクトリ内の
.htaccessではRewriteRuleは そのディレクトリ基準で評価される - WordPressのルーティングより 必ず上に書く
$1を使うことで 末尾パスを維持できる
方法②：親（ルート）の .htaccess にまとめて書く
複数の転送をルートへまとめる方法もありますが、子ディレクトリの設定やサーバー構成を含めて検証が必要です。
書き方（ドキュメントルート）
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^figma/(.*)$ https://new-site.com/figma/$1 [R=301,L]
RewriteRule ^photoshop/(.*)$ https://new-site.com/photoshop/$1 [R=301,L]
RewriteRule ^Illustrator/(.*)$ https://new-site.com/illustrator/$1 [R=301,L]
RewriteRule ^google-workspace/(.*)$ https://new-site.com/google/$1 [R=301,L]
</IfModule>
この方法のメリット
- WordPressの自動上書きの影響を受けない
- 1ファイルで全リダイレクトを管理できる
- 転送が先に成立したリクエストではWordPressへ到達しない
- 旧URLと新URLの対応を一覧で管理できる
なぜ WordPress より「上」に書く必要があるのか
掲載のWordPressルールは、実在するファイル・ディレクトリを除き、対象の要求をindex.phpへ内部的に書き換えます。
RewriteRule . /index.php [L]先に内部書き換えが成立すると、後ろに置いた転送ルールが想定どおり適用されない場合があります。
同じ.htaccessの自動生成ブロックの外側・上へ転送ルールを置いて検証します。
リダイレクトは必ず WordPress ルールより先に書く、これは WordPress + .htaccess の鉄則です。
よくある注意点
覚えておきましょう！
① 301はキャッシュされる
ブラウザに強くキャッシュされるため、検証時はシークレットモード推奨。
② 大文字・小文字に注意
たとえば/Illustrator/ と /illustrator/ は別物として扱われる場合があります。
③ BEGIN WordPress 内は触らない
編集すると管理画面操作で上書きされます。
記述を作る・確かめる
転送するURLが多いときは、.htaccessリダイレクト生成で記述を作れます。
旧URLと新URLの対応表を貼ると、Redirect 301・RewriteRule・RedirectMatch のいずれかの形で出力します。
www統一・常時SSL化・末尾スラッシュ統一の定番の記述も、選ぶだけで追加できます。
入力したURLはサーバーに送られず、ブラウザーの中だけで変換されます。
書いたあとはリダイレクトチェックで、301になっているかと転送の段数を確かめてください。
まとめ
.htaccessでのリダイレクトは WordPressより先に書く- 単体ならサブディレクトリ
.htaccess - 親へまとめる場合も、子ディレクトリの.htaccessと処理順を確認する
- 恒久移転は 301リダイレクトを使う
WordPress環境では「どこに書くか」「順番」が非常に重要です。
仕組みを理解しておけば、安全かつSEOに配慮したURL移転が行えます。
この記事で紹介しているコードは、GitHubのMOTOKI-LLC/WAZA-codeにもまとめています。
転送範囲と検証項目
サブディレクトリ例は管理画面・ログインを除外しますが、ルートの複数ルール例はそれらも含めて転送します。同じ動作ではありません。管理画面を残すなら除外条件を各RewriteRuleの直前へ追加してください。末尾スラッシュのない入口URL、存在するファイル、子ディレクトリに別の.htaccessがある場合も個別に確認します。
例の転送先にはクエリ文字列を指定していないため、元のクエリが引き継がれます。
秘密情報を含むパラメーターを別ドメインへ渡さないでください。
元URL、Location、最終ステータスとループの有無を確認し、日本語・空白などを含むパスも対象サーバーで試します。
不具合時は追加したルールを元のバックアップへ戻し、ブラウザー・CDNの転送キャッシュも確認します。301は検索エンジンへの移転シグナルであり、順位の維持を保証するものではありません。参照：Apacheのディレクトリ単位の書き換え、RewriteRuleフラグ。旧GitHubの記述は今回の修正とは未同期です。
管理画面の除外と子ディレクトリを実測する
除外条件の末尾の(?:/|$)は、管理画面・ログインURLの区切りを指定します。
以前の前方一致だけの条件では、wp-admin-otherやwp-login.php-backupまで除外されました。
2026年10月3日の隔離Apache 2.4.69でこれを再現し、修正版では正規の管理画面・ログインURLを残し、似た名前のURLを301転送できることを確認しました。
親の転送ルールと、子に置いたWordPress形式の内部書き換えを同時に使った試験では、子のindex.phpへ到達して200となる例がありました。
子の自動生成ブロックより上へ転送を置くと301になりました。
親に書けば常に転送できるとは判断せず、実際の子設定を含めて検証します。
空白・#・日本語を含むパスは、今回の試験ではURLエンコードしたLocationで転送されました。
%3Fを含むパスはWindows版Apacheのファイル名制約で403になりました。
この結果をLinuxなど別のサーバーへ一般化せず、同じ入力を対象環境で確認してください。
/figmaのような末尾スラッシュなしの要求では、まず同じサイトの/figma/へ301となり、転送が1段増えることも確認しました。
検証対象は掲載ルールと試験用のファイル・内部書き換えです。
実際のWordPressのログイン、移転先の内容、CDNを含む本番移行は検証していません。
