結論から言うと、良いURLは「理解できる・増殖しない・できるだけ変えなくて済む」の3点を満たします。新規ページは小文字、ハイフン、安定した分類、必要最小限のパラメータを基本にします。既存URLは検索流入、被リンク、ブックマーク、広告、フォーム、API、計測が結び付いた資産なので、短く見せるためだけに変更しないことが重要です。
新規URLは単純に。公開済みURLは、改善価値が移行リスクを上回る場合だけ変える
「SEOに強そう」「URLが長いから」といった感覚ではなく、利用者の理解、重複URLの抑制、運用の安定性、移行後の検証可能性で判断します。
| 基本方針 | 読者が内容を理解でき、同じ内容のURLを増やさず、長期維持できる構造にする |
|---|---|
| 区切り文字 | 英単語はハイフンで区切り、小文字へ統一する |
| 階層 | 組織図ではなく利用者が理解できる分類を使い、変更されやすい部署名や年度を安易に入れない |
| 日本語URL | 利用可能。ただし共有時のエンコード、入力、分析、外部連携を含めて運用しやすさを確認する |
| canonical | 重複・類似ページの代表URLを示す。廃止URLの転送や利用者の移動にはリダイレクトを使う |
| 既存URL変更 | 見た目だけなら変えない。変更するなら旧新一対一対応と公開前後の検証を必須にする |
| 確認日 | 2026年7月29日 |
URL構造とは、ページの場所と状態を伝える設計ルール
URL構造は、ドメイン以下のパスだけを指す言葉ではありません。プロトコル、ホスト名、パス、クエリパラメータ、フラグメントをどの目的で使うか、同じ内容へ複数の入口が生まれたときにどのURLを代表にするかまで含む設計です。
https://通信方式。通常はHTTPSへ統一example.comドメインやサブドメイン/guides/url/内容やページ種別を識別?sort=price絞り込み・表示・計測など#migration同じ文書内の位置を示すURLだけで検索順位が決まるわけではありません。それでも、単純で一貫したURLは、利用者がリンク先を予測しやすく、内部リンクやsitemapを管理しやすくし、クロール対象の無駄な増殖を抑える助けになります。
SEOと運用を両立するURL設計の7原則
Googleは、理解しやすい語、対象読者の言語、ハイフン、必要最小限のパラメータを推奨し、URLの大文字と小文字を別のものとして扱います。ここでは、その推奨をサイト運用へ落とし込むための基準を整理します。
内容を説明する短い語を使う
長いIDだけより、ページの役割が分かる語を選びます。タイトル全文や検索語を詰め込まず、別ページと区別できる範囲で簡潔にします。
複数語はハイフンで区切る
英単語を複数使う場合は「url-structure」のようにハイフンを基本にします。既存のアンダースコアURLは、区切りだけを理由に一斉変更しません。
小文字へ統一する
「/Server/」と「/server/」を別ページとして公開しない設計にします。同じ内容を返す場合も、採用版へリダイレクトし、内部リンクとcanonicalを統一します。
階層は利用者の理解で決める
社内組織やサーバー内フォルダをそのままURLへ写す必要はありません。読者が期待するカテゴリとナビゲーションに合わせ、内部リンクから到達できる構成にします。
変わりやすい情報を常設URLへ入れない
年度、部署名、キャンペーン名、CMS拡張子は将来の変更を誘発します。日付そのものに意味があるニュースや法定記録は例外です。
対象読者の言語を選び、運用方法を統一する
日本語URLも利用できます。共有時のパーセントエンコード、入力ミス、アクセス解析、外部ツールとの互換性を確認し、英字転写とのどちらを採るか全体方針を決めます。
パラメータと自動生成URLを必要最小限にする
セッションID、追跡値、並べ替え、無制限の絞り込み組合せが内部リンクから増殖しないようにします。内容差のあるURLと表示状態だけのURLを分けて管理します。
サイト種別ごとに、長く維持できるURLの型を作る
個別ページを公開するたびにURLを考えると、表記揺れと例外が増えます。ページ種別ごとに、必須の識別子、任意の分類、言語・地域、末尾スラッシュ、廃止時の対応責任者まで決めておくと運用が安定します。
サービス
https://example.com/services/web-development/担当部署や料金プランではなく、提供内容が変わっても維持できるサービス名を使います。
記事・ガイド
https://example.com/guides/url-migration/継続更新する解説は日付なし、年月で識別するニュースや記録は日付ありなど、媒体の役割で分けます。
EC商品
https://example.com/products/running-shoe-1234/商品名変更に耐える安定IDを併用できます。色・サイズごとのURLをindex対象にするか事前に決めます。
カテゴリ
https://example.com/products/shoes/利用者が一覧へ到達するための安定分類を使います。複数フィルタを組み合わせるたびにURLを無制限に作りません。
多言語
https://example.com/en/services/言語ごとに固有URLを用意し、各版へ明示的に移動できるリンクとhreflangを整えます。別言語ページへcanonicalを向けないよう注意します。
URLパラメータ・フラグメント・canonicalの役割を分ける
URLの差が独立した内容を表すのか、同じ内容の並べ替えや計測にすぎないのかを先に決めます。「パラメータはすべて削除」「canonicalを付ければ何でも解決」といった一律運用は避けてください。
| 形式 | 例 | 設計・SEO上の判断 |
|---|---|---|
| 内容を変えるパラメータ | /products?category=shoes | 固有一覧として必要なら、クロール可能な内部リンク、title、見出し、canonicalを整える。組合せが大量ならindex対象を限定する。 |
| 並べ替え・表示 | /products?sort=price | 同じ集合の順番だけが違うなら、基準一覧との重複を増やさない。共有状態としてURLを残す場合もindex方針を決める。 |
| 計測パラメータ | /guide?utm_source=newsletter | 内容を変えない追跡値を内部リンクやsitemapへ恒常的に載せない。canonicalは追跡なしURLへそろえる。 |
| フラグメント | /guide/#migration | 同じ文書内の位置を示す用途に使う。独立した本文の切替やindex対象ページの識別には依存しない。 |
重複・類似ページの代表URLを示す
canonicalは、同じまたは非常に似たページ群の代表候補を検索エンジンへ伝える信号です。canonicalページ自身にも自己参照canonicalを置き、内部リンクとsitemapを同じURLへそろえます。
利用者の転送や廃止URLの移動
canonicalはブラウザを転送せず、指定どおり必ず採用される命令でもありません。廃止URLを新しい場所へ恒久移動するなら、サーバー側の301または308を使います。
既存URLは、変更による利益と移行リスクを比較する
公開済みURLには、検索エンジンのindexだけでなく、外部リンク、ブックマーク、メール、QRコード、広告、アクセス解析、API、フォーム送信先、社内資料が結び付いています。新規URLの理想形へ近づけるだけでは、それらを切断するコストを正当化できません。
見た目の改善しか得られない場合
- 内容とURLの意味が大きく矛盾していない
- 流入、被リンク、共有、広告、外部連携で使われている
- 短さ、区切り、キーワード追加だけが目的
- 旧新対応表、リダイレクト、監視を準備できない
明確な問題を解決できる場合
- HTTPからHTTPS、ドメイン変更、CMS移行で必然的に変わる
- 複数の重複ページを一つの有用なページへ統合する
- 機密情報、セッションID、重大な誤分類を含む
- 古い構造が利用者の移動や日常運用を継続的に妨げる
ドメイン・CMS・デザイン・本文を同時に大きく変えない
複数の大変更を同時に行うと、検索流入やコンバージョンが落ちたときに原因を切り分けられません。可能なら「ホスティング移行」「URL変更」「デザイン変更」「本文統合」をリリース単位で分け、各段階の基準値を保存します。
WordPressのパーマリンク変更は、公開前と公開後で判断が違う
新規サイトの公開前なら、投稿名、カテゴリ、日付の要否を検討して規則を決められます。一方、公開済みサイトで管理画面のパーマリンク設定を変更すると、投稿・カテゴリ・フィード・画像・カスタム投稿など広い範囲へ影響する可能性があります。
運用しやすい規則を先に固定
常設記事なら、日付や変更されやすいカテゴリを必須にしない構成を候補にします。末尾スラッシュ、小文字、英字転写、日本語URLの扱いもサイト全体で統一します。
設定保存だけでは移行にならない
旧URLから新URLへの一対一リダイレクト、内部リンク、canonical、sitemap、キャッシュ、CDN、プラグイン、Search Console、アクセス解析、復旧手順が必要です。
URL変更を7段階で進める
Googleのサイト移転ガイドは、旧新URL対応表を作り、恒久リダイレクトを設定し、内部リンクやcanonicalを更新し、公開後に監視する流れを示しています。規模が大きいほど、試験範囲、サーバー容量、クロール増加、復旧方法も見積もります。
https://example.com/old-page/https://example.com/new-page/現状を保存する
クロールで取得したURL、HTTP状態、canonical、index可否、内部リンク、sitemap、検索流入、被リンク、重要コンバージョン、外部連携を保存します。CMS、サーバーログ、解析、Search Consoleを組み合わせます。
旧URLと新URLを一対一で対応付ける
同じ内容または統合後の最も関連する内容へ対応付けます。多数の旧URLを無関係なトップページへ送らず、代替がない削除ページは404または410を検討します。
ステージングで新URLを完成させる
本文、画像、CSS、JavaScript、フォーム、ログイン、決済、構造化データ、パンくず、canonical、hreflangを確認します。公開前noindexやアクセス制限の解除担当も決めます。
恒久リダイレクトを実装する
サーバー側の301または308を使い、旧URLから最終新URLへ直接一回で到達させます。ブラウザ内JavaScriptや遅延meta refreshを第一選択にしません。
すべての参照先を新URLへ更新する
内部リンク、canonical、sitemap、hreflang、構造化データ、OGP、広告、メール、プロフィール、QRコード、API、フォーム、解析設定を更新します。自サイト内リンクを旧URL経由に残しません。
公開直後に全件検査する
旧URLが301または308、新URLが200を返し、チェーン・ループ・誤転送がないことを機械検査します。主要ページはブラウザ、モバイル、フォーム送信、ログイン、決済でも確認します。
長期監視し、リダイレクトを維持する
Googleはリダイレクトをできるだけ長く、一般に少なくとも1年維持するよう案内しています。利用者の古いリンクを考えると、それ以上または恒久的な維持が適切な場合もあります。
301・308リダイレクトの最小実装例
実装方法はサーバー、CDN、CMS、アプリ構成で異なります。以下は考え方を確認するための最小例です。本番ではクエリ文字列、末尾スラッシュ、URLエンコード、キャッシュ、ループ、POST・APIの挙動をステージングで検証してください。
Redirect 301 /old-page/ https://example.com/new-page/location = /old-page/ {
return 301 https://example.com/new-page/;
}// 通常の恒久移動
http.Redirect(w, r, "/new-page/", http.StatusMovedPermanently)
// メソッドを保持する恒久移動を使う場合
http.Redirect(w, r, "/new-page/", http.StatusPermanentRedirect)公開前後の検証は、応答・内容・検索・業務の4層で行う
一部ページが表示できるだけでは移行成功とはいえません。旧URLが正しく移動し、新URLの内容と検索シグナルが一致し、重要操作と計測が継続し、公開後のクロール・index・流入が許容範囲で推移していることを確認します。
HTTP応答と到達先
旧URL、http・https、www有無、大文字小文字、末尾スラッシュ、主要パラメータを検査。旧URLは最終新URLへ直接移動し、新URLは200を返すことを確認します。
HTMLと検索シグナル
title、H1、本文、画像、canonical、robots、hreflang、構造化データ、OGP、パンくず、内部リンク、sitemapを新URLへそろえます。
Search Consoleとログ
代表URLのURL検査、Page Indexing、sitemap、クロール統計、サーバーログを確認し、404、5xx、リダイレクト増加を追います。site:検索だけで監査しません。
利用者と業務操作
ナビゲーション、サイト内検索、共有、ログイン、問い合わせ、購入、ダウンロード、広告、外部APIを主要ブラウザとモバイルで操作します。
公式資料と確認日
次の一次資料を2026年7月29日に確認しました。Google Searchの推奨とHTTP仕様を分け、サイト固有のサーバー、CMS、CDN、フォーム、APIの挙動はステージングと本番で測定してください。
URL構造に関するよくある質問
URLは短いほどSEOに有利ですか？
短さだけで順位が決まるわけではありません。内容を識別でき、不要な語やパラメータがなく、共有・運用しやすい長さを選びます。公開済みURLを数文字短くするためだけの変更は、移行リスクに見合わないことが多いです。
URLに日本語を使ってはいけませんか？
日本語URLも利用できます。ただし、共有時のパーセントエンコード、入力、分析、外部システム、運用担当者の扱いやすさを確認し、英字転写とのどちらを採るかサイト全体で統一します。
URLにキーワードを入れると順位が上がりますか？
内容を説明する自然な語は理解に役立ちますが、順位上昇を保証しません。検索語を繰り返した長いURLより、本文、title、見出し、内部リンク、内容の品質を優先します。
WordPressのパーマリンク設定を公開後に変えてもよいですか？
全投稿のURLが変わる可能性があるため、旧新一覧、一対一リダイレクト、内部リンク、canonical、sitemap、キャッシュ、計測、復旧を準備してから判断します。管理画面で保存できることと、安全に移行できることは別です。
末尾スラッシュは付けるべきですか？
どちらでも構いませんが、一つの形式へ統一します。スラッシュ有無の両方が200を返す場合は採用版へリダイレクトし、canonical、内部リンク、sitemapも同じ形式へそろえます。
301と308はどちらを使えばよいですか？
どちらも恒久移動に使えます。通常のGETページは既存インフラとの相性を優先できます。POSTやAPIではメソッド保持が重要なため、308を含めて実クライアント、CDN、キャッシュで検証します。
既存URLはSEOのために作り直すべきですか？
見た目やキーワード追加だけを理由に作り直さないでください。重複統合、ドメイン・CMS移行、重大な誤分類、機密情報を含むURLなど、変更価値が移行リスクを上回る場合に限って計画します。
まとめ：良いURLは、理解でき、増殖せず、変えなくて済む
新規URLは、対象読者が理解できる語、小文字、ハイフン、安定した分類、必要最小限のパラメータを基本にします。公開済みURLは見た目だけで変えず、明確な問題を解決できる場合だけ移行してください。
変更するなら、旧新一対一対応表、恒久リダイレクト、canonical・内部リンク・sitemap更新、フォームやAPIを含む重要操作、公開後監視を一つの計画として実行します。URLだけで検索成果を保証せず、内容と利用体験も同時に改善することが大切です。
Finite Field 編集部公式仕様、実装上の安全性、検索シグナル、利用者の移動を分けて確認し、URL変更の利益と損失を比較できるよう編集しています。
