Google Maps 爬蟲 GitHub：2026 年哪些可用、哪些會壞

GitHub 上大約有 符合「google maps scraper」。但其中大多數都已經失效了。

這聽起來很誇張，不過如果你曾經 clone 過 repo、跟 Playwright 依賴項纏鬥過，還在凌晨 2 點看著爬蟲吐出空白 CSV，你大概就懂那種感覺。Google Maps 全球有 ——它是地球上最完整的在地商家資料庫之一。難怪從業務開發到代理商老闆，大家都想把這些資料抓下來。問題在於，Google 會以數週到數月的頻率調整 Maps 介面，而每一次改動都可能悄悄弄壞你才花一小時設好的爬蟲。就像一位 GitHub 使用者在 2026 年 3 月的 issue 裡說的，這個工具 這不是冷門邊緣案例，而是核心流程直接壞掉。我今年一直密切追蹤這些 repo，發現「GitHub 上看起來很活躍」和「今天真的能抓到資料」之間的落差，比多數人想像得還大。這篇指南是我誠實整理訊號與雜訊的嘗試——會說明哪些 repo 能用、哪些會壞、什麼時候該直接跳過 GitHub，以及抓完資料後接下來該怎麼做。

GitHub 上的 Google Maps 爬蟲是什麼？為什麼大家會用？

GitHub 上的 Google Maps 爬蟲通常是 Python 或 Go 腳本（有時包在 Docker 裡），會在無頭瀏覽器中開啟 Google Maps，輸入像「芝加哥的牙醫」這類搜尋詞，然後擷取畫面上顯示的商家列表資料——名稱、地址、電話、網站、評分、評論數、分類、營業時間，有時還包括經緯度。

GitHub 會成為這類工具的預設據點，原因很簡單：程式碼免費、開源，而且理論上還能自行客製。你可以 fork 一個 repo、調整搜尋參數、加上自己的 proxy 邏輯，並匯出成你需要的任何格式。

大家通常想抓的資料欄位大致如下：

誰會用這些工具？做外撥名單的業務團隊、分析在地市場的房地產專業人士、做競品分析的電商團隊、執行在地 SEO 稽核的行銷人員。共同點很簡單：他們都需要結構化的在地商家資料，而且不想一筆一筆從瀏覽器手動複製貼上。

為什麼業務與營運團隊會搜尋 Google Maps 爬蟲 GitHub repo

Google Maps 之所以有吸引力，原因很單純：在地商家資訊真的就在那裡。不是某個冷門目錄，不是在付費牆後面，而是直接放在搜尋結果裡。

這個商業價值主要可分成三大類。

名單開發與潛在客戶挖掘

這是最主要的用途。一位為自由工作者和代理商打造 Google Maps 爬蟲的創辦人，曾直白描述這個流程： 其中一個最活躍的 repo（gosom/google-maps-scraper）甚至直接告訴使用者，可以請它的 agent 這不是興趣型用途，而是銷售管道。

市場研究與競品分析

營運與策略團隊會用抓回來的 Maps 資料，按社區統計競爭者、分析評論情緒、找出市場缺口。一位在地 SEO 從業者曾 。這種分析如果要靠人工大規模完成，幾乎不可能。

在地 SEO 稽核與名錄網站建置

行銷人員會抓 Google Maps 來稽核在地搜尋曝光、檢查 NAP（名稱、地址、電話）一致性，並建立目錄網站。有位使用者曾 。

為什麼抓取會讓人心動的勞動成本算術

就算是用瀏覽器視窗人工蒐集，也不是免費。Upwork 把行政資料輸入的虛擬助理報價放在 。如果一個人每家花 1 分鐘抓基本資訊，1,000 家就要約 16.7 小時——還沒做 QA 前，人工成本大約就是 200–334 美元。若每家花 2 分鐘，同樣名單的成本就變成 400–668 美元。這才是每一個「免費 GitHub 爬蟲」真正要對比的基準。

