Google Places API מול Scraping: עלויות, פערים, ומה הייתי בוחר

לפני כמה חודשים, מפתח ב-Stack Overflow פרסם שאלה שעדיין פתוחה מאז 2012: "Google Places API Place Details limited to 5 reviews?" ארבע־עשרה שנים, מאות הצבעות בעד, והתשובה עדיין אותה תשובה — כן, מקסימום חמש ביקורות. המגבלה הזו לבדה מסבירה למה הוויכוח הזה בכלל קיים.

אם אי פעם הייתם צריכים נתונים מ-Google Places בהיקף גדול — רשימות לידים, ביקורות של מתחרים, דפוסי תנועה פיזית, או ביקורת SEO מקומית — כנראה נתקלתם באותה צומת דרכים. ה-API הרשמי של Google Places מסודר, מובנה ומתועד היטב. אבל הוא לא מחזיר את כל מה שרואים בדף Google Maps, והחשבון יכול להתנפח מהר מאוד ברגע שחורגים מהתוכנית החינמית. Scraping תופס יותר מידע, מתומחר אחרת, ומגיע עם כאבי ראש משלו (CAPTCHAs, סלקטורים שנשברים, ואזור אפור משפטי). הקדשתי לא מעט זמן לחקור את שני הצדדים — תיעוד ה-API, תמחור ה-SKUs, כלי ה-scraping, והפשרות בעולם האמיתי — והמאמר הזה הוא התוצאה. נעבור על פערי הנתונים שדה־אחר־שדה, עלויות אמיתיות ב-10K/100K/1M רשומות, המציאות של anti-bot, ותוכנית עבודה מעשית שמשלבת בין השניים. וגם תרשים החלטה, כי אף אחד לא רוצה לקרוא 3,000 מילים ועדיין לא לדעת מה לבחור.

מהו Google Places API, ומה הוא באמת נותן לכם?

Google Places API הוא הדרך הרשמית והמסודרת של Google לשלוף נתוני עסקים — שמות, כתובות, מספרי טלפון, דירוגים, ביקורות, תמונות — מתוך המאגר שלהם. שולחים בקשת HTTP ומקבלים JSON מעוצב. זו הצינורית המוסדרת.

הגרסה הנוכחית (Places API "New") מארגנת הכול סביב field masks. כשקוראים ל-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, לא "הכול". חמש.
• תמונות: מוגבל ל-10 הפניות לתמונות לכל מקום ב-Place resource.
• Popular times / עומס בזמן אמת: לא זמין כשדה סטנדרטי ב-Places API. Google מאשרת שהמידע הזה קיים בממשקים לצרכנים (על סמך נתוני Location History מצטברים ואנונימיים), ו-Maps blog מסביר איך זה עובד — אבל רשימת השדות לא כוללת אותו.
• Q&A: לא חשוף.
• "אנשים גם חיפשו" / מתחרים: לא חשוף.
• תפריט / מחירון: לא שדה סטנדרטי.

מי בדרך כלל משתמש ב-Google Places API?

• חברות לוגיסטיקה שמאמתות ומקודדות כתובות גיאוגרפיות
• אפליקציות תיירות ואירוח שמציגות מלונות, מסעדות ואטרקציות קרובות
• פלטפורמות נדל״ן שמעשירות נכסים עם נתונים על עסקים מקומיים
• סוכנויות SEO מקומי שבודקות עקביות של NAP (שם, כתובת, טלפון)
• צוותי מכירות שבונים רשימות לידים על בסיס Place IDs ומידע עסקי בסיסי

אם השימוש שלכם מתאים היטב ל"אני צריך נתוני מקום מובנים בתוך אפליקציית פרודקשן", ה-API הוא נקודת הפתיחה הנכונה. אם השימוש כולל את המילים "כל הביקורות", "popular times" או "ניתוח מתחרים" — תמשיכו לקרוא.

מה המשמעות של "Scraping" לנתוני Google Places?

Web scraping הוא שימוש בתוכנה כדי לחלץ אוטומטית נתונים מדף אינטרנט — במקרה הזה, תוצאות Google Maps או Google Search — במקום דרך API רשמי. ה-scraper קורא את הדף כמו שהדפדפן שלכם קורא אותו, ואז שולף את החלקים המובנים: שמות עסקים, כתובות, טקסט ביקורות, דירוג כוכבים, היסטוגרמות של popular times, Q&A, הצעות למתחרים, גלריית התמונות המלאה, וכל דבר אחר שמוצג על המסך.

