SEOのサイト構造とURL設計

サイトの構造は、1つのテーマにハブを1枚立て、その下に記事を束ねる形に寄せます。束ね先の無い記事は、増やすほど孤立します。 URLは内容が分かる英小文字とハイフンで短く付け、一度決めたら変えないのが原則です。変えるなら301と対応表が要ります。 この章は、ハブと記事の分け方・URLの決め方・内部リンクとパンくず・構造化データを順に並べ、10項目の点検リストで構造の合否を出すための章です。

この章で分かること

• トピッククラスタ（ハブとスポーク）の作り方と、当社サイトでの実装
• URLの決め方。Googleが公表しているURL構造のベストプラクティスと、変えるときの6手順
• 内部リンク・パンくず・構造化データ（Organization／BreadcrumbList／Article）の入れ方

ページを3種類に分ける

まず、サイトの中のページを3つに分けます。役割が違うので、狙う語も本数の考え方も違います。

種類	役割	狙う語（4章の分類）	本数の考え方
サービスページ	売る。問い合わせの着地点	Do	売りたいもの1つにつき、ちょうど1枚
ハブページ	テーマの入口。記事を束ねる	テーマそのものの語	テーマにつき1枚
記事	個別の疑問に答える	Know	テーマにつき、答えられる疑問の数だけ

記事を書き始める前に、ハブとサービスページが1枚ずつあることを確かめます。 記事だけが増えて束ね先が無い状態が、最も多い形です。

トピッククラスタ（ハブとスポーク）

ハブがテーマの入口、スポークがそのテーマの記事です。次の3方向のリンクが全部揃って、初めてこの形になります。

1. ハブ → 各記事（一覧）
2. 各記事 → ハブ（パンくずで自動的に張る）
3. 記事 → 同じテーマの関連記事

当社サイトの実装

誰でも開いて確認できる範囲で書きます。

• テーマは6つ。/kintone・/jichitai・/real-estate・/ai・/chusho・/recruit。それぞれがハブです
• 各テーマの下に一覧（/kintone/blog）と記事（/kintone/blog/kintone-mitsumori-souba）を置いています
• 記事は119本あります。どの記事がどのテーマに属するかは、ファイル名の接頭辞で機械的に決めています（kintone- で始まる記事は /kintone/ の下）。人が手で振り分けると、記事が増えたところで必ずずれるためです
• 集客サービスの入口は /marketing。その下に /services/seo・/services/aio・/services/meo などのサービスページを並べています
• この教科書自体も同じ形です。 /textbook がシリーズ全体のハブ、/marketing/textbook がこの本、/marketing/textbook/03-keisoku が章です

1テーマあたり何本書くか。 本数の基準はGoogleから公表されていません。当社の判断は「ハブ1枚＋そのテーマで自社が答えられる疑問の数だけ」です。書くことが無くなったら止めます。 本数を目標にすると薄いページが増え、7章の統合作業が増えるだけです。

URLの決め方

Googleは検索セントラルで、URL構造のベストプラクティスを公表しています（URL構造のベストプラクティス）。ここは推測ではなく、書いてあることです。

公表されていること	具体
長いID番号ではなく、意味のある単語を使う	/kintone/blog/kintone-mitsumori-souba ／ ×/p?id=8821
単語の区切りはアンダースコアではなくハイフン	kintone-mitsumori-souba ／ ×kintone_mitsumori_souba
不要なパラメータを削って短くする	セッションIDをURLに入れない。Cookieを使う
非ASCII文字はパーセントエンコーディングする	日本語URLは自動でエンコードされ、長く読みにくくなります

ここに、自分で決める3つを足します。どれも正解が公表されていないので、決めて統一することが合格ラインです。

決めること	当社の決め方	理由
階層の深さ	3階層まで（/テーマ/blog/記事）	トップから3クリック以内にするため（2章の工程8）
日付を入れるか	入れない	更新しても古く見えない。年をまたいで移動しなくて済む
末尾スラッシュ	付けない（サイト全体で統一）	canonical と構造化データのURLを完全に一致させるため

一度決めたら変えません。 URLを変えるということは、そのURLに付いていた外部からのリンクと、Googleが持っている評価の引き継ぎを、301でやり直すということです。見た目をきれいにするためだけに変えるものではありません。

変えるときの6手順

#	手順	落とし穴
1	旧URL → 新URL の対応表を全件作る	1行でも漏らすと、そのページだけ消えます
2	旧URLから新URLへ301（恒久的な移動）を設定する	302（一時的）を使わない
3	サイト内のリンクを新URLに書き換える	301任せにしない
4	サイトマップから旧URLを消し、新URLだけを載せる	旧URLを残すと「両方読んで」と言っていることになります
5	Search Console でサイトマップを再送信し、URL検査で新URLを確認
6	30日後・90日後に確認する	旧URLのインデックスが消えたか／新URLの表示回数が元の水準に戻ったか

当社は旧 /blog/<slug> から /テーマ/blog/<slug> へ移したとき、301の対応表をコード側で自動生成し、サイトマップには新URLだけを出しています。

内部リンク

1本ずつ手で管理すると、記事が増えたところで必ず切れます。ルールにして、自動で張ります。

張る場所	ルール	当社の実装
記事 → ハブ	全記事に必ず1本	パンくずで自動的に入る
ハブ → 記事	新しい順に一覧	/kintone/blog が一覧ページ
記事 → 記事	同じテーマの関連記事を3本	記事の属性から自動で選ぶ
記事 → サービスページ	そのテーマのサービスへ1本以上	記事末尾に固定で置く

合格ラインは2章の工程8と同じです。 重要ページがトップから3クリック以内、内部リンクが0のページが無い、内部リンク数の上位に売りたいページが並んでいる。

リンクの文字（アンカーテキスト）は、リンク先の内容を表す言葉にします。「詳しくはこちら」だけのリンクは、リンク先が何のページかを伝えていません。

パンくず

全ページに置きます。役割は2つです。

1. 人が「今どこにいるか」を分かる
2. BreadcrumbList の構造化データにすると、検索結果のURL部分にパンくずが表示される（Googleが対応を公表しているリッチリザルトの1つです）

構造化データは3つだけ入れる

2章で書いたとおり、構造化データを入れると順位が上がるという公表はありません。 効くのは、対応するリッチリザルトの対象になることと、会社の実体を機械が読める形で1か所に確定させることです。入れるのは3つで足ります。

種類	どこに	何を書くか	目的
Organization	サイト全体（トップ）	社名・所在地・URL・ロゴ・法人番号・代表者・外部の公的データベースへのリンク	会社を1つのものとして確定させる
BreadcrumbList	全ページ	トップからの階層	検索結果にパンくずを出す
Article	記事	タイトル・説明・公開日・更新日・著者・発行者	誰がいつ書いたかを機械が読める形にする

当社の実装

構造化データの生成は1ファイル（schema.ts）にまとめています。ページごとに手で書くと、必ずずれるためです。

• Organization に法人番号を入れ、sameAs にgBizINFO と国税庁の法人番号公表サイトへのリンクを置いています。第三者が確認できる場所と結び付けるのが目的です
• 代表者を Person として別に定義し、@id で Organization から参照しています。記事の著者も同じ @id を指します。同じ会社・同じ人物を、サイト中で1つのIDにまとめるためです
• 記事の Article には isPartOf を付け、その記事がどのテーマの一覧に属するかを書いています。ハブと記事の関係を、リンクだけでなく構造化データでも示す形です

必須は、書いてある内容が画面の表示と一致していることです。 不一致はスパムポリシー違反です（2章）。

重複と canonical

構造の最後は、同じ内容が2つのURLで開けない状態にすることです。

起きやすい形	直し方
www有無・http/https が両方開ける	301で1つに寄せる（2章の工程1）
末尾スラッシュ有無が両方開ける	サイト全体でどちらかに統一する
?utm_source= 付きが別ページ扱いになる	canonical をパラメータ無しの自分自身に向ける
同じ記事が複数カテゴリの下で開ける	記事のURLを1つに決める。カテゴリ違いのURLを作らない
旧URLと新URLが両方開ける	旧URLは301にする（両方が200を返さない）

canonical はGoogleにとって命令ではなくヒントです（2章）。最終的な解決は、1つの内容が1つのURLでしか開けない状態にすることです。

サイトマップは構造から自動生成する

サイトマップは手で書きません。ページの一覧データから組み立てます。

当社の sitemap.ts の作りは次のとおりです。

• 固定ページ・テーマのハブ・サービスページ・記事・教科書の章・プラグインを、それぞれの一覧データから組み立てている（ページを1枚足せば、サイトマップにも自動で載ります）
• 記事は新URLだけを出す。旧 /blog/<slug> は301で飛ぶので載せない
• 公開予定日が未来の記事は出さない。 サイトマップを1時間ごとに作り直しているので、予約した日が来れば自動で載ります
• 公開済みのものだけ出す（プラグインが0本なら、その一覧ページも出さない）
• lastmod には、実際に更新した日を入れる（全ページ「今日」にしない。2章の工程4）

合格ラインは2章の工程4と同じです。ステータス「成功」、エラー0、検出URL数が公開ページ数と±10%以内。

よくある間違い5つ

1. ハブを作らずに記事だけ増やす 束ね先が無いので、記事が孤立し、トップから3クリック以内に入りません。直し方：テーマごとに1枚ハブを立て、パンくずと記事末尾から必ずリンクする。記事を書く前にハブを作ります。

2. URLを後から「きれいにする」 評価の引き継ぎをやり直す作業が発生します。直し方：変えると決めたなら、対応表 → 301 → サイト内リンクの書き換え → サイトマップ更新 → 再送信 → 30日後・90日後の確認、までを1セットでやる。やり切れないなら変えません。

3. カテゴリやタグを増やし、同じ記事が何本ものURLで開けるようにする 自社の中で重複を量産しています。直し方：記事のURLは1つに固定し、カテゴリは一覧ページへのリンクとしてだけ使う。タグの一覧ページは作らない（作るなら noindex にする）。

4. 構造化データを「順位が上がる」と思って何種類も入れる 入れるほど、画面表示との不一致が増えます。直し方：Organization・BreadcrumbList・Article の3つに絞り、画面と一致させる。FAQ と HowTo は2026年9月時点で検索ギャラリーに載っていないので、出る前提では扱いません（2章）。

5. サイトマップを手で書く 更新漏れが必ず起きます。直し方：ページの一覧データから生成する仕組みに寄せる。それができないCMSなら自動生成の機能を使い、noindex のページと404が混ざっていないかを月1回見ます。

この章の出口

手元に残っているべきものは3つです。

1. ページの一覧表（種類＝サービス／ハブ／記事、URL、属するテーマ）
2. URLの命名ルールを書いた1枚（階層・区切り・日付の有無・末尾スラッシュ）
3. 構造化データ3種類が入り、リッチリザルトテストでエラー0の状態

ここまでで、置き場所が決まりました。次は、その1枚をどう書くかです。

次の章へ：6章 SEOのページの書き方｜タイトル・見出し・本文