Google Maps API、GitHub 爬蟲 repo、無程式碼工具：2026 年決策樹

在你 clone 任何東西之前，先選好路線。資料量、預算、技術能力，以及你能接受多少維護成本，都很關鍵。

什麼時候適合用 Google Places API

如果你的查詢量是小到中等，而且你需要官方授權與可預測的帳單，那 API 很明顯是首選。Google 把原本通用的每月額度改成各 SKU 的免費上限：許多 Essentials SKU 有 ，Pro 有 5,000 次，Enterprise 有 1,000 次。之後，Text Search Pro 每 1,000 次收 ，而 Place Details Enterprise + Atmosphere 則是每 1,000 次 5 美元。

最大的限制是評論。API 每個地點最多只會回傳 。如果你需要完整評論內容，API 就不夠用了。

什麼時候適合用 GitHub 爬蟲

如果你要的是大量關鍵字加地理位置的探索、API 欄位之外的瀏覽器可見資料、完整評論文字，或自訂解析邏輯——而且你有能力用 Python/Docker 維護爬蟲，那 GitHub repo 會是正確選擇。代價是，所謂的「免費」只是把費用轉移成時間、proxy、重試和故障處理。光是 proxy 成本就可能累積：，，。

什麼時候適合用像 Thunderbit 這樣的無程式碼工具

如果你的團隊不懂技術？如果優先目標是盡快把資料送進 Sheets、Airtable、Notion 或 CSV？那無程式碼工具可以跳過整個 Python/Docker/proxy 設定流程。使用 ，你只要安裝 Chrome 擴充功能、打開 Google Maps、點一下「AI Suggest Fields」，再點「Scrape」——然後就能 。雲端爬取模式會自動處理反機器人防護，且可 ，不需要設定 proxy。

簡單決策流程： 如果你只需要少於 500 家商家，而且有預算 → 用 API。若你需要數千筆，而且會 Python → 用 GitHub repo。若你需要快速拿到資料、又不想做技術設定 → 用無程式碼工具。

2026 年新鮮度稽核：哪些 Google Maps 爬蟲 GitHub repo 今天真的能用？

這是我希望自己一開始做研究時就已經存在的章節。大多數「最佳 Google Maps 爬蟲」文章只會列 repo 名稱、簡短描述和星數，卻不會告訴你這東西這個月到底還能不能吐資料。

怎麼判斷一個 Google Maps 爬蟲 GitHub repo 還活著

在 clone 任何東西之前，先跑這份檢查清單：

• 最近是否有程式碼提交： 看最近 3–6 個月內是否有真正的 commit，不是只有 issue 留言。
• Issue 健康狀態： 看最近更新的 3 個 issue，內容是核心故障（空欄位、selector 錯誤、瀏覽器當機）還是功能需求。
• README 品質： 是否有完整文件說明目前的瀏覽器堆疊、Docker 設定與 proxy 配置。
• Issue 裡的警訊詞： 搜尋「search box」、「reviews_count = 0」、「driver」、「Target page」、「selector」、「empty」。
• Fork 與 PR 活動： 有活躍 fork 與已合併 PR，通常代表社群還在維護。

如果沒有近期程式碼活動、核心爬取 bug 也沒修，還沒有 proxy 或瀏覽器維護指引，那這個 repo 多半不夠活躍，不適合商業用途——即使星數看起來很漂亮。

評估過的熱門 Google Maps 爬蟲 GitHub repo

我依照上面的方法，評估了星數最高的一批 repo。以下是總表，後面會有個別說明。

gosom/google-maps-scraper

目前是最強的開源通用型選擇。README 的成熟度異常高：CLI、web UI、REST API、Docker 指令、proxy 配置、grid／bounding-box 模式、Email 擷取，以及多種匯出目標。它聲稱可抓 ，也明確寫了 proxy，因為「對於較大規模的爬取工作，proxy 有助於避免速率限制。」

