【Google検索セントラル解説】URL構造のベストプラクティス｜クロールされやすいURLの要件・避けたい形・英日の差

2026年10月8日

中野輝規

自社サイトのURLは、一度つけると何年も使い続けます。Googleは、検索セントラルの1ページに、URLの作り方と避けたい形をまとめています。

この記事は、そのページ「URL structure best practices for Google Search」を英語版の原文から読んで整理します。英語版と日本語版の比べ読み、書き換えの経緯、弊社のサイトで確かめたことも書きます。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。URLの形は記事が増えるほど直しにくくなるため、Googleの求めを原文で確かめました。

結論：3行で言うと

クロールされやすいURLの要件は3つです。IETF STD 66に沿うこと、フラグメントでページの内容を変えないこと、パラメータを一般的な形で書くこと。満たさないと、クロールが非効率になる可能性が高いとされています
わかりやすさの勧めは、読める単語、読者の言語、ハイフン区切り、少ないパラメータです。URLの大文字と小文字は別物として扱われる点にも注意が要ります
絞り込みの掛け合わせ、無関係なパラメータ、セッションID、カレンダー、壊れた相対リンクは、URLを増やします。原因ごとに対処は違いますが（Cookie、nofollow、ルート相対のリンクなど）、「クロールの問題を直す」の節の先頭に挙がるのは、robots.txtでGooglebotのアクセスをブロックする検討です

このページの基本情報

項目	内容
原題（英語）	URL structure best practices for Google Search
日本語版の題名	Google 検索における URL 構造のベストプラクティス
英語版の最終更新日	2025年12月10日
日本語版の最終更新日	2025年12月31日
Google検索セントラルの中の位置（章）	「クロールとインデックス登録」（Crawling and indexing）
直近の主な更新	変更履歴の記載は2025年6月18日の書き直しです。ページの日付は9月1日と12月10日にも変わっています。12月10日は本文が変わっていませんでした

原文はこちらです。英語版／日本語版。

Googleがこのページで言っていること

導入と3つの要件

冒頭に、クロールを妨げないURL構造の要件が3つ挙がっています。満たさない場合、クロールが非効率になる可能性が高いと書かれています。

例として、クロール頻度が極端に高くなる、まったくクロールされない、の2つが挙がっていますが、これらに限らないとされています。

IETF STD 66に従う：Googleは、この規格で定められたURLに対応します。規格が「予約文字」と定める文字は、パーセントエンコード（%に続く16進数で表す方法）が必要です
フラグメントで内容を変えない：フラグメントは、URLの「#」以降の部分です。Googleは通常フラグメントに対応しないため、ページの内容を変えるために使わないよう求めています。JavaScriptで内容を変えるなら、代わりにHistory APIを使うよう勧めています
パラメータは一般的な形で書く：キーと値は「=」で結び、パラメータの追加は「&」でつなぎます。同じキーに複数の値を持たせるときは、規格に抵触しない文字（例：カンマ）を使えます

推奨の例は ?category=dresses&sort=low-to-high の形です。非推奨の例は、コロンとかっこで書く形と、カンマ1つでキーと値を、カンマ2つでパラメータを区切る形です。

URLをわかりやすくする

ここから先は、理解を助けるための勧めで、「可能な限り」の位置づけです。

項目	原文の内容
わかりやすい単語	長いID番号より、読める単語を使います
読者の言語	読者がドイツ語で検索するならドイツ語、日本語で検索するなら日本語の単語をURLに使います。日本語の例（ペパーミント）が載っています
パーセントエンコード	リンクのhref属性には、必要に応じてパーセントエンコードを使います。予約されていないASCII文字はそのままで構いません。ASCII範囲外の文字は、エンコードするべきだとしています
単語の区切り	アンダースコアよりハイフンを勧めます。理由として、ユーザーと検索エンジンがURLの中の概念を見分けやすくなる点を挙げています。アンダースコアは、歴史的な経緯から勧めないとされ、プログラミング言語が関数名に使うなど、「まとめて扱うべき概念」を示す書き方としてすでに広く使われているためと説明されています。単語を区切らずにつなげる形も、推奨しない例に載っています
パラメータの数	内容を変えないパラメータは削って、URLを短くします
大文字と小文字	GoogleのURL処理は大文字と小文字を区別し、`/APPLE` と `/apple` を別のURLとして扱います。ウェブサーバーが同じ扱いにしているなら、どちらかにそろえます
複数の地域を対象にするサイト	国別ドメイン、または国別のサブディレクトリ（`/de/` など）が、推奨の例です

URLが不必要に増える原因と対処

複雑なURLは、同じ内容や似た内容を指すURLを大量に生みます。その結果、Googlebotが必要以上に帯域を使ったり、内容をすべてインデックスに登録できなかったりする可能性がある、と書かれています。

