AO2 FIELD GUIDE · N002 · SEO 與網站搜尋
B2B 選題先看採購障礙、證據成熟度與後續承接能力。附題目卡及排序決策表，區分立即製作、補資料、更新舊文與暫緩情境。
B2B 選題：先問這篇文章要解除哪一個採購障礙
半導體與電子產品的採購問題，常分散在工程、採購和管理者身上。工程師想知道介面能否整合，採購想確認供貨條件，主管則想理解導入風險。把這三種問題都寫成「產品優勢」，容易得到三篇任務相同、細節不足的文章。選題會議應先用一句話寫出：哪個角色，在什麼情境，缺哪份資訊，所以無法往下評估。
例如「IoT 很重要」還不是可交付的題目；「既有設備不能更換時，如何整理感測資料上傳需求」才有明確工作。前者可以支援品牌介紹，後者適合產出需求盤點表。兩者沒有固定高下，差別在目前要解決的業務問題。Google 的內容指引也把服務既有讀者、提供原創價值與幫助完成目標列為自我檢查方向，並未要求為每個關鍵字另寫一篇文章。
把業務提問變成有來源的題目卡
先整理一小組去識別的詢問、業務會議筆記與產品 FAQ。保留問題原話和使用情境，不要急著改成吸引點擊的標題。同一句「能不能接系統」，可能在問通訊協定、資料欄位或部署權限；若混成一題，寫完也無法驗收。問題涉及哪條產品線、現有頁面回答到哪裡、還缺哪個角色確認，都應進入題目卡。
| 欄位 | 要回答的問題 | 示意填法 |
|---|---|---|
| 讀者任務 | 誰卡在哪一步 | 設備整合者無法確認介面需求 |
| 問題證據 | 問題從何而來 | 去識別詢問摘要、日期與觀察者 |
| 資訊缺口 | 現有頁面缺什麼 | 未列輸入條件與不適用情境 |
| 可用來源 | 誰能確認 | 核准規格版本與 PM |
| 承接安排 | 讀完往哪裡去 | 需求清單與既有詢問入口 |
來源可信不等於每次都要取得完整 CRM 匯出。早期可以由業務提供去識別摘要，再邀請 PM 核對共通性。相反地，即使一個詞有搜尋量，企業沒有相關產品、可公開資料或服務能力，也不適合直接列為優先題目。
先通過必要條件，再比較優先順序
採用兩階段排序會比直接加總分數清楚。先確認供應範圍、公開許可與專業核對人；缺少其中一項，就標成「待確認」，不靠其他分數補過。可發布的題目再依需求急迫性、現有內容缺口、證據成熟度及承接安排比較。若兩題相近，優先選能補上既有閱讀路徑斷點的一題。
不建議把四個主觀的五分量表加總後，當成精確的投資報酬排序。分數可以促進討論，但需保留判定理由、缺口和改變排序的條件。例如樣品申請頁還沒有人接手時，先寫大量導向申請的文章，可能只是把流程問題放大。
| 觀察 | 目前處理 | 重新評估的條件 |
|---|---|---|
| 需求明確、證據完整 | 排入近期製作 | 完成 Brief 與核准分工 |
| 需求明確、資料矛盾 | 先解決資料問題 | 指定來源獲得核准 |
| 內容已有但難找到 | 先改善既有文章 | 確認確實有新任務才另寫 |
| 題目熱門、超出供應範圍 | 暫緩或改成有邊界的觀點 | 能提出原創依據與合理承接 |
電子產業示例：把「高熱度」改成「可評估」
以下為方法示例，並非 AO2 客戶成果。一家假想電子模組廠有三個候選題：「AIoT 趨勢」、「模組選型需要哪些介面資料」和「客製開發要準備什麼」。業務回報近期反覆補問介面和環境條件，PM 也已有核准規格，因此第二題可以先做。第三題若尚未確認最小開發範圍，先補內部共識；第一題則保留，等待有獨特觀察與可靠資料時再寫。
這個判斷不是宣稱第二題一定帶來更多流量，而是它有可核對的交付條件。完成後，業務可實際拿文章協助一次需求整理，記錄客戶仍不理解的欄位，回饋給下一輪編輯。是否減少補問，需要觀察紀錄才能下結論。
用一輪小型編輯週期驗證排序
先挑三個任務不同的題目，指定來源提供人、編輯、核准人和承接頁。發布後記錄哪些頁面真的被業務採用、哪個問題仍重複出現，以及訪客下一步是否能完成。流量資料與業務回饋要一起看；樣本不足時，保留未知，比寫成成功案例有用。
常見問題
沒有搜尋量工具，還能開始嗎？
可以。先整理業務、售後與技術支援中已發生的問題，記錄讀者角色、任務、現有答案、可靠來源與內容缺口。再看目前搜尋結果和 Search Console 中可取得的查詢，補充用語與頁型。優先選有明確決策價值且資料可用的題目試作。搜尋量未知就保持未知，不把沒有工具資料等同沒有需求，也不自行估一個數字填進排序表。
每個產品都要分配一樣多的文章嗎？
不需要。先為每條產品線列出辨認、比較、選型、安裝與維護等實際問題，再評估哪些已有可用頁面。產品成熟度、文件完整度與讀者任務不同，篇數自然不同。同一問題若只需補產品頁一段，就不另開文章；有獨立取捨與證據才拆題。排序表應保留主要承接頁、資料負責人與完成條件，而不是先均分篇數再找理由填滿。
參考資料與方法範圍
查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台或可及性說明；工作表與決策流程為本文整理，產業情境另行標示為假想示例。作者公開分享作為工作觀點來源，不作客戶成效或資格背書。