缺點不是沒人維護，而是邊緣欄位的正確性漂移。2026 年的新 issue 顯示 、，以及 。所以它在商家列表擷取上仍可信，但如果你要豐富的評論與營業時間資料，就還得等修復。

omkarcloud/google-maps-scraper

因為星數高、存在時間長，所以很顯眼，但它看起來比較像封裝好的 extractor 產品，而不是透明的 OSS——有支援管道、桌面安裝檔、加值服務。2026 年 4 月有位使用者說，應用程式啟動後終端機一直噴出 ，最後卡住不動。另一個未解 issue 則抱怨工具 它不是死了，但對想要可檢視、可自行修補的 OSS 讀者來說，不算最乾淨的答案。

gaspa93/googlemaps-scraper

它不是那種通用的大規模搜尋名單爬蟲，而是一個專門的 ，從特定 Google Maps POI 評論 URL 出發，抓取近期評論，並支援 metadata 擷取與評論排序。這種較窄的定位其實對某些工作流程很有價值——但它沒有解決大多數商業使用者真正關心的「搜尋發現」問題。

conor-is-my-name/google-maps-scraper

很符合現代營運團隊的直覺：Docker 優先安裝、JSON API、商務友善欄位，還在 裡有社群曝光。不過 2026 年 3 月的 issue 正好示範了這類工具有多脆弱：某位使用者更新容器後，輸出顯示爬蟲 這是核心流程失敗，不是外觀層級的小問題。

Zubdata/Google-Maps-Scraper

紙面上它的欄位很廣：email、評論、評分、地址、網站、電話、分類、營業時間。實際上，公開 issue 區卻說了不同的故事：使用者回報 、，以及 。再加上較舊的提交歷史，很難推薦它作為 2026 年的選擇。

patxijuaristi/google_maps_scraper

在 GitHub 搜尋裡很容易找到，但最強的公開訊號是一個 ，而不是活躍維護。它出現在這篇文章裡，主要是作為「搜尋上看起來還活著，但實務上很風險」的例子。

逐步教學：如何從 GitHub 設定一個 Google Maps 爬蟲

你已經決定 GitHub repo 是正確路線了嗎？那實際的設定流程大概會長這樣。我這裡會講通用流程，不綁定特定 repo——因為目前活躍選項的步驟其實驚人地相似。

步驟 1：克隆儲存庫並安裝相依套件

常見流程如下：

1. git clone 該 repo
2. 建立 Python 虛擬環境（或拉取 Docker 映像）
3. 透過 pip install -r requirements.txt 或 docker-compose up 安裝相依套件
4. 有時還要安裝瀏覽器執行環境（Playwright 用 Chromium、Selenium 用 ChromeDriver）

像 和 這種 Docker 優先的 repo，可以減少相依套件地獄，但不會完全消失——你還是需要 Docker 正常運作，並且有足夠磁碟空間放瀏覽器映像。

步驟 2：設定搜尋參數

多數通用型爬蟲都會想要：

• 關鍵字 + 地點（例如「Austin TX 的水電工」）
• 結果上限（要抓多少筆）
• 輸出格式（CSV、JSON、資料庫）
• 有時還會支援 地理邊界框 或網格式探索的半徑設定

較好的 repo 會把這些做成 CLI 參數或 JSON request body。較舊的 repo 可能得直接修改 Python 檔案。

步驟 3：設定 proxies（如果需要）

只要不是很小的測試量，就會想用 proxies。，並明確把 proxies 視為大規模任務的標準解法。沒有它們的話，跑幾十次請求後就很可能遇到 CAPTCHA 或 IP 封鎖。

步驟 4：執行爬蟲並匯出資料

執行腳本，看瀏覽器走過結果卡片，然後等待 CSV 或 JSON 輸出。順利路徑只要幾分鐘；但不順的路徑——比任何人承認的都更常見——通常會出現：

