使用 Codex 將低點擊頁面轉化為你的下一個流量成長機會
使用 Codex 診斷一個低點擊或過時的頁面，選擇刷新、合併、保持原樣或重新導向提案，並準備一份可審查的改善計畫。
決定一個低點擊頁面接下來該做什麼
一個低點擊的頁面不自動代表它很差。它的標題可能承諾了錯誤的東西。開場可能錯過了訪客的問題。它可能與另一個頁面重疊。它的事實可能過時。或者它可能只是太新、衡量太少，或針對一個狹窄的決策。改變每個看起來很弱的頁面會製造噪音，並破壞你需要學習的歷史。
這個工作坊給 Codex 一個頁面、一個完整的比較期間，以及頁面的原始目的。它回傳一份刷新決策，你可以在任何人編輯、重新導向、刪除或發布任何內容之前檢查它。
你的完成成果： 一個標記為 KEEP、REFRESH、CONSOLIDATE、REDIRECT PROPOSAL 或 LEAVE ALONE 的決策；當變更有理時一份有證據支持的變更表；以及一份前後衡量筆記。
在這種情況下使用： 一個現有頁面有令人失望的點擊、一個過時的答案，或與另一個 URL 混淆的重疊。預留 45-60 分鐘。 帶上實際的 URL 或草稿、它的流量任務、事實包、原始發布說明，以及一份完整的 Search Console 或分析匯出。不要使用公開的估算作為你的成效數據。如果決策達到那個點，你還需要一個可以批准重新導向、刪除或生產編輯的人。
選擇一個有足夠歷史可以檢查的頁面
從一個 URL 開始，而不是二十個的清單。對 Northstar Books，選擇 /before-self-assessment-bookkeeping-checklist：它已經存在一個完整的比較期間，獲得準備問題的曝光，但訪客不常到達探索通話連結。原始任務是：「幫助自由接案設計師在決定每月記帳支援是否適合之前收集記錄。」
製作一份像這樣的刷新輸入筆記：
refresh-input.md
URL：/before-self-assessment-bookkeeping-checklist
Original mission（原始任務）：幫助自由接案設計師在決定每月記帳支援是否適合之前收集記錄。
Release date and change（發布日期和變更）：2026-05-01；初始檢查清單頁面。
Completed comparison periods（完成的比較期間）：2026-06-01 至 2026-06-28 vs 2026-05-01 至 2026-05-28。
Evidence attached（附上的證據）：GSC 頁面匯出、當前頁面副本、事實包、內部連結清單、日期 2026-06-20 的客戶回饋。
Observed issue（觀察到的問題）：搜尋詞暗示人們也想要遠端服務適合度；頁面開場沒有解釋邊界。
Known competing/related URLs（已知的競爭/相關 URL）：/monthly-bookkeeping-for-designers。
Do not change（不要更改）：服務排除項目、稅務建議邊界、未經擁有者批准的現有 URL。observed issue 這個短語不是聲稱它造成了低點擊。它是給決策的一個問題。如果頁面上週才上線，寫 insufficient time 並安排一個審查日期，而不是強迫刷新。
給 Codex 完整的決策提示詞
附上輸入筆記和列出的檔案，然後確切地複製這個提示詞。
閱讀 [refresh-input.md]、[當前頁面 URL 或副本]、[traffic-mission.md]、
[fact-pack.md]、[發布說明]、[完成的 GSC/分析匯出] 和 [內部連結清單]。
建立 refresh-decision.md。
恰好選擇一個：KEEP、REFRESH、CONSOLIDATE、REDIRECT PROPOSAL 或 LEAVE ALONE。
然後提供：
1. 支持該決策的證據，以及阻止更強主張的未知事項；
2. 此頁面現在必須回答的訪客問題；
3. 原始任務是否仍然正確；
4. 如果要測試的 REFRESH 合理，具體的標題、開場、證明、段落、CTA 和內部連結變更；
5. 可能有重疊的 URL 和逐對解釋；
6. 技術或歷史風險，包括 Canonical/重新導向考量；
7. 變更前狀態、實作邊界、審查日期和回溯計畫。
不要編輯、發布、刪除、重新導向、更改 Canonical、提交 URL、
更改衡量設定，或聲稱一個指標移動是由單一頁面元素造成的。
將缺失的事實標記為 NEEDS OWNER FACT。在讀提議的文案之前先讀決策
決策必須主導。Northstar Books 的一個強烈回答可能說：
Decision（決策）：REFRESH。
Reason（原因）：原始準備任務仍然與每月服務頁面不同。完成的頁面數據和帶日期的回饋
顯示一個未解決的遠端適合度問題。當前的開場給出一個檢查清單，但沒有說明服務可以和
不能幫助什麼。
Boundary（邊界）：保留當前的 URL 和稅務申報排除。加入一個簡短、有事實支持的
「遠端記帳是適合的嗎？」決策區塊，連結到獨立服務適合度頁面。不要與
/monthly-bookkeeping-for-designers 合併；那個頁面在讀者識別需求之後解釋服務範圍。它分開了兩個頁面工作。檢查清單幫助某人準備。服務頁面幫助某人評估持續協助。這是一個有用的內部連結的證據，而不是複製文案的理由。
使用這個表格拒絕錯誤的行動
決策 | 何時選擇它 | 下一個安全步驟 |
|---|---|---|
Keep | 頁面準確，沒有證據識別一個讀者問題 | 記錄原因並設定一個稍後的審查日期 |
Refresh | 任務仍然不同，但回答、證明、標題、路徑或 CTA 薄弱 | 準備一份狹窄的批准變更表 |
Consolidate | 兩個頁面真正服務同一個讀者決策和證明需求 | 製作一份合併計畫；在更改 URL 之前保留歷史 |
Redirect proposal | 舊頁面過時，存在一個清晰的等效目的地 | 獲得技術/擁有者批准並測試重新導向計畫 |
Leave alone | 證據太薄弱、時間期間不完整，或一個關鍵事實未確認 | 收集一個缺失的事實或等待一個完整期間 |
永遠不要因為 Codex 說一個頁面很薄就選擇 redirect。一個重新導向改變訪客路線，並可能影響歷史訊號。它需要一個有效的目的地、技術審查和擁有者批准。同樣，合併不是把兩個頁面複製在一起；它需要一個選擇的倖存 URL、有用內容的映射、內部連結更新、衡量保留和回溯計畫。
在合併任何內容之前測試頁面重疊
對每個可能重疊的 URL，並排寫下兩個問題：
URL | 訪客問題 | 主要證明 | 下一步行動 |
|---|---|---|---|
檢查清單頁面 | 在尋求幫助之前我該收集哪些記錄？ | 入職檢查清單 | 檢查就緒度或閱讀服務適合度 |
每月服務頁面 | 為設計師包含哪些持續的記帳協助？ | 服務範圍和排除項目 | 要求探索通話 |
如果那些列不同，頁面值得不同的角色和一個情境化連結。如果問題、證明和行動都相同，一個合併審查是合理的。如果 Codex 無法識別不同的列，不要接受一個自信的合併推薦。使用這個恢復提示詞：
在比較表中顯示頁面角色：訪客問題、開場回答、證明、下一步行動和獨特段落。
如果三個或更多欄位相同，提出一個合併計畫。如果它們不同，解釋使兩個頁面都有用的
內部連結。不要推薦一個沒有映射目的地和擁有者批准的技術審查的重新導向。將 REFRESH 決策轉化為一個有約束的變更表
一旦人工批准決策，不要要求 Codex 全面改寫。要求測試已識別問題的最小變更。
使用已批准的 refresh-decision.md、當前頁面、事實包和主題系統地圖，
準備 refresh-change-sheet.md。包含：
- 要新增、移除或修訂的確切段落及原因；
- 前後的標題和開場；僅使用已確認的事實；
- 每個帶有事實包來源的主張；
- 要新增、移除或更改的內部連結，附有錨點情境；
- URL、Canonical、索引、重新導向和分析邊界；
- 發布前檢查、擁有者批准和回溯觸發；
- 下一個審查的完整比較期間和日期。
不要編輯 CMS/儲存庫、發布、重新導向、刪除、加入結構化資料、提交 URL
或更改分析。在需要擁有者輸入的地方停止。以檢查清單而言，一份適當的表可能加入一個由服務範圍支持的 90 字遠端適合度決策區塊、一個情境化連結和一個更清晰的標題。它不會加入無關的城市頁面、改寫每個段落，或聲稱服務適合每個設計師。
好的和壞的刷新
好的： 修訂開場以回答實際的準備問題、陳述一個文件化的服務邊界、在讀者收到檢查清單之後連結到服務適合度頁面，並保存變更前狀態。
壞的： 更改發布日期、在每個標題中插入關鍵字、刪除 URL，並稱它為 SEO 刷新。這使得無法分辨為訪客改善了什麼，並可能沒有證據地引入風險。
像受控實驗一樣發布，而不是批量更新
在擁有者更改頁面之前，在一個發布資料夾中保存這四項：
refresh-[page-slug]/
before-page-copy-or-screenshot.md
refresh-decision.md
approved-change-sheet.md
measurement-note.md然後對照實際的提議變更執行發布關卡。讓 CMS 或程式碼擁有者批准發布；讓開發者批准技術路由；並記錄發布日期。發布之後，檢查 URL 載入、批准的標題/開場/連結存在、目的地正常工作，以及頁面有預期的 Canonical/索引狀態。不要因為一天的移動就慶祝或撤銷它。等待變更表中指名的比較期間。
在審查日期，將新的證據餵回你的每週成長循環。Codex 應該比較期間、列出什麼改變了、識別未知事項，並只選擇一個下一步行動。它不得在沒有充分證據的情況下聲稱刷新造成了一個結果。
疑難排解
沒有原始任務或發布說明存在。 從頁面、事實包和擁有者記憶重建一個，但標記假設。在提議變更之前保存它，這樣未來的審查有一個基準線。
頁面有曝光但沒有有用的查詢數據。 使用頁面回饋、內部連結情境和內容準確性來決定是等待還是做一個小的讀者優先改善。不要發明一個關鍵字意圖。
一個關鍵主張過時。 停止刷新並先用公開事實修正工作流程修正事實。一個吸引人的標題不能彌補一個不準確的頁面。
想要的變更需要一個重新導向或 Canonical 更改。 將結果轉化為一個帶有映射表、受影響的連結、擁有者、測試和回溯的技術提案。不要在一個內容編輯時段中套用它。
完成檢查清單和下一課
- [ ] 我選擇了一個有完整比較期間或清晰等待條件的頁面。
- [ ] 我的刷新決策指明了證據、未知事項和恰好一個結果。
- [ ] 我按訪客問題、證明和下一步行動檢查了可能的重疊。
- [ ] 任何實際變更都有狹窄的批准表、變更前狀態和回溯邊界。
- [ ] 我安排了一個稍後的證據審查，而不是猜測因果關係。
現在將這些決策的教訓收集成一個基於容量的營運計畫：建立你的 90 天計畫，從初步成果擴展到 1,000,000 自然流量。
作者：Elise Morgan，Auspia 十五年編輯 SEO 策略師。Elise 專注於以證據為導向的內容刷新和有意義的編輯改善。
![低點擊刷新工作包流程圖]()
對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。
