Bing AI Performance 診斷流程：引用下滑時先查什麼再動內容

月度檢討會開到一半，主管把報表投影到牆上，問了一句最難回答的話：上個月引用還有六百多，這個月剩不到三百，是不是我們的內容被降權了？先把它當一個情境看：一家 B2B 設備商的官網小組，就這樣走進 Bing Webmaster Tools 的 AI Performance。負責的同事翻了十分鐘，發現兩件更麻煩的事。不同檢視各自加總，數字對不起來；整份報表裡，也找不到任何點擊數可以對照。

工具沒有壞，也沒有那麼神。麻煩來自閱讀習慣：把引用當曝光、把引用當權威分數、把片語清單當關鍵字排名。三個動作都在用舊報表的框架，讀一份量測基礎完全不同的資料，結論自然會歪。

面對引用下滑，順序比結論重要。先確認問題是不是這份報表答得了，再排除資料口徑、抽樣與索引，然後才輪到動內容。下面照這個順序，把整份報表從定位、欄位、排查一路走到月報與處置。

快速重點。Bing AI Performance 量的是 Microsoft 支援介面中的來源引用活動，沒有 AI 點擊與轉換。引用下滑先查日期範圍與欄位版本，再查索引與內容變更；數字對不上，多半是抽樣與版本差異。把觀察、假設、行動分層寫進月報，判斷才站得住。

你想回答的問題，決定這份報表的用法

2026 年 2 月，微軟在 Bing Webmaster Tools 開放公開預覽的 AI Performance 報表。依官方公告的定義，它呈現網站內容在 Microsoft 支援的 AI 介面中被列為來源的引用活動，涵蓋 Microsoft Copilot、Bing 的 AI 生成摘要，以及部分合作夥伴的整合；公告同時寫明，引用次數不代表點擊、權威分數、排名，也不代表網站在個別回答裡的定位。這段定義就是使用的邊界：它量的是來源露出，不是使用者行為。

打開報表前，先把手上的問題分成兩欄。它答得了的：哪些頁面被列為來源、內容常和哪些主題片語一起出現、引用量隨時間怎麼變。它答不了的：點擊與轉換、單一答案裡發生的細節、其他 AI 產品上的表現。問題落在第二欄，該換工具，不該硬讀。

三個直覺誤讀可以先記下來。把引用當曝光，會想拿它算點閱率；把引用當權威，會把總次數當品牌分數；把片語當關鍵字清單，會照著它改標題。三個方向犯的是同一種錯：資料量的根本不是那件事。

使用上有兩個前提。網站要先在 Bing Webmaster Tools 完成驗證，資料才會歸到對的資源；還沒設定的話，照Bing Webmaster Tools 的安裝與驗證指引走一遍即可。資料每天更新，但有處理延遲，而且經過彙整與抽樣，出現頻率很低的引用，報表可能略過不列（見Bing Webmaster Tools 的 AI Performance 說明）。期待逐筆帳目的人，在這裡就要調整預期。

日期範圍有 7 天、30 天、3 個月與自訂區間四種。抽樣資料在短區間的雜訊最大，看趨勢從 30 天起跳比較穩；7 天只適合確認資料在不在，不適合下判斷。入口以工具內的 AI Performance 名稱為準，上層選單未來可能調整，把路徑寫死反而靠不住。

從一個提問到列名來源，中間發生了什麼

微軟對 Copilot 網頁搜尋的公開資料，能確認的只有兩段：使用者提問後，Copilot 會先把問題改寫成較短的 Bing 查詢；Bing 送回結果、摘要與引用，Copilot 才用取回的資料組合回答（參考Microsoft Learn 對 Copilot Studio 網頁搜尋的說明與Microsoft Support 對 Copilot Chat 網頁搜尋的說明）。使用者的原句不會直接變成檢索詞；系統真正送出的，是它自行換寫、用來取回內容的精簡查詢。

把這條路徑壓成三道關卡，排查時就有共同的語言：

1. 被找到。頁面在不在索引裡、檢索詞組會不會命中，是第一道門。連索引都沒有的頁面，後面全部無效。
2. 被取回。進入候選結果，才有機會被拿去組答案。這一關官方沒有公開排序細節，內容端能做的，是讓頁面清楚回答特定主題，而不是什麼都沾一點。
3. 被顯示。支援介面把網址列為來源，才會變成報表裡的一筆。前兩關過了、這關沒過，數字一樣是零。

三道關卡也決定防守位置。被找到靠索引與網址整潔；被取回靠頁面與主題的對應夠清楚，標題、小標與首段說的是同一件事；被顯示取決於介面怎麼組答案、怎麼列來源，這一段內容端只能間接影響。力氣花在前兩道，成果最看得見；第三道留給觀察。

