WordPressの日本語URLを英語へ変更する方法｜301確認まで

WordPressの記事タイトルを日本語で付けると、スラッグにも日本語が入ることがあります。ブラウザでは読めても、URLをコピーすると %E3%80%90... のような長い文字列になり、共有や管理がしづらくなります。

だからといって、公開済み記事のスラッグだけを変えて終わりにしてはいけません。古いURLを開いた読者が404になれば、外部リンクも検索流入もそこで途切れます。

この記事では、実際にUnplifeの公開済み記事を日本語スラッグから英語へ変更したときの手順をもとに、次の4点を確認します。

1. WordPressで英語スラッグへ変更する
2. 旧URLが新URLへ301転送される
3. 新URLのcanonicalが自分自身を指す
4. XMLサイトマップに新URLだけが載る

英語スラッグへ変えれば検索順位が上がる、という話ではありません。目的は、URLを短く管理しやすくしながら、既存の入口を壊さず移行することです。

公開前なら、英語スラッグを付けてから公開する

まだ下書きなら作業は簡単です。投稿を一度下書き保存し、右側の「投稿」設定にある「スラッグ」を開いて、英小文字とハイフンで入力します。

例えば、次のようにします。

記事の内容	スラッグ例
Macの初期設定	mac-first-setup
Gitコミットメッセージ	git-commit-message-guide
Raycastのクリップボード履歴	raycast-clipboard-history

スラッグは、タイトルをそのまま英訳する必要はありません。記事を識別できる主要語だけを残します。日付、how-to、complete-guideなど、なくても意味が通る語は増やしません。

WordPress公式ドキュメントでも、投稿または固定ページを下書き保存したあと、投稿設定のスラッグ欄からURL末尾を編集できると説明されています。

公開前なら旧URLへのアクセスは基本的に存在しないため、この段階で整えるのが最も安全です。

公開済みURLは、変更前に旧URLを控える

公開済み記事では、先に変更前のURLをそのまま保存します。ブラウザのアドレスバーに表示された文字列だけでなく、リンク先として使える完全なURLを控えます。

今回確認した投稿は、次のように変更しました。

種別	URL
旧URL	https://unplife.com/2026/02/08/【保存版】新しいmacを買ったら最初にやるべき爆.../
新URL	https://unplife.com/2026/02/08/mac-first-setup/

旧URLは実際にはさらに長い日本語スラッグです。本文では読みやすさのため途中を省略していますが、転送確認には省略していないURLを使いました。

このとき、サイト全体のパーマリンク構造まで同時に変えません。記事単体のスラッグ変更と、/%year%/%monthnum%/%day%/%postname%/ のようなサイト全体の構造変更は別の作業です。同時に行うと、転送に失敗した原因を切り分けにくくなります。

WordPressでスラッグを変更する

この実測で変更したのは、WordPress標準の「投稿」のスラッグです。固定ページ、階層型のカスタム投稿タイプ、サイト全体のパーマリンク構造変更は、同じ自動転送を前提にできません。

それらを変更する場合は、先にリダイレクト用プラグインまたはサーバー設定で、旧URLから新URLへ301を設定できる状態にします。設定方法と権限が分からなければ、公開URLはまだ変えません。

ブロックエディターでは、次の順で変更します。

1. 「投稿」から対象記事の編集画面を開く
2. 右側の投稿設定で「スラッグ」を開く
3. 英語スラッグを入力する
4. 「更新」を押す
5. 実際の「投稿を表示」リンクを開く
6. WordPressが確定した新URLを記録する

入力には英小文字、数字、ハイフンを使います。単語の区切りに空白やアンダースコアを使わず、mac-first-setupのように書きます。

スラッグが既存記事と重複すると、WordPressが末尾へ数字を追加する場合があります。入力した文字列を新URLだと思い込まず、保存後の投稿リンクを確認します。

更新しただけでは、移行が成功したとは判断できません。ここから旧URLと、保存後に確定した新URLを別々に確認します。

旧URLが301で新URLへ移動するか確認する

まず、ログアウト状態またはシークレットウィンドウで旧URLを開きます。新URLの記事が表示されるだけでなく、最終的なアドレスバーが新URLになっていることを確認します。

ターミナルを使える場合は、レスポンスヘッダーを見ると明確です。

curl -I --max-redirs 0 '旧URL'

Unplifeで2026年10月4日に確認した結果は、要点だけ抜き出すと次の通りでした。

HTTP/2 301
location: https://unplife.com/2026/02/08/mac-first-setup/
x-redirect-by: WordPress

301は恒久的な移動を表します。Googleも、URLを恒久的に変更する場合は、可能ならサーバー側の301または308リダイレクトを使うよう案内しています。

WordPressには、過去のスラッグから現在の投稿を探し、新しいパーマリンクへ301転送するwp_old_slug_redirect()があります。ただし、これはどんなURL変更でも保証する仕組みではありません。WordPress Coreの実装では、階層型の投稿タイプを対象外にしています。

そのため、少なくとも次の場合は「WordPressが勝手に直すはず」と決めつけず、個別に確認します。

• 固定ページや階層型のカスタム投稿タイプ
• サイト全体のパーマリンク構造を変えた場合
• リダイレクトやキャッシュ系プラグインが動いている場合
• 同じ旧スラッグを複数の記事で使ったことがある場合
• 日付部分やカテゴリー部分も同時に変えた場合