ההבחנה המרכזית: ה-API נותן לכם את מה ש-Google בוחרת לחשוף. Scraping נותן לכם, לפחות בתיאוריה, את כל מה שאדם יכול לראות בדף.

אבל "Scraping" הוא לא דבר אחד. יש שלוש גישות שונות מאוד, וההבדלים ביניהן משמעותיים.

סקריפטים עצמאיים לעומת APIs מנוהלים לעומת כלים ללא קוד

גישה	איך זה עובד	למי זה מתאים	הפשרה המרכזית
סקריפטים עצמאיים (Puppeteer, Playwright, Selenium)	כותבים ומתחזקים סקריפט של דפדפן headless שמנווט בדפי Google Maps ומנתח את ה-DOM	מפתחים שצריכים שליטה מלאה ולוגיקה מותאמת אישית	עומס תחזוקה גבוה מאוד — סלקטורים נשברים כש-Google משנה את הממשק
APIs מנוהלים ל-scraping (Thunderbit API, SerpApi, Outscraper)	שולחים URL או שאילתה ל-API; הוא מטפל ברינדור, ב-anti-bot ובפירוק, ומחזיר נתונים מובנים	מפתחים שרוצים פלט מובנה בלי לתחזק scraper	המחיר ואיכות השירות משתנים בין ספקים; אתם סומכים על צד שלישי
תוספי דפדפן ללא קוד (Thunderbit Chrome Extension)	חילוץ בלחיצה מהדפדפן — AI מציע שדות, לוחצים "Scrape", מייצאים ל-Sheets/Excel	משתמשי עסק, משווקים וצוותי מכירות שצריכים נתונים מהר לגיליון	פחות גמיש לצינורות מורכבים; תלוי באיכות ה-AI של הכלי

בקיצור: DIY = הכי גמיש אבל הכי יקר בתחזוקה. APIs מנוהלים = פלט מובנה בלי תחזוקה. כלים ללא קוד = הכי מהיר למי שאינו מפתח.

Google Places API מול Scraping: השוואת נתונים שדה־אחר־שדה

זה הטבלה שהייתי רוצה שהייתה קיימת כשנכנסתי למחקר הזה. כל שדה שמשתמש עסקי או מפתח עשוי להזדקק לו, משווה זה מול זה:

שדה נתונים	Google Places API	Web Scraping
שם העסק	✅ מלא (Pro)	✅ מלא
כתובת / מיקום	✅ מלא (Essentials)	✅ מלא
מספר טלפון	✅ Enterprise	✅ כשמופיע
כתובת אתר	✅ Enterprise	✅ כשמופיע
דירוג מצטבר	✅ Enterprise	✅ מלא
מספר מדרגים	✅ Enterprise	✅ מלא
ביקורות בודדות (טקסט + דירוג)	⚠️ מקסימום 5 ביקורות	✅ כל הביקורות הזמינות
Popular times / עומס בזמן אמת	❌ לא שדה API סטנדרטי	✅ ניתן לחילוץ (כשמוצג)
אזור Q&A	❌ לא חשוף	✅ ניתן לחילוץ
מטא־דאטה של תמונות	✅ עד 10 הפניות דרך Photos endpoint	✅ גלריה מלאה
תפריט / מחירון	❌ לא שדה סטנדרטי	⚠️ כשמופיע בדף
"אנשים גם חיפשו" (מתחרים)	❌ לא חשוף	✅ ניתן לחילוץ
שעות פעילות	✅ Enterprise	✅ כשמופיע
רמת מחיר	✅ Enterprise	✅ כשמופיע
Place ID	✅ חזק (Essentials)	⚠️ אפשרי, אבל ה-API הוא מקור הסמכות
Google Maps URI	✅ Pro	✅ זה כתובת הדף
תגובות בעל העסק לביקורות	⚠️ יש לאמת זמינות עדכנית	✅ לרוב גלוי
מיקום ב-SERP / map-pack	❌ לא המטרה של ה-API	✅ דרך SERP scraping

הפער הבולט: אם אתם צריכים סט מלא של ביקורות לניתוח סנטימנט, ניטור מוניטין או benchmarking מול מתחרים, ה-API לבדו לא יספיק. חמש ביקורות למקום הן מדגם, לא מאגר נתונים.

Popular times ודפוסי תנועה פיזית? אותו סיפור. אם אתם יועצי קמעונאות או אנליסטים של נדל״ן מסחרי, scraping הוא המסלול היחיד — המידע הזה פשוט לא נמצא ב-API.

