コンテンツクラスターとパンくずプロトコル
トポロジーの問題
3つのウェブサイト。shawnos.ai、thegtmos.ai、thecontentos.ai。それぞれが独自のコンテンツを持っている。ブログ記事、ナレッジ用語、ハウツーガイド、Wiki記事。個々には堅実だ。しかし、検索エンジンやAIプラットフォームは個別のページを見ない - グラフを見る。そして明示的なエッジのないグラフは、ただの切断されたノードの集合にすぎない。
問題は、どんなコンテンツを持っているか、ではない。コンテンツがどう接続されているか、だ。
ハブ・アンド・スポーク
トポロジーはハブ・アンド・スポーク型だ。1つの親コンセプト -「AIで構築する」- から、3つの専門的な垂直領域が分岐する。
shawnos.aiがハブだ。ビルダーの個人ブランド。システム構築プロセスそのもの。
thegtmos.aiがスポーク1。GTMワークフロー、パートナープレイブック、アウトリーチ自動化。ハブのツールキットが生み出すGTMシステム。
thecontentos.aiがスポーク2。コンテンツメソドロジー、ボイスDNA、AIアシステッドライティング。ハブが実証するコンテンツパイプラインとメソドロジー。
再帰的な構造こそが要点だ。システムを構築する行為こそがshawnosのコンテンツだ。システムが生み出すGTMワークフローこそがgtmosのコンテンツだ。システムでコンテンツを作るメソドロジーこそがcontentosのコンテンツだ。各サイトのコンテンツが、他の2サイトの命題を証明する。
taxonomy.yaml
トポロジーはwebsite/taxonomy.yamlで定義されている。誰かの頭の中ではなく。Notionドキュメントでもなく。マシンが読めるバージョン管理されたYAMLファイルに。
このファイルはすべてのコンテンツピラーをドメインにマッピングする：
- building-sharing → shawnos
- plays-series → gtmos
- skill-system-shares → gtmos
- release-reactions → shawnos
- newsletter-editorial → shawnos
- newsletter-growth → contentos
- reddit-growth-seo → contentos
ルーティングルールは明示的だ。パーソナルストーリーはshawnosへ。GTMシステムはgtmosへ。コンテンツ戦略はcontentosへ。ドメインをまたぐ投稿にはプライマリドメインと兄弟サイトへのクロスリンクが付く。
パンくずプロトコル
ウェブサイトのパンくずリストは通常、後付けだ。ホーム > ブログ > 投稿タイトル。基本的な階層構造。このシステムのパンくずプロトコルは異なる - 前方参照型のクロスサイトナビゲーションシステムだ。
すべてのページがトポロジー内の自分の位置を知っている。shawnosのハウツーガイドは、自分がgeo-seoカテゴリに属していることを知っている。gtmosに関連ガイドが存在することも知っている。パンくずスキーママークアップ（JSON-LDのBreadcrumbList）がこの階層を検索エンジンに伝える。
しかし重要なのは前方参照の部分だ。新しいハウツーエントリがcanonicalSite: 'gtmos'を持つとき、thegtmos.aiでネイティブにレンダリングされ、shawnos.aiからのリダイレクトが作成される。gtmosのパンくずはGTMOS > How-To > Content Cluster Strategyと表示される。shawnosのリダイレクトは、このコンテンツがハブではなくスポークに存在することを検索エンジンに伝える。
これは意図的なトポロジーだ。単なるナビゲーションではない。
データレイヤー
クロスサイトリンキングアーキテクチャは、website/packages/shared/data/にある3つのTypeScriptデータファイルに存在する：
how-to-wiki.ts - すべてのエントリがcanonicalSiteフィールドとrelated配列を持つ。canonicalSiteがどのドメインでページをレンダリングするかを決定する。related配列が他のエントリへの双方向リンクを作成する。
engineering-terms.ts - 他の用語にリンクするrelated配列を持つナレッジ用語。プログラマティックな内部リンクが、用語のすべての言及をその定義ページに自動的に接続する。
content-wiki.ts - ContentOS用のWikiエントリ。独自のrelated配列を持つ。
related配列がコンテンツグラフのエッジだ。関連リンク付きの新しいエントリを追加するたびに、エッジを追加している。既存のエントリが新しいエントリへのバックリンクを追加するたびに、エッジを双方向にしている。行き止まりなし。孤児なし。
Canonicalルーティング
ハウツーエントリのcanonicalSiteフィールドが、クロスサイトコンテンツ配置のメカニズムだ。エントリがcanonicalSite: 'gtmos'を持つとき、shawnos.aiのハウツーページはthegtmos.ai/how-to/[slug]へのリダイレクトを生成する。gtmosサイトは@shawnos/sharedから同じデータをインポートしてネイティブにレンダリングする。
1つのデータファイル。3つのサイト。自動ルーティング。モノレポだからこそシームレスに実現できる。3つのサイトすべてが同じパッケージを共有しているからだ。APIコールもコンテンツ同期もCMSレプリケーションもない。1つのTypeScriptインポートだ。
なぜクラスターがAI引用に重要なのか
AIエンジンは個別のページだけをインデックスするのではない。トピカルオーソリティを評価する。あるトピックについて包括的にカバーしているサイト - 複数のページがクロスリンクし、異なるコンテンツタイプが異なる角度をカバーしている - は、優先的に引用される。
トピッククラスターはこれの明示的なバージョンだ。1つのピラーページが広いトピックをカバーする。サポートするクラスターページがサブトピックを深掘りする。すべてがクロスリンクする。クラスターはAIエンジンに「このサイトはこのテーマを所有している」というシグナルを送る。
3サイトアーキテクチャがこれを増幅する。shawnos、gtmos、contentosがそれぞれの垂直領域でオーソリティを構築する。クロスサイトリンクが垂直領域を接続する。sameAsスキーママークアップが、この3つのサイトが1つのエンティティを表すことを検索エンジンに伝える。クラスターは1つのサイト内にとどまらない - ネットワーク全体に広がる。
複利効果
新しいコンテンツが加わるたびにクラスターが強化される。新しいナレッジ用語は定義ページを持ち、RSSフィードに表示され、スキーママークアップが付き、それに言及するすべてのページからのプログラマティックな内部リンクに利用可能になる。新しいハウツーガイドは関連用語、関連ガイド、関連Wikiエントリにリンクし、グラフに新しいエッジを作り出す。
SQLiteコンテンツインデックスがすべてを追跡する。taxonomyがルーティングする。パンくずがナビゲートする。スキーママークアップが記述する。そしてすべてのピースがバージョン管理されたファイル内のTypeScriptデータオブジェクトだ。
このシステムはコンテンツを保持するだけではない。コンテンツアーキテクチャそのものだ。
$ cat website/taxonomy.yaml | head -20