För några månader sedan ställde en utvecklare på Stack Overflow en fråga som har hängt kvar sedan 2012: "Google Places API Place Details limited to 5 reviews?" Fjorton år senare, med hundratals uppröster, är svaret fortfarande detsamma: ja, max fem recensioner. Den begränsningen säger i princip allt om varför den här diskussionen ens finns.
Om du någon gång har behövt Google Places-data i större skala — leadlistor, konkurrentrecensioner, mönster för besöksflöden, lokala SEO-granskningar — har du säkert också hamnat vid samma vägskäl. Den officiella Google Places API:n är ren, strukturerad och väl dokumenterad. Men den ger dig inte allt du kan se på en Google Maps-sida, och kostnaden kan rusa iväg så fort du passerar gratisnivån. Scraping fångar mer, har en annan kostnadsmodell och kommer med sina egna huvudvärkspunkter (CAPTCHA, trasiga selektorer, juridiska gråzoner). Jag har lagt mycket tid på att gå igenom båda sidor — API-dokumentationen, prissättningen, scraping-verktygen och de praktiska avvägningarna — och den här artikeln är resultatet. Vi går igenom datagap fält för fält, verkliga kostnader vid 10K/100K/1M poster, anti-bot-verkligheten och en praktisk hybridstrategi. Dessutom får du ett beslutsflöde, för ingen vill läsa 3 000 ord och ändå inte veta vad man ska välja.
Vad är Google Places API egentligen, och vad får du ut av den?
Google Places API är Googles officiella, strukturerade sätt att hämta företagsdata — namn, adresser, telefonnummer, betyg, recensioner, bilder — från deras databas. Du skickar en HTTP-begäran och får tillbaka formaterad JSON. Det är den godkända vägen.
Den nuvarande versionen (Places API "New") bygger allt kring field masks. När du anropar Place Details anger du exakt vilka fält du vill ha — displayName, formattedAddress, rating, reviews, photos osv. — och Google debiterar dig utifrån den högsta prisklassen bland de fält du begärde. Utelämnar du field mask får du ett fel, inte ett standardsvar. Det är gjort så med flit: Google vill att du bara betalar för det du använder (och gärna mer för de riktigt värdefulla fälten).
De tillgängliga fälten är uppdelade i olika prisnivåer:
| Nivå | Exempel på fält | Vad du får |
|---|---|---|
| Essentials | Place ID, formaterad adress, plats, fotometadata | Grundläggande identitet och platsinfo |
| Pro | Visningsnamn, verksamhetsstatus, Google Maps-URI, primär typ | Mer utförlig företagsinformation |
| Enterprise | Betyg, antal användarbetyg, webbplats, telefonnummer, öppettider, prisnivå | De fält de flesta företagsanvändare faktiskt vill ha |
| Enterprise + Atmosphere | Recensioner, recensionssammanfattning, generativ sammanfattning, bekvämligheter, parkering, takeaway/leverans | Den rikaste (och dyraste) datan |
De viktigaste endpoints som de flesta bryr sig om är: Autocomplete (för sök medan du skriver), Text Search och Nearby Search (för att hitta platser), Place Details (för att berika en redan känd plats) och Place Photos (för bilder).
Nu till begränsningarna som faktiskt spelar roll:
- Recensioner: Place-resursen returnerar max 5 recensioner per plats, sorterade efter relevans. Punkt. Inte 50, inte "alla". Fem.
- Bilder: Begränsat till 10 fotoreferenser per plats i Place-resursen.
- Populära tider / live-trafik: Finns inte som standardfält i Places API. Google bekräftar att datan finns i konsumentytor (baserat på aggregerad, anonymiserad platshistorik), och deras Maps-blogg förklarar hur det fungerar — men fältlistan innehåller det inte.
- Q&A-sektion: Exponeras inte.
- "People also search for"-konkurrenter: Exponeras inte.
- Meny / prislista: Inte ett standardfält.
Vem använder vanligtvis Google Places API?
- Logistikföretag som verifierar och geokodar adresser
- Rese- och hospitality-appar som visar närliggande hotell, restauranger och sevärdheter
- Fastighetsplattformar som berikar objektannonser med lokal företagsdata
- Lokala SEO-byråer som granskar konsekvens i NAP (namn, adress, telefon)
- Säljteam som bygger leadlistor från Place IDs och grundläggande företagsinfo
Om ditt användningsfall passar in i "jag behöver strukturerad platsdata i en produktionsapp" är API:n rätt utgångspunkt. Om ditt användningsfall innehåller orden "alla recensioner", "popular times" eller "konkurrentanalys" — fortsätt läsa.
Vad betyder egentligen "scraping" av Google Places-data?
Web scraping innebär att man använder programvara för att automatiskt extrahera data från en webbsida — i det här fallet Google Maps eller Google Search-resultat — istället för via ett officiellt API. Scrapern läser sidan på samma sätt som din webbläsare gör och plockar sedan ut de strukturerade bitarna: företagsnamn, adresser, recensionstext, stjärnbetyg, diagram över populära tider, Q&A, konkurrentförslag, hela bildgalleriet och allt annat som visas på skärmen.
Den viktiga skillnaden: API:n ger dig det Google väljer att exponera. Scraping ger dig, i teorin, allt som en människa kan se på sidan.
Men "scraping" är inte en enda sak. Det finns tre ganska olika angreppssätt, och avvägningarna mellan dem är stora.
Eget skript vs. hanterade scraping-API:er vs. no-code-verktyg
| Angreppssätt | Hur det fungerar | Bäst för | Huvudavvägning |
|---|---|---|---|
| Eget skript (Puppeteer, Playwright, Selenium) | Du skriver och underhåller ett headless browser-skript som navigerar Google Maps-sidor och tolkar DOM:en | Utvecklare som vill ha full kontroll och egen logik | Högst underhållsbörda — selektorer går sönder när Google ändrar gränssnittet |
| Hanterade scraping-API:er (Thunderbit API, SerpApi, Outscraper) | Du skickar en URL eller sökfråga till ett API; det sköter rendering, anti-bot och parsning och returnerar strukturerad data | Utvecklare som vill ha strukturerad output utan att underhålla scrapers | Prissättning och kvalitet varierar; du litar på en tredje part |
| No-code webbläsartillägg (Thunderbit Chrome Extension) | Klicka-och-välj-extrahering direkt i webbläsaren — AI föreslår fält, du klickar "Scrape", exporterar till Sheets/Excel | Affärsanvändare, marknadsförare och säljteam som snabbt behöver data i ett kalkylblad | Mindre flexibelt för komplexa flöden; beror på verktygets AI-kvalitet |
Kort sagt: eget skript = mest flexibelt men mest underhåll. Hanterade API:er = strukturerad output, inget underhåll. No-code-verktyg = snabbast för icke-utvecklare.
Google Places API jämfört med scraping: datafält för datafält
Det här är tabellen jag önskar att jag hade när jag började gräva i ämnet. Varje fält en affärsanvändare eller utvecklare kan behöva, sida vid sida:
| Datafält | Google Places API | Web Scraping |
|---|---|---|
| Företagsnamn | ✅ Fullständigt (Pro-nivå) | ✅ Fullständigt |
| Adress / plats | ✅ Fullständigt (Essentials-nivå) | ✅ Fullständigt |
| Telefonnummer | ✅ Enterprise-nivå | ✅ När det syns |
| Webbplats-URL | ✅ Enterprise-nivå | ✅ När det syns |
| Samlat betyg | ✅ Enterprise-nivå | ✅ Fullständigt |
| Antal användarbetyg | ✅ Enterprise-nivå | ✅ Fullständigt |
| Enskilda recensioner (text + betyg) | ⚠️ Max 5 recensioner | ✅ Alla tillgängliga recensioner |
| Populära tider / live-trafik | ❌ Inte ett standardfält i API:n | ✅ Går att extrahera (när det renderas) |
| Q&A-sektion | ❌ Exponeras inte | ✅ Går att extrahera |
| Fotometadata | ✅ Max 10 referenser via Photos-endpoint | ✅ Hela galleriet |
| Meny / prislista | ❌ Inte ett standardfält | ⚠️ När det finns på sidan |
| "People also search for" (konkurrenter) | ❌ Exponeras inte | ✅ Går att extrahera |
| Öppettider | ✅ Enterprise-nivå | ✅ När det syns |
| Prisnivå | ✅ Enterprise-nivå | ✅ När det syns |
| Place ID | ✅ Starkt stöd (Essentials) | ⚠️ Möjligt, men API:n är den kanoniska källan |
| Google Maps-URI | ✅ Pro-nivå | ✅ Det är sidans URL |
| Ägarens svar på recensioner | ⚠️ Kontrollera aktuell tillgänglighet | ✅ Ofta synligt |
| SERP-/map-pack-position | ❌ Inte API:ns syfte | ✅ Via SERP-scraping |
Den stora luckan: om du behöver kompletta recensionsmängder för sentimentanalys, omdömesspårning eller konkurrensjämförelser räcker inte API:n ensam. Fem recensioner per plats är ett urval, inte ett dataset.
Populära tider och besöksflöden? Samma sak. Om du är retail-konsult eller fastighetsanalytiker för kommersiella lokaler är scraping den enda vägen — den datan finns helt enkelt inte i API:n.
Å andra sidan: för korrekta Place IDs, strukturerade adresser för geokodning eller för att driva en butiksfinder är API:n renare, mer tillförlitlig och officiellt stödd.
Den verkliga kostnaden: Google Places API jämfört med scraping vid 10K, 100K och 1M poster
Kostnad är den mest missförstådda delen av beslutet. Många registrerar sig för API:ns gratisnivå, bygger en prototyp och får sedan en räkning som får ögonen att tåras när de skalar upp. På scraping-sidan underskattar man ofta proxykostnader och utvecklarens arbetstid.
Så här ser matematiken ut.
Prisgenomgång för Google Places API
Google gjorde om prissättningen för Maps Platform i mars 2025 och ersatte den gamla fasta 200-dollar-krediten per månad med gratisnivåer per SKU och volymbaserade nivåer. Den nuvarande prissättningen fungerar så här:
- Essentials-fält (Place Details): 10 000 gratis anrop/månad, därefter 5,00 USD per 1 000 upp till 100K
- Pro-fält (Place Details): 5 000 gratis, därefter 7,00 USD/1K
- Enterprise-fält (Place Details): 1 000 gratis, därefter 20,00 USD/1K
- Enterprise + Atmosphere (recensioner, bekvämligheter): 1 000 gratis, därefter 25,00 USD/1K
Viktig detalj: om din field mask innehåller ens ett enda Enterprise + Atmosphere-fält (som reviews) debiteras hela anropet enligt den nivån. Och ett vanligt arbetsflöde kedjar flera SKU:er — Text Search Pro för att hitta platser, sedan Place Details Enterprise + Atmosphere för att berika dem — så kostnaderna staplas på varandra.
En enda "uppslagning" är sällan samma sak som ett enda debiterbart anrop.
Scraping-kostnader: verktyg, proxies och utvecklarens tid
Scraping-kostnaderna kan delas in i tre delar:
- Verktygsabonnemang eller API-krediter: Hanterade scraping-API:er tar betalt per anrop, per kredit eller per post. SerpApi tar betalt per sökning. Outscraper använder pay-as-you-go per post. Thunderbits API använder ett kreditsystem (Extract = 20 krediter/anrop). Thunderbit Chrome Extension tar 1 kredit per outputrad.
- Proxykostnader (endast DIY): Residential proxies för Google Maps-scraping kostar vanligtvis 50–300 USD/månad beroende på volym och leverantör.
- Utvecklarens tid (endast DIY): Att bygga och underhålla Puppeteer/Playwright-skript. Det här är den dolda kostnaden som ofta knäcker DIY-ekonomin (mer om det nedan).
Kostnadstabell sida vid sida: API vs. scraping i skala
| Skala | Google Places API (Enterprise + Atmosphere) | Hanterat scraping-API (est.) | DIY-scraping (proxy + utvecklartid) |
|---|---|---|---|
| 10K poster/månad | ~225 USD (1K gratis, 9K × 25 USD/1K) | ~50–150 USD beroende på leverantör | ~50 USD proxy + 2–4 tim utveckling/månad |
| 100K poster/månad | ~2 475 USD (efter gratisnivån tillkommer volymnivåer) | ~250–500 USD | ~150 USD proxy + 8–16 tim utveckling/månad |
| 1M poster/månad | ~17 975 USD (volymnivåer sänker styckpriset, men totalen är fortfarande hög) | ~1 500–3 000 USD | ~300 USD proxy + 20+ tim utveckling/månad + risk för avbrott |
Notera: API-estimaten använder offentliga volymnivåer för Place Details Enterprise + Atmosphere, applicerade efter den 1K gratisnivån. Estimaten för hanterade scraping-API:er är ungefärliga spann över flera leverantörer. DIY-utvecklartid antar en belastad timkostnad på 50–100 USD/timme.
Mönstret är tydligt: i hobbyskala (under 10K) kan API:ns gratisnivåer göra den till det billigaste alternativet, särskilt om du bara behöver Essentials- eller Pro-fält. I verksamhetsskala (100K+) drar API-kostnaden iväg, särskilt för rika fält. I företagsskala (1M+) kan API:n närma sig femsiffriga belopp per månad, och scraping eller datatjänster blir ekonomiskt mer intressanta — förutsatt att du faktiskt behöver de extra fält som API:n inte exponerar.
Om du bara behöver adresser och Place IDs: skrapa inte. API:n är billigare och bättre för det. Kostnadsargumentet för scraping håller bara när du behöver data som API:n inte kan returnera.
Verklighetskollen om anti-bot: varför egna Google-scrapers går sönder
Här är delen scraping-förkämpar ofta hoppar över. Google vill inte att du ska scrapa Google Maps. De har byggt flera försvarslager och uppdaterar dem regelbundet.
Googles lager av skydd
- reCAPTCHA-utmaningar: Automatiserade webbläsare triggar CAPTCHA oftare än mänskliga användare
- JavaScript-rendering på klientsidan: Google Maps är en tung JavaScript-applikation. En enkel HTTP-begäran räcker inte för att få renderat innehåll — du behöver en fullständig headless browser
- Browser fingerprinting: Google identifierar headless browsers via canvas-fingerprints, WebGL, navigator-egenskaper och andra signaler
- IP-begränsning: För många begäranden från samma IP (eller samma proxy-subnät) och du blockeras
- Förändringar i DOM-strukturen: Google ändrar regelbundet hur sidorna byggs — konsensus i Reddit-trådar och GitHub-issues är att selektorer går sönder varannan vecka till varannan månad
Den sista punkten är den tysta mördaren. Ett Puppeteer-skript som fungerade perfekt i juni kan plötsligt ge tomma resultat i juli eftersom Google bytt namn på en CSS-klass eller byggt om en div-struktur.
Den dolda kostnaden för att underhålla egna skript
Varje gång Google ändrar sin DOM måste någon i teamet:
- Upptäcka att scrapern är trasig (förhoppningsvis innan fel data sprids)
- Inspektera den nya sidstrukturen
- Uppdatera selektorer, hantera nya CAPTCHA-typer, justera retry-logik
- Testa och rulla ut igen
På ett år kan den här underhållstiden lätt överstiga abonnemangskostnaden för ett hanterat scraping-API. Jag har sett team lägga 40+ utvecklartimmar per år bara på att hålla en Google Maps-scraper vid liv — och det är en konservativ uppskattning för en medelkomplex setup.
Varför hanterade scraping-API:er finns
Det är just den här underhållsbördan som gjort att tjänster som Thunderbits API, SerpApi och Outscraper finns. De absorberar anti-bot-komplexiteten — JS-rendering, CAPTCHA-lösning, proxyrotation, selector-underhåll — och returnerar strukturerad data.
Thunderbits POST /extract-endpoint med renderMode: "full" hanterar JavaScript-tunga sidor som Google Maps och returnerar strukturerad JSON som matchar ditt schema, inte rå HTML som fortfarande behöver parsas. MCP-servern utökar detta till AI-agenter — Claude, Cursor eller andra LLM-baserade arbetsflöden kan hämta Google Maps-data mitt i en uppgift utan att lämna sin miljö.
För icke-tekniska användare är Thunderbit Chrome Extension alternativet utan underhåll: öppna en Google Maps-sida, klicka "AI Suggest Fields", klicka "Scrape", exportera till Sheets. Inga selektorer, inga proxies, ingen felsökning.
SerpApi och Outscraper är starka alternativ med olika prismodeller och outputformat. SerpApi returnerar strukturerad JSON per sökning; Outscraper tar betalt per post med pay-as-you-go-prissättning. Rätt val beror på volym, budget och om du behöver strukturerad JSON eller är bekväm med att tolka halvstrukturerad output.
Hybridstrategin: använd Google Places API och scraping tillsammans
Ingen av de topprankade artiklarna om det här ämnet föreslår det jag har sett fungera bäst i praktiken: att använda båda. Många team landar i att använda den officiella API:n för vissa uppgifter och scraping för andra. Tricket är att matcha rätt verktyg med rätt jobb.
När den officiella API:n vinner
- Autocomplete i en live-produkt: Låg latens, följer villkoren, tillförlitlig SLA. Ingen diskussion.
- Platsbaserade backend-system: Butikssökare, adressverifiering, matchning av Place IDs. API:n är strukturerad, stödd och dokumenterad.
- Integrationer med höga compliance-krav: Enterprise-avtal, publika produkter eller andra sammanhang där efterlevnad av Googles villkor är absolut nödvändig.
När scraping vinner
- Fullständig extrahering av recensioner (5K+ recensioner per plats): Sentimentanalys, omdömesspårning, konkurrensjämförelser. API:ns 5-recensionsgräns gör den oanvändbar här.
- Engångsextraktion av leadlistor: Billigare för batchjobb utan löpande debitering. Ett no-code-verktyg som Thunderbit kan skrapa en lista med företag och exportera till ett kalkylblad på några minuter.
- Analys av populära tider / besöksflöden: Inte tillgängligt via API. Punkt slut.
- Q&A-data, konkurrenters "people also search for": Syns bara på sidan, inte i API:n.
När ett hybridupplägg är vettigt
- Löpande bevakning av pris/betyg: Använd API:n för grundläggande strukturerad data (Place ID, adress, samlat betyg), och scrapa sedan för djupdata som API:n missar (fulla recensioner, populära tider).
- Berikningsflöden: Använd API:n för att få Place IDs och kanonisk företagsinformation, och scrapa sedan enskilda listningssidor för kompletta recensionsmängder, Q&A och konkurrentkontext.
- Schemalagd bevakning: Thunderbits schemalagda scraper (för no-code-användare) eller CLI-batchextraktion med cron (för utvecklare) kan hantera återkommande scraping utan egen infrastruktur.
Beslutsmatris för användningsfall
| Användningsfall | Rekommenderad metod | Varför |
|---|---|---|
| Autocomplete i en live-app | ✅ Officiell API | Låg latens, följer villkoren, tillförlitlig |
| Hämta 5K+ kompletta recensionsmängder | ✅ Scraping / scraping-API | API:n begränsar till 5 recensioner per plats |
| Engångslista över lokala företag | ✅ Scraping (eller Thunderbit-tillägget) | Billigare för batch; ingen löpande debitering |
| Analys av populära tider / besöksflöden | ✅ Endast scraping | Inte tillgängligt via API |
| Löpande bevakning av pris/betyg | ⚠️ Hybrid | API för grunddata, scraping för djupdata |
| Backend för platsbaserad app | ✅ Officiell API | Strukturerad, stödd, SLA |
| SERP-spårning för lokal SEO | ✅ Scraping / SERP-API | Inte Places API:ns syfte |
| Konkurrenters "people also search for" | ✅ Endast scraping | Exponeras inte via API |
Beslutsflöde: Google Places API eller scraping — vad ska du välja?
Istället för ett luddigt "det beror på" får du här ett konkret beslutsramverk. Gå igenom dessa fyra frågor:
1. Behöver du realtidsdata i en produktionsapp? → Ja: Använd den officiella API:n. Den stöds, har SLA och följer villkoren. Stanna här. → Nej: Fortsätt.
2. Behöver du data som API:n inte returnerar (fulla recensioner, populära tider, Q&A)? → Ja: Då krävs scraping. API:n kan bokstavligen inte ge dig den datan. → Nej: Fortsätt.
3. Hur många poster per månad? → Under 10K: API:n är sannolikt billigast, särskilt om du bara behöver Essentials- eller Pro-fält. Gratisnivåerna räcker långt i den här skalan. → Över 10K: Scraping eller ett hanterat scraping-API blir ofta mer ekonomiskt, särskilt för rika fält.
4. Har du utvecklarresurser för att bygga och underhålla scrapers? → Ja: Eget Puppeteer/Playwright ger maximal kontroll (men räkna med löpande underhåll). → Nej: Använd ett hanterat scraping-API (Thunderbit API, SerpApi, Outscraper) eller ett no-code-verktyg (Thunderbit Chrome Extension).
Snabb jämförelse av utvecklarorienterade alternativ
| Verktyg | Prismodell | Outputformat | Klarar anti-bot | Stöd för batch |
|---|---|---|---|---|
| Thunderbit API / MCP | Kreditbaserat (Extract = 20 krediter/anrop) | Strukturerad JSON som matchar schema | ✅ JS-rendering, proxyrotation, geo-routing | ✅ Upp till 100 URL:er per batch |
| SerpApi | Per sökning (nivåbaserade planer) | Strukturerad JSON | ✅ | ✅ Via API-parametrar |
| Outscraper | Per post (pay-as-you-go) | JSON / CSV | ✅ | ✅ Via taskköer |
| DIY (Puppeteer/Playwright) | Proxy + utvecklartid | Rå HTML (du parsar själv) | ❌ Du hanterar det själv | ✅ Vad du än bygger |
Thunderbits API-differentierare: den returnerar strukturerad JSON som matchar ett JSON Schema du själv definierar — inte rå HTML eller Markdown som fortfarande behöver tolkas. Om du matar en LLM-pipeline eller laddar en databas sparar det verklig efterbearbetningstid.
Hur Thunderbit passar in (för både affärsanvändare och utvecklare)
Vi byggde Thunderbit för att bygga bron mellan "jag behöver Google Maps-data" och "jag vill inte bli en scraping-infrastrukturingenjör". Så här fungerar det för båda målgrupperna.
För icke-tekniska användare: webbläsartillägget
- Öppna en Google Maps-sida — en resultatsida eller en enskild företagslista
- Klicka på "AI Suggest Fields" — Thunderbits AI läser sidan och föreslår kolumner (företagsnamn, adress, betyg, recensioner, telefon osv.)
- Klicka på "Scrape" — tillägget extraherar data till en strukturerad tabell. Använd cloud mode för upp till 50 sidor samtidigt
- Scrapa undersidor — klicka "Scrape Subpages" för att öppna varje listning och hämta fullständiga detaljer
- Exportera — till Excel, Google Sheets, Airtable eller Notion. Gratis export av data, ingen betalvägg
För återkommande bevakning — veckovisa kontroller av konkurrenters betyg, nya företagslistningar — kör den schemalagda scrapern automatiskt enligt det intervall du väljer.
För utvecklare: API, MCP-server och CLI
POST /extractmed ett JSON Schema: Skicka en Google Maps-URL, definiera fälten du vill ha och få tillbaka strukturerad JSON. SättrenderMode: "full"för JavaScript-tunga sidor. Thunderbit hanterar rendering, anti-bot, proxyrotation och geo-routing.POST /distill: Få ren Markdown från vilken sida som helst — användbart för LLM-pipelines som behöver råinnehåll snarare än strukturerade fält. 1 kredit/anrop jämfört med 20 för Extract.- MCP-server: AI-agenter (Claude, Cursor) kan scrapa Google Maps-data mitt i ett arbetsflöde. Stöd för distillation, strukturerad extraktion, fältförslag och batchjobb upp till 100 URL:er.
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonför schemalagd scraping eller CI/CD-integrerad körning.
Kreditprissättning: Extract = 20 krediter/anrop, Distill = 1 kredit/anrop. API-krediter gäller per anrop, inte per rad (till skillnad från tillägget, där 1 kredit = 1 outputrad). Se Thunderbit Pricing för aktuella planer.
Juridiska aspekter och villkor
Jag håller det här kort och sakligt — inga skrämselrubriker, inget säljsnack.
Google Places API kommer med tydliga villkor: Googles tjänstespecifika villkor säger att Places API-innehåll får användas utan en Google-karta, men får inte användas tillsammans med en karta som inte är från Google. Latitud- och longitudvärden får cachas i upp till 30 sammanhängande kalenderdagar; Place IDs får lagras utan tidsbegränsning. Attribuering krävs för detaljer, bilder och recensioner.
Scraping av Google Maps kan strida mot Googles användarvillkor. Tillämpningen varierar — risker inkluderar IP-blockering, CAPTCHA-väggar och i sällsynta fall rättsliga åtgärder. Hanterade scraping-API:er tar ofta en del av compliance-bördan på sig för användarens räkning, men det är inte ett juridiskt skydd.
För produktionsappar som riktar sig till slutanvändare är den officiella API:n det säkrare valet. För intern research, batchanalys och konkurrensintelligens är scraping vanligt i branschen. Rådgör med juridisk expertis för kommersiella arbetsflöden.
Vad jag faktiskt skulle välja — och varför
Efter att ha gått igenom prissättning, fältlistor, community-trådar och verktygsdokumentation landar jag här:
- Använd den officiella API:n när du behöver realtidsdata som följer villkoren i en produktionsapp, eller när Essentials-/Pro-fält räcker och volymen är under 10K/månad. Gratisnivåerna är generösa i liten skala, och datakvaliteten är klockren.
- Använd scraping (hanterat API eller no-code-verktyg) när du behöver fulla recensioner, populära tider, Q&A, konkurrentkontext eller något fält som API:n inte exponerar. Också när volymen överstiger 10K–100K poster/månad och du vill ha rika fält (Enterprise + Atmosphere) — då blir API-räkningen svår att försvara.
- Använd båda när ditt arbetsflöde kräver kanoniska Place IDs och grundläggande strukturerad data (API) plus djup information från den synliga sidan (scraping). Det här är vanligare än många artiklar medger.
Kostnadens brytpunkt: under cirka 10K poster/månad med grundläggande fält är API:n enklare och ofta gratis. Över det, särskilt för rik data, blir scraping mer ekonomiskt. Vid 1M poster med Enterprise + Atmosphere-fält tittar du på cirka 18K USD/månad med API:n jämfört med en bråkdel av det med en hanterad scraper.
Om du vill testa detta själv är Thunderbit Chrome Extension det snabbaste sättet att se vad scraping fångar jämfört med API:n. För utvecklarflöden har Thunderbit API-dokumentationen allt du behöver för att komma igång. Och om du vill läsa mer om web scraping utan kod eller AI web scraping i allmänhet har vi skrivit mycket om det på bloggen.
Viktiga slutsatser
- Google Places API är rätt verktyg för produktionsappar, autocomplete och strukturerade platsuppslag — men den begränsar recensioner till 5, bilder till 10 och exponerar inte populära tider, Q&A eller konkurrentförslag.
- Scraping fångar allt som syns på en Google Maps-sida, inklusive fulla recensionsmängder och data om populära tider, men kräver att man hanterar anti-bot-försvar eller betalar för en hanterad tjänst.
- Under 10K poster/månad gör API:ns gratisnivåer den ofta till det billigaste alternativet. Över 100K är scraping eller hanterade scraping-API:er vanligtvis mer ekonomiska för rik data.
- Egna scrapers går ofta sönder på grund av Googles anti-bot-försvar och DOM-förändringar — räkna med 40+ utvecklartimmar per år i underhåll, eller använd ett hanterat verktyg.
- Den bästa strategin i verkligheten är ofta hybrid: API för kanoniska ID:n och grundfält, scraping för den djupare intelligens som API:n inte kan ge.
- Thunderbit passar båda sidor: ett Chrome-tillägg för no-code-användare och ett strukturerat JSON-API/MCP-server för utvecklare.
Vanliga frågor
Kan man få ut fler än 5 Google-recensioner via Places API?
Nej. Google Places API begränsar antalet recensioner till 5 per plats, sorterade efter relevans. Så har det varit sedan API:n lanserades och det har inte ändrats trots många års önskemål från utvecklare. För att komma åt alla tillgängliga recensioner för ett företag är scraping (antingen eget eller via ett hanterat scraping-API) enda alternativet.
Är det lagligt att scrapa Google Maps?
Det finns inget universellt ja-eller-nej-svar. Scraping av offentligt synlig Google Maps-data kan strida mot Googles användarvillkor, och tillämpningen varierar från IP-blockering till, i sällsynta fall, rättsliga åtgärder. Många företag använder scraping för intern research och konkurrensanalys utan problem. Hanterade scraping-API:er tar på sig en del av compliance-risken, men de är inte ett juridiskt skydd. Om du bygger en kommersiell produkt eller behandlar persondata bör du kontakta jurist.
Vad kostar Google Places API för 100K uppslag?
Det beror på vilka fält du begär. För Place Details på Essentials-nivå cirka 450 USD. På Pro-nivå cirka 1 615 USD. För Enterprise + Atmosphere (som inkluderar recensioner och bekvämligheter) cirka 2 475 USD. Om ditt arbetsflöde dessutom kräver Text Search Pro för att hitta platser, lägg till cirka 3 040 USD. De här uppskattningarna använder Googles publicerade volymnivåer och antar ett debiterbart anrop per post efter gratisnivån.
Vad är skillnaden mellan ett scraping-API och ett no-code scraping-verktyg?
Ett scraping-API (som Thunderbits Open API) är för utvecklare som integrerar scraping i kod, automationsflöden eller AI-agentarbetsflöden via HTTP-anrop. Ett no-code-verktyg (som Thunderbit Chrome Extension) låter icke-tekniska användare peka, klicka och exportera data från webbläsaren utan att skriva kod. Båda kan returnera strukturerad data; skillnaden ligger i gränssnittet och integrationsmodellen.
Fungerar Thunderbit på Google Maps-sidor?
Ja. Chrome Extension kan scrapa Google Maps-sökresultat och enskilda företagslistningar — AI föreslår fält automatiskt, och du kan använda cloud mode för upp till 50 samtidiga sidor. API:ns POST /extract med renderMode: "full" hanterar Google Maps JavaScript-renderade sidor och returnerar strukturerad JSON som matchar ditt schema. MCP-servern gör det möjligt för AI-agenter att hämta Google Maps-data mitt i ett arbetsflöde.
Läs mer