• 瀏覽器意外關閉
• Chrome driver 版本不匹配
• selector／搜尋框失敗
• 評論數或營業時間回傳空白

這四種情況都出現在 裡。

步驟 5：處理錯誤與故障

當爬蟲回傳空結果或錯誤時：

1. 查看該 repo 的 GitHub Issues，找有沒有類似回報
2. 檢查是否是 Google Maps UI 變動（新的 selector、不同頁面結構）
3. 更新到 repo 的最新 commit
4. 如果維護者還沒修，看看 forks 有沒有社群補丁
5. 想一想：與其除錯，是否改用其他工具更划算

實際的首次設定時間： 如果你熟悉終端機，但還沒有現成可用的 Playwright/Docker/proxy 環境，第一次成功抓取的現實範圍通常是 30–90 分鐘。不是 5 分鐘。

如何避免在抓 Google Maps 時被封鎖與速率限制

Google 沒有公開一個明確門檻說「你在 X 次請求後就會被封鎖」。Google 故意讓它不透明。有人回報在伺服器型 Playwright 設定下，大約 後就遇到 CAPTCHA；也有人聲稱某個公司自建的 Maps 爬蟲在單一 IP 下每天可跑到 。所以門檻不是高或低，而是不穩定、而且依情境而變。

下面是一張實用策略表：

在請求間加入隨機延遲

固定 1 秒間隔很可疑。要用隨機抖動——動作之間隔 2 到 5 秒，偶爾再加長暫停。這是你最容易做的一件事，而且完全不用花錢。

旋轉 proxies（residential vs. datacenter）

residential proxies 效果更好，因為它們看起來像真實使用者，但成本也更高。最新價格： 、、。datacenter proxies 可以應付輕量爬取，但在 Google 旗下產品上更容易被標記。

隨機化瀏覽器指紋

對無頭瀏覽器爬蟲來說：輪換 user agent、視窗大小和其他指紋訊號。預設的 Playwright／Puppeteer 設定很容易被偵測。這做起來較難，但免費，而且效果很好。

用雲端爬取把問題外包出去

像 這類工具，會透過雲端爬取基礎設施，自動處理反機器人防護、IP 輪換與速率限制。Thunderbit 在雲端模式下可 ——不需要設定 proxy 或延遲。對不想變成兼職反機器人工程師的團隊來說，這是最實際的路線。

Google 的速率限制實際上會長什麼樣子

你被限流的跡象包括：

• 爬取中途出現 CAPTCHA
• 之前成功的查詢突然變成空結果
• 暫時性 IP 封鎖（通常 1–24 小時）
• 頁面載入品質下降（變慢、內容不完整）

恢復方式：停止爬取、輪換 IP、等 15–60 分鐘，再用更低的並行數繼續。如果你經常碰到限制，表示你的設定需要 proxies，或者根本該換方法。

無程式碼退路：什麼時候 GitHub 的 Google Maps 爬蟲不值得你花時間

大約 90% 談 Google Maps 抓取的文章，都假設你會 Python。但很多讀者——代理商老闆、業務、在地 SEO 團隊、研究人員——其實只需要試算表中的一排排資料，不是瀏覽器自動化專案。如果你是這類人，這一節會誠實談清楚取捨。

「免費」GitHub 爬蟲的真實成本

「免費」GitHub 爬蟲其實是把帳單轉移到時間上。如果你把自己的時間估成每小時 50 美元，花 2 小時在設定、1 小時除錯、30 分鐘設定 proxy，那你在抓到任何一筆列表前，就已經花了 175 美元。再加上 proxy 成本和 Google 介面變動後的持續維護，「免費」選項立刻就不便宜了。

Thunderbit 如何簡化 Google Maps 抓取

實際上用 的流程是這樣：