講機制要停在官方可確認的範圍。Azure AI Search 的 hybrid search 文件確實說明，檢索可以同時用 BM25 全文比對與向量相似度，再以 RRF 合併結果；但微軟沒有確認 Copilot 或 Bing 摘要採用同一套實作。同集團的產品只能當類比，不能畫上等號。檢索與排序的細節未揭露之處，答案就是不知道，不需要用推測補滿。

還有一個容易被忽略的細節：報表把多種介面的活動併在一起呈現。Copilot 的問答、Bing 摘要、合作夥伴的整合，各自有自己的回答組成方式；報表只給合計後的引用活動，不細分哪個介面貢獻多少。要做管道層級的歸因，資料不支援；要比較不同介面的表現，只能靠第三方題庫另外設計。

三道關卡的價值在後面：引用下滑的排查順序，就是沿著被顯示往被找到倒著檢查，先排除量測與顯示條件的問題，再回頭看索引與內容。機制不必背，順序記住就夠。

四種會走進這份報表的商業情境

很少人是為了認識功能而打開它。多數人帶著具體壓力進來，情境不同，先看的欄位與地雷也不同。

四種情境有共同的下一步：把問題寫成一句話，再決定打開哪個欄位。問題寫不清楚，欄位再多也只是數字堆。AI 搜尋的整體環境與基本功，可以先讀AI 搜尋時代的 SEO 基礎攻略，再回來處理報表判讀。

六個欄位拆成四種診斷角色

欄位數量隨版本增加，逐一背定義效益有限。換個分法：每個欄位在診斷裡扮演一種角色，角色對應生成路徑上的量測點。量看總數，面看分布，主題看片語，方向看時間；2026 年 6 月後加入的 Intents、Topics、Citation Share 與 Compare，則是疊在上面的分類與比較層。

量的角色最容易被過度解讀。Total Citations 計算期間內內容被當作可見來源引用的總次數，適合當趨勢的起點，不適合當橫向比較的分數。不同網站的內容量、主題需求與索引規模都不同，引用總數的絕對值沒有可比性；自己跟自己比，才有意義。

面的角色看分布。Average Cited Pages 把期間內每天被引用的不重複頁面數做平均，Page-level 引用指出是哪些網址。兩者合起來回答：引用集中在少數頁面，還是散在內容群上。集中的結構風險在單點，主力頁一出事，總量跟著掉；太分散則看不出哪類內容真的被需要。

欄位要併著讀，兩個組合最常見。量升、面不動：引用可能更集中在既有頁面，先查主力網址的內容狀態。面升、量不動：引用可能分散到更多頁面，先查新出現網址的主題集中度。這兩句都是資料判讀，不是因果結論。延伸欄位的邊界也要記住：Compare 只顯示差異，不解釋原因；想用 Citation Share 推回總量，或在同日期範圍自行推算份額，都越過了資料口徑。

分類與比較欄位的讀法也要保守。Intents 把片語歸到資訊、商業、比較、規劃等意圖，Topics 把相關片語聚成主題群；兩者都是分類器的輸出，名稱未必符合你的人工判斷，把它當成另一種切角度的方式就好。Citation Share 顯示某個片語累積的全部引用裡，自家網站占多少比例；其他網站是誰，報表不揭露，也推不出競爭對手的表現。想知道自己以外的事，這份報表天生不回答。

欄位版本影響能回答的問題。2 月是原始報表，3 月加入 Grounding Query 與 Pages 的雙向對照，6 月再預覽 Intents、Topics、Citation Share、Compare（見Bing Search Blog 的更新公告）。哪個月匯出、當時有哪些欄位，會直接改變判讀的底線。

Grounding queries 不是誰輸入了什麼字

Grounding queries 是欄位裡最容易被讀錯的一項。官方給它的定義，是與引用取回相關、經分組概括後的片語：每一列不是使用者的完整問題，也不是逐次回答的紀錄，而是彙整與抽樣後的主題代表。對應關係是多對多，一個片語可以對應多個頁面，一個頁面也可以對應多個片語。

多對多還代表兩個方向數出來的數字不保證對稱。Grounding Query 與 Pages Mapping 支援雙向查詢，官方也說明：因取樣時間窗不盡相同，兩邊出現不一致的計數屬正常，不代表資料漏了。看到某頁同時掛在多個片語下，可能是涵蓋面廣，也可能只是歸組粗；兩種解釋都說得通，答案要回到頁面本身的內容。

