Ahrefs Dashboard API 按鈕是什麼？手查、MCP、報表一次看懂

Ahrefs Dashboard 裡的 API 按鈕，並不是另一套報表，也不是另一種 Ahrefs 資料。它只是把你目前在畫面上選好的網站、國家、日期、欄位與排序方式，翻譯成程式可以讀懂的查詢。

先講最重要的結論：如果你只是要分析 Ahrefs 畫面上已經跑出的這一次資料，直接匯出 CSV／Excel 交給 Codex 就好，不需要再呼叫 API，也不必把 API 網址貼給 Codex。

畫面上的資料是「這一次已經查到的結果」；API 網址則是「請 Ahrefs 依照同一組條件再查一次的配方」。複製 API code，不是把畫面上的 50 筆資料取出來，而是把網站、國家、日期、欄位與排序規則保存成機器下次可以重跑的指令。

---

資料都跑完了，為什麼還要取 API？

答案是：如果只做這一次分析，通常不需要。你在 Dashboard 看完資料後，匯出 CSV／Excel，再請 Codex 分析、分類或整理成文章與報表，這條路最直接，也不會為了取得同一批資料而再發出一次 API request。

以下以 Spotify.com 的 Top Pages 查詢為例。這條長網址不是裝著 50 筆結果的下載連結，而是在告訴 Ahrefs：「請查 Spotify、All locations、指定日期的 Top Pages，依流量排序，最多回傳 50 列，而且只帶回指定欄位。」執行它，就等於重新點一次餐；不是把桌上已經送來的那盤菜打包。

所以，Dashboard 的 API code 只有在「之後還要用相同規則重查」時才特別有價值，例如每週自動更新客戶報表、固定追蹤十個競品，或把資料存進自己的資料庫。若資料已經跑完，而你只想讓 Codex 解讀這一份結果，匯出檔案才是正確入口。

真正容易混淆的，是「手查、API、MCP、報表」看起來都能取得或處理 Ahrefs 資料，卻分別負責不同工作。如果沒有先把它們拆開，很容易誤以為複製一條長網址就是匯出資料，或以為 MCP 是一條不會消耗 API units 的捷徑。

接下來會從這條 Spotify Top Pages API 網址開始，逐段解釋它代表什麼、和手查及 MCP 有何差異、如何估算 units，以及資料最後要經過哪些步驟才會成為可以閱讀或自動更新的報表。

---

先用一句話分清楚：手查、API、MCP、報表各做什麼？

這四個名詞最重要的差別，不在資料來源，而在工作角色。

因此，手查是你自己開車；REST API 是程式沿著固定路線開車；MCP 是你用中文告訴 AI 目的地，由 AI 規劃路線；報表則是把抵達後取得的資料整理成別人看得懂的畫面。

如果想進一步理解 MCP 的設定、用途與限制，可以接著閱讀站內的Ahrefs MCP 完整教學。本文只處理 API 查詢與報表之間最容易混淆的界線。

---

Dashboard 的 API 按鈕，其實是一台「查詢翻譯機」

Ahrefs 官方把報表中的 API 按鈕稱為 query builder，也就是查詢產生器。使用者在畫面上改變網站、國家、日期、欄位或排序，按鈕顯示的 cURL 指令也會跟著更新。

這代表使用者不必從零撰寫 API 網址。比較常見的流程是先在 Ahrefs 介面中探索，找到真正需要的畫面，再讓 Ahrefs 把當下條件翻譯成機器查詢。

Spotify 實例：同一個查詢有 URL 與 cURL 兩種複製方式

下方是 Spotify.com 的完整 URL 版本。它只有 endpoint 與查詢參數，不包含 API Key：

https://api.ahrefs.com/v3/site-explorer/top-pages?date=2026-08-26&limit=50&order_by=sum_traffic%3Adesc&select=url%2Ctop_keyword_best_position_title%2Ctop_keyword%2Ctop_keyword_country%2Cpage_type%2Cur%2Csum_traffic%2Cvalue%2Creferring_domains%2Ckeywords%2Ctop_keyword_volume%2Ctop_keyword_best_position%2Ctop_keyword_best_position_kind&target=spotify.com%2F

這一段不是 Brand Radar API。從路徑中的 /site-explorer/top-pages 就可以看出，它呼叫的是 Site Explorer 的 Top Pages endpoint。

同一個查詢也可以複製成 cURL。cURL 除了 URL，還會把 HTTP method 與 header 一起寫出來；下列 YOUR_API_KEY 只是占位文字，發布文章時不能換成真實金鑰：

