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