מצד שני, עבור Place IDs קנוניים, כתובות מובנות לגיאוקודינג, או בניית store locator, ה-API נקי, אמין, ורשמי.

העלות האמיתית: Google Places API מול Scraping ב-10K, 100K, ו-1M רשומות

עלות היא החלק הכי לא מובן בהחלטה הזו. משתמשים רבים נרשמים לתוכנית החינמית של ה-API, בונים אבטיפוס, ואז מקבלים חשבון שגורם להם למצמץ חזק כשעוברים את המגבלה. בצד של scraping, אנשים נוטים להמעיט בעלויות פרוקסי ובזמן פיתוח.

אז הנה החישוב.

פירוט תמחור Google Places API

במרץ 2025 Google שינתה את מודל התמחור של Maps Platform, והחליפה את ה-200 דולר זיכוי חודשי קבוע במכסות שימוש חינמיות לפי SKU ותמחור מדורג לפי נפח. התמחור הנוכחי עובד כך:

• שדות Essentials (Place Details): 10,000 בקשות חינם לחודש, ואז 5.00 דולר לכל 1,000 עד 100K
• שדות Pro (Place Details): 5,000 חינם, ואז 7.00 דולר ל-1K
• שדות Enterprise (Place Details): 1,000 חינם, ואז 20.00 דולר ל-1K
• Enterprise + Atmosphere (ביקורות, שירותים): 1,000 חינם, ואז 25.00 דולר ל-1K

פרט קריטי: אם field mask שלכם כולל אפילו שדה אחד של Enterprise + Atmosphere (כמו reviews), כל הבקשה תחויב לפי אותה רמה. ובוורקפלואו טיפוסי יש שרשרת של כמה SKUs — למשל Text Search Pro כדי למצוא מקומות, ואז Place Details Enterprise + Atmosphere כדי להעשיר אותם — כך שהעלויות מצטברות.

"חיפוש" בודד כמעט אף פעם אינו בקשה מחויבת אחת בלבד.

עלויות Scraping: כלים, פרוקסי וזמן מפתח

עלויות Scraping מתחלקות לשלושה מרכיבים:

1. מנוי לכלי או קרדיטים ל-API: APIs מנוהלים גובים לפי בקשה, לפי קרדיט או לפי רשומה. SerpApi גובה לפי חיפוש. Outscraper עובד במודל pay-as-you-go לפי רשומה. Thunderbit's API משתמשת במערכת קרדיטים (Extract = 20 קרדיטים לבקשה). תוסף Chrome של Thunderbit גובה קרדיט אחד לכל שורת פלט.
2. הוצאות פרוקסי (רק ב-DIY): פרוקסי residential ל-scraping של Google Maps עולים בדרך כלל 50–300 דולר לחודש, תלוי בנפח ובספק.
3. זמן מפתח (רק ב-DIY): בנייה ותחזוקה של סקריפטים ב-Puppeteer/Playwright. זו העלות הסמויה שהורגת את הכלכלה של DIY (עוד על זה בהמשך).

טבלת עלויות זה לצד זה: API מול Scraping בקנה מידה גדול

היקף	Google Places API (Enterprise + Atmosphere)	Managed Scraping API (הערכה)	DIY Scraping (פרוקסי + זמן פיתוח)
10K רשומות/חודש	כ-225 דולר (1K חינם, 9K × ‏$25/1K)	כ-50–150 דולר, תלוי בספק	כ-50 דולר לפרוקסי + 2–4 שעות פיתוח/חודש
100K רשומות/חודש	כ-2,475 דולר (לאחר תקרת החינם, חלים tiers לפי נפח)	כ-250–500 דולר	כ-150 דולר לפרוקסי + 8–16 שעות פיתוח/חודש
1M רשומות/חודש	כ-17,975 דולר (tiers לפי נפח מורידים עלות ליחידה, אבל הסכום הכולל עדיין גבוה)	כ-1,500–3,000 דולר	כ-300 דולר לפרוקסי + 20+ שעות פיתוח/חודש + סיכון לשבירה

הערות: אומדני ה-API משתמשים ב-tiers לפי נפח שפורסמו עבור Place Details Enterprise + Atmosphere, לאחר תקרת 1K החינמית. אומדני ה-Managed scraping הם טווחים משוערים בין ספקים. זמן פיתוח ב-DIY מניח עלות כוללת של 50–100 דולר לשעה.