實際操作是雙向各查一次。挑三到五個與業務有關的片語，看它們對應到哪些頁面，記下頁面是否真的回答那個主題；再挑引用最多的三個網址，反向看它們和哪些片語一起出現。兩次紀錄對得起來，主題定位就清楚；對不起來，通常表示頁面想回答的，和被取用的脈絡有落差。

讀的時候留意片語的粒度。有些片語很寬，像一個主題的統稱；有些很窄，接近特定產品或情境。寬片語對應的頁面多，不代表每一頁都同等相關；窄片語對應的頁面少，反而適合直接檢查那幾頁的內容狀態。先分寬窄，再決定檢查順序，會比照著清單從頭看到尾有效率。

這份清單適合看網站常和哪些主題聚落一起被引用，不適合估搜尋量或需求規模。要理解真實需求，仍要回到搜尋意圖的分析框架與傳統查詢資料，把片語當線索，不當答案。

操作價值最高的，其實不是引用總次數，而是片語與頁面的對應關係：總次數只告訴你有多少，對應關係才告訴你內容被放進哪些問題脈絡。改善動作從對應關係出發，也比追逐總數具體。

引用下滑時的排查順序

先講一個原則：排查的目的是縮小範圍，不是找兇手。每一步都在問同一件事，這個因素能不能解釋看到的變化；能解釋就標記，不能就排除。五步走完，手上的清單就是月報第二層的素材。

1. 查資料口徑。確認日期範圍、網站資源與欄位版本一致。兩次看的區間不同、資源不同，或欄位剛改版，比較就無效；一致後仍下滑，再往下走。
2. 查抽樣與顯示門檻。低頻引用本來就可能不顯示，官方把彙整活動有限列為片語不出現的正常原因之一。基數很低時先拉長區間，不做單週結論。
3. 查索引與檢索阻擋。確認重要頁面仍留在 Bing 索引裡，robots.txt 沒有無意間擋掉爬蟲；依Google 對 robots.txt 的定位說明，它管的是爬蟲抓不抓，不是頁面存取權。重複網址也要清理：canonical 是強訊號、不是指令（見Google 對重複網址整併的說明），多版本網址分散取回機會，等於第一道關卡就漏。實作方法可對照canonical 與重複網址的處理指南。
4. 查內容變更時間軸。把下滑起點對上站內改版、下架、網址調整的時間。有對得上的事件，先記為待驗假設，不是結論。
5. 停在可觀察的事實。查完仍無引用，能寫下來的只有觀察到的變化與已排除的項目。單一事件的因果判定，這份資料支撐不了。

零引用或下滑，不等於被降權。官方說明趨勢同時受需求、內容、模型與合作介面更新影響；想把數字歸因到單一原因的衝動，本身就是排查時要排除的對象。可觀察的事實先於任何解釋，這句話值得寫進每次檢查的結尾。

加總對不上，多半不是資料壞了

同一個日期範圍，時間軸、頁面與片語三個檢視各自加總，結果常不相等。原因在設計：頁面與片語各自抽樣，時間窗略有差異，欄位又隨 2 月、3 月、6 月的改版逐步增加。跨版本或跨檢視直接拼接，對不上是正常後果，不是工具故障。

把版本演進記成時間軸：2 月的原始報表，3 月的 Grounding Query 與 Pages 雙向對照（見Microsoft Advertising 對 dashboard 更新的說明），6 月的分類與比較欄位。每次匯出，順手記下日期、當時可用欄位與篩選條件；CSV 與 Excel 匯出會套用當前篩選，事後很難還原。

一個常見的對不上長這樣：3 月匯出的表沒有 Citation Share 欄位，7 月匯出的有。把兩份表貼成同一張長表，舊月份的份額全是空值，看起來像憑空消失。實際上只是欄位當時還不存在。版本註記一欄，就能擋掉這種誤會。

版本註記可以變成月報的固定欄位。跨月比較註明欄位版本，讀的人才分得出是表現變了，還是量尺變了。資料每天更新但有處理延遲、低頻引用可能不顯示，是官方對這份資料的一貫定位：代表性趨勢，不是逐筆會計帳。

匯出紀錄可以簡單到三個欄位：日期、欄位版本、篩選條件。看起來像多餘的工，但它同時解決兩個問題：三個月後回頭看數字時，知道當時量的是什麼；功能改版後，舊報告不用重寫，加一行版本說明就能繼續引用。資料的壽命，取決於註記的完整度。

兩個動作要避免：自行補差額把數字對齊，或挑較大的那個數字往上報。對不上時保留原值、加註條件，比修出一個好看卻失去來源的總數有用。

引用與流量是兩條線，進站要另外量

