Codexにページをつなげさせる ── すべての新しい記事に役割を持たせる
Codexを使って孤立したページを有用なトピックシステムに変換します：ページの役割を定義し、文脈に応じた内部リンクを提案し、すべての新しいページに読者の旅を与えます。
ページは有用な場所につながるべき
最初のトラフィックページには、クリックを得る以上の役割が必要です：読者が続け、比較し、変換し、検証するのを助けること。内部リンクがその経路を作ります。
完了の定義： 追加、削除、または後で作成する文脈に応じたリンクの承認済みリストを含む小さなトピックマップ。
45分を確保してください。 5〜15の関連URLまたは下書き、トラフィックミッション、最初のトラフィックページ引き継ぎを持参。ドメイン全体ではなく、1つの顧客問題から始めます。
Codexにページインベントリを渡す
トラフィックミッション、最初のトラフィックページ、これらのURLまたはローカルファイルを
読んでください：[リスト]。トピックシステムマップを作成：各ページの訪問者の役割、
ハブまたはコンバージョンページ、3〜8の文脈に応じたリンク提案、提案されたアンカーテキストの意味、
孤立/重複の警告。目的地が読者の次の決定を助ける場合のみリンク。編集しない、リンクを追加しない、
ページを発明しない。最初に小さなインベントリを作成する
最初のトピックシステムにクローラーは必要ありません。5〜15の関連ページまたは下書きのテーブルを作成します：
url_or_draft,title,current_visitor_job,primary_question,next_action,confirmed新しいサイトでは、計画されたURLを使用します。既存サイトでは、ドメイン全体ではなく1つのトピックから始めます。目的は、サイト全体で何かを自動化する前に、有用な読者の旅を接続することです。
読者の旅を明らかにするインベントリを構築する
記帳の例では、最初のインベントリはわずか4行かもしれません：
URLまたは下書き | 現在の役割 | 主な質問 | 次のアクション | 証拠ステータス |
|---|---|---|---|---|
/before-self-assessment-bookkeeping-checklist | デザイナーが記録を準備するのを助ける | 何を集めるべきか？ | サービス適合性を確認 | 承認された下書き |
/bookkeeping-for-designers | 月次サービス適合性を説明 | このサービスは私のためか？ | ディスカバリーコールを予約 | 既存ページ、レビューが必要 |
/how-it-works | オンボーディングの不確実性を減らす | 連絡後に何が起こるか？ | 予約またはサービスページに戻る | 計画されたページ |
/contact | 資格のある訪問者に行動させる | どうやって返信を得るか？ | フォームを送信 | オーナー確認が必要 |
これはすでにトピックシステムです。100のURLは必要ありません。各行に異なる決定があり、各決定が次のリンクに存在理由を与えます。
すべてのリンクに読者の理由を与える
各提案は答える必要があります：ソース読者がどこでより多くの助けを必要としているか、目的地がどの決定を助けるか、どの表現が正直に説明するか、到着後に何が起こるか？
提案された各内部リンクについて、リンク前のソース文、提案されたリンクフレーズ、
宛先URL/下書き、読者の理由、リンクが無理に感じられる場合のリスクノートを示してください。
明確な読者の理由のないリンクは拒否してください。良い：期限チェックリストは、専門家の助けがいつ有用かを説明した後、記帳サービスページにリンクします。悪い：すべてのページがキーワード密集のアンカーですべてのページにリンクします。
文脈の中で提案を検査する
リンク提案にはソース文全体を含める必要があります。これらを比較します：
弱いソース：デザイナー向け記帳についてもっと学ぶ。
弱いアンカー：デザイナー向け記帳。
理由：SEO内部リンク。有用なソース：このチェックリストの記録が毎月積み上がっているなら、ディスカバリーコールが
価値があるか決定する前に、フリーランスデザイナー向けの月次記帳に何が含まれるか確認してください。
有用なアンカー：フリーランスデザイナー向けの月次記帳に何が含まれるか。
理由：読者はサービス適合ページが次の決定に役立つ地点に到達した。2番目のバージョンはキーワードを押すために存在しません。なぜ目的地が今関連しているかを読者に伝えます。
Codexが一般的なフッターのようなリンクリストを提案する場合は、この修復プロンプトを使用します：
ソース文、読者の決定、その決定を解決する目的地のないすべての提案を拒否してください。
このトピックマップで8つ以下のリンクにしてください。同じアンカーテキストを再利用したり、
サイト全体の挿入を推奨したりしないでください。読者のニーズでリンクを承認する
各提案について尋ねます：このセクションを読み終えた読者は、本当にその次のページを望むか？そうでなければ拒否します。次にCodexに、サイト全体の自動リンク挿入ではなく、レビュー可能なページ差分を求めます。
リンクを1ページずつ適用します。サイト全体に同じアンカーを追加するスクリプトを実行しないでください。マップが欠落した役割を明らかにした場合、missing proof または missing decision page として記録します。自動的に作成しないでください。
レビュー可能なリンクシートを作成する
マップを承認した後、Codexに小さな変更シートを求めます：
承認されたトピックシステムマップを読んでください。承認された各リンクについて、ソース
URLまたはファイル、現在のソース文、提案された改訂文、アンカーテキスト、目的地、
読者の理由、目的地がライブかどうかのチェックを提供してください。ファイルを編集しない、
リンクを挿入しない、ナビゲーションを変更しない、ページを作成しない、何も公開しない。ソースページを一度に1つレビューします。読者がするように目的地を開きます。暗示された次の質問に答えなければ、リンクを拒否します。目的地が存在しない場合は、ソース文をリンクなしのままにし、欠落したページを空のURLではなく将来の決定として記録します。
一般的なマップの失敗をトラブルシューティングする
すべてがホームページを指している。 インベントリには明確なサービス、製品、決定ページがおそらくない。リンクを強制する前に欠落した役割を追加します。
すべての記事がすべての記事にリンク。 各特定のセクションの後に読者がどのリンクを選ぶか尋ねます。それを保持し、残りを削除します。
同じアンカーがどこでも繰り返される。 読者がクリックする理由の周りに文を書き直します。自然なバリエーションは類義語の回転ではなく、異なる文脈から来ます。
マップを小さな読者の経路に変える
編集を要求する前に、矢印で最初のバージョンを描きます：
チェックリストの質問
-> 読者が助けを必要とするときのサービス適合ページ
-> 読者がプロセスの詳細を必要とするときのhow-it-worksページ
-> 彼らが行動する準備ができたときのみの連絡ページ矢印はサイトの階層ではなく読者の選択を説明します。サービス適合ページの読者は、準備ができていない場合チェックリストに戻る必要があるかもしれません。そのリンクは有用です。連絡ページからすべてのガイドへのリンクは通常そうではありません。
各矢印について、停止条件を書きます。チェックリストからサービスへの矢印は、サービスページが範囲を述べていないか、予約アクションが壊れている場合に停止します。how-it-worksの矢印は、ページが計画のみの場合に停止します。これにより、読者が今日実際に使用できるものについてマップが正直になります。
スプレッドシートだけでなく、リリース後にリンクを確認する
承認された編集者または開発者がリンクを追加した後、デスクトップとモバイルでソースと宛先を開きます。宛先が読み込まれること、アンカーが文で意味をなすこと、宛先が暗示された質問に答えることを確認します。topic-map-links.md にソースURL、宛先URL、日付、レビュアーを記録します。内部リンクが時代遅れのページを指している場合は、同じレビュープロセスで削除します。デフォルトでホームページに置き換えないでください。
新しいサイトと既存サイトが同じ方法を使用する方法
新しいサイトは計画されたページパスでマップを作成できます。構築されていないパスはすべて PLANNED とマークし、ライブとはしないでください。実際に公開されたページ間でのみリンクし、将来の矢印は目的地が準備できるまでマップに保持します。これにより、ブループリントが野心的だったという理由だけで、壊れた内部リンクで新しいサイトが立ち上がるのを防ぎます。
既存サイトは、ナビゲーションが正しいと仮定するのではなく、現在のページをリストすることから始めます。サービスページにはすでに20のリンクがあるかもしれませんが、ページ上の質問で読者を助けるものは1つもないかもしれません。同じインベントリ列を使用し、一度に1つの悪いリンクを置き換えるか削除します。単一のトピックマップ演習からグローバルメニューを再設計しないでください。
承認後にのみファイルまたはCMS固有の引き継ぎを求める
ソースと宛先が明確になったら、Codexに正確な実装リクエストを準備させることができます：
承認されたリンクシートを使用してください。リポジトリの場合は、何かを変更する前に正確な
ページファイルと提案された行レベルの編集をリストしてください。CMSの場合は、ソース文と
宛先URLを含むコピー/貼り付け手順を準備してください。リンクを文脈に沿って維持し、文が
小さな書き直しを必要としない限り、既存の読者向けコピーを保持してください。編集、
公開、デプロイ、グローバルナビゲーションの変更を行わないでください。結果の差分またはCMS変更シートを承認されたマップと照合してレビューします。リンクはコンテンツの変更であり、新しい段落と同じ承認に値します。
完了チェックリスト
- [ ] インベントリにはタイトルとURLだけでなくページの役割が含まれている。
- [ ] すべての提案リンクにソース文と読者の理由がある。
- [ ] 欠落または無関係な目的地へのリンクを拒否した。
- [ ] サイト全体のリンクスクリプトではなく、承認された変更シートを保存した。
- [ ] 未構築の目的地を早期リンクするのではなく、計画済みとマークした。
- [ ] 各承認済みリンク変更後にライブのソースと宛先を確認した。
リンク変更リリースノートを使用する
人間が小さなリンク変更を承認した後、他のページ変更と同じように記録します。コンパクトなノートは、アンカーがオプションのように見えるという理由で、後の編集者が有用な経路を削除するのを防ぎます：
リンク変更日：[日付]
ソースURLと文：[正確な文脈]
宛先URLと読者の質問：[URLと暗示された次の質問]
承認された理由：[この経路が読者を助ける理由]
検証：[デスクトップ/モバイルチェック、レビュアー、結果]
ロールバック：[宛先が変更された場合、元の文を削除または復元]宛先が後でリダイレクトしたり、不正確になったり、暗示された質問に答えなくなったりした場合は、ノートを再度開き、意図的にリンクを置き換えるか削除します。これが、サイトが成長してもトピックシステムが読みやすく保たれる方法であり、継承されたアンカーの山になるのを防ぎます。
計画された読者の経路にまだ目的地がない場合の回復
マップに空の矢印があるからといってリンクを作らないでください。ソース文をリンクなしで有用に保ち、目的地を PLANNED とマークし、欠落したページの質問を次の承認された作業キューに追加します。目的地が最終的に公開されたら、マップを再度開き、実際に暗示された次の質問に答えるかテストし、その後にのみリンク変更シートを準備します。これにより、訪問者が到達できない助けを約束するナビゲーションという、新しいサイトの一般的な間違いを防ぎます。
コースマップ
著者：David Sinclair、Auspia 500以上のトピッククラスターを担当するトピックオーソリティ戦略家。Davidは読者と検索エンジンが有用な証拠をナビゲートするのを助けるトピックシステムについて書いています。
![トピックシステムワークパケットワークフロー図]()
この課題にはこの順序を使用します：実際の入力から始め、証拠を確認し、レビュー可能な出力を準備し、読者の次のステップを選択します。