התבנית ברורה: בקנה מידה תחביבי (מתחת ל-10K), המכסות החינמיות של ה-API עשויות להפוך אותו לאופציה הזולה ביותר, במיוחד אם צריך רק שדות Essentials או Pro. בקנה מידה עסקי (100K+), העלויות של ה-API מזנקות, במיוחד עבור שדות עשירים. בקנה מידה ארגוני (1M+), ה-API יכול להתקרב לעשרות אלפי דולרים בחודש, ואז scraping או שירותי dataset נעשים אטרקטיביים כלכלית — בהנחה שבאמת צריך את השדות הנוספים שה-API לא חושף.

אם אתם צריכים רק כתובות ו-Place IDs, אל תגרדו. ה-API זול יותר ומתאים יותר לזה. טיעון העלות לטובת scraping תקף רק כשצריך מידע שה-API לא יכול להחזיר.

בדיקת המציאות של Anti-Bot: למה Scrapers של Google שנבנים לבד נשברים

זה החלק שחסידי scraping נוטים לדלג עליו. Google לא רוצה שתגרדו את Google Maps. הם בנו כמה שכבות הגנה ומעדכנים אותן באופן קבוע.

מערך ההגנות של Google

• אתגרי reCAPTCHA: דפדפנים אוטומטיים מפעילים CAPTCHAs הרבה יותר מאשר משתמשים אנושיים
• רינדור JavaScript בצד לקוח: Google Maps היא אפליקציית JavaScript כבדה. בקשת HTTP פשוטה לא תחזיר תוכן מרונדר — צריך דפדפן headless מלא
• טביעת אצבע לדפדפן: Google מזהה דפדפנים headless דרך canvas fingerprints, WebGL, מאפייני navigator ואותות נוספים
• הגבלת קצב לפי IP: יותר מדי בקשות מאותו IP (או מאותו subnet של פרוקסי) והמערכת חוסמת
• שינויים במבנה ה-DOM: Google משנה את מבנה הדפים שלה באופן קבוע — הקונצנזוס בקהילות Reddit ו-GitHub הוא שסלקטורים נשברים כל כמה שבועות עד חודשים

הנקודה האחרונה היא הרוצח השקט. סקריפט Puppeteer שעבד מצוין ביוני יכול להחזיר תוצאות ריקות ביולי, רק כי Google שינתה שם של מחלקת CSS או ארגנה מחדש div.

העלות הנסתרת של תחזוקת סקריפטים עצמאיים

בכל פעם ש-Google משנה את ה-DOM, מישהו בצוות צריך:

1. לזהות שה-scraper נשבר (רצוי לפני שנתונים שגויים מתפשטים)
2. לבדוק את מבנה הדף החדש
3. לעדכן סלקטורים, לטפל בסוגי CAPTCHA חדשים, לכוון מחדש לוגיקת retry
4. לבדוק ולפרוס מחדש

במהלך שנה, זמן התחזוקה הזה יכול בקלות לעלות על עלות המנוי ל-API מנוהל. ראיתי צוותים שורפים 40+ שעות מפתח בשנה רק כדי לשמור על scraper של Google Maps בחיים — וזה אומדן שמרני למדי עבור סטאפ ברמת מורכבות בינונית.

למה בכלל קיימים APIs מנוהלים ל-Scraping

עומס התחזוקה הזה הוא בדיוק הסיבה לשירותים כמו Thunderbit's API, SerpApi ו-Outscraper. הם סופגים את המורכבות של anti-bot — רינדור JS, פתרון CAPTCHA, סיבוב פרוקסים, תחזוקת סלקטורים — ומחזירים נתונים מובנים.

נקודת הקצה POST /extract של Thunderbit עם renderMode: "full" מטפלת בדפים עתירי JavaScript כמו Google Maps ומחזירה JSON מובנה שתואם לסכמה, לא HTML גולמי שעדיין צריך לנתח. ה-MCP server מרחיב את זה לסוכני AI — Claude, Cursor או תהליכי עבודה אחרים מבוססי LLM יכולים לגרד נתוני Google Maps תוך כדי משימה, בלי לצאת מהסביבה שלהם.

למשתמשים לא טכניים, ה-Thunderbit Chrome Extension הוא האפשרות ללא תחזוקה: פותחים דף Google Maps, לוחצים "AI Suggest Fields", לוחצים "Scrape", ומייצאים ל-Sheets. בלי סלקטורים, בלי פרוקסי, בלי דיבוג.