1. 安裝
2. 前往 Google Maps 並執行搜尋
3. 點選 「AI Suggest Fields」 —— Thunderbit 的 AI 會讀取頁面並建議欄位（商家名稱、地址、電話、評分、網站等）
4. 點選 「Scrape」，資料就會自動結構化
5. 使用 子頁面爬取，從抓下來的 URL 進入每家商家網站，擷取更多聯絡資訊（Email、電話號碼）——把 GitHub repo 使用者得手動做的事自動化
6. 匯出到 —— 匯出沒有付費牆

不需要 Python。不需要 Docker。不需要 proxies。不需要維護。對做名單開發的業務與行銷團隊來說，這直接移除了 GitHub repo 原本需要的整個設定負擔。

價格背景： Thunderbit 採點數制，。免費方案每月涵蓋 6 個頁面，免費試用涵蓋 10 個頁面，入門方案為 。

抓完之後：整理與擴充你的 Google Maps 資料

大多數指南都停在原始擷取。原始資料不是名單。論壇使用者經常回報 ，還會問「這種設定下你怎麼處理重複資料？」抓完之後，接下來才是真正的工作。

去除重複資料

重複資料會從分頁重疊、對重疊區域重複搜尋、涵蓋同一批商家的網格／bounding-box 策略，以及一家商家有多個列表而混入。

最佳實務的去重順序：

1. 若爬蟲有暴露 place_id，就先用它比對（最可靠）
2. 以正規化後的 商家名稱 + 地址 做精確比對
3. 以名稱 + 地址做模糊比對，再用電話或網站確認

簡單的 Excel／Sheets 公式（COUNTIF、移除重複項）就能處理大部分情況。若資料量更大，用 pandas 寫個快速 Python 去重腳本會很有效。

正規化電話號碼與地址

抓回來的電話格式千奇百怪：(555) 123-4567、555-123-4567、+15551234567、5551234567。若要匯入 CRM，請統一成 E.164 格式——也就是 + 國碼 + 國內號碼，例如 +15551234567。

—— 少做一道清理步驟。

地址則建議統一格式：街道、城市、州／省、郵遞區號。移除多餘空白、修正縮寫不一致（St vs Street），若準確度很重要，可用地理編碼服務驗證。

用 Email、網站與社群資料做擴充

Google Maps 列表幾乎一定會有網站 URL，但幾乎不會直接附上 Email。最有效的流程是：

1. 先抓 Maps 做商家發現（名稱、地址、電話、網站 URL）
2. 再造訪每家商家網站，擷取 Email、社群連結與其他聯絡資訊

這正是最好的 GitHub repo 與無程式碼工具會在這裡交會的地方：

• ，方式是造訪商家網站
• 可以從抓下來的 URL 前往每家商家網站，擷取 Email 與電話號碼——而且全部會附加回原始表格

對沒有內建擴充功能的 GitHub repo 使用者來說，這代表你得寫第二個爬蟲，或手動逐站造訪。Thunderbit 把這兩步濃縮成一個流程。

匯出到你的 CRM 或工作流程工具

最實用的匯出目的地有：

• Google Sheets：方便協作清理與分享
• Airtable：適合有篩選與檢視的結構化資料庫
• Notion：輕量級營運資料庫
• CSV/JSON：適合匯入 CRM 或後續自動化

Thunderbit 支援 。大多數 GitHub repo 只匯出 CSV 或 JSON——CRM 整合得你自己處理。如果你想了解更多把抓取資料送進試算表的方法，也可以看我們的 指南。

Google Maps 爬蟲 GitHub repo：完整對照表

這裡是適合收藏的總結表，涵蓋所有做法：

如果你想更了解不同抓取方法的選擇，也可以看看我們整理的 懶人包，或是 的比較。

法律與服務條款考量

篇幅不長，但很重要。

Google 目前的 Maps Platform 條款寫得很明確：客戶不得為了服務外用途而 ，其中包括在允許的服務使用範圍之外，複製和儲存商家名稱、地址或使用者評論。Google 的服務特定條款也只允許某些 API 有限快取，通常 。