旧URLが404になる場合は、そのまま放置せず、事前に用意したリダイレクト用プラグインまたはサーバー設定で「旧URL → 対応する新URL」の301を設定します。すべてをトップページへ送るのではなく、内容が同じ記事へ1対1で転送します。転送を設定できない場合は、バックアップした値を使って元のスラッグへ戻します。

新URLの200とcanonicalを確認する

続いて、新URL自体が正常に表示されるか確認します。

curl -I 'https://unplife.com/2026/02/08/mac-first-setup/'

実測結果はHTTP/2 200でした。新URLが200以外なら、スラッグ、公開状態、キャッシュ、パーマリンク設定を先に見直します。

次に、ページのHTMLソースでcanonicalを確認します。UnplifeではCocoonが次のタグを出力していました。

<link rel="canonical" href="https://unplife.com/2026/02/08/mac-first-setup/">

canonicalが旧URLを指したままだと、リダイレクト先と正規URLの指定が食い違います。SEOプラグインやテーマの設定を使っている場合は、新URLを指しているか実ページで確認します。

XMLサイトマップから旧URLが消えたか確認する

WordPress標準のXMLサイトマップは、通常https://example.com/wp-sitemap.xmlから確認できます。これはサイトマップの索引であり、記事URLが直接並んでいない場合があります。「投稿」に対応する子サイトマップまで開いて対象記事を検索します。

今回確認したURLは次の2つです。

種別	URL
サイトマップ索引	https://unplife.com/wp-sitemap.xml
投稿用サイトマップ	https://unplife.com/wp-sitemap-posts-post-1.xml

SEOプラグインが別のサイトマップを生成している場合は、すでにSearch Consoleへ登録しているサイトマップと、その配下の投稿用サイトマップを確認します。

Unplifeの投稿サイトマップでは、変更後に次の英語URLが掲載されていました。

https://unplife.com/2026/02/08/mac-first-setup/

旧日本語URLは掲載されていませんでした。Googleの公式資料でも、サイトマップには検索結果へ表示したいcanonical URLを含めるよう案内しています。

サイトマップ送信はクロールやインデックス登録を保証するものではありません。Search Consoleですでにサイトマップを送信している場合は、更新されたサイトマップをGoogleが再取得できる状態か確認します。

内部リンクとSearch Consoleを確認する

サイト内に旧URLへのリンクが残っていると、読者は毎回リダイレクトを経由します。WordPressの本文、メニュー、関連記事、プロフィール、SNSの固定投稿など、自分で変更できるリンクは新URLへ直します。

Search Consoleでは、確認する画面を分けます。

• URL検査の登録済み情報: Googleが現在どのURLを登録し、どのURLをcanonicalとして選んだか確認する
• URL検査のライブテスト: 現在のページへGoogleがアクセスできるか確認する。Googleが選ぶcanonicalの予測には使わない
• 検索パフォーマンス: 期間内に発生したクリックや表示回数を確認する

検索パフォーマンスは過去の実績を含みます。変更前を含む期間を表示すれば、旧URLの履歴は残ります。旧URLの記録がレポートから消えることを、移行完了の条件にはしません。変更日以降へ期間を絞り、新URL側に表示やクリックが移っているかを別に見ます。

Googleが旧URLを再クロールし、301やcanonicalなどのシグナルを処理するまでには時間差があります。

変更直後は表示回数や順位の上下を理由に何度もURLを変えず、まず次の技術状態を確認します。

確認対象	期待する状態
旧URL	301で対応する新URLへ移動
新URL	200で本文を表示
canonical	新URLを指定
XMLサイトマップ	新URLだけを掲載
サイト内リンク	可能な範囲で新URLへ更新

この5点が揃ったら、Search ConsoleのURL検査で新URLの登録済み情報とライブテストを確認し、必要ならインデックス登録をリクエストします。リクエストはクロールや検索結果への掲載を保証せず、同じURLへ何度送っても速くなるわけではありません。

検索結果が新URLへ切り替わっても、旧URLの301転送は外しません。GoogleはURL移行時の転送を一般に少なくとも1年間、利用者のためには可能なら継続して維持するよう案内しています。外部リンクやブックマークは、その後も旧URLのまま残るためです。

日本語URLは、公開後に必ず変えるものではない

日本語スラッグは長く見え、コピー時にパーセントエンコードされるため、運用上は英語の方が扱いやすいと感じます。しかし、日本語URLだから検索エンジンに登録されないわけではありません。

すでに外部リンクや検索流入がある記事では、見た目だけのために変更する価値があるかを先に考えます。変更するなら、英語にすることよりも、旧URLを404にしないことが重要です。

新規記事は公開前に短い英語スラッグを設定する。公開済み記事は、301、200、canonical、サイトマップまで確認できるときだけ変える。現在はこの運用に統一しています。

参考資料

• WordPress: Page/Post Settings sidebar
• WordPress Developer Resources: wp_check_for_changed_slugs()
• WordPress Developer Resources: wp_old_slug_redirect()
• Google Search Central: Redirects and Google Search
• Google Search Central: How to move a site
• Google Search Central: Build and submit a sitemap
• Google Search Central: Ask Google to recrawl your URLs
• Search Consoleヘルプ: URL検査ツール
• Search Consoleヘルプ: 検索パフォーマンス レポート

更新履歴

• 2026-10-04: 初稿作成。公開済み投稿の301転送、新URLの200、canonical、XMLサイトマップを実サイトで確認