主管常問「AI 到底有沒有帶來業績」，這份報表答不了。引用屬於來源露出，進站要靠分析工具量。回答時把三件事拆開講：引用是露出訊號，造訪是 GA4 的工作階段，轉換要另外接事件與歸因窗口。三條獨立的時間序列，只觀察是否同向；不相加、不相除，也不拚成同一條漏斗。

GA4 在 2026 年 5 月新增 AI Assistants 預設渠道：referrer 符合已知 AI 助理時，medium 會標成 ai-assistant，工作階段歸入 AI Assistants（見Google Analytics 的更新說明）。但規則會隨平台調整，Google 也未公布一份可長期當規格用的網域清單（依預設渠道定義與流量來源的歸因說明）；沒有來源資訊的造訪可能落進 direct，細節見direct traffic 的說明。查數字時同時看來源、媒介、管道與著陸頁，比記任何固定清單可靠。

跟主管回報時，可以直接用一段話術骨架：引用看 Bing 報表，量的是來源露出；造訪看 GA4，量的是記錄到的進站；轉換看事件與歸因設定，量的是商業成果。三個數字各有單位與期間，同向可以講，不能互相換算。這段話先擋住「引用換算成業績」的追問，也誠實面對資料的邊界。

Google 搜尋那側的量法又不同。Search Console 已把 AI Overviews 與 AI Mode 的連結表現併入 Web 成效（計算方式見官方對點擊與曝光的定義），2026 年 6 月起部分網站另出現生成式 AI 專用報表，量連結曝光，沒有點擊與 CTR 欄位（見Google Search Central 的公告與報表說明）。基礎操作看Google Search Console 的完整教學；專用報表的欄位與限制，另有Search Console AI 報表的解析。

兩平台的量測口徑不同，數字不能比大小。Bing 的數字只談 Microsoft 支援的介面，GSC 的數字只談 Google 搜尋與其生成式功能；拿一邊的引用對另一邊的點擊，口徑不同，連母市場都不同。要比就 Bing 對 Bing、Google 對 Google，中間用內容維度串，不用數字直接除。

引用不是曝光，進站也不是被引用：涵蓋的介面與分母都不一樣。GA4 沒記到造訪，也不代表點擊從未發生。

第一方引用與第三方題庫，各量不同的東西

已經付費訂了 AI 能見度工具的團隊，常問還需不需要看這份免費報表。需要，因為兩者的母體不同：Bing 記錄的是支援介面裡實際發生的引用活動，屬第一方資料；第三方工具則先選定一批 prompts、按固定週期重複投問，回答的是這批問題裡誰出現。一個記錄實際發生的事，一個抽樣提問。兩者可以並排，不能對齊。

第三方的作法可以看兩份公開文件：Semrush 對 prompt tracking 的說明與Semrush 對 AI visibility 資料來源的說明。抽樣、去重與辨識方式的選擇，各家都不同，讀報表前先讀方法。

若要自己維護題庫，清單怎麼設計，本身就是研究設計。分組依用途走：比較類、教學類、在地類與品牌類各自獨立；語言、地區、平台與重跑頻率固定下來；每一輪重跑都留存原始回答或畫面快照，日後才分得清，是引用對象真的換人，還是工具調整了計數方式。要擴充 prompts 時另存一個版本，新舊各自保留基準，不要把新題目直接塞進舊趨勢。

有些工具的題庫兼有兩種來源：廠商固定維護一批，加上使用者自訂 prompts；讀數字前先分清楚，可參考Ahrefs Brand Radar 兩種資料來源的讀法。

第三方數字看方向，不宣稱市占。固定題庫的優點是穩定，侷限是結論只適用那批問題；大型題庫接觸面廣，侷限則在抽樣未必貼近你的實際客群。並排的正確寫法是分欄標注：一欄 Bing 引用與期間，一欄第三方能見度與題庫版本，各自標單位與方法，讓讀的人自己看方向是否一致，不替他們下互相印證的結論。

什麼時候信哪一邊？問實際發生的事，信第一方：某頁有沒有在支援介面被列為來源，平台自己的紀錄最接近現場。問特定問題集合的表現，信題庫：固定的 prompts 定期重跑，變化可以歸給題目範圍內的因素。問整體市場或競品動態，兩邊都只能當參考，需要更多來源交叉。

把引用寫進 KPI 之前，先過三個關卡

團隊想把引用次數變成指標之前，有三個關卡要過。任何一關沒過，它就先留在觀察指標，不進 KPI。