法律層級很清楚：

• 使用 API 的合約基礎最明確
• GitHub 爬蟲 運作在更灰色的地帶
• 無程式碼工具 能降低營運負擔，但不會免除你自己的合規責任

請針對你的具體情境諮詢法律顧問。若想更深入了解法律面，我們另外整理了 。

重點整理：2026 年該怎麼選 Google Maps 爬蟲方案

在研究了 repo、issue、論壇與價格頁之後，現況大致如下：

1. 在投入設定時間之前，一定要先檢查 repo 新鮮度。 星數不是「今天還能用」的保證。看最近 3 個 issue，再看最近 3–6 個月內是否有程式碼提交。

2. 目前最好的開源方案是 gosom/google-maps-scraper——但即使它也有 2026 年新的欄位退化問題。把它當作需要監控的活系統，而不是設定好就能放著不管的工具。

3. Google Places API 是穩定性與法律清晰度最好的答案——但它有上限（最多 5 則評論、按次計價），而且不太適合大量探索。

4. 對非技術團隊來說，像 這樣的無程式碼工具是更務實的替代方案。 從設定到拿到第一批資料的時間差是幾分鐘，不是幾小時，而且你也不用變成兼職爬蟲維護者。

5. 原始資料只完成一半。 請預留時間做去重、電話正規化、Email 擴充，以及 CRM 匯出。能自動處理這些步驟的工具（例如 Thunderbit 的子頁面爬取與 E.164 正規化）通常能省下比你想像更多的時間。

6. 「免費爬蟲」最好理解為：附帶未付費維護的軟體。 如果你有技能，而且喜歡這類工作，那很合理。但如果你只是個業務，想在週五前拿到 500 筆鳳凰城牙醫名單，那就是很差的交易。

如果你想探索更多商家資料擷取方式，可以看看我們的 、，以及 指南。你也可以在 看教學影片。

常見問題

從 GitHub 使用 Google Maps 爬蟲是免費的嗎？

軟體本身免費，工作不是。你會花 30–90 分鐘設定、之後持續花時間排除故障，而且若有實際量體，proxy 成本常常每月還要 10–100 美元以上。如果你的時間有價值，「免費」其實名不副實。

使用 GitHub 的 Google Maps 爬蟲需要 Python 技能嗎？

大多數熱門 repo 都需要基本的 Python 與命令列知識。Docker 優先的 repo 雖然降低負擔，但並不代表完全不用技術——你仍然要除錯容器問題、設定搜尋參數，並處理 proxy 配置。對非技術使用者來說，像 這類無程式碼工具提供了 2 步驟替代方案，不需要寫程式。

Google Maps 爬蟲 GitHub repo 多久會壞一次？

沒有固定排程，但目前 GitHub issue 歷史顯示，核心故障與欄位退化會以數週到數月的週期出現。Google 會定期更新 Maps 介面，讓 selector 和解析邏輯在一夜之間失效。活躍 repo 會快速修復；停止維護的 repo 就會一直壞下去。

我可以用 GitHub 爬蟲抓 Google Maps 評論嗎？

有些 repo 支援完整評論擷取（gaspa93/googlemaps-scraper 就是專門做這件事），但有些只會抓摘要資料，例如評分和評論數。評論也是 Google 改變頁面行為時最先出現漂移的欄位之一——所以即使是支援評論的 repo，在 UI 更新後也可能回傳不完整資料。

如果我不想用 GitHub 爬蟲，最好的替代方案是什麼？

主要有兩條路：使用 Google Places API，獲得官方、結構化的存取方式（但有成本與欄位限制）；或用 像 這樣的無程式碼工具，快速、由 AI 驅動地擷取資料，不需要寫程式。API 最適合需要合規確定性的開發者。Thunderbit 最適合想快速把資料放進試算表的商務使用者。

進一步閱讀