URLを単なるルーティング設定として扱うチームは少なくありません。しかしAIエンジンは、URLもテキスト情報として読み取り、ページのテーマや引用に値するかを判断する手がかりにします。繁体字中国語サイトでは、さらに「スラッグを中国語にするか、英語にするか」という判断も必要です。本記事では、パスとスラッグを分けて整理し、すぐに見直せる設計方法を解説します。
AIエンジンはURLをどう「読む」のか
LLMの検索システムは、URLを単語に分解して意味を捉え、回答を生成して出典を示す際にも表示します。たとえば /blog/url-structure-llm-friendly なら、「URL構造についてのページ」だとモデルに直接伝えられます。一方、/p?id=48213 からは何の手がかりも得られず、ページ本文だけを頼りに内容を推測することになります。条件の似た情報源が並んだとき、内容との関連性が高く、人が読んでも意味のわかるURLは、モデルとユーザー双方の解釈負荷を下げるため、引用候補に選ばれやすくなります。
パスの階層も、それ自体が文脈を伝えます。/geo-audit/pricing なら、GEO監査サービスの料金ページだとひと目でわかり、モデルもそのページが属するテーマを把握できます。ただし、階層を深くしすぎると別の問題が生じます。トップページから遠く、内部リンクも少ないページほどクローラーに見落とされやすくなり、発見されていないコンテンツをAIエンジンが取得することもできません。URLの読みやすさとクロール可能性は別の要素ですが、どちらもURL構造に支えられています。
繁体字中国語スラッグの難点：漢字は長いエンコード文字列になる
URLに漢字を入れると、ブラウザやサーバーではパーセントエンコードされます。たとえば /blog/URL構造設計 は、保存・共有・参照される際に /%E9%83%A8%E8%90%BD%E6%A0%BC/… のような長い文字列になります。アドレスバーでは中国語に見えていても、実際に送信されるのはエンコード文字列です。AIの要約、SNSなどのリンクカード、管理画面のレポートにもこの文字列が渡るため、本来期待していた意味上のメリットが失われます。さらに、一部の外部ツールやAIクローラーはエンコードURLの処理が安定せず、途中で切れたり、正しく解析できなかったりする場合があります。
- 中国語スラッグ（例：/blog/URL構造設計）：アドレスバーではわかりやすく見えますが、送信・引用時には %E9%83%A8... のようなパーセントエンコードになります。AIの要約、共有リンク、レポート上では内容を判別しにくくなります。
- 英語またはローマ字のスラッグ（例：/blog/url-structure-llm-friendly）：システムをまたいでも安定し、人が読んで意味を理解でき、AIにもそのまま引用されやすい形式です。B2B SaaSサイトでは現実的な第一候補になります。
- タイトルは繁体字中国語、スラッグは簡潔な英語にする：現時点でAI検索に最も安定した組み合わせです。タイトル全体を英訳する必要はなく、中心概念を表す2〜3語の英単語で十分です。
もちろん、繁体字中国語を使うべき場所まで減らす必要はありません。ページタイトル、H1、本文は引き続き繁体字中国語で作成し、検索評価と読者体験の中心に据えます。スラッグはあくまで基盤の一部なので、テーマの核だけを簡潔に表せば十分です。また、URLはすべて小文字に統一します。サーバーによっては /Blog と /blog を別ページとして扱うため、大文字と小文字が混在すると、気づかないうちに重複URLが生まれます。すでに長期間インデックスされている中国語スラッグは、慌てて一括変更してはいけません。改修時には、必ず301リダイレクトで旧URLから引き継いでください。
そのまま実践できる、AIフレンドリーなパス設計の原則
- 階層は浅いほどよい：主要コンテンツは2〜3階層以内（/blog/<slug>）を目安にします。階層が増えるほど、発見やクロールから漏れるリスクが高まります。
- スラッグで内容を伝える：連番や日付ではなく、コンテンツのテーマを表す単語を使います。/blog/2026/07/post-482 よりも /blog/url-structure-llm-friendly が適切です。
- サイト全体で形式を統一する：同じ種類のコンテンツには同じパス形式を使い、クローラーやモデルが構造を予測できるようにします。
- 小文字とハイフンを使う：すべて小文字にし、単語の区切りにはアンダースコア「_」ではなくハイフン「-」を使います。大文字・小文字や記号の違いによる重複URLを防げます。
- 主要コンテンツをクエリパラメータの配下に置かない：?id= や ?p= を含むURLは、安定したインデックスや参照が難しくなります。
- 公開後のURLは安易に変えない：変更が必要な場合は、必ず301リダイレクトを設定し、旧URLに蓄積された評価と引用を引き継ぎます。
コンテンツクラスターに合わせてパス構造を設計する
ピラー、クラスター、サブトピックの関係をサイト内の内部リンクに反映すると、AIエンジンは、どのテーマについて情報の厚みがあるのかを判断しやすくなります。同じピラーに属する記事同士をつなぎ、それぞれからピラーページへリンクすれば、単発の記事が散在しているのではなく、体系的なコンテンツ群であることがモデルにも伝わります。クラスターページとサブトピックの記事を双方向で結ぶことで、モデルは孤立した1ページだけでなく、リンクをたどってテーマ全体を読み取りやすくなります。内部リンクが適切に設計されていれば、URLをクラスター単位で階層化するかどうかは二次的な問題です。
繁体字中国語サイトの多言語対応：言語プレフィックスとhreflang
多くのB2Bサイトのように複数言語で情報を提供するなら、/zh-TW/blog/… や /en/blog/… のように、パスの先頭へ言語プレフィックスを置きます。どの言語版かをひと目で識別でき、クローラーも言語ごとに処理しやすくなります。各言語版には相互にhreflangを設定し、デフォルトとしてx-defaultも指定してください。これにより、AIエンジンと検索エンジンが適切な相手に適切な言語版を提示しやすくなり、各ページが重複コンテンツとして扱われ、互いの評価を薄める事態を防げます。
- 言語プレフィックスはパスの先頭に置く：/zh-TW/blog/...、/en/blog/... のようにすると、言語をひと目で識別でき、クローラーも言語別に処理しやすくなります。
- 各言語版にhreflangを相互設定し、デフォルトとしてx-defaultを指定する（繁体字中国語サイトでは、英語版またはzh-Hantをデフォルトにすることがよくあります）。
- 各言語版では、できるだけ同じスラッグを使う：翻訳するのはコンテンツであり、パスではありません。対応関係が明確になり、重複コンテンツと判断されにくくなります。
陥りやすいURL設計の落とし穴
よくある失敗は、公開日をパスに入れて半年後には古い記事に見えてしまうこと、データベースの連番をスラッグにしてモデルがテーマを読み取れなくなること、タイトル変更時にリダイレクトを設定せずスラッグも変え、蓄積された参照を一度に失うことです。同じページに末尾スラッシュの有無やwwwの有無による複数のURLが存在し、クローラーから別ページとして数えられるケースもあります。どれも修正自体は難しくありませんが、放置すればAIに引用される可能性を継続的に薄めてしまいます。
URL構造は、最初に正しく設計すれば長期にわたって効果が続く基盤です。AI対策のために、サイト全体を作り直す必要はありません。多くの場合、スラッグに意味を持たせ、パスを浅くし、多言語版へhreflangを設定し、旧URLを301リダイレクトで適切に処理するだけでも差が生まれます。自社サイトのクロール可能性や引用されやすさに、どのような課題があるかを把握したい場合は、Tenten GEOの30日間GEO監査で、パス、構造化データ、検索パフォーマンスをページ単位で棚卸しできます。まず方向性を確認したい方は、/contact から30分間のGEO診断をご予約ください。貴社のサイト構造を具体的に確認しながらお話しします。