curl --request GET 
  --header "Authorization: Bearer YOUR_API_KEY" 
  --header "Content-Type: application/json" 
  --url "https://api.ahrefs.com/v3/site-explorer/top-pages?date=2026-08-26&limit=50&order_by=sum_traffic%3Adesc&select=url%2Ctop_keyword_best_position_title%2Ctop_keyword%2Ctop_keyword_country%2Cpage_type%2Cur%2Csum_traffic%2Cvalue%2Creferring_domains%2Ckeywords%2Ctop_keyword_volume%2Ctop_keyword_best_position%2Ctop_keyword_best_position_kind&target=spotify.com%2F"

實際畫面中，Ahrefs 會在 Top pages 表格右側開啟「Pull this report with API」視窗，並提供 cURL／URL 切換。截圖右下角也顯示這組欄位的 request cost 為每列 44 units。

網址中的每個參數，都是畫面當下的查詢條件

%2C、%3A、%2F 只是 URL encoding，分別代表逗號、冒號與斜線。它們不是密碼，也不是額外功能。

---

---

沒有寫在網址裡的預設值，也會影響結果

這條網址沒有指定 mode 與 protocol。依 Ahrefs Top Pages 官方文件，mode 預設是 subdomains，protocol 預設是 both。

換句話說，這不是只看一個精確頁面，也不只看 HTTPS，而是可能涵蓋 Spotify 主網域及其子網域的 HTTP／HTTPS 資料。這正是 API 與 MCP 常見的風險：即使網址看起來很精確，省略的參數仍然可能擴大範圍。

---

API 網址負責「查什麼」，API Key 負責「能不能查」

剛才的長網址只有查詢條件，沒有 API Key。依 Ahrefs 官方規格，API Key 應放在 HTTP request 的 Authorization header：

Authorization: Bearer YOUR_API_KEY

所以，單純把 API endpoint 貼進一般瀏覽器，不代表瀏覽器就能替你完成一個已授權的 Ahrefs API request。網址和權限是分開的。

這裡還有三種很像、但用途完全不同的網址：

• https://app.ahrefs.com/...：給人看的登入後 Ahrefs 頁面。
• https://api.ahrefs.com/v3/...：給程式呼叫的 REST API endpoint。
• https://api.ahrefs.com/mcp/mcp：讓支援 MCP 的 AI client 連接 Ahrefs 的 server URL。

把私人 Dashboard URL 貼給 Codex，通常只是在告訴 Codex「這個頁面在哪裡」，不會自動提供登入狀態與資料。把 REST API query 貼給 Codex，Codex可以精確理解你想查什麼，但真正執行仍需要已設定好的 Ahrefs MCP 或 API 授權。

API Key 不應直接貼進文章、公開網址、試算表或聊天訊息。如果 cURL 中含有真實 Key，分享前應先換成 <AHREFS_API_KEY> 之類的占位文字。

---

手查、REST API、MCP，應該怎麼選？

這三種方式沒有誰一定比較高級。好的工作流程通常會混合使用，而不是硬選一種。

情境一：只想快速確認一個網站，先手查

如果只是想快速查看 Spotify 目前有哪些高流量頁面，直接開 Site Explorer 最直覺。畫面可以切換國家、日期、排序與欄位，也能從圖表中發現異常。

手查的主要優點是容易看懂與抽查。它使用的是 Ahrefs 產品介面的方案規則，不是本文示範的 public API request；不同方案仍可能有 credits、報表 rows 與匯出限制，不能籠統理解成「完全沒有用量限制」。

情境二：每週都要抓完全相同的資料，使用 REST API

如果每週都要抓同一批網站、相同國家與固定欄位，REST API 比人工操作更容易重現。程式可以保存 endpoint、參數、回傳時間與原始 JSON，再交給資料庫、Google Sheets 或報表系統。

這種方式適合正式資料管線，但也要自己處理 API Key、錯誤、schema 變更、cache、分頁與 units 上限。

情境三：問題需要跨報表與解釋，使用 MCP

如果需求是「先找競爭者，再分析其 Top Pages，最後整理成內容機會」，MCP 可以讓 AI 依序呼叫不同工具，再把資料分類與解釋。

MCP 的價值是減少你手動組參數與搬運資料的工作，不是創造新的 Ahrefs 資料。想先理解 MCP 協定本身，也可以參考站內的MCP 新手入門指南。

Ahrefs 官方也特別提醒，外部 MCP endpoint 不是一般用途的 REST API。需要正式程式整合、固定資料管線或產品功能時，應使用 Ahrefs public API，而不是自行用 script 把 MCP server 當成普通 HTTP API。

---

50 筆資料不等於 50 units：真正成本藏在 select 裡

Ahrefs API 的一般付費計算概念是：

max(50, per_row_cost × returned_rows)

每個 unique field 都有每列成本。多數欄位預設為 1 unit，但部分指標是 5 或 10 units。同一欄位如果同時出現在 select 與 order_by，只計算一次。

