Kilka miesięcy temu developer na Stack Overflow zadał pytanie, które pozostaje otwarte od 2012 roku: „Google Places API Place Details limited to 5 reviews?” Czternaście lat, setki głosów i odpowiedź wciąż ta sama — tak, maksymalnie pięć opinii. Już samo to ograniczenie pokazuje, skąd bierze się cała ta dyskusja.
Jeśli kiedykolwiek potrzebowałeś danych z Google Places na większą skalę — list leadów, opinii o konkurencji, analizy ruchu pieszego, audytów lokalnego SEO — pewnie trafiłeś na ten sam dylemat. Oficjalne Google Places API jest czyste, uporządkowane i dobrze opisane. Ale nie zwraca wszystkiego, co widzisz na stronie Google Maps, a rachunek potrafi mocno urosnąć, gdy wyjdziesz poza darmowy limit. Google Maps scraping potrafi wyciągnąć więcej, rozlicza się inaczej i ma własny zestaw problemów (CAPTCHA, psujące się selektory, szare strefy prawne). Sporo czasu poświęciłem na analizę obu podejść — dokumentacji API, cenników, narzędzi do scrapowania i realnych kompromisów — i ten artykuł jest efektem tych poszukiwań. Omówimy brakujące pola dane po polu, rzeczywiste koszty przy 10K/100K/1M rekordów, realia walki z botami oraz praktyczny hybrydowy playbook. Dorzucam też schemat decyzyjny, bo nikt nie chce czytać 3000 słów i nadal nie wiedzieć, co wybrać.
Czym jest Google Places API i co tak naprawdę daje?
Google Places API to oficjalny, uporządkowany sposób Google na pobieranie danych o firmach — nazw, adresów, numerów telefonów, ocen, opinii, zdjęć — z ich bazy. Wysyłasz żądanie HTTP i dostajesz sformatowany JSON. To zatwierdzona ścieżka.
Obecna wersja (Places API „New”) opiera wszystko na field masks. Gdy wywołujesz Place Details, wskazujesz dokładnie, jakich pól potrzebujesz — displayName, formattedAddress, rating, reviews, photos itd. — a Google nalicza opłatę według najwyższego poziomu pola, które zażądałeś. Jeśli pominiesz field mask, dostaniesz błąd, a nie domyślną odpowiedź. To celowe: Google chce, abyś płacił tylko za to, czego używasz (i więcej za najciekawsze dane).
Dostępne pola są podzielone na poziomy cenowe:
| Poziom | Przykładowe pola | Co dostajesz |
|---|---|---|
| Essentials | Place ID, sformatowany adres, lokalizacja, metadane zdjęć | Podstawowa identyfikacja i lokalizacja |
| Pro | Nazwa wyświetlana, status firmy, Google Maps URI, główny typ | Bogatsze informacje o firmie |
| Enterprise | Ocena, liczba ocen, strona internetowa, numery telefonów, godziny otwarcia, poziom cen | Pola, których biznesowi użytkownicy najczęściej naprawdę potrzebują |
| Enterprise + Atmosphere | Opinie, podsumowanie opinii, generatywne podsumowanie, udogodnienia, parking, takeout/delivery | Najbogatsze (i najdroższe) dane |
Najważniejsze endpointy: Autocomplete (do wyszukiwania w trakcie wpisywania), Text Search i Nearby Search (do odkrywania miejsc), Place Details (do wzbogacania znanego miejsca) oraz Place Photos (dla obrazów).
Oto ograniczenia, które naprawdę mają znaczenie:
- Opinie: Place resource zwraca maksymalnie 5 opinii na miejsce, posortowanych według trafności. Tyle. Nie 50, nie „wszystkie”. Pięć.
- Zdjęcia: W Place resource limit to 10 odwołań do zdjęć na miejsce.
- Popular times / live busyness: Nie są dostępne jako standardowe pole Places API. Google potwierdza, że dane istnieją w interfejsach konsumenckich (na podstawie zagregowanej, zanonimizowanej Location History), a blog Maps wyjaśnia jak to działa — ale lista pól tego nie zawiera.
- Sekcja Q&A: Nie jest udostępniana.
- „People also search for” / konkurenci: Nie są udostępniane.
- Menu / cennik: To nie jest standardowe pole.
Kto najczęściej korzysta z Google Places API?
- Firmy logistyczne walidujące i geokodujące adresy
- Aplikacje turystyczne i hotelowe pokazujące pobliskie hotele, restauracje i atrakcje
- Platformy nieruchomości wzbogacające oferty o dane o lokalnych biznesach
- Agencje lokalnego SEO sprawdzające spójność NAP (name, address, phone)
- Zespoły sprzedaży budujące listy leadów na podstawie Place ID i podstawowych informacji o firmie
Jeśli Twój przypadek użycia mieści się w schemacie „potrzebuję uporządkowanych danych o miejscach w aplikacji produkcyjnej”, API jest dobrym punktem startowym. Jeśli w grę wchodzą słowa „wszystkie opinie”, „popular times” albo „analiza konkurencji” — czytaj dalej.
Co oznacza „scraping” danych z Google Places?
Web scraping to użycie oprogramowania do automatycznego pobierania danych ze strony internetowej — w tym przypadku z Google Maps albo wyników Google Search — zamiast przez oficjalne API. Scraper odczytuje stronę tak, jak robi to przeglądarka, a potem wyciąga elementy strukturalne: nazwy firm, adresy, treści opinii, oceny w gwiazdkach, wykresy popular times, Q&A, sugestie konkurencji, pełną galerię zdjęć i wszystko inne widoczne na ekranie.
Kluczowa różnica: API daje Ci to, co Google zdecydowało się udostępnić. Scraping daje — przynajmniej w teorii — wszystko, co widzi człowiek.
Ale „scraping” nie oznacza jednego rozwiązania. Są trzy bardzo różne podejścia, a różnice między nimi są istotne.
Skrypty DIY vs zarządzane API do scrapowania vs narzędzia no-code
| Podejście | Jak działa | Najlepsze dla | Główny kompromis |
|---|---|---|---|
| Skrypty DIY (Puppeteer, Playwright, Selenium) | Piszesz i utrzymujesz skrypt z bezgłową przeglądarką, który przechodzi po stronach Google Maps i parsuje DOM | Deweloperzy potrzebujący pełnej kontroli i własnej logiki | Najwyższy koszt utrzymania — selektory psują się, gdy Google zmienia interfejs |
| Zarządzane API do scrapowania (Thunderbit API, SerpApi, Outscraper) | Wysyłasz URL albo zapytanie do API; ono zajmuje się renderowaniem, antybotem i parsowaniem, a zwraca uporządkowane dane | Deweloperzy chcący strukturalnego wyniku bez utrzymywania scraperów | Ceny i jakość zależą od dostawcy; ufasz stronie trzeciej |
| Rozszerzenia przeglądarkowe no-code (Thunderbit Chrome Extension) | Pobieranie danych kliknięciem z przeglądarki — AI podpowiada pola, klikasz „Scrape”, eksportujesz do Sheets/Excel | Użytkownicy biznesowi, marketerzy, zespoły sprzedaży potrzebujące danych szybko w arkuszu | Mniejsza elastyczność przy złożonych pipeline’ach; zależy od jakości AI w narzędziu |
Krótko: DIY = największa elastyczność, ale też największy koszt utrzymania. Zarządzane API = wynik strukturalny, bez utrzymania. Narzędzia no-code = najszybsza droga dla osób nietechnicznych.
Google Places API vs scraping: porównanie danych pole po polu
To tabela, którą chciałbym mieć, gdy zaczynałem ten research. Każde pole, którego może potrzebować biznes lub developer, zestawione obok siebie:
| Pole danych | Google Places API | Web Scraping |
|---|---|---|
| Nazwa firmy | ✅ Pełna (poziom Pro) | ✅ Pełna |
| Adres / lokalizacja | ✅ Pełny (poziom Essentials) | ✅ Pełny |
| Numer telefonu | ✅ Poziom Enterprise | ✅ Gdy widoczny |
| Adres URL strony | ✅ Poziom Enterprise | ✅ Gdy widoczny |
| Średnia ocena | ✅ Poziom Enterprise | ✅ Pełna |
| Liczba ocen użytkowników | ✅ Poziom Enterprise | ✅ Pełna |
| Pojedyncze opinie (tekst + ocena) | ⚠️ Maks. 5 opinii | ✅ Wszystkie dostępne opinie |
| Popular times / live busyness | ❌ Nie jest standardowym polem API | ✅ Do wyciągnięcia (gdy są wyrenderowane) |
| Sekcja Q&A | ❌ Niedostępna | ✅ Do wyciągnięcia |
| Metadane zdjęć | ✅ Maks. 10 odwołań przez endpoint Photos | ✅ Pełna galeria |
| Menu / cennik | ❌ Nie jest standardowym polem | ⚠️ Gdy jest obecne na stronie |
| „People also search for” (konkurenci) | ❌ Niedostępne | ✅ Do wyciągnięcia |
| Godziny otwarcia | ✅ Poziom Enterprise | ✅ Gdy widoczne |
| Poziom cen | ✅ Poziom Enterprise | ✅ Gdy widoczny |
| Place ID | ✅ Pewne i oficjalne (Essentials) | ⚠️ Możliwe, ale API pozostaje źródłem kanonicznym |
| Google Maps URI | ✅ Poziom Pro | ✅ To adres strony |
| Odpowiedzi właściciela na opinie | ⚠️ Sprawdź aktualną dostępność | ✅ Często widoczne |
| Pozycja w SERP / map pack | ❌ To nie jest cel API | ✅ Przez scrapowanie SERP |
Najważniejsza luka: jeśli potrzebujesz pełnych zestawów opinii do analizy sentymentu, monitoringu reputacji albo benchmarku konkurencji, samo API nie wystarczy. Pięć opinii na miejsce to próbka, nie baza danych.
Popular times i wzorce ruchu pieszego? To samo. Jeśli jesteś konsultantem retailowym albo analitykiem nieruchomości komercyjnych, scraping to jedyna droga — tych danych po prostu nie ma w API.
Z drugiej strony, do kanonicznych Place ID, uporządkowanych adresów do geokodowania czy zasilania store locatora API jest czystsze, pewniejsze i oficjalnie wspierane.
Prawdziwy koszt: Google Places API vs scraping przy 10K, 100K i 1M rekordów
Koszt jest najbardziej niezrozumianą częścią tej decyzji. Wielu użytkowników zakłada konto, korzysta z darmowego limitu API, buduje prototyp, a potem dostaje rachunek, który robi wrażenie, gdy tylko skala przekroczy próg darmowy. Po stronie scrapingu ludzie zaniżają koszty proxy i czas pracy developerów.
Zróbmy więc rachunek.
Rozbicie cen Google Places API
Google przebudowało cennik Maps Platform w marcu 2025, zastępując stary stały 200-dolarowy kredyt miesięczny limitami darmowego użycia na poziomie SKU i progami wolumenowymi. Aktualny cennik działa tak:
- pola Essentials (Place Details): 10 000 darmowych requestów miesięcznie, potem 5 USD za 1000 do 100K
- pola Pro (Place Details): 5000 darmowych, potem 7 USD/1K
- pola Enterprise (Place Details): 1000 darmowych, potem 20 USD/1K
- Enterprise + Atmosphere (opinie, udogodnienia): 1000 darmowych, potem 25 USD/1K
Kluczowy detal: jeśli field mask zawiera choć jedno pole z poziomu Enterprise + Atmosphere (np. reviews), całe zapytanie jest rozliczane według tej stawki. A typowy workflow łączy kilka SKU — Text Search Pro do odkrywania miejsc, a potem Place Details Enterprise + Atmosphere do ich wzbogacenia — więc koszty się kumulują.
Jedno „lookup” to rzadko jedno rozliczane żądanie.
Koszty scrapingu: narzędzia, proxy i czas devów
Koszty scrapingu można podzielić na trzy koszyki:
- Subskrypcja narzędzia lub kredyty API: zarządzane API do scrapowania pobierają opłatę za request, za kredyt albo za rekord. SerpApi liczy za wyszukiwanie. Outscraper działa w modelu pay-as-you-go za rekord. Thunderbit API korzysta z systemu kredytów (Extract = 20 kredytów/request). Rozszerzenie Chrome od Thunderbit pobiera 1 kredyt za każdy wynikowy wiersz.
- Koszt proxy (tylko DIY): Residential proxies do scrapowania Google Maps zwykle kosztują 50–300 USD miesięcznie, zależnie od wolumenu i dostawcy.
- Czas pracy developerów (tylko DIY): budowa i utrzymanie skryptów Puppeteer/Playwright. To ukryty koszt, który zabija ekonomię DIY (więcej poniżej).
Tabela kosztów: API vs scraping na większą skalę
| Skala | Google Places API (Enterprise + Atmosphere) | Zarządzane API do scrapowania (szac.) | DIY scraping (proxy + czas devów) |
|---|---|---|---|
| 10K rekordów/miesiąc | ~225 USD (1K free, 9K × 25 USD/1K) | ~50–150 USD w zależności od dostawcy | ~50 USD proxy + 2–4 godz. dev/mies. |
| 100K rekordów/miesiąc | ~2475 USD (po limicie darmowym wchodzą progi wolumenowe) | ~250–500 USD | ~150 USD proxy + 8–16 godz. dev/mies. |
| 1M rekordów/miesiąc | ~17 975 USD (progi wolumenowe obniżają cenę jednostkową, ale łączny koszt nadal jest wysoki) | ~1500–3000 USD | ~300 USD proxy + 20+ godz. dev/mies. + ryzyko awarii |
Uwaga: szacunki API korzystają z opublikowanych progów wolumenowych dla Place Details Enterprise + Atmosphere, liczonych po wykorzystaniu 1000 darmowych wywołań. Szacunki dla zarządzanych API do scrapowania to przybliżone zakresy między dostawcami. Czas DIY zakłada koszt pracy 50–100 USD/h.
Wniosek jest jasny: przy skali hobbystycznej (poniżej 10K) darmowe limity API mogą zrobić z niego najtańszą opcję, zwłaszcza jeśli potrzebujesz tylko pól Essentials albo Pro. Przy skali biznesowej (100K+) koszty API rosną bardzo szybko, szczególnie dla bogatych pól. Przy skali enterprise (1M+) API może zbliżyć się do pięciocyfrowych kwot miesięcznie, a Google Maps scraping albo usługi datasetowe stają się ekonomicznie sensowne — zakładając, że naprawdę potrzebujesz tych dodatkowych pól, których API nie wystawia.
Jeśli potrzebujesz tylko adresów i Place ID, nie scrape’uj. API jest do tego tańsze i lepsze. Argument kosztowy za scrapingiem ma sens tylko wtedy, gdy potrzebujesz danych, których API nie zwraca.
Zderzenie z rzeczywistością antybota: dlaczego własne Google scrapery się wykrzaczają
To jest część, którą pomijają entuzjaści scrapingu. Google nie chce, żebyś scrapował Google Maps. Zbudowali wiele warstw obrony i regularnie je aktualizują.
Wielowarstwowe zabezpieczenia Google
- Wyzwania reCAPTCHA: automatyczne przeglądarki wywołują CAPTCHA znacznie częściej niż użytkownicy
- Renderowanie JavaScript po stronie klienta: Google Maps to ciężka aplikacja JS. Zwykły request HTTP nie zwróci wyrenderowanej treści — potrzebujesz pełnej bezgłowej przeglądarki
- Fingerprinting przeglądarki: Google wykrywa headless browsery przez canvas fingerprints, WebGL, właściwości navigatora i inne sygnały
- Limitowanie IP: zbyt wiele żądań z jednego IP (albo tej samej podsieci proxy) kończy się blokadą
- Zmiany struktury DOM: Google regularnie zmienia budowę stron — na podstawie zgody społeczności na Reddit i w wątkach GitHub selektory psują się co kilka tygodni lub miesięcy
Ten ostatni punkt to cichy zabójca. Skrypt Puppeteer, który działał idealnie w czerwcu, może zwracać puste wyniki w lipcu, bo Google zmienił nazwę klasy CSS albo przebudował div.
Ukryty koszt utrzymywania własnych skryptów
Za każdym razem, gdy Google zmienia DOM, ktoś z Twojego zespołu musi:
- Zauważyć, że scraper nie działa (najlepiej zanim złe dane zaczną się rozprzestrzeniać)
- Przeanalizować nową strukturę strony
- Zaktualizować selektory, obsłużyć nowe typy CAPTCHA, dopasować retry logic
- Przetestować i wdrożyć zmiany
W skali roku ten czas utrzymania może z łatwością przewyższyć koszt subskrypcji zarządzanego API do scrapowania. Widziałem zespoły, które spaliły ponad 40 godzin pracy developerów rocznie tylko po to, by utrzymać scraper Google Maps przy życiu — i to ostrożny szacunek dla umiarkowanie złożonej konfiguracji.
Dlaczego istnieją zarządzane API do scrapowania
Właśnie dlatego istnieją usługi takie jak Thunderbit API, SerpApi i Outscraper. Przejmują na siebie złożoność antybota — renderowanie JS, rozwiązywanie CAPTCHA, rotację proxy, utrzymanie selektorów — i zwracają uporządkowane dane.
Endpoint POST /extract w Thunderbit z renderMode: "full" obsługuje strony ciężkie od JavaScriptu, takie jak Google Maps, i zwraca dopasowany do schematu, strukturalny JSON, a nie surowy HTML, który i tak trzeba by jeszcze parsować. Serwer MCP rozszerza to na agentów AI — Claude, Cursor lub inne workflow oparte na LLM mogą scrapować dane z Google Maps w trakcie zadania, bez wychodzenia ze swojego środowiska.
Dla osób nietechnicznych Thunderbit Chrome Extension to opcja bez utrzymania: otwierasz stronę Google Maps, klikasz „AI Suggest Fields”, klikasz „Scrape”, eksportujesz do Sheets. Bez selektorów, bez proxy, bez debugowania.
SerpApi i Outscraper to solidne alternatywy z innymi modelami cen i formatami wyjściowymi. SerpApi zwraca uporządkowany JSON dla każdego wyszukiwania; Outscraper rozlicza się za rekord w modelu pay-as-you-go. Właściwy wybór zależy od skali, budżetu i tego, czy potrzebujesz strukturalnego JSON, czy akceptujesz półstrukturalny wynik do dalszego parsowania.
Playbook hybrydowy: używanie Google Places API i scrapingu razem
Żaden z wysoko pozycjonowanych artykułów na ten temat nie podpowiada tego, co w praktyce działa najlepiej: korzystanie z obu rozwiązań. Wiele zespołów finalnie opiera się na oficjalnym API w jednych zadaniach, a na Google Maps scraping w innych. Trik polega na tym, by dopasować narzędzie do zadania.
Kiedy wygrywa oficjalne API
- Autocomplete w działającej aplikacji produkcyjnej: niskie opóźnienia, zgodność z ToS, niezawodny SLA. Tu nie ma dyskusji.
- Backendy aplikacji lokalizacyjnych: store locatory, walidacja adresów, dopasowanie Place ID. API jest uporządkowane, wspierane i dobrze opisane.
- Integracje wrażliwe na compliance: kontrakty enterprise, produkty publiczne lub każdy kontekst, w którym zgodność z ToS Google jest nie do negocjacji.
Kiedy wygrywa scraping
- Pełne pobieranie opinii (5K+ opinii na miejsce): analiza sentymentu, monitoring reputacji, benchmark konkurencji. Limit 5 opinii w API sprawia, że to rozwiązanie jest tu bezużyteczne.
- Jednorazowe tworzenie listy leadów: taniej w przypadku zadań wsadowych bez cyklicznego naliczania opłat. Narzędzie no-code takie jak Thunderbit potrafi w kilka minut zeskrobać listę firm i wyeksportować ją do arkusza.
- Analiza popular times / ruchu pieszego: niedostępne przez API. Kropka.
- Dane Q&A, „people also search for” konkurentów: widoczne tylko na stronie, nie w API.
Kiedy sens ma podejście hybrydowe
- Bieżące monitorowanie cen i ocen: użyj API do podstawowych danych strukturalnych (Place ID, adres, średnia ocena), a potem scrappuj głębsze pola, których API nie pokazuje (pełne opinie, popular times).
- Workflow wzbogacania danych: użyj API, aby pobrać Place ID i kanoniczne informacje o firmie, a potem scrapuj indywidualne listingi po pełne zestawy opinii, Q&A i kontekst konkurencyjny.
- Monitorowanie cykliczne: zaplanowany scraper Thunderbit (dla użytkowników no-code) albo batch extract z crona (dla developerów) mogą obsłużyć powtarzalne scrapowanie bez własnej infrastruktury.
Macierz decyzyjna dla zastosowań
| Zastosowanie | Rekomendowana metoda | Dlaczego |
|---|---|---|
| Autocomplete w działającej aplikacji | ✅ Oficjalne API | Niskie opóźnienia, zgodność z ToS, niezawodność |
| Pobieranie 5K+ pełnych zestawów opinii | ✅ Scraping / API do scrapowania | API ogranicza się do 5 opinii na miejsce |
| Jednorazowa lista lokalnych leadów | ✅ Scraping (lub rozszerzenie Thunderbit) | Taniej przy pracy wsadowej; bez ciągłego billing’u |
| Analiza popular times / ruchu pieszego | ✅ Tylko scraping | Niedostępne w API |
| Ciągły monitoring cen / ocen | ⚠️ Hybryda | API dla danych podstawowych, scraping dla głębokich pól |
| Backend aplikacji lokalizacyjnej | ✅ Oficjalne API | Struktura, wsparcie, SLA |
| Śledzenie pozycji w lokalnym SEO SERP | ✅ Scraping / SERP API | To nie jest cel Places API |
| „People also search for” konkurencji | ✅ Tylko scraping | Nie jest udostępniane przez API |
Schemat decyzyjny: Google Places API vs scraping — co wybrać?
Zamiast niejasnego „to zależy”, oto konkretny framework decyzyjny. Przejdź przez te cztery pytania:
1. Czy potrzebujesz danych w czasie rzeczywistym w aplikacji produkcyjnej? → Tak: użyj oficjalnego API. Jest wspierane, ma SLA i jest zgodne z ToS. Na tym kończymy. → Nie: idź dalej.
2. Czy potrzebujesz danych, których API nie zwraca (pełne opinie, popular times, Q&A)? → Tak: Google Maps scraping jest konieczny. API po prostu nie potrafi zwrócić tych danych. → Nie: idź dalej.
3. Ile rekordów miesięcznie? → Poniżej 10K: API prawdopodobnie będzie najtańsze, zwłaszcza jeśli potrzebujesz tylko pól Essentials lub Pro. Darmowe limity sporo tu pokrywają. → Powyżej 10K: scraping lub zarządzane API do scrapowania będzie zwykle bardziej opłacalne, szczególnie przy bogatych polach.
4. Czy masz zasoby developerskie na budowę i utrzymanie scraperów? → Tak: DIY z Puppeteer/Playwright daje maksymalną kontrolę (ale zaplanuj stałe utrzymanie). → Nie: użyj zarządzanego API do scrapowania (Thunderbit API, SerpApi, Outscraper) albo narzędzia no-code (Thunderbit Chrome Extension).
Szybkie porównanie alternatyw dla developerów
| Narzędzie | Model cenowy | Format wyjściowy | Obsługa antybota | Obsługa batchy |
|---|---|---|---|---|
| Thunderbit API / MCP | Oparte na kredytach (Extract = 20 kredytów/request) | Strukturalny JSON dopasowany do schematu | ✅ Renderowanie JS, rotacja proxy, geo-routing | ✅ Do 100 URL-i w batchu |
| SerpApi | Za wyszukiwanie (plany warstwowe) | Strukturalny JSON | ✅ | ✅ Przez parametry API |
| Outscraper | Za rekord (pay-as-you-go) | JSON / CSV | ✅ | ✅ Przez kolejki zadań |
| DIY (Puppeteer/Playwright) | Proxy + czas devów | Surowy HTML (sam parsujesz) | ❌ To Ty się tym zajmujesz | ✅ Tyle, ile sam zbudujesz |
Wyróżnik API Thunderbit: zwraca strukturalny JSON dopasowany do schematu JSON, który sam definiujesz — nie surowy HTML ani Markdown, które i tak trzeba później obrabiać. Jeśli zasila to pipeline LLM albo bazę danych, oszczędzasz realny czas post-processingu.
Gdzie w to wszystko wpisuje się Thunderbit (dla biznesu i developerów)
Zbudowaliśmy Thunderbit po to, by połączyć dwa światy: „potrzebuję danych z Google Maps” oraz „nie chcę zostać inżynierem od infrastruktury scrapingu”. Oto jak działa to dla obu grup.
Dla osób nietechnicznych: rozszerzenie Chrome
- Otwórz stronę Google Maps — wynik wyszukiwania albo pojedynczy listing firmy
- Kliknij „AI Suggest Fields” — AI Thunderbit odczyta stronę i zaproponuje kolumny (nazwa firmy, adres, ocena, opinie, telefon itd.)
- Kliknij „Scrape” — rozszerzenie wyciągnie dane do strukturalnej tabeli. Użyj trybu cloud do nawet 50 stron równolegle
- Scrapuj podstrony — kliknij „Scrape Subpages”, aby wejść w każdy listing i pobrać pełne szczegóły
- Eksportuj — do Excel, Google Sheets, Airtable lub Notion. Eksport danych jest darmowy, bez paywalla
Do powtarzalnego monitoringu — cotygodniowych sprawdzeń ocen konkurencji, nowych listingów firm — zaplanowany scraper działa automatycznie według ustalonego harmonogramu.
Dla developerów: API, serwer MCP i CLI
POST /extractz JSON Schema: wyślij URL Google Maps, zdefiniuj potrzebne pola i odbierz uporządkowany JSON. UstawrenderMode: "full"dla stron ciężkich od JavaScriptu. Thunderbit obsługuje renderowanie, antybota, rotację proxy i geo-routing.POST /distill: pobiera czysty Markdown z dowolnej strony — przydatne w pipeline’ach LLM, które potrzebują surowej treści, a nie pól strukturalnych. 1 kredyt/request zamiast 20 dla Extract.- Serwer MCP: agenci AI (Claude, Cursor) mogą scrapować dane z Google Maps w trakcie pracy. Obsługuje distillation, strukturalną ekstrakcję, sugestie pól i batch joby do 100 URL-i.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsondo zaplanowanego scrapingu albo integracji z CI/CD.
Cennik kredytów: Extract = 20 kredytów/request, Distill = 1 kredyt/request. Kredyty API liczone są za request, nie za wiersz (w przeciwieństwie do rozszerzenia, gdzie 1 kredyt = 1 wynikowy wiersz). Aktualne plany sprawdzisz w Thunderbit Pricing.
Aspekty prawne i zgodność z warunkami korzystania
Będę krótki i rzeczowy — bez straszenia i bez sprzedażowej gadki.
Google Places API ma jasne warunki: warunki specyficzne dla usługi Google mówią, że treści z Places API mogą być używane bez mapy Google, ale nie z mapą spoza Google. Współrzędne latitude/longitude można cache’ować przez maksymalnie 30 kolejnych dni kalendarzowych; Place ID można przechowywać bezterminowo. W przypadku szczegółów, zdjęć i opinii wymagane jest przypisanie źródła.
Scraping Google Maps może naruszać warunki korzystania z Google. Egzekwowanie bywa różne — ryzyka obejmują blokady IP, CAPTCHA i (rzadko) działania prawne. Zarządzane API do scrapowania zwykle przejmują część odpowiedzialności za zgodność, ale nie są tarczą prawną.
W aplikacjach produkcyjnych skierowanych do użytkowników końcowych bezpieczniejszym wyborem jest oficjalne API. Do badań wewnętrznych, analiz wsadowych i competitive intelligence scraping jest powszechną praktyką branżową. W przypadku workflow komercyjnych skonsultuj się z prawnikiem.
Co bym faktycznie wybrał i dlaczego
Po przejrzeniu cenników, list pól, wątków społeczności i dokumentacji narzędzi, mój werdykt jest taki:
- Użyj oficjalnego API, gdy potrzebujesz danych w czasie rzeczywistym, zgodnych z ToS, w aplikacji produkcyjnej, albo gdy wystarczają Ci pola Essentials/Pro i masz wolumen poniżej 10K/miesiąc. Darmowe limity są przy małej skali naprawdę hojne, a jakość danych jest bezdyskusyjna.
- Użyj scrapingu (zarządzanego API albo narzędzia no-code), gdy potrzebujesz pełnych opinii, popular times, Q&A, kontekstu konkurencji albo jakiegokolwiek pola, którego API nie udostępnia. Także wtedy, gdy wolumen przekracza 10K–100K rekordów/miesiąc i prosisz o bogate pola (Enterprise + Atmosphere) — rachunek z API trudno wtedy obronić.
- Użyj obu rozwiązań, gdy workflow wymaga kanonicznych Place ID i podstawowych danych strukturalnych (API) oraz głębszej inteligencji z widocznej strony (scraping). To częstsze, niż większość artykułów przyznaje.
Punkt przegięcia kosztów: poniżej ok. 10K rekordów/miesiąc przy podstawowych polach API jest prostsze i często darmowe. Powyżej tego progu, zwłaszcza dla bogatych danych, scraping staje się bardziej opłacalny. Przy 1M rekordów i polach Enterprise + Atmosphere mówimy o około 18 tys. USD miesięcznie w API kontra ułamek tej kwoty przy zarządzanym scraperze.
Jeśli chcesz to sprawdzić samodzielnie, Thunderbit Chrome Extension to najszybszy sposób, by zobaczyć, co daje Google Maps scraping w porównaniu z API. Dla workflow developerskich dokumentacja Thunderbit API zawiera wszystko, czego potrzebujesz na start. A jeśli chcesz poczytać więcej o web scrapingu bez kodowania albo AI web scrapingu w ogóle, na blogu opisaliśmy te tematy szerzej.
Najważniejsze wnioski
- Google Places API to właściwe narzędzie do aplikacji produkcyjnych, autocomplete i uporządkowanych wyszukiwań miejsc — ale ogranicza opinie do 5, zdjęcia do 10 i nie udostępnia popular times, Q&A ani sugestii konkurencji.
- Scraping wyciąga wszystko, co widać na stronie Google Maps, w tym pełne zestawy opinii i dane o popular times, ale wymaga radzenia sobie z ochroną antybotową albo płacenia za usługę zarządzaną.
- Poniżej 10K rekordów miesięcznie darmowe limity API często czynią je najtańszą opcją. Powyżej 100K scraping albo zarządzane API do scrapowania zwykle są bardziej opłacalne dla bogatych danych.
- Własne scrapery psują się regularnie przez zabezpieczenia antybotowe Google i zmiany DOM — zaplanuj 40+ godzin pracy developera rocznie na utrzymanie albo użyj narzędzia zarządzanego.
- Najlepsza praktyka w realnych projektach to często model hybrydowy: API dla kanonicznych ID i podstawowych pól, Google Maps scraping dla głębokiej wiedzy, której API nie zwróci.
- Thunderbit obsługuje oba światy: rozszerzenie Chrome dla użytkowników no-code oraz API/serwer MCP zwracające strukturalny JSON dla developerów.
FAQ
Czy da się pobrać więcej niż 5 opinii Google przez Places API?
Nie. Google Places API ogranicza zwracane opinie do 5 na miejsce, posortowanych według trafności. Tak jest od premiery API i mimo wielu lat próśb developerów nic się tu nie zmieniło. Aby uzyskać wszystkie dostępne opinie o firmie, scraping (DIY albo przez zarządzane API do scrapowania) jest jedyną opcją.
Czy scrapowanie Google Maps jest legalne?
Nie ma jednej odpowiedzi „tak” albo „nie”. Scraping publicznie widocznych danych z Google Maps może naruszać warunki korzystania z Google, a egzekwowanie waha się od blokad IP po — rzadko — działania prawne. Wiele firm używa scrapingu do badań wewnętrznych i analizy konkurencji bez problemów. Zarządzane API do scrapowania przejmują część ryzyka zgodności, ale nie są tarczą prawną. Jeśli budujesz produkt komercyjny albo przetwarzasz dane osobowe, skonsultuj się z prawnikiem.
Ile kosztuje Google Places API przy 100K lookupów?
To zależy od tego, jakich pól żądasz. Dla Place Details na poziomie Essentials to około 450 USD. Na poziomie Pro około 1615 USD. Dla Enterprise + Atmosphere (w tym opinie i udogodnienia) około 2475 USD. Jeśli workflow wymaga też Text Search Pro do odkrywania miejsc, dolicz kolejne około 3040 USD. Szacunki korzystają z opublikowanych progów wolumenowych Google i zakładają jedno rozliczane wywołanie na rekord po przekroczeniu darmowego limitu.
Jaka jest różnica między API do scrapowania a narzędziem no-code do scrapowania?
API do scrapowania (jak Thunderbit Open API) jest dla developerów, którzy integrują scraping z kodem, automatyzacją lub workflow agentów AI przez żądania HTTP. Narzędzie no-code (jak Thunderbit Chrome Extension) pozwala osobom nietechnicznym wskazać, kliknąć i wyeksportować dane z przeglądarki bez pisania kodu. Oba rozwiązania mogą zwracać strukturalne dane; różnica tkwi w interfejsie i modelu integracji.
Czy Thunderbit działa na stronach Google Maps?
Tak. Rozszerzenie Chrome może scrapować wyniki wyszukiwania Google Maps oraz pojedyncze listingi firm — AI automatycznie podpowiada pola, a w trybie cloud można obsłużyć do 50 stron równolegle. Endpoint API POST /extract z renderMode: "full" obsługuje strony Google Maps renderowane przez JavaScript i zwraca strukturalny JSON dopasowany do schematu. Serwer MCP umożliwia agentom AI scrapowanie danych z Google Maps w trakcie workflow.
Dowiedz się więcej