1. 資料量夠不夠穩。引用基數低的網站，單週波動就是雜訊。先拉長觀察期間確認穩定；不通過時，改成每月檢視一次。
2. 能不能建立可驗證的關係。引用要和品牌查詢、造訪或其他資料對得起來，至少同向。找不到可驗證關係時，把它當內容維護的排序依據，不當目標。
3. 有沒有版本與口徑註記流程。每次匯出記日期、欄位與篩選，跨月比較註明版本。流程還沒建立前，把它列為附註訊號。

三個關卡也決定檢視頻率。資料量小的網站，月頻就夠，看太勤只會被波動帶著反覆改文；資料量大的網站可以週頻，但改變觀察頻率時，前後期間要對齊同一種區間長度，不然趨勢圖的鋸齒會誤導。頻率本身，也是口徑的一部分。

外部報告可以當背景，不能當定義。行銷現況調查顯示 AI 使用在成長（見HubSpot 的行銷現況報告），這支持持續觀察，不支持把引用寫成長期承諾；第三方研究估計多數頁面沒有搜尋流量（見Ahrefs 的流量研究），也不能反推引用門檻的高低。指標的定義要來自自家資料。

引用上升不保證排名、流量或轉換，這句限制要跟著指標一起寫進文件。三個關卡的設計本身就是防過度承諾的機制：先證明量測穩定，再談目標數字。

月報的三層寫法：觀察、假設、行動

回到開場那種月會。一份經得起追問的月報可以拆成三層：最下層只陳述量到的數字，引用總數、被列為來源的頁面數、升降幅度，單位和期間標清楚；第二層列可檢查的解釋，每條標明是待驗假設，例如主力頁改版、索引狀態或主題分布變化；第三層放具體行動，更新過期數字、補來源、修連結。三層不混寫，未驗證的原因就進不了結論區。

用一個情境示範：一家在地連鎖服務站的月報。觀察層寫引用總量與被引用頁面數的變化，附期間與欄位版本；假設層寫兩條可檢查的解釋，各自標注驗證方式；行動層只放本月真的會做的兩件事。三層各自獨立，主管就不會把假設當成已證明的原因。

假設層有個小技巧：每條假設後面，接一個可執行的檢查。例如「主力頁改版影響取回」後面接「比對改版日前後兩個同長度區間」；「索引流失」後面接「用 site: 查詢確認收錄狀態」。檢查做完，假設就升級成事實或被刪掉，月報的結論區永遠乾淨。

還有一個單位紀律要顧：「引用 200 次」不等於「200 個工作階段」。並列不同來源的數字時，單位、期間、平台與出處都要寫清楚；用 Compare 時，措辭寫「更新後觀察到變化」，不寫「更新造成成長」。同一頁同時有 Bing 引用、GSC 曝光與 GA4 工作階段時，保留三條獨立序列，觀察是否同向即可。

月報之外，季報可以多做一件事：回顧三個月前的假設清單，看哪些已驗證、哪些已刪除。假設層如果只進不出，表示驗證動作沒有真的執行，月報又會退回解釋的堆疊。定期清空假設層，三層結構才守得住。

診斷結束後，內容端的三種處置

查完之後，內容端只有三種最小處置，判準是片語與頁面的關係，不是單一片語本身。

1. 修正可驗證資訊。日期、價格、規格、連結逐項檢查，錯了就改。這是收益最確定的一種處置。
2. 補上缺的定義與適用條件。片語指向的問題，頁面只覆蓋一部分就補寫缺口；與頁面主題有明顯落差時，檢查的是定位，不是篇幅。
3. 維持現狀續觀察。頁面已完整回答對應問題時，不動。不要因為單一抽樣片語，就讓整篇內容轉向另一個題目。

內容基本功可以參考微軟 2025 年 10 月的官方內容建議，換成可執行的檢查是四件事：內容可被爬取與索引、段落結構清楚到能單獨理解、數字與主張附可回查的來源、跨格式保持一致。官方也提醒，重要文字不要只藏在需要點開的區塊、文件檔或圖片裡；文件檔可以被索引，但 HTML 才給得出標題與段落的層級；圖片承載的關鍵訊息，也要有文字版本。這些做法降低取回與解析的風險，不是引用保證。

結構化資料的邊界也要先講清楚：只描述頁面上看得見、也真實存在的內容，標記正確也不保證 rich result，更沒有 AI 專用標記的官方保證（見Google 的結構化資料政策與生成式 AI 最佳做法指南）。導入細節看結構化資料的導入指南。

一輪診斷到這裡完整：界定問題、認識欄位角色、依序排查、分層報告、最小處置。功能仍在公開預覽，欄位會繼續變動；每次報告保留日期、版本與限制，下次數字不一樣時，才有辦法回頭解釋差異從哪裡來。