本例的 Spotify 查詢包含 13 個欄位：

• sum_traffic：10 units／row。
• value：10 units／row。
• top_keyword_volume：10 units／row。
• referring_domains：5 units／row。
• 其餘 9 個欄位：各 1 unit／row。

因此每列成本為：

10 + 10 + 10 + 5 + 9 = 44 units／row

如果真的回傳滿 50 列，上限就是：

44 × 50 = 2,200 units

這是依官方 schema 計算的上限，不代表本次真的已花掉 2,200 units。實際成本還會受到回傳列數與 Ahrefs cache 狀態影響；官方說明，從 cache 提供的 request 不消耗 units，最終應以 response headers 中的 actual usage 為準。

真正的省錢方法，是先問這些欄位會不會改變決策

假設目的只是列出流量最高的頁面與主要關鍵字，可能只需要：

select=url,sum_traffic,top_keyword
order_by=sum_traffic:desc
limit=50

這三個 unique fields 的每列成本是 1＋10＋1＝12 units。如果回傳滿 50 列，上限約為 600 units。和原本的 2,200 units 相比，少了 1,600 units，但仍保留回答核心問題所需的資料。

這也是 Dashboard API 按鈕最容易被忽略的地方：它通常會帶入目前報表上顯示的所有欄位。複製 cURL 的同時，也可能把一整組暫時用不到的成本一起複製出去。

---

API 網址和「能不能放進報表」是兩件事

API 的工作是取得資料；報表的工作是讓人閱讀。中間至少還隔著整理、儲存與呈現。

Ahrefs API／MCP 取數
        ↓
整理欄位、保存日期、標記來源
        ↓
Google Sheets／資料庫／本地檔案
        ↓
Report Builder／Looker Studio／HTML／PDF

因此，把 API URL 直接貼到報表畫面，通常不會自動長出圖表。報表工具必須知道如何驗證 Ahrefs、如何讀取 JSON 或 connector、欄位如何對應，以及多久更新一次。

四種常見的「報表」，其實也不完全相同

• Ahrefs 報表畫面：在 Site Explorer、Brand Radar 等工具中即時操作與查看。
• Brand Radar saved report：保存 entities、競爭者、filters 與 location，方便日後回到相同設定查看。
• Ahrefs Report Builder：把目前支援的 Ahrefs widgets 組成自訂報表，並可輸出或列印；實際支援項目可能隨產品更新。
• Looker Studio／自行製作的 HTML：在 Ahrefs 之外呈現資料，需要 connector 或自己的資料管線。

例如 Brand Radar 官方說明同時提供 API、Report Builder widgets 與 Looker Studio Connector。這三條路都能使用 Brand Radar 資料，卻分別代表「取數」、「Ahrefs 內部呈現」與「外部報表呈現」。如果還不熟悉 Brand Radar 的 Mentions、Citations、Impressions 與 Share of Voice，可以先看Ahrefs Brand Radar 指標完整解讀。

一次性報表和自動更新報表，也要分開

Codex今天透過 MCP 取得一次資料，再製作 HTML 或 PDF，得到的是有資料日期的快照。要讓它下週自動更新，還需要排程、快取、錯誤處理、API units 上限與資料版本管理。

換句話說，「能做成報表」不等於「已經是一套自動化監測系統」。少了更新機制，報表就只代表製作當下的資料。

---

最安全的 Ahrefs API／MCP 工作流程

新手不需要先學會寫程式。比較穩定的做法，是把探索、估價、執行與報表拆成幾個步驟。

1. 先手查：在 Ahrefs 介面確認真正想回答的問題，不要一開始就要求完整匯出。
2. 複製 API query：把畫面條件轉成 cURL，但先不要執行。
3. 解碼參數：確認 endpoint、target、mode、protocol、country、date、select、order_by 與 limit。
4. 計算上限：查看官方欄位成本，算出 request 的 units upper bound。
5. 刪除多餘欄位：只保留真的會改變分析或決策的資料。
6. 安全連線：API Key 放在 secret／connector；使用 MCP 時走 OAuth 或專用 MCP Key，不貼在對話中。
7. 核准後只執行一次：不要自動分頁、重試或擴大網站清單。
8. 保存原始結果：記錄查詢日期、參數、raw response、usage headers 與是否 cache hit。
9. 最後才做報表：依讀者需求輸出成表格、圖表、HTML、PDF 或持續更新的 dashboard。

把 API query 貼給 Codex 時，可以使用以下指令：

請先解析這段 Ahrefs API query，不要執行。

列出：
1. endpoint
2. target 與 scope
3. country 與 date
4. select 欄位
5. order_by 與 limit
6. 依 Ahrefs 官方文件估算的最高 API units
7. 可以刪除但不影響核心問題的欄位

等我確認後，才能透過 Ahrefs MCP 執行一次。
不要自動分頁、重試或增加其他網站。

這段 Prompt 的重點不是寫得很長，而是把「先規劃、後執行」說清楚。AI 可以協助解讀與最佳化查詢，但是否值得消耗 units，仍然應該由人決定。

---

常見錯誤：看起來只差一點，結果可能完全不同

• 把 Dashboard 網頁網址當成 API：app.ahrefs.com 是人看的頁面，不等於程式 endpoint。
• 把 API endpoint 當成完整授權：網址說明查什麼，API Key 才決定能不能查。
• 把 MCP 當成免費通道：Ahrefs MCP 和直接 API v3 會使用同一類月度 API units。
• 看到 limit=50 就以為只花 50 units：欄位成本乘上回傳 rows 才是主要計算基礎。
• 照單全收 select：報表畫面顯示的欄位不一定全部都需要帶進 API。
• 沒有確認 mode：預設 subdomains 可能讓查詢範圍大於原本想像。
• 把一次性 HTML 當成 live dashboard：沒有排程與資料更新，就只是特定日期的快照。
• 讓 AI 自動重試與分頁：每一頁、每一次重試都可能變成新的付費 request。
• 把估算值當成實際值：Ahrefs 的 Organic Traffic、Traffic Value 等指標是模型估算，重要判斷仍應搭配 GSC、網站分析與實際業務資料。

如果同時使用 Brand Radar 與 Site Explorer，還要注意兩者回答的問題不同。站內的Brand Radar 與 Site Explorer 差異，可以接著說明為什麼兩邊看到的 AI／SEO 數字可能不一致。

---

總結：先分清楚連線、查詢、取數與呈現

Ahrefs 手查、REST API 與 MCP 並不是三套互相競爭的資料服務。手查讓人操作；REST API 讓程式按照固定參數取數；MCP 讓 AI 用自然語言選擇並呼叫 Ahrefs 工具。

Dashboard 的 API 按鈕只負責把目前畫面翻成查詢，不負責提供權限，也不負責製作報表。API Key／OAuth 解決連線與授權，API／MCP 解決取數，Report Builder、Looker Studio、HTML 或 PDF 才解決呈現。

遇到一條看不懂的 Ahrefs 長網址時，不必急著執行。先把它翻譯成「查誰、查哪裡、哪一天、要幾列、要哪些欄位、最多花多少 units」，就能把看似技術性的問題，重新變成可以管理的商業決策。

---

Ahrefs API、MCP 與報表常見問題

Ahrefs API 網址可以直接貼給 Codex 嗎？

可以用來讓 Codex 理解查詢條件，但不要附上真實 API Key。要真正取得資料，Codex 還需要已授權的 Ahrefs MCP 或安全設定的 API 連線。

只貼 Ahrefs Dashboard 網頁網址可以嗎？

通常不夠。私人 Dashboard URL 不會自動把你的登入狀態、表格內容與 API 權限一起交給 Codex。比較準確的方式是貼已遮蔽憑證的 cURL，或直接寫出網站、國家、日期、欄位與筆數。

MCP 和 REST API 查相同資料，費用會一樣嗎？

如果使用相同 endpoint、fields、filters、sorting 與回傳 rows，成本原則上相同。Ahrefs 官方說明，MCP 代替使用者發出的呼叫與直接 API 使用相同的月度 API units。實際扣除仍要看 cache 與 response usage headers。

API URL 可以直接變成 Looker Studio 報表嗎？

不能只靠貼網址完成。Looker Studio 需要能處理驗證與欄位結構的 connector，或先把 API 資料保存到可讀取的資料源。Brand Radar 有官方 Connector 時，優先採用官方連線方式。

Brand Radar saved report 等於 API 嗎？

不等於。Saved report 主要保存品牌 entities、競爭者、filters 與 location，讓你回到相同設定查看。API 則讓程式取得資料。兩者可以描述相近條件，但使用方式不同。

不會寫程式，還需要理解 API 參數嗎？

不需要自己從零寫程式，但至少要看懂 target、country、date、limit、select 與 order_by。這些參數直接決定查詢範圍、回答內容與 units 成本，也是檢查 AI 有沒有選錯資料的基本能力。

---

官方資料來源

• Ahrefs API Introduction
• Ahrefs API Limits Consumption
• Ahrefs API Keys Creation and Management
• Site Explorer Top Pages API
• What Is Ahrefs MCP
• Ahrefs MCP ChatGPT Web Setup
• Ahrefs Report Builder
• What Is Brand Radar and How to Use It
• How to Create a Report in Brand Radar

本文查核日期為 2026 年 8 月 26 日。Ahrefs 的方案、API units、支援欄位、MCP client 與報表功能可能更新，實際使用前請以官方文件及帳號介面為準。