幾個月前，Stack Overflow 上有位開發者貼出了一個自 2012 年就一直掛著的問題："Google Places API 的 Place Details 是否最多只會回傳 5 則評論？" 十四年過去，幾百個讚，答案還是一樣——對，最多五則評論。光是這一項限制，就足以說明這場爭論為什麼一直存在。
如果你曾經需要大規模的 Google Places 資料——名單開發、競品評論、來客流量模式、在地 SEO 稽核——你大概也走到過同樣的岔路口。官方的 Google Places API 乾淨、結構化，而且文件完整。但它不會回傳你在 Google Maps 頁面上看得到的所有內容，而且一旦超過免費額度，費用很可能迅速失控。爬取可以拿到更多資料，成本結構也不同，但麻煩也不少（CAPTCHA、選擇器失效、法律灰色地帶）。我花了很多時間研究兩邊——API 文件、計價 SKU、爬取工具鏈，以及實務上的取捨——這篇文章就是整理後的成果。我們會逐欄對照資料缺口、比較在 1 萬 / 10 萬 / 100 萬筆時的真實成本、談反機器人現實，以及一套實用的混合策略。最後還會附上決策流程圖，畢竟沒人想讀完 3,000 字後，還是不知道該選哪個。
什麼是 Google Places API？它到底能提供哪些資料？
Google Places API 是 Google 官方、結構化的商家資料取得方式——包含名稱、地址、電話、評分、評論、照片等，都是從他們的資料庫中拉取。你送出 HTTP request，就會拿到格式化後的 JSON。這是官方認可的管道。
目前的版本（Places API「New」）是以 field mask 為核心。當你呼叫 Place Details 時，必須明確指定要哪些欄位——像是 displayName、formattedAddress、rating、reviews、photos 等——而 Google 會依你要求的最高級別欄位來計費。如果不帶 field mask，系統不會回預設結果，而是直接報錯。這樣設計的目的很明確：Google 希望你只為自己真正使用的資料付費，而且越「高級」的資料，收費也越高。
可用欄位 依照不同價格層級劃分：
| 層級 | 範例欄位 | 可取得的內容 |
|---|---|---|
| Essentials | Place ID、格式化地址、位置、照片中繼資料 | 基本身分與位置資訊 |
| Pro | 顯示名稱、商家狀態、Google Maps URI、主要類型 | 更完整的商家資料 |
| Enterprise | 評分、使用者評分數、網站、電話、營業時間、價格等級 | 多數商業用戶最想要的欄位 |
| Enterprise + Atmosphere | 評論、評論摘要、生成式摘要、設施、停車、外帶 / 外送 | 最豐富、也最昂貴的資料 |
多數使用者最常用的端點包括：Autocomplete（邊打邊搜）、Text Search 與 Nearby Search（搜尋地點）、Place Details（補強既有地點資訊）、以及 Place Photos（圖片）。
但真正重要的限制有這些：
- 評論： Place resource 每個地點最多只回傳 5 則評論，並依相關性排序。就這樣。不是 50 則，也不是「全部」。只有五則。
- 照片：Place resource 中每個地點最多只提供 10 個照片參照。
- 熱門時段 / 即時擁擠程度：不是標準 Places API 欄位。Google 確實證實這類資料存在（依據彙總且匿名化的位置歷史資料），而且他們的 Maps 部落格也有說明 其運作方式——但 欄位清單 裡就是沒有它。
- Q&A 區塊：不會暴露出來。
- 「大家也搜尋這些地方」的競品建議：不會暴露出來。
- 菜單 / 價格表：不是標準欄位。
誰通常會用 Google Places API？
- 物流公司：驗證地址與地理編碼
- 旅遊與飯店應用：顯示附近飯店、餐廳、景點
- 房地產平台：用在地商家資料補強物件資訊
- 在地 SEO 顧問：稽核 NAP（名稱、地址、電話）一致性
- 業務團隊：根據 Place ID 與基本商家資訊建立名單
如果你的需求很單純，就是「我想在正式上線的產品裡拿到結構化地點資料」，API 會是對的起點。如果你的需求裡出現「全部評論」、「熱門時段」或「競品分析」，那就繼續往下看。
什麼叫做「爬取」Google Places 資料？
網頁爬蟲 是指用軟體自動從網頁擷取資料——在這裡，就是從 Google Maps 或 Google Search 結果頁擷取，而不是透過官方 API。爬蟲會像你的瀏覽器一樣讀取頁面，然後把可結構化的部分抓下來：商家名稱、地址、評論文字、星等評分、熱門時段圖表、Q&A、競品建議、完整照片庫，以及畫面上呈現的其他資訊。
重點差異在於：API 給你的是 Google 願意對外開放的內容；爬取則是理論上能拿到人類在頁面上看得到的一切。
不過「爬取」不是單一做法，而是三種很不一樣的路線，而且彼此取捨差異很大。
DIY 腳本 vs 代管式爬取 API vs 無程式碼工具
| 做法 | 運作方式 | 最適合誰 | 主要取捨 |
|---|---|---|---|
| DIY 腳本（Puppeteer、Playwright、Selenium） | 你自己撰寫並維護無頭瀏覽器腳本，導覽 Google Maps 頁面並解析 DOM | 需要完全控制與自訂邏輯的開發者 | 維護成本最高——Google 一改 UI，選擇器就可能壞掉 |
| 代管式爬取 API（Thunderbit API、SerpApi、Outscraper） | 你把 URL 或查詢丟給 API；它負責渲染、反機器人處理與解析，然後回傳結構化資料 | 想要結構化輸出、又不想自己維護爬蟲的開發者 | 不同供應商的價格與品質差異很大；你得信任第三方 |
| 無程式碼瀏覽器擴充套件 (Thunderbit Chrome Extension) | 在瀏覽器裡點選擷取，AI 會先建議欄位，你再按「爬取」，匯出到 Sheets / Excel | 需要快速把資料整理到試算表的商務使用者、行銷、業務團隊 | 對複雜流程彈性較低；依賴工具的 AI 品質 |
簡單來說：DIY = 最彈性，但維護成本最高。代管 API = 有結構化輸出，幾乎不用維護。無程式碼工具 = 非開發者最快上手。
Google Places API 與爬取：逐欄位資料比較
這就是我當初研究這個主題時最希望存在的表格。把商務用戶或開發者可能需要的每個欄位，一次攤開來比：
| 資料欄位 | Google Places API | 網頁爬取 |
|---|---|---|
| 商家名稱 | ✅ 完整（Pro 層級） | ✅ 完整 |
| 地址 / 位置 | ✅ 完整（Essentials 層級） | ✅ 完整 |
| 電話號碼 | ✅ Enterprise 層級 | ✅ 可見時可取得 |
| 網站 URL | ✅ Enterprise 層級 | ✅ 可見時可取得 |
| 整體評分 | ✅ Enterprise 層級 | ✅ 完整 |
| 使用者評分數 | ✅ Enterprise 層級 | ✅ 完整 |
| 單則評論（文字 + 評分） | ⚠️ 最多 5 則評論 | ✅ 可取得全部可見評論 |
| 熱門時段 / 即時擁擠程度 | ❌ 不是標準 API 欄位 | ✅ 可擷取（若頁面有渲染） |
| Q&A 區塊 | ❌ 不會暴露 | ✅ 可擷取 |
| 照片中繼資料 | ✅ 透過 Photos 端點最多 10 個參照 | ✅ 完整圖庫 |
| 菜單 / 價格表 | ❌ 不是標準欄位 | ⚠️ 頁面有顯示時可取得 |
| 「大家也搜尋這些地方」（競品） | ❌ 不會暴露 | ✅ 可擷取 |
| 營業時間 | ✅ Enterprise 層級 | ✅ 可見時可取得 |
| 價格等級 | ✅ Enterprise 層級 | ✅ 可見時可取得 |
| Place ID | ✅ 非常可靠（Essentials） | ⚠️ 可以嘗試，但 API 是權威來源 |
| Google Maps URI | ✅ Pro 層級 | ✅ 就是頁面 URL |
| 店家對評論的回覆 | ⚠️ 需確認目前是否可用 | ✅ 常可見 |
| SERP / map-pack 名次 | ❌ 不是 API 的用途 | ✅ 可透過 SERP 爬取 |
最關鍵的落差是：如果你需要完整評論集合來做情緒分析、口碑監測或競品基準比較，單靠 API 根本不夠。每個地點只有 5 則評論，這只是樣本，不是資料集。
熱門時段與來客流量模式也是同樣情況。如果你是零售顧問或商用不動產分析師，爬取幾乎是唯一選擇——這類資料根本不在 API 裡。
反過來說，如果你要的是權威的 Place ID、可用來地理編碼的結構化地址，或是要做店家定位頁，API 會更乾淨、更穩定，也有官方支援。
真實成本：Google Places API 與爬取在 1 萬、10 萬、100 萬筆資料時的差異
成本是這個決策裡最容易被誤解的部分。很多人先用 API 免費額度做出原型，等規模一拉高，帳單就會讓人倒抽一口氣。至於爬取這邊，大家常常低估了代理成本和開發時間。
所以我們直接算給你看。
Google Places API 計價拆解
Google 在 2025 年 3 月重新整理了 Maps Platform 的計價方式，將原本固定的 每月 200 美元額度 改成 SKU 層級的免費次數與按量分級計價。目前的 價格 大致如下：
- Essentials 欄位（Place Details）：每月 10,000 次免費請求，之後每 1,000 次 $5.00，最高到 10 萬次
- Pro 欄位（Place Details）：5,000 次免費，之後每 1K $7.00
- Enterprise 欄位（Place Details）：1,000 次免費，之後每 1K $20.00
- Enterprise + Atmosphere（評論、設施）：1,000 次免費，之後每 1K $25.00
關鍵細節在這裡：如果你的 field mask 裡只要包含一個 Enterprise + Atmosphere 欄位（像 reviews），整個 request 就會以那一層級計費。而且典型流程通常會串接多個 SKU——先用 Text Search Pro 找地點，再用 Place Details Enterprise + Atmosphere 補資料——成本是疊加上去的。
所以一次「查詢」很少只會產生一筆帳單請求。
爬取成本：工具、代理與開發時間
爬取成本可以拆成三塊：
- 工具訂閱或 API 點數：代管式爬取 API 通常會按請求、按點數或按筆資料計費。SerpApi 是按搜尋次數收費。Outscraper 採用按筆資料付費。Thunderbit API 則是點數制（Extract = 每次請求 20 點）。Thunderbit Chrome Extension 則是每輸出一列 1 點。
- 代理伺服器成本（僅限 DIY）：針對 Google Maps 爬取的住宅代理，通常每月約 $50–$300，視流量與供應商而定。
- 開發時間（僅限 DIY）：要自己打造並維護 Puppeteer / Playwright 腳本。這是最容易被忽略、但最傷經濟效益的隱藏成本（下面會再談）。
API 與爬取的規模化成本對照表
| 規模 | Google Places API（Enterprise + Atmosphere） | 代管式爬取 API（估算） | DIY 爬取（代理 + 開發時間） |
|---|---|---|---|
| 每月 1 萬筆 | 約 $225（1K 免費，9K × $25/1K） | 約 $50–$150，依供應商而異 | 約 $50 代理費 + 每月 2–4 小時開發維護 |
| 每月 10 萬筆 | 約 $2,475（超過免費額度後，適用分級價格） | 約 $250–$500 | 約 $150 代理費 + 每月 8–16 小時開發維護 |
| 每月 100 萬筆 | 約 $17,975（雖有量大折扣，但總額仍然很高） | 約 $1,500–$3,000 | 約 $300 代理費 + 每月 20+ 小時開發維護 + 壞掉風險 |
註：API 估算是依據 Google 公布的量大分級價格，並在 1K 免費額度後套用於 Place Details Enterprise + Atmosphere。代管式爬取 API 估算為各家供應商的概略區間。DIY 開發時間假設每小時全成本 $50–$100。
趨勢很清楚：在小量測試規模（1 萬筆以下），如果你只需要 Essentials 或 Pro 欄位，API 的免費額度常常就是最便宜的方案。到了商業規模（10 萬筆以上），API 成本會快速飆升，尤其是需要豐富欄位時。到了企業規模（100 萬筆以上），API 每月可能逼近五位數，這時爬取或資料服務在經濟上就很有吸引力——前提是你真的需要 API 沒有提供的那些欄位。
如果你只需要地址和 Place ID，就不要爬。這種情況下 API 更便宜，也更適合。只有當你需要 API 拿不到的資料時，爬取的成本論點才成立。
反機器人現實檢查：為什麼 DIY Google 爬蟲常常壞掉
這一段是很多爬蟲推廣者不太會提的。Google 不想讓你爬 Google Maps。他們已經建了多層防護，而且還會定期更新。
Google 的多層防線
- reCAPTCHA 挑戰：自動化瀏覽器觸發 CAPTCHA 的機率遠高於真人
- 前端 JavaScript 渲染：Google Maps 是重度 JavaScript 應用，單純 HTTP request 拿不到渲染後內容——你需要完整的無頭瀏覽器
- 瀏覽器指紋辨識：Google 會透過 canvas 指紋、WebGL、navigator 屬性等訊號偵測無頭瀏覽器
- IP 流量限制：同一個 IP（或同一代理子網）請求太多就會被擋
- DOM 結構變動：Google 會定期調整頁面架構——Reddit 和 GitHub issue 的共識是，選擇器常常每隔幾週到幾個月就會失效一次
最後這點最致命。六月還跑得好好的 Puppeteer 腳本，到了七月可能就全空了，只因為 Google 改了一個 CSS class，或重組了一個 div。
維護 DIY 腳本的隱藏成本
每次 Google 改 DOM，你團隊裡就得有人去做這些事：
- 先發現爬蟲壞了（最好是在錯誤資料擴散前）
- 檢查新的頁面結構
- 更新選擇器、處理新的 CAPTCHA 類型、調整重試邏輯
- 測試並重新部署
放大到一年來看，這些維護時間很容易超過代管式爬取 API 的訂閱費用。我看過有些團隊為了維持 Google Maps 爬蟲運作，一年燒掉超過 40 小時的開發時間——而且這還是對中等複雜度架構的保守估算。
為什麼會有代管式爬取 API？
這種維護負擔，正是 Thunderbit 的 API、SerpApi 與 Outscraper 存在的原因。它們把反機器人複雜度——JS 渲染、CAPTCHA 處理、代理輪換、選擇器維護——都接走，直接回傳結構化資料。
Thunderbit 的 POST /extract 端點搭配 renderMode: "full"，可以處理像 Google Maps 這種高度依賴 JavaScript 的頁面，回傳的是符合 schema 的結構化 JSON，而不是還得自己再解析的原始 HTML。 MCP server 甚至把這件事延伸到 AI agent——Claude、Cursor 或其他基於 LLM 的工作流，都能在任務執行途中直接抓取 Google Maps 資料，而不必離開自己的環境。
對非技術使用者來說，Thunderbit Chrome Extension 就是零維護方案：打開 Google Maps 頁面，點「AI Suggest Fields」，再點「Scrape」，然後匯出到 Sheets。沒有選擇器、沒有代理、沒有除錯。
SerpApi 和 Outscraper 也是不錯的替代方案，只是價格模型與輸出格式不同。SerpApi 每次搜尋回傳結構化 JSON；Outscraper 則是按筆資料、採用即用即付。最適合哪個，取決於你的量、預算，以及你需不需要結構化 JSON，或是能不能接受半結構化輸出再自行解析。
混合策略：把 Google Places API 和爬取一起用
這個主題裡，幾乎沒有高排名文章會提到一件我實務上看到最好用的方法：兩個都用。很多團隊最後都是一部分工作交給官方 API，一部分工作交給爬取。關鍵是把每個工具放在最適合的位置。
什麼情況下官方 API 會贏
- 正式上線應用裡的 Autocomplete：低延遲、符合 ToS、SLA 穩定，沒有懸念。
- 以位置為核心的應用後端：店家定位頁、地址驗證、Place ID 對應。API 結構化、受支援、文件完整。
- 對合規敏感的整合：企業合約、對外產品，或任何 Google ToS 合規不能妥協的情境。
什麼情況下爬取會贏
- 完整評論擷取（每個地點 5K+ 則評論）：情緒分析、口碑監測、競品基準比較。API 的 5 則上限在這裡幾乎沒用。
- 一次性名單擷取：對於沒有持續帳單的批次作業，爬取更便宜。像 Thunderbit 這類無程式碼工具 可以在幾分鐘內抓一整串商家並匯出試算表。
- 熱門時段 / 來客流量分析： API 根本沒有提供。就是這樣。
- Q&A 資料、競品「大家也搜尋」：只會出現在頁面上，不會進 API。
什麼情況下適合混合做法
- 持續性的價格 / 評分監控：先用 API 取得基本結構化資料（Place ID、地址、整體評分），再用爬取補足深層欄位（完整評論、熱門時段）。
- 補強型工作流：先用 API 拿 Place IDs 和權威商家資訊，再去爬個別列表頁，抓完整評論集、Q&A 和競品脈絡。
- 排程監控：Thunderbit 的排程爬蟲（無程式碼用戶）或 CLI 批次擷取搭配 cron（開發者）都能處理重複性爬取，不需要自建基礎設施。
使用情境決策矩陣
| 使用情境 | 建議方式 | 原因 |
|---|---|---|
| 正式應用中的 Autocomplete | ✅ 官方 API | 低延遲、符合 ToS、可靠 |
| 抓取 5K+ 完整評論集 | ✅ 爬取 / 爬取 API | API 每個地點最多只有 5 則評論 |
| 一次性本地商家名單 | ✅ 爬取（或 Thunderbit 擴充套件） | 批次處理更便宜；沒有持續帳單 |
| 熱門時段 / 來客流量分析 | ✅ 只用爬取 | API 沒有提供 |
| 持續價格 / 評分監控 | ⚠️ 混合 | API 管基本資料，爬取補深度欄位 |
| 以位置為核心的應用後端 | ✅ 官方 API | 結構化、受支援、有 SLA |
| Local SEO SERP 名次追蹤 | ✅ 爬取 / SERP API | 不是 Places API 的用途 |
| 競品「大家也搜尋」 | ✅ 只用爬取 | API 不會暴露 |
決策流程圖：Google Places API vs 爬取，你該怎麼選？
與其回答一句模糊的「看情況」，不如直接給你一套具體判斷框架。請依序回答這四個問題：
1. 你是否需要在正式產品裡即時資料？ → 是：用官方 API。它有支援、有 SLA，而且符合 ToS。到這裡就可以停了。 → 否：繼續。
2. 你是否需要 API 不會回傳的資料（完整評論、熱門時段、Q&A）？ → 是：必須爬取。API 根本給不了這些資料。 → 否：繼續。
3. 你每月大概要處理多少筆資料？ → 少於 1 萬筆：API 很可能最便宜，尤其只需要 Essentials 或 Pro 欄位時。免費額度在這個量級很夠用。 → 超過 1 萬筆：爬取或代管式爬取 API 往往更划算，尤其是需要豐富欄位時。
4. 你有沒有開發資源可以自己做與維護爬蟲？ → 有：用 Puppeteer / Playwright DIY，控制力最高（但要預留持續維護成本）。 → 沒有：改用代管式爬取 API（Thunderbit API、SerpApi、Outscraper）或無程式碼工具（Thunderbit Chrome Extension）。
面向開發者的替代方案快速比較
| 工具 | 計價模式 | 輸出格式 | 能否處理反機器人 | 批次支援 |
|---|---|---|---|---|
| Thunderbit API / MCP | 點數制（Extract = 每次請求 20 點） | 符合 schema 的結構化 JSON | ✅ JS 渲染、代理輪換、地理路由 | ✅ 每批最多 100 個 URL |
| SerpApi | 每次搜尋（分級方案） | 結構化 JSON | ✅ | ✅ 透過 API 參數 |
| Outscraper | 按筆資料（即用即付） | JSON / CSV | ✅ | ✅ 透過任務佇列 |
| DIY（Puppeteer / Playwright） | 代理 + 開發時間 | 原始 HTML（你自己解析） | ❌ 你自己處理 | ✅ 取決於你怎麼做 |
Thunderbit API 的差異化亮點在於：它會根據你定義的 JSON Schema 回傳符合結構的 JSON，而不是還要再解析的原始 HTML 或 Markdown。若你要接 LLM 工作流或匯入資料庫，這能省下大量後處理時間。
Thunderbit 在這裡怎麼派上用場（給商務使用者與開發者）
我們打造 Thunderbit 的目的，就是把「我需要 Google Maps 資料」和「我不想自己變成爬蟲基礎架構工程師」之間的缺口補起來。以下是它對兩種受眾的用法。
給非技術使用者：Chrome 擴充套件
- 打開 Google Maps 頁面——可以是搜尋結果頁，也可以是單一商家列表
- 點「AI Suggest Fields」——Thunderbit 的 AI 會讀取頁面並建議欄位（商家名稱、地址、評分、評論、電話等）
- 點「Scrape」——擴充套件會把資料擷取成結構化表格。可使用雲端模式，同時處理最多 50 個頁面
- 爬取子頁面——點「Scrape Subpages」逐一進入各列表頁，抓完整資料
- 匯出——到 Excel、Google Sheets、Airtable 或 Notion。資料匯出免費，沒有付費牆
若是週期性監控——每週競品評分檢查、新店家名單——排程爬蟲會依你設定的頻率自動執行。
給開發者：API、MCP Server 與 CLI
POST /extract搭配 JSON Schema：送入 Google Maps URL，定義你要的欄位，回傳結構化 JSON。對 JavaScript 很重的頁面可設定renderMode: "full"。Thunderbit 會處理 渲染、反機器人、代理輪換與地理路由。POST /distill：從任何頁面取得乾淨的 Markdown——對需要原始內容而非結構欄位的 LLM 工作流很有用。每次請求 1 點，而不是 20 點。- MCP Server：AI agents（Claude、Cursor）可以在任務途中抓取 Google Maps 資料。支援摘要提取、結構化擷取、欄位建議，以及最多 100 個 URL 的批次作業。
- CLI：
thunderbit batch extract --file urls.txt --schema places.json，可用於排程或整合到 CI/CD 的爬取流程。
點數價格：Extract = 每次請求 20 點，Distill = 每次請求 1 點。API 點數是按請求計費，不是按列計費（不同於擴充套件，1 點 = 1 輸出列）。最新方案請見 Thunderbit Pricing。
法律與服務條款考量
我會簡短而務實地說——不嚇人，也不賣弄。
Google Places API 有清楚的條款：Google 的服務專屬條款 說明，Places API 內容可以在沒有 Google Map 的情況下使用，但不能搭配非 Google 地圖。緯經度資料最多可快取 30 個連續日曆天；Place ID 可以永久保存。此外，詳細資料、照片與評論都需要標註來源。
爬取 Google Maps 可能違反 Google 的服務條款。執法強度不一，風險包括 IP 封鎖、CAPTCHA 阻擋，極少數情況下還可能涉及法律行動。代管式爬取 API 通常會替使用者承擔一部分合規複雜度，但這不等於法律保障。
如果你做的是面向終端使用者的正式產品，官方 API 通常是更安全的選擇。若是內部研究、批次分析或競業情報，爬取在業界其實很常見。若是商業工作流程，請諮詢你自己的法律顧問。
如果是我，我會怎麼選？
在看完計價 SKU、欄位清單、社群討論與工具文件之後，我的結論是：
- 用官方 API：當你需要在正式產品中取得即時、符合 ToS 的資料，或是 Essentials / Pro 欄位已經足夠，而且每月量少於 1 萬筆時。小規模下免費額度很大方，資料品質也無可挑剔。
- 用爬取（代管 API 或無程式碼工具）：當你需要完整評論、熱門時段、Q&A、競品脈絡，或任何 API 不會暴露的欄位時。若每月規模超過 1 萬到 10 萬筆，而且你查的是豐富欄位，API 帳單就很難說服自己。
- 兩者並用：當你的流程同時需要權威 Place ID 與基本結構化資料（API），又需要頁面上看得到的深度情報（爬取）時。這比大多數文章承認的情況還常見。
成本轉折點也很明確：在每月約 1 萬筆以下、且只用基本欄位時，API 更簡單，而且常常免費。超過這個量，尤其是要豐富資料時，爬取通常更划算。若是 100 萬筆且使用 Enterprise + Atmosphere 欄位，API 大約會到每月 1.8 萬美元，而代管式爬蟲只需要其中一小部分。
如果你想親自測試，Thunderbit Chrome Extension 是最快看出爬取能抓到什麼、API 又少了什麼的方法。若是開發者流程，Thunderbit API 文件 已經把入門所需都整理好了。至於想進一步了解無程式碼網頁爬蟲 或 AI 網頁爬蟲，我們也已經在部落格裡做了完整整理。
重點摘要
- Google Places API 是正式產品、Autocomplete 與結構化地點查詢的正確工具——但評論最多只回傳 5 則、照片最多 10 張，而且不會暴露熱門時段、Q&A 或競品建議。
- 爬取可以抓到 Google Maps 頁面上可見的所有內容，包括完整評論集與熱門時段資料，但你得自己處理反機器人防護，或付費使用代管服務。
- 在每月少於 1 萬筆時，API 的免費額度通常就是最便宜的方案。超過 10 萬筆時，若需要豐富資料，爬取或代管爬取 API 通常更划算。
- DIY 爬蟲會因 Google 的反機器人防護與 DOM 變動而頻繁失效——每年要預留 40 小時以上的開發維護時間，或者直接用代管工具。
- 實務上最好的策略往往是混合：用 API 取得權威 ID 與基本欄位，再用爬取補足 API 無法提供的深度情報。
- Thunderbit 同時服務兩邊：無程式碼使用者可用 Chrome 擴充套件，開發者則可使用結構化 JSON API / MCP server。
常見問題
能透過 Places API 拿到超過 5 則 Google 評論嗎？
不能。Google Places API 每個地點最多只回傳 5 則評論，而且依相關性排序。這從 API 上線以來就是如此，雖然多年來開發者一直要求更高上限，但始終沒有改變。若你要取得商家的全部可見評論，唯一方法就是爬取（DIY 或使用代管式爬取 API）。
爬取 Google Maps 合法嗎？
沒有一個能放諸四海皆準的簡單答案。爬取公開可見的 Google Maps 資料可能違反 Google 的服務條款，執法範圍從 IP 封鎖到（少數情況下）法律行動不等。許多企業會把爬取用於內部研究與競業情報，而沒有出現問題。代管式爬取 API 會吸收一部分合規風險，但它們不是法律保護傘。如果你要打造商業產品，或處理個人資料，請諮詢法律顧問。
如果我要查 100K 筆，Google Places API 會花多少錢？
取決於你要哪些欄位。若是 Place Details 的 Essentials 層級，大約 $450。Pro 層級約 $1,615。Enterprise + Atmosphere（包含評論與設施）約 $2,475。如果你的流程還需要用 Text Search Pro 來搜尋地點，還要再加約 $3,040。這些估算是依據 Google 公布的量大分級價格，並假設每筆資料都會產生一筆計費請求（超過免費額度後）。
爬取 API 和無程式碼爬取工具有什麼差別？
爬取 API（像 Thunderbit 的 Open API）是給開發者的，透過 HTTP request 把爬取整合到程式碼、自動化流程或 AI agent 工作流中。無程式碼工具（像 Thunderbit Chrome Extension）則讓非技術使用者可以直接在瀏覽器裡點選、擷取並匯出資料，不需要寫任何程式。兩者都能回傳結構化資料；差別在於介面與整合方式。
Thunderbit 能在 Google Maps 頁面上運作嗎？
可以。Chrome 擴充套件可爬取 Google Maps 的搜尋結果頁與單一商家列表——AI 會自動建議欄位，而且雲端模式最多可同時處理 50 個頁面。API 的 POST /extract 端點搭配 renderMode: "full" 可以處理 Google Maps 這種由 JavaScript 渲染的頁面，並回傳符合 schema 的結構化 JSON。MCP server 則能讓 AI agent 在工作流中途直接抓取 Google Maps 資料。
延伸閱讀
