トピッククラスターを作るときは、記事数やキーワードの一覧から始めません。見込み顧客が最後に答えたい広い問いを決め、その問いへ最も広く答える既存URLを親記事として一つ選びます。親記事だけでは終えられない判断がある場合に限り、その問いを子記事へ分けます。

すでに複数のページがあるなら、新しいURLを作る前に役割を並べます。各ページが受け持つ問いと読後の判断が同じなら重複候補です。公開済みURLはすぐ統合せず、流入やリンクの証拠がそろうまで保留します。

親記事は読者が最後に答えたい広い問いから選びます

親記事の役割は、個別の条件へ入る前に全体の判断を進めることです。関連語を多く含むページや検索ボリュームが大きい語を狙うページが、そのまま親記事になるわけではありません。

まず「誰が何を決めたいのか」を一文にします。次に、その問いへ最も広く答えている既存URLを探します。読者がそのページから必要な個別判断へ進めるなら、本文の長さやURL階層にかかわらず親記事の候補になります。

候補が部分的にしか答えていない場合も、すぐ新しいURLを作る必要はありません。同じ問いを受け持てる既存ページなら、そのURLを書き直すほうが役割を一本化できます。親記事を一つに絞るのは、読者が広い問いへ戻る場所を曖昧にしないためです。

子記事は親記事だけでは終えられない判断へ分けます

子記事には、読み終えた時点で独立した確認や選択が終わる問いを渡します。詳しく書けることや検索語が違うことは、別URLを作る理由になりません。

候補を見つけたら、親記事を読んだだけでは何が決められないかを一文にします。その問いだけを読んだ人がどの判断を終えられるかも定めます。最後に、その結果を親記事の広い問いへどう戻すかを確かめます。

親記事へ数段落を加えるだけで答えきれるなら、子記事として独立させません。個別の条件によって結論が変わり、その判断に固有の根拠が必要なら別URLにする意味が生まれます。

検索語が違っても読後の判断が同じならURLを分けません

表現が異なる二つの検索語でも、同じ人が同じ答えへ着くなら代表URLは一つで足ります。一方の既存ページを残し、必要な内容を追記するか書き直します。Google公式SEOスターターガイドが扱う重複コンテンツは、異なるURLで同じ内容が表示される技術上の状態です。本稿では、同じ問いと完了状態を複数のURLへ渡していないかを見る編集判断と分けて考えます。

親記事へ戻る理由がなければ別のまとまりとして扱います

子記事で終えた判断が親記事の広い問いを進めないなら、そのページは同じまとまりに入れません。語句や技術領域が近いだけでは、読者の経路はつながらないためです。そのページは別の広い問いへ置くか、独立した記事として扱います。見た目の網羅性を優先して囲い込むと、トピッククラスターの境界がかえって分かりにくくなります。

Googleの公式原則とAdRegionの設計手順は別のものです

2026年7月23日に確認した三つのGoogle公式資料では、トピッククラスターや親記事と子記事をランキング標準として定めていません。これはGoogleがこれらの語を一度も使っていないという主張ではありません。本稿が参照する資料から、固定された親子構造や本数を要件として導けないという意味です。

Google公式SEOスターターガイドは、サイトを論理的に整理するとページ同士の関係を理解しやすくなると説明しています。Googleが既知のページからリンクをたどり、新しいページを見つけることも示しています。ただし、配置図を作ること自体は必須要件ではありません。

Googleのリンクに関するベストプラクティスから確認できるのは、解決可能なURLを持つリンクと文脈に合うアンカーテキストの原則です。重要なページへ少なくとも一つの内部リンクを設ける推奨はありますが、理想的なリンク数は示されていません。

有用で信頼性の高いユーザー第一のコンテンツに関する公式資料は、想定する読者とサイトの主な目的を確かめる考え方を示しています。読者が目的を果たせるだけの情報を得られるかという観点も、各URLの役割を考える背景にできます。

ここまでがGoogle公式資料から確認できる原則です。親記事を一つ選び、異なる完了状態だけを子記事へ分ける手順はAdRegion独自の編集判断です。既存URLの処遇やリンクの方向も同じです。この手順をGoogleの規格として扱わず、順位や問い合わせの向上も保証しません。

既存URLを配置図へ並べると重複の境界が見えます

配置図では、すべての候補を同じ軸で比べます。URLごとの問いと読後の判断を横に並べると、名前が似ていても役割が違うページを見分けやすくなります。次の表は2026年7月23日にAdRegionの作業環境で確認した限定例です。各行を自社のURLへ置き換えるときも、受け持つ問いと読後の判断を先に埋めます。

役割実在URL受け持つ問い読後にできる判断現在確認できる内部リンク
親記事/knowledge/ai-agent-cms-workflowAIと人とCMSで一件の記事をどう受け渡すか工程ごとの入力から保存先までを決める本文から四つの子記事へリンク
子記事/knowledge/content-without-mass-production執筆前の企画をどこへ置くか企画の掲載先と保留条件を決める関連記事から親記事と完成原稿レビューへリンク
子記事/knowledge/ai-agent-review-flow完成原稿を次にどう扱うか公開可否と修正先を決める関連記事から親記事と運用規程へリンク
子記事/knowledge/content-governance-basics公開や訂正を誰が決めるか決定者と停止条件を規程へ置く本文から親記事と二つの判断記事へリンク
子記事/knowledge/markdown-article-workflow承認済みMarkdownをどう公開して戻すか公開する版と異常時に戻す版を決める親記事から本文リンク

content-without-mass-productionai-agent-review-flow は、どちらも公開や統合を判断するため重複して見えます。前者が受け取るのは執筆前の問いです。後者が受け取るのは完成原稿なので、判断する時点と次の行動が異なります。

content-governance-basics も公開判断を扱いますが、一件の原稿を判定する記事ではありません。組織として誰が決めるかを継続的な規程へ置く記事です。受け取るものと読後の判断を比べれば、三つのURLを分ける理由が見えてきます。

この配置図で確認したのは役割とリンクだけです

この例で確認できたのは、各slugのMarkdownが存在し、別の問いと完了状態を持つことです。親記事から子記事へのリンクと一部の戻り先もソース上で確認しました。公開側の変換処理がMarkdownリンクを <a href> へ変えることも確認済みです。ただし、本番HTMLの出力とHTTP応答や実際の到達は確認していません。

検索順位や検索流入は測定していません。表示回数とクリックの変化も未確認です。問い合わせへの寄与や被リンクの効果も確かめていません。この表は成果事例ではなく、作業環境で役割とリンクを確認できた配置図の例です。

内部リンクは次の判断が必要になる文脈からつなぎます

内部リンクの方向は、親子関係の形ではなく読者の次の判断で決めます。すべての親記事と子記事を機械的に往復させる必要はありません。Googleのリンクに関するベストプラクティスに沿い、本文リンクは解決可能なURLを持つ <a href> として出力します。公開前にはアンカーテキストと実際の到達先も確かめます。

親記事から子記事へは答えが条件で分かれる箇所からつなぎます

親記事で個別の条件によって結論が変わる箇所には、子記事へ進む理由があります。関連ページを末尾にまとめるだけでなく、その判断が必要になった本文からつなぎます。たとえば記事制作の全体工程を読んでいる人が、完成原稿を公開してよいか迷う箇所でレビュー記事を案内します。リンク先で何を判断できるかが分かれば、読者は必要なときだけ深く進めます。

子記事からは広い判断へ戻る必要があるときにつなぎます

子記事で一つの確認を終えた後、その結果を全体の判断へ戻す必要があるなら親記事へつなぎます。相談できる範囲を確かめる段階へ進んだ人には、サービスページが次の行き先になる場合もあります。相互リンクそのものを目的にすると、読者が使わない往復が増えます。配置図では方向と理由まで決め、段落内の位置や文言は内部リンクを設計する工程で詰めます。

重複候補は新しい記事を足さず既存URLの処遇を決めます

同じ問いと読後の判断を持つURLが見つかったら、新しい記事を加えて違いを作ろうとしません。どのURLを代表として残すかを先に考えます。

まだ公開していない候補なら、同じ完了状態を一つのURLへまとめます。役割は必要でも答えが不足しているページは、既存URLのまま書き直します。異なる判断を終えられるなら、境界を明記して別々に残します。

公開済みURLを統合する場合は、内容の近さだけで決められません。まずSearch Consoleで流入クエリとURLごとの実績を確認します。次に外部サイトから受けているリンクを調べます。サイト内の導線と問い合わせへの寄与も確かめてから移行先を決めます。

観測期間や表示回数が足りないページを、需要がないと断定することはできません。証拠が不足していれば処遇を保留します。統合すると決めた後のリダイレクトやcanonicalは別の実装工程です。

配置図を作る前後の工程を混ぜないようにします

この配置図が受け取るのは、検索者の問いと代表URLの候補がすでに分かれている状態です。候補語から問いを作る作業は検索意図マップの作り方が担当します。

本稿で決めるのは親記事と子記事の役割です。既存URLの処遇とリンクの方向が決まれば、配置図としての作業は終わります。リンクを置く段落と文言は内部リンク設計の記事へ渡します。

記事から相談判断へつなぐ場合も、サービスページの本文構成までは配置図へ含めません。その設計はサービスページのSEO設計で扱います。支援範囲を確かめる必要がある人だけがSEOサイト構築へ進めるようにします。

配置図ができたら一人の読者がたどれるか確かめます

最後に見るのは、図が整っているかではなく一人の読者が判断を進められるかです。親記事から必要な子記事を選び、個別の判断を終えて広い問いへ戻れる経路をたどります。

途中で読む理由が分からないリンクに出会ったら、リンクを増やす前にページの役割を見直します。子記事を読んでも何も決められないなら、その問いは親記事へ戻したほうがよいかもしれません。

自社で着手するときは、見込み顧客が最後に答えたい広い問いを一つだけ選びます。その問いへ最も広く答える既存URLを配置図の最初の行へ置いてください。次の行には、親記事だけでは終えられない判断を持つURLだけが残ります。