SerpApi ו-Outscraper הן חלופות טובות עם מודלי תמחור ופורמטי פלט שונים. SerpApi מחזירה JSON מובנה לכל חיפוש; Outscraper גובה לפי רשומה במודל pay-as-you-go. הבחירה הנכונה תלויה בהיקף, בתקציב, ובשאלה אם אתם צריכים JSON מובנה או נוח לכם לנתח פלט חצי־מובנה.

תוכנית העבודה ההיברידית: להשתמש ב-Google Places API וב-Scraping יחד

אף אחד מהמאמרים המובילים בנושא לא מציע את מה שראיתי עובד הכי טוב בפועל: להשתמש בשניהם. הרבה צוותים נשענים בסוף על ה-API הרשמי עבור חלק מהמשימות, ועל scraping עבור אחרות. הטריק הוא להתאים כל כלי למשימה הנכונה.

מתי ה-API הרשמי מנצח

• Autocomplete באפליקציית פרודקשן חיה: שיהוי נמוך, עמידה בתנאי השימוש, SLA אמין. אין תחרות.
• Back-end לאפליקציה מבוססת מיקום: store locators, אימות כתובות, התאמת Place IDs. ה-API מובנה, נתמך ומתועד.
• אינטגרציות רגישות לתאימות: חוזים ארגוניים, מוצרים מול לקוחות, או כל הקשר שבו עמידה בתנאי השימוש של Google היא לא דבר שאפשר להתפשר עליו.

מתי Scraping מנצח

• חילוץ מלא של ביקורות (5K+ ביקורות לכל מקום): ניתוח סנטימנט, ניטור מוניטין, benchmarking מול מתחרים. מגבלת 5 הביקורות של ה-API הופכת אותו לחסר ערך כאן.
• חילוץ חד־פעמי של רשימת לידים: זול יותר למשימות batch בלי חיוב שוטף. כלי ללא קוד כמו Thunderbit יכול לגרד רשימת עסקים ולייצא לגיליון תוך דקות.
• ניתוח popular times / תנועת לקוחות: לא זמין דרך ה-API. נקודה.
• נתוני Q&A, ו-"אנשים גם חיפשו" של מתחרים: מופיעים רק בדף, לא ב-API.

מתי גישה היברידית הגיונית

• ניטור מתמשך של מחיר/דירוג: משתמשים ב-API לנתונים מובנים בסיסיים (Place ID, כתובת, דירוג מצטבר), ואז ב-scraping לשדות עמוקים שה-API מפספס (ביקורות מלאות, popular times).
• תהליכי העשרה: משתמשים ב-API כדי לקבל Place IDs ומידע עסקי קנוני, ואז מגרדים דפי רישום בודדים כדי לקבל סט ביקורות מלא, Q&A והקשר של מתחרים.
• ניטור מתוזמן: ה-scheduled scraper של Thunderbit (למשתמשים ללא קוד) או batch extract דרך CLI (למפתחים) יכולים לטפל ב-scraping חוזר בלי תשתית מותאמת אישית.

מטריצת החלטה לפי שימוש

שימוש	שיטה מומלצת	למה
Autocomplete באפליקציה חיה	✅ API רשמי	שיהוי נמוך, תאימות לתנאי השימוש, אמינות
שליפת 5K+ סטים מלאים של ביקורות	✅ Scraping / Scraping API	ה-API מוגבל ל-5 ביקורות למקום
רשימת לידים של עסקים מקומיים חד־פעמית	✅ Scraping (או תוסף Thunderbit)	זול יותר ל-batch; בלי חיוב מתמשך
ניתוח popular times / תנועת לקוחות	✅ Scraping בלבד	לא זמין דרך ה-API
ניטור מתמשך של מחיר/דירוג	⚠️ היברידי	API לנתונים בסיסיים, scraping לשדות עמוקים
Back-end לאפליקציה מבוססת מיקום	✅ API רשמי	מובנה, נתמך, עם SLA
מעקב אחר מיקום ב-SERP עבור SEO מקומי	✅ Scraping / SERP API	זו לא המטרה של Places API
"אנשים גם חיפשו" של מתחרים	✅ Scraping בלבד	לא חשוף ב-API

תרשים החלטה: Google Places API מול Scraping — מה כדאי לבחור?

במקום "זה תלוי" מעורפל, הנה מסגרת החלטה ברורה. עברו דרך ארבע השאלות האלה:

1. האם אתם צריכים נתונים בזמן אמת באפליקציית פרודקשן? → כן: השתמשו ב-API הרשמי. הוא נתמך, יש לו SLA, והוא עומד בתנאי השימוש. עצרו כאן. → לא: המשיכו.

2. האם אתם צריכים נתונים שה-API לא מחזיר (ביקורות מלאות, popular times, Q&A)? → כן: צריך scraping. ה-API פשוט לא יכול לתת את המידע הזה. → לא: המשיכו.

3. כמה רשומות יש לכם בחודש? → מתחת ל-10K: ה-API כנראה הזול ביותר, במיוחד אם צריך רק Essentials או Pro. המכסות החינמיות מכסות הרבה בהיקף הזה. → מעל 10K: Scraping או managed scraping API כנראה יהיו כלכליים יותר, במיוחד עבור שדות עשירים.

4. האם יש לכם משאבי פיתוח לבנות ולתחזק scrapers? → כן: DIY עם Puppeteer/Playwright נותן שליטה מקסימלית (אבל צריך לתקצב תחזוקה שוטפת). → לא: השתמשו ב-managed scraping API (Thunderbit API, SerpApi, Outscraper) או בכלי ללא קוד (Thunderbit Chrome Extension).

השוואה מהירה בין חלופות שמיועדות למפתחים

כלי	מודל תמחור	פורמט פלט	מטפל ב-anti-bot	תמיכה ב-batch
Thunderbit API / MCP	מבוסס קרדיטים (Extract = 20 קרדיטים לבקשה)	JSON מובנה תואם סכימה	✅ רינדור JS, סיבוב פרוקסים, ניתוב גיאוגרפי	✅ עד 100 URLs לכל batch
SerpApi	לפי חיפוש (תוכניות מדורגות)	JSON מובנה	✅	✅ דרך פרמטרים ב-API
Outscraper	לפי רשומה (pay-as-you-go)	JSON / CSV	✅	✅ דרך task queues
DIY (Puppeteer/Playwright)	פרוקסי + זמן פיתוח	HTML גולמי (אתם מנתחים אותו)	❌ אתם מטפלים בזה	✅ כל מה שתבנו

היתרון המבדל של Thunderbit API: הוא מחזיר JSON מובנה שתואם לסכמה שאתם מגדירים ב-JSON Schema — לא HTML גולמי או Markdown שעדיין צריך לעבד. אם אתם מזינים צינור LLM או טוענים מסד נתונים, זה חוסך זמן post-processing אמיתי.

איך Thunderbit משתלב כאן (למשתמשים עסקיים ולמפתחים)

בניתי את Thunderbit כדי לגשר על הפער בין "אני צריך נתונים מ-Google Maps" לבין "אני לא רוצה להפוך למהנדס תשתיות scraping." הנה איך זה עובד לשני הקהלים.

למשתמשים לא טכניים: תוסף Chrome

1. פותחים דף Google Maps — דף תוצאות חיפוש או רישום של עסק בודד
2. לוחצים "AI Suggest Fields" — ה-AI של Thunderbit קורא את הדף ומציע עמודות (שם העסק, כתובת, דירוג, ביקורות, טלפון וכו')
3. לוחצים "Scrape" — התוסף מחלץ את הנתונים לטבלה מובנית. אפשר להשתמש ב-cloud mode עד 50 דפים במקביל
4. מגרדים תת־דפים — לוחצים "Scrape Subpages" כדי להיכנס לכל רישום ולשלוף פרטים מלאים
5. מייצאים — ל-Excel, Google Sheets, Airtable או Notion. ייצוא נתונים חינמי, בלי חומת תשלום

לניטור חוזר — בדיקות שבועיות של דירוג מתחרים, רישומים חדשים של עסקים — ה-scheduled scraper רץ אוטומטית בקצב שבחרתם.

למפתחים: API, MCP Server ו-CLI

• POST /extract עם JSON Schema: שולחים URL של Google Maps, מגדירים את השדות שרוצים, ומקבלים JSON מובנה. מגדירים renderMode: "full" לדפים עתירי JavaScript. Thunderbit מטפל ברינדור, anti-bot, סיבוב פרוקסים וניתוב גיאוגרפי.
• POST /distill: מקבלים Markdown נקי מכל דף — שימושי לצינורות LLM שצריכים תוכן גולמי ולא שדות מובנים. 1 קרדיט לבקשה לעומת 20 ב-Extract.
• MCP Server: סוכני AI (Claude, Cursor) יכולים לגרד נתוני Google Maps תוך כדי משימה. תומך ב-distillation, חילוץ מובנה, הצעות לשדות ומשימות batch עד 100 כתובות.
• CLI: thunderbit batch extract --file urls.txt --schema places.json עבור scraping מתוזמן או משולב CI/CD.

תמחור הקרדיטים: Extract = 20 קרדיטים לבקשה, Distill = 1 קרדיט לבקשה. הקרדיטים ב-API הם לפי בקשה, לא לפי שורה (בניגוד לתוסף, שבו 1 קרדיט = שורת פלט אחת). בדקו את Thunderbit Pricing לתוכניות המעודכנות.

שיקולים משפטיים ותנאי שימוש

אשמור את זה קצר ועובדתי — בלי הפחדות ובלי מכירת יתר.

ה-Google Places API מגיע עם תנאים ברורים: התנאים הספציפיים לשירות של Google אומרים שתוכן של Places API ניתן לשימוש גם בלי מפה של Google, אבל אסור להשתמש בו עם מפה שאינה של Google. ערכי latitude/longitude אפשר לשמור במטמון עד 30 ימים קלנדריים רצופים; אפשר לשמור Place IDs ללא הגבלת זמן. נדרשת ייחוסיות עבור פרטים, תמונות וביקורות.

Scraping של Google Maps עשוי להפר את תנאי השימוש של Google. האכיפה משתנה — הסיכונים כוללים חסימות IP, קירות CAPTCHA, ובמקרים נדירים גם צעדים משפטיים. APIs מנוהלים ל-scraping בדרך כלל סופגים חלק מעומס התאימות בשם המשתמשים, אבל זה לא מגן משפטי.

לאפליקציות פרודקשן שפונות למשתמשי קצה, ה-API הרשמי הוא הבחירה הבטוחה יותר. למחקר פנימי, ניתוח batch ומודיעין תחרותי, scraping הוא פרקטיקה נפוצה בתעשייה. התייעצו עם יועץ משפטי לגבי תהליכי עבודה מסחריים.

מה הייתי בוחר בפועל, ולמה

אחרי שצללתי לתמחור, לרשימות השדות, לדיונים בקהילה ולתיעוד של הכלים, זו המסקנה שלי:

• להשתמש ב-API הרשמי כשצריך נתונים בזמן אמת, תואמי תנאי שימוש, בתוך אפליקציית פרודקשן, או כששדות Essentials/Pro מספיקים והנפח נמוך מ-10K לחודש. המכסות החינמיות נדיבות בהיקף קטן, ואיכות הנתונים מעולה.
• להשתמש ב-scraping (API מנוהל או כלי ללא קוד) כשצריך ביקורות מלאות, popular times, Q&A, הקשר של מתחרים, או כל שדה שה-API לא חושף. גם כשנפח העבודה חורג מ-10K–100K רשומות בחודש ואתם מבקשים שדות עשירים (Enterprise + Atmosphere) — החשבון של ה-API נעשה קשה להצדקה.
• להשתמש בשניהם כשזרימת העבודה דורשת Place IDs קנוניים ונתונים מובנים בסיסיים (API) לצד מודיעין עמוק מהדף עצמו (scraping). זה הרבה יותר נפוץ ממה שרוב המאמרים מודים.

נקודת המפנה בעלויות: מתחת לכ-10K רשומות בחודש עם שדות בסיסיים, ה-API פשוט יותר ולעיתים קרובות חינמי. מעל זה, במיוחד עבור נתונים עשירים, scraping נעשה חסכוני יותר. ב-1M רשומות עם שדות Enterprise + Atmosphere, אתם מסתכלים על כ-18K דולר לחודש ב-API מול חלק קטן מזה עם scraper מנוהל.

אם תרצו לבדוק את זה בעצמכם, Thunderbit Chrome Extension הוא הדרך המהירה ביותר לראות מה scraping תופס לעומת ה-API. עבור תהליכי עבודה של מפתחים, תיעוד Thunderbit API כולל כל מה שצריך כדי להתחיל. ולקריאה נוספת על web scraping ללא קוד או על AI web scraping באופן כללי, כיסינו את הנושאים האלה בהרחבה בבלוג.

נקודות מפתח

• Google Places API הוא הכלי הנכון לאפליקציות פרודקשן, autocomplete וחיפושי מקום מובנים — אבל הוא מוגבל ל-5 ביקורות, 10 תמונות, ולא חושף popular times, Q&A או הצעות למתחרים כשדות סטנדרטיים.
• Scraping תופס את כל מה שנראה בדף Google Maps, כולל סטים מלאים של ביקורות ונתוני popular times, אבל מחייב התמודדות עם הגנות anti-bot או תשלום עבור שירות מנוהל.
• מתחת ל-10K רשומות בחודש, המכסות החינמיות של ה-API הופכות אותו לעיתים קרובות לאפשרות הזולה ביותר. מעל 100K, scraping או APIs מנוהלים לרוב חסכוניים יותר עבור נתונים עשירים.
• Scrapers שנבנים לבד נשברים לעיתים קרובות בגלל הגנות anti-bot ושינויים ב-DOM של Google — כדאי לתקצב 40+ שעות מפתח בשנה לתחזוקה, או להשתמש בכלי מנוהל.
• האסטרטגיה הכי טובה בעולם האמיתי היא לרוב היברידית: API עבור מזהים קנוניים ושדות בסיסיים, scraping עבור מודיעין עמוק שה-API לא יכול להחזיר.
• Thunderbit משרת את שני הצדדים: תוסף Chrome למשתמשים ללא קוד, ו-API/MCP server שמחזירים JSON מובנה למפתחים.

שאלות נפוצות

האם אפשר לקבל יותר מ-5 ביקורות של Google דרך Places API?

לא. Google Places API מגביל את החזרת הביקורות ל-5 לכל מקום, ממוינות לפי רלוונטיות. זה היה המצב מאז שה-API הושק, וזה לא השתנה למרות שנים של בקשות מפתחים. כדי לגשת לכל הביקורות הזמינות על עסק, scraping (עצמאי או דרך API מנוהל) הוא האפשרות היחידה.

האם scraping של Google Maps חוקי?

אין תשובת כן/לא גורפת. Scraping של נתוני Google Maps שנראים לציבור עשוי להפר את תנאי השימוש של Google, והאכיפה נעה מחסימות IP ועד, לעיתים נדירות, צעדים משפטיים. הרבה עסקים משתמשים ב-scraping למחקר פנימי ולמודיעין תחרותי בלי בעיות. APIs מנוהלים ל-scraping סופגים חלק מסיכון התאימות, אבל הם לא מגן משפטי. אם אתם בונים מוצר מסחרי או מעבדים מידע אישי, התייעצו עם עורך דין.

כמה עולה Google Places API עבור 100K חיפושים?

זה תלוי באילו שדות מבקשים. עבור Place Details ברמת Essentials, כ-450 דולר. ברמת Pro, כ-1,615 דולר. ב-Enterprise + Atmosphere (שכולל ביקורות ושירותים), כ-2,475 דולר. אם הוורקפלואו גם דורש Text Search Pro לצורך גילוי, צריך להוסיף עוד כ-3,040 דולר. האומדנים האלה משתמשים ב-tiers לפי נפח ש-Google פרסמה ומניחים בקשה מחויבת אחת לכל רשומה אחרי תקרת החינם.

מה ההבדל בין scraping API לבין כלי scraping ללא קוד?

scraping API (כמו Thunderbit's Open API) מיועד למפתחים שמשלבים scraping בקוד, בצינורות אוטומציה או בתהליכי עבודה של סוכני AI דרך בקשות HTTP. כלי ללא קוד (כמו Thunderbit Chrome Extension) מאפשר למשתמשים לא טכניים להצביע, ללחוץ ולייצא נתונים מהדפדפן בלי לכתוב קוד. שניהם יכולים להחזיר נתונים מובנים; ההבדל הוא בממשק ובמודל האינטגרציה.

האם Thunderbit עובד על דפי Google Maps?

כן. תוסף Chrome יכול לגרד תוצאות חיפוש של Google Maps ורישומי עסקים בודדים — ה-AI מציע שדות אוטומטית, ואפשר להשתמש ב-cloud mode עד 50 דפים במקביל. נקודת הקצה POST /extract של ה-API עם renderMode: "full" מטפלת בדפים של Google Maps שמרונדרים ב-JavaScript ומחזירה JSON מובנה שתואם לסכמה. ה-MCP server מאפשר לסוכני AI לגרד נתוני Google Maps תוך כדי תהליך העבודה.

למידע נוסף

• What Is Web Scraping
• Ai Web Scraping
• Instant Data Scraper Alternatives
• Web Scraping Without Coding
• Ai Lead Generation