原因	何が起きるか	原文の対処
絞り込みの掛け合わせ	「ビーチに面した」「フィットネスセンターつき」のように条件を足せる一覧ページで、URLの数が急増します。Googlebotは、各ホテルのページに行き着くための少数の一覧があれば足ります	「クロールの問題を直す」の節で、並べ替えと絞り込みの機能のブロックを検討し、ファセットナビゲーションは別ページへ案内しています
無関係なパラメータ	参照元の記録、ショッピングの並べ替え、セッションIDなどが、URLを増やします	セッションIDは、可能な限りURLに入れず、Cookieの利用を検討します。問題のあるURLには、robots.txtでのブロックの検討が挙がっています
カレンダー	開始日と終了日に制限がないカレンダーが、未来と過去の日付へのリンクを制限なく作ることがあります	無限に続くカレンダーがある場合は、動的に作られる未来の日付のページへのリンクに、nofollow属性を付けます
壊れた相対リンク	親ディレクトリ相対のリンク（`../../` の形）を誤った場所に置くと、存在しないページへのURLが生まれることがあります。サーバーが存在しないページに適切なHTTPステータスを返さない場合、無限の空間になりえます	親ディレクトリ相対ではなく、ルート相対のURLを使います

クロールの問題を直す

問題のURLをGooglebotがクロールしていたら、robots.txtでのブロックを検討するよう書かれています。対象の例は、検索結果を作る動的なURL、カレンダーのような無限の空間を作りうるURL、並べ替えと絞り込みの機能です。

ファセットナビゲーション（絞り込みの仕組み）がある場合は、絞り込みURLのクロール管理を扱う別ページを案内しています。

私はその別ページの英語版（2025年12月18日更新）も開きました。インデックスに載せる必要がない絞り込みURLは、robots.txtで止める方法が先頭に挙がっています。

絞り込みの条件をフラグメントで指定する方法も挙がっています。フラグメントはクロールに影響しないためです。

canonicalとnofollowは、この2つより長期的な効果が低いとされています。

今回のページは、内容を変えるためのフラグメントを避けるよう求めています。私の整理では、見せたい内容を変える場合と、クロールさせたくない絞り込みの場合とで、フラグメントの扱いが分かれています。

英語版と日本語版の違い

英語版は2025年12月10日、日本語版は2025年12月31日の更新です。日本語版のほうが21日新しい状態です。

2026年10月8日に、両方を取り直して突き合わせました。見出し、箇条書き、表、コード例の数とリンク先が一致し、項目が増えたり減ったりする差はありませんでした。

断定の強さが違う、訳の濃淡にあたる点は、主に次の4つありました。

robots.txtでのブロック：英語版は「使うことを検討してください」「ブロックを検討してください」と書いています。日本語版は「ブロックできます」「ブロックします」で、私には決まった手順のように読めます。セッションIDのCookieも、英語版は「検討してください」、日本語版は「使用してください」です
予約されていないASCII文字：英語版は「エンコードしない形のままでもよい」という許可の書き方です。日本語版は「そのまま残る可能性があります」で、起こりうる現象の説明に読めます
ASCII範囲外の文字：英語版は「パーセントエンコードするべき」という強さです。日本語版は「パーセントエンコードを行う必要があります」で、より強く読めます
冒頭の警告：英語版は、要件を満たさないとクロールが非効率になる可能性が高い、という書き方です。日本語版は「効率が低下する可能性があります」です

更新の経緯

変更履歴（2026年10月3日に取得した版）と、Internet Archiveの保存版の本文を突き合わせました。

2024年4月6日の保存版（ページの日付は2024年3月18日）：フラグメントとパラメータの書き方の節がありません
2023年7月20日：変更履歴に、利用者の意見を受けて、Google検索がURLでサポートする文字を明確化した、という項目があります。この保存版との突き合わせはしていません
2024年7月5日：変更履歴に、フラグメントの案内の明確化があります。同年10月23日には、URLパラメータの推奨事項の追加があります。どちらも、それまで別の資料にだけ書かれていた内容です。2025年5月25日の保存版（ページの日付は2025年2月4日）には、2つの節が入っています
2025年6月18日：変更履歴に、URL構造の資料の書き直しがあります。流れを整理し、実際のURLに基づく例を加えたもので、挙動の変更は無いとされています
2025年9月1日：ページの日付が変わりました。変更履歴に記載がなく、中身は不明です
2025年12月10日：ページの日付が変わりました。2025年11月15日の保存版と現在の英語版を、段落・箇条書き単位で比べ、差は0件でした。変更履歴にこのページの項目があるのは、上の4件（2023年7月20日、2024年7月5日、2024年10月23日、2025年6月18日）だけです

2025年5月25日の保存版と、2025年11月15日の保存版を比べると、書き直しで次の点が変わっていました。

導入と規格：規格への言及から始まる形が、「要件」を示す形に変わりました。規格の名前も、RFC 3986からIETF STD 66に変わり、ASCII範囲外の文字は「UTF-8でエンコード」から「パーセントエンコード」の表現になりました
大文字と小文字：以前は「サーバーが同じ扱いにしているならそろえる」という対処の1項目でした。現在は「GoogleのURL処理は区別する」と、先に事実を書いています
削除：「ドキュメントの動的な生成」の項目と、robots.txtで正規表現を使えるという一文です
追加：日本語のURL例、アンダースコアを勧めない理由の説明、ファセットナビゲーションの別ページへの案内、壊れた相対リンクをルート相対で直す説明です

2025年6月から9月の保存版は取得できず、上の変更が6月18日のものかは断定できません。

このページから、言えること・言えないこと

言えること	言えないこと
要件を満たさないURL構造は、クロールが非効率になる可能性が高い、と書かれています	URLを直せば順位が上がる。このページは、クロールとインデックス登録の話に絞られています
読者の言語の単語をURLに使うよう勧めています。日本語のURL例も載っています	日本語のURLが英語のURLより有利、または不利。比較は書かれていません
GoogleのURL処理は、大文字と小文字を区別します	大文字のURLを小文字へ転送することが必須。書かれているのは、同じ扱いならどちらかにそろえる、という勧めです
問題のURLについて、robots.txtでのブロックを検討するよう書かれています	ブロックすれば、すでに登録されたURLがインデックスから消える。このページが扱うのはクロールで、削除への言及はありません

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。従業員が数人から数十人で、WordPressのサイトを持つ会社を想定します。

1. 新しい記事のURLを、読める単語とハイフンで決める

WordPressの投稿の編集画面では、右側の設定に、URLの末尾（スラッグ）を直す欄があります。

公開前に、読める単語をハイフンでつないだ形に直しておきます。公開後にURLを変えると、旧URLからの転送を別に設定する必要が生じます。

この点は、このページに書かれていません。

日本語の題名から自動でできるスラッグは、パーセントエンコードされた長い文字列になりがちです。日本語の単語も、ローマ字や英単語も、このページは良し悪しを決めていません。

社内で統一しておくと、迷いません。WordPressの「パーマリンク設定」では、数字のIDだけの形を避けて「投稿名」を選べます。

2. 自社に、パラメータが増える仕組みがあるか確かめる

ブラウザだけで確かめられます。自社サイトの一覧ページで、絞り込み、並べ替え、検索ボックスを1回ずつ操作します。

そのたびに、アドレスバーの末尾に「?」や「&」が現れるかを見ます。現れた形のURLは、クロールの対象になりえます。

次に、「自社のドメイン/robots.txt」をブラウザで開き、該当するURLの拒否の行があるかを見ます。予約システムのカレンダーが未来の月へ際限なくリンクしていないかも、同じ要領で確かめます。

3. 計測用のパラメータを、サイト内のリンクに使わない

このページは、参照元の記録に使うパラメータを、URLを増やす例として挙げています。UTMなど計測用パラメータの名前は出てきません。

ここからは私の読み取りです。計測用パラメータを付けたURLをサイト内のリンクに貼ると、同じページのURLが増えます。

付けるのは、サイトの外に出す広告やメールのリンクだけにするのが無難です。セッションIDがURLに入る仕組みの有無は、制作会社に尋ねれば確認できます。

4. 大文字小文字、相対リンク、フラグメントを点検する

メールやSNSでURLを貼るときは、大文字と小文字を変えないと社内で決めておきます。サーバーの設定しだいで、別の書き方でも同じページが表示され、Googleには別のURLに見えます。

主要なページを1つ開き、ページのソース表示で href="../ を検索します。見つかれば、親ディレクトリ相対のリンクです。

アドレスが「#/」で始まるように、フラグメントでページを切り替える作りは、このページが避けるよう求めています。新規の制作では、制作会社に確かめます。

URLの階層とサイト構造の考え方は、弊社の別の記事「サイト構造の最適化とは？内部リンクとURL階層で検索順位を上げるSEOの基本」にあります。今回の記事は公式ページの解説、あちらは実務の手順という役割です。

弊社のサイトで確かめたこと

2026年10月8日に、kenkyo.aiで外から見えるURLの形を確認しました。Search Consoleの数字は見られないため、実際のクロールの結果は未確認です。

確認	結果
`curl -sL https://kenkyo.ai/robots.txt`	規則は、管理画面のフォルダの拒否が1行と、その中の1ファイルの許可が1行です。ほかの拒否の行は0行でした
トップページと記事2本のHTMLと応答ヘッダーを取得して、href属性を数える	href属性は77個、101個、101個でした。`../` で始まるものは3ページとも0本です。「sessionid」「PHPSESSID」「sid=」を含むものも0本です。応答ヘッダーのSet-Cookieも、3ページとも0件でした
フラグメント（「#」）つきのリンクの種類を見る	料金欄へ飛ぶ「#price」と、コメントの位置を指す「#comment-数字」の2種類だけです。「#/」の形は0本でした
`curl` でパラメータつきのURL（`?utm_source=test&sort=low-to-high`）を取得する	200で返りました。canonical（正規のURLを示すタグ）は、パラメータのないURLを指していました。このページが挙げる対処のrobots.txtとは別の仕組みです
`curl -sI` で、末尾のスラッシュを外したURLを取得する	301で、スラッシュつきのURLへ転送されました
サイトマップの3ファイル（記事2つ、固定ページ1つ）のURLを数える	計1,083本でした。大文字を含むURLは0本、パスが2階層以上のURLも0本です