讓 Codex 連結你的頁面，讓每篇新文章都有一個任務

使用 Codex 將孤立的頁面轉化為一個有用的主題系統：定義頁面角色、提議情境化的內部連結，並給每個新頁面一個讀者旅程。

一個頁面應該引導到有用的地方

你的第一流量頁面需要一個超越獲得點擊的工作：幫助讀者繼續、比較、轉換或驗證。內部連結創造了那條路線。

完成的定義： 一張小型主題地圖和一份已批准的連結清單，清楚標明要新增、移除或稍後建立的連結。

預留 45 分鐘。 帶上五到十五個相關 URL 或草稿、流量任務和第一流量頁面交接。從一個客戶問題開始，而不是你的整個網域。

把你的頁面清單交給 Codex

閱讀我的流量任務、第一流量頁面和這些 URL 或本地檔案：[列表]。
建立一張主題系統地圖，包含：每個頁面的訪客任務；中心或轉換頁面；
3-8 個情境化連結提案；建議的錨點文字含義；以及任何孤立/重複警告。
僅在目的地幫助讀者的下一個決策時才連結。不要編輯、新增連結或發明頁面。

先建立一個小型清單

第一個主題系統不需要爬蟲。建立一個包含五到十五個相關頁面或草稿的表格：

url_or_draft,title,current_visitor_job,primary_question,next_action,confirmed

對一個新網站，使用計畫中的 URL。對一個現有網站，從一個主題開始，而不是整個網域。目標是在站點範圍自動化之前，先連接一個有用的讀者旅程。

建立一個揭示讀者旅程的清單

以記帳範例而言，第一個清單可能只有四列：

這已經是一個主題系統。你不需要一百個 URL。每一列有不同的決策，而每個決策給下一個連結一個存在的理由。

給每個連結一個讀者理由

每個提案必須回答：來源讀者在哪裡需要更多幫助；目的地幫助解決什麼決策；什麼措辭誠實地描述它；以及他們到達後會發生什麼？

對於每個提議的內部連結，顯示連結前的來源句子、提議的連結短語、
目的地 URL/草稿、讀者理由，以及如果連結可能感覺勉強的風險說明。
拒絕沒有清晰讀者理由的連結。

好的：一個截止日檢查清單在解釋專業協助何時有用之後，連結到一個記帳服務頁面。壞的：每個頁面都用關鍵字密集的錨點連結到每個頁面。

在情境中檢查一個提案

一個連結提案必須包含整個來源句子。比較這些：

薄弱的來源：了解更多關於設計師記帳的資訊。
薄弱的錨點：設計師記帳。
理由：SEO 內部連結。

有用的來源：如果此檢查清單中的記錄每個月已經堆積起來，在你決定探索通話是否
值得之前，先了解自由接案設計師的每月記帳包含什麼。
有用的錨點：自由接案設計師的每月記帳包含什麼。
理由：讀者已經到達服務適合度頁面可以幫助下一個決策的點。

第二個版本不是為了推動一個關鍵字而存在。它告訴讀者為什麼目的地現在是相關的。

如果 Codex 提出一個泛泛的頁尾式連結清單，使用這個修復提示詞：

拒絕每一個沒有來源句子、讀者決策和能解決該決策的目的地的提案。
在此主題地圖中保留不超過八個連結。不要重用相同的錨點文字或建議站點範圍的插入。

按讀者需求批准連結

對每個提案問：一個剛讀完這個段落的讀者，會真的想要那一個下一個頁面嗎？如果不，拒絕它。然後要求 Codex 提供一份可審查的頁面差異，而不是一個站點範圍的自動連結插入。

一次一個頁面地應用連結。不要執行一個在整個網站加入相同錨點的腳本。如果地圖揭示了一個缺失的工作，記錄為 missing proof 或 missing decision page；不要自動建立它。

建立一份可審查的連結表

在你批准地圖之後，要求 Codex 提供一份小型變更表：

閱讀已批准的主題系統地圖。對於每個已批准的連結，提供來源 URL 或檔案、
當前的來源句子、建議的修訂句子、錨點文字、目的地、讀者理由，
以及目的地是否已上線的檢查。不要編輯檔案、插入連結、更改導覽、
建立頁面或發布任何內容。

一次審查一個來源頁面。像讀者一樣打開目的地。如果它沒有回答暗示的下一個問題，拒絕這個連結。如果目的地不存在，保持來源句子不連結，並將缺失的頁面記錄為一個未來的決策，而不是一個空的 URL。

解決常見的地圖失敗

一切都指向首頁。 清單可能缺乏一個清晰的服務、產品或決策頁面。在強迫連結之前加入缺失的工作。

每篇文章都連結到每篇文章。 詢問在每個特定段落之後，讀者會選擇哪個連結。保留那一個；移除其餘的。

相同的錨點到處重複。 圍繞讀者點擊的理由改寫句子。自然的變化來自不同的情境，而不是同義詞旋轉。

將地圖轉化為一個小型的讀者路徑

在要求任何編輯之前，先用箭頭畫出第一個版本：

檢查清單問題
  -> 讀者需要幫助時的服務適合度頁面
  -> 讀者需要流程細節時的 how-it-works 頁面
  -> 只在他們準備好行動時的聯絡頁面

箭頭描述的是讀者的選擇，而不是網站階層。服務適合度頁面上的一個讀者，如果還沒準備好，可能需要返回檢查清單。那個連結是有用的。從聯絡頁面回到每個指南的連結通常不是。

對每個箭頭，寫一個停止條件。檢查清單到服務的箭頭，在服務頁面沒有陳述範圍或其預約行動損壞時停止。how-it-works 的箭頭，在頁面只是計畫中的時候停止。這讓地圖對讀者今天實際可以使用什麼保持誠實。

在發布後檢查連結，而不只是在試算表中

在一個已批准的編輯器或開發者加入一個連結之後，在桌面和手機上打開它的來源和目的地。檢查目的地載入、錨點在句子中有意義，以及目的地回答暗示的問題。在 topic-map-links.md 中記錄來源 URL、目的地 URL、日期和審查者。如果一個內部連結指向一個過時的頁面，通過同樣的審查流程移除它；不要預設用首頁取代它。

新網站和現有網站如何使用相同的方法

一個新網站可以用計畫中的頁面路徑製作地圖。將每個尚未建立的路径標記為 PLANNED，而不是已上線。只在實際發布的頁面之間連結；將未來的箭頭保留在地圖中，直到它們的目的地準備好。這避免了一個新網站因為藍圖很雄心勃勃，就帶著損壞的內部連結上線。

一個現有網站從列出當前頁面開始，而不是假設導覽是正確的。一個服務頁面可能已經有二十個連結，但沒有一個能幫助讀者處理頁面上的問題。使用相同的清單欄位，然後一次替換或移除一個差的連結。不要從單一次的主題地圖練習重新設計整個選單。

只在批准之後要求檔案或 CMS 特定的交接

當來源和目的地清晰時，你可以讓 Codex 準備一份精確的實作請求：

使用已批准的連結表。如果這是一個儲存庫，在更改任何東西之前列出確切的頁面檔案
和提議的逐行編輯。如果這是一個 CMS，準備帶有來源句子和目的地 URL 的複製/貼上
說明。保持連結情境化，並保留現有的讀者面向文案，除非句子需要小幅改寫。
不要進行編輯、發布、部署或更改全域導覽。

對照已批准的地圖審查產生的差異或 CMS 變更表。一個連結是一個內容變更：它應該得到與一個新段落相同的批准。

完成檢查清單

• [ ] 我的清單包含頁面工作，而不僅僅是標題和 URL。
• [ ] 每個提案連結都有來源句子和讀者理由。
• [ ] 我拒絕了指向缺失或不相關目的地的連結。
• [ ] 我已儲存一份已批准的變更表，而不是執行站點範圍的連結腳本。
• [ ] 我將尚未建立的頁面標記為計畫中，而不是提前連結到它們。
• [ ] 在每個已批准的連結變更後檢查了實際的來源和目的地。

使用一份連結變更發布說明

在一個人批准一個小型連結變更之後，像任何其他頁面變更一樣記錄它。一份精簡的筆記防止後來的編輯器因為錨點看起來可有可無而移除一個有用的路徑：

連結變更日期：[日期]
來源 URL 和句子：[確切的情境]
目的地 URL 和讀者問題：[URL 和暗示的下一個問題]
批准的理由：[為什麼這條路徑幫助讀者]
驗證：[桌面/手機檢查、審查者、結果]
回溯：[如果目的地變更，移除或恢復原始句子]

如果一個目的地後來重新導向、變得不準確或不再回答暗示的問題，重新打開筆記並刻意替換或移除連結。這就是主題系統在網站成長時保持可讀的方式，而不是變成一堆繼承的錨點。

當一個計畫中的讀者路徑還沒有目的地時恢復

不要因為地圖有一個空的箭頭就編造一個連結。保持來源句子有用但不連結，將目的地標記為 PLANNED，並將缺失的頁面問題加入下一個已批准的工作佇列。當目的地最終發布時，重新打開地圖，測試它是否真的回答暗示的下一個問題，然後才準備一份連結變更表。這防止一個常見的新網站錯誤：導覽承諾了訪客無法到達的幫助。

課程地圖

下一課：給 Codex 一個安全的發布檢查清單。

作者：David Sinclair，Auspia 主題權威策略師，負責超過 500 個主題群集。David 專注於幫助讀者和搜尋引擎瀏覽有用證據的主題系統。

![主題系統工作包流程圖]()

對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。