דף חיפוש אחד של Google Shopping יכול להסתיר מודעות ממומנות בין תוצאות אורגניות, להשמיט מחירים לגמרי כשמוצר אזל מהמלאי, ואפילו לשכפל את אותו מוצר אצל חמישה מוכרים שונים. במהלך השבועות האחרונים פירקתי לגורמים תשעה כלים שטוענים שהם יודעים להפוך את הבלגן הזה לנתונים נקיים ושימושיים — והתשובה הכנה היא ש"הכי טוב" תלוי לחלוטין בשאלה אם אתם מפתחים שבונה צינור נתונים, או משווקים שרק רוצים את המספרים בגיליון עד יום שישי.
הפיצול הזה חוזר שוב ושוב גם במחקר. ב־r/learnpython וב־r/node אנשים מחליפים טיפים על Puppeteer, Playwright ורוטציית פרוקסים. ב־r/PPC, לעומת זאת, מחפשים משהו יותר בכיוון של "תנו לי פשוט את הנתונים, אני לא רוצה לגעת בקוד". לכן, במקום לדרג את תשעת הכלים לפי האלפבית או להדביק תגית "הטוב ביותר" למי שיש לו את דף הבית הכי נוצץ, דירגתי כל כלי מול שישה קריטריונים קונקרטיים וסידרתי אותם לפי תהליך העבודה — קודם כל APIs מנוהלים ל־SERP, אחר כך תשתיות של פרוקסים וסקרייפינג, אחר כך פלטפורמת אקטורים למפתחים, ולבסוף כלי דפדפן בלי קוד.
מה הופך סקרייפר Google Shopping ל"טוב"? קריטריוני הדירוג שלנו
"הכי טוב" הוא מושג שעושה הרבה עבודה ברוב הכתבות מסוג רשימה, אז הנה מה הוא באמת אומר כאן. דירגתי את כל תשעת הכלים לפי אותם שישה גורמים, במקום לחזור על מה שכל דף שיווק של ספק טוען:
- כיסוי נתונים — האם הסכמה המתועדת מחזירה בצורה אמינה מחיר, מוכר, דירוג, מספר ביקורות, משלוח, והבחנה אמיתית בין מודעות ממומנות לתוצאות אורגניות?
- תמיכה במיקום/אזור — האם אפשר באמת לכוון למדינה, שפה או מכשיר מסוימים, או שאתם תלויים במה שכתובת ה־IP של הפרוקסי מחליטה להחזיר?
- מורכבות ההקמה — האם זה מפתח API ובקשת GET, או משימה בתור עם callbacks, או תהליך דו־שלבי עם שרשור טוקנים, או דף שלוחצים עליו?
- עומס תחזוקה — מי אחראי כש־Google משנה את מבנה ה־HTML או זורקת CAPTCHA: אתם, או הספק?
- מסלול ייצוא/אינטגרציה — dump של JSON, או חיבור ישיר ל־Sheets, Airtable או למחסן הנתונים שלכם?
- שקיפות מחירים — האם הספק מפרסם עלות אמיתית ליחידה שאפשר לחשב ממנה, או שצריך "לפנות למכירות" כדי לגלות כמה משהו עולה?
דבר אחד שאני לא מתכוון לעשות כאן הוא להמציא שיעורי הצלחה, מדדי מהירות או אחוזי דיוק. אף אחד ברשימה הזאת לא ביצע בנצ'מרק עצמאי מול האחרים, וטענות ספקים כמו "99.9% הצלחה" או "מהיר בטירוף" הן טקסט שיווקי, לא מדידה. במקום זה תקבלו את מה שהתיעוד של כל ספק עצמו באמת מוכיח — ובסוף, זה די והותר לעבודה.
מפתחים רוצים קוד, משווקים רוצים בלי קוד
אם ביליתם קצת זמן בפורומים שקשורים לסקרייפינג, אתם כבר יודעים שהפיצול הזה קיים, אבל שווה לנסח אותו במפורש כי הוא מסביר את סדר הרשימה. מפתחים שבונים צינור נתונים רוצים מפתח API, JSON צפוי מראש, פרמטרי מיקום מפורשים, וסכמה שאפשר לאמת ולנרמל בהמשך.
אנשי שיווק ו־PPC רוצים משהו יותר בכיוון של "תכוון לדף, קבל את הגיליון". הם לא רוצים לתחזק סקריפט של Puppeteer כש־Google משנה את פריסת ה־Shopping בפעם השלישית ברבעון הזה (וזה יקרה — Google משנה את ה־markup של Shopping לעיתים קרובות מספיק כדי שגם ספקי ה־API מפרסמים על זה changelogs).
לכן הרשימה הזו נעה מספקי SERP API מנוהלים (SerpApi, Serper, SearchAPI, DataForSEO) — JSON מובנה, בלי התעסקות בפרוקסים, אבל עדיין דורש קוד — דרך תשתיות של פרוקסים וסקרייפינג (Bright Data, Oxylabs) שנותנות יותר שליטה במחיר של יותר הגדרה, אל פלטפורמת אקטורים גמישה למפתחים (Apify), ומסתיימת ב־Thunderbit, כלי דפדפן אוטונומי בלי קוד לאנשים שבאמת לא רוצים לכתוב או לתחזק קוד סקרייפינג.
9 סקרייפרי Google Shopping הטובים ביותר במבט אחד
| כלי | מודל איסוף | מורכבות הגדרה | תמיכה במיקום | מי הכי מתאים | עומס תחזוקה |
|---|---|---|---|---|---|
| SerpApi | API מנוהל ל־Shopping | נמוכה (מפתח API) | חזקה (location, gl, hl, device) | מהנדסי נתונים, כלי SEO | מטופל על ידי הספק |
| Serper | SERP API כללי, Shopping כסוג תוצאה אחד | נמוכה | בינונית (מדינה/שפה מתועדים) | מפתחים רגישי-עלות | מטופל על ידי הספק |
| SearchAPI | API מנוהל ל־Shopping + Product Offers | נמוכה–בינונית (דו־שלבי להצעות) | בינונית | צוותי השוואת הצעות/מוכרים | מטופל על ידי הספק |
| DataForSEO | API לסוחר מבוסס משימות | בינונית (תור/callback) | חזקה | צינורות בתפזורת/מתוזמנים | מטופל על ידי הספק |
| Bright Data | Dataset + Scraper API + SERP API | בינונית (תלוי בממשק) | חזקה מאוד | צוותי נתונים ארגוניים | משותף |
| Oxylabs | API דו־שלבי לחיפוש + פרטי מוצר | בינונית (שרשור טוקנים) | חזקה מאוד | צוותי נתונים ארגוניים | משותף |
| Scrapingdog | נקודת קצה ייעודית ל־Shopping | נמוכה–בינונית | בינונית | מפתחים שמקפידים על תקציב | מטופל על ידי הספק |
| Apify | פלטפורמת אקטורים/מפתחים | בינונית–גבוהה | תלוי באקטור | בוני צינורות מותאמים אישית | מנוהל על ידי המשתמש |
| Thunderbit | חילוץ בדפדפן, בלי קוד, עם סוכנות אוטומטית | נמוכה מאוד (One Click Extract) | תלוי בדף היעד | משווקים/PPC, ללא קוד | נמוך, תלוי בדף |
(כדאי לאמת מחירים עדכניים, מגבלות קרדיטים וכיסוי לפי מיקום בתיעוד החי של כל ספק לפני שמתחייבים — הדברים האלה משתנים מהר, ולכמה מהספקים כבר היו שינויים שוברים ב־2026.)
1. SerpApi — מנוהל, עשיר בפיצ'רים, ומודע במפורש ל־cache
SerpApi מפעיל מנוע ייעודי ל־Google Shopping (engine=google_shopping) שמקבל את השאילתה שלכם ומחזיר shopping_results מובנים — מיקום, כותרת, מזהה מוצר, מחיר וגם מחיר מספרי שחולץ, מחיר ישן/בתשלומים, משלוח, מצב, דירוג, ביקורות ותמונות. זו סכמה חזקה באמת, ו־SerpApi מתעד בנפרד תוצאות Shopping ממומנות דרך סכמת Google Ads Shopping, כך שאפשר לאתר מודעות ממומנות — רק לא כ־flag אחיד ואמין של sponsored: true/false שמובנה בתוך תגובת ה־Shopping הייעודית.
מה שמייחד את SerpApi הוא כמה הוא מפורש לגבי הדברים שבדרך כלל נושכים אותך מאוחר יותר. תמיכה במיקום מאפשרת location ברמת עיר או uule מדויק, לצד פרמטרים נפרדים של gl (מדינה), hl (שפה) ו־device (desktop, tablet, mobile). והוא גם אומר במפורש ששאילתות זהות יכולות להיפתר מה־cache עד שעה אחת כברירת מחדל — תשובות מה־cache הן בחינם, ו־no_cache=true מכריח שליפה חדשה. זו רמת גילוי שרוב הספקים מסתירים או מדלגים עליה.
המחיר (נבדק ב־2026-08-13) פומבי וחודשי: מסלול Free עם 250 חיפושים, Starter ב־$25 ל־1,000, ועד Big Data ב־$275 ל־30,000. רק חיפושים מוצלחים נספרים מהמכסה — בקשות מה־cache או בקשות שנכשלו לא נספרות. שווה לדעת: Google הגישה בתחילת 2026 תביעה נגד SerpApi על שיטות גישה לנתונים; SerpApi חולק על התיאור ואומר שהוא ניגש לתוצאות ציבוריות ללא אימות. זו סיטואציה משפטית חיה, לא פסק דין, אז התייחסו לזה כגורם סיכון שצריך לעקוב אחריו ולא כסיבה להימנע מהכלי באופן מוחלט.
מתאים במיוחד ל: מפתחים שרוצים את סכמה ה־Shopping העשירה ביותר בתיעוד ואת השליטה הכי מפורשת על cache ועל locale.
2. Serper — מהיר, ידידותי לתקציב, ועם טענת freshnness הכי נקייה
Serper מציג את עצמו כ־Google SERP API כללי, שבו Shopping יושב לצד Search, Images, News, Maps, ועוד כמה סוגי תוצאות. אם אתם כבר שולפים תוצאות חיפוש רגילות ורק צריכים להוסיף נתוני Shopping, זו תוספת עם פחות חיכוך מאשר להרים ספק ייעודי נוסף.
הדוגמה הציבורית ל־Shopping מחזירה כותרת, מקור, קישור ישיר למוכר, מחיר בפורמט מוצג, משלוח, דירוג, מספר מדרגים, מספר הצעות, מזהה מוצר ומיקום — מספיק טוב לניטור בסיסי של כרטיסי מוצר, אם כי התיעוד הציבורי לא חושף את אותו עומק של פרטי הצעת מוכר או שדות של מחיר מבצע כמו ש־SearchAPI או Oxylabs מתעדים. נקודת המכירה הכי נקייה של Serper היא ההבטחה ל־freshness: הוא אומר שכל קריאה שואלת את Google בלייב ושום דבר לא נשמר ב־cache, מה שמסיר את ההחלטה על ניהול cache שמשתמשי SerpApi צריכים לקבל (אבל במחיר של תשלום על כל שאילתה חוזרת, גם אם היא זהה).
התמחור עובד לפי חבילות קרדיטים בתשלום מראש ולא לפי מנוי — 2,500 שאילתות חינם להתחלה, ואז $50 ל־50,000 קרדיטים עם ירידה עד $0.30 ל־1,000 בחבילה העליונה, כשהקרדיטים תקפים לשישה חודשים. דף התמחור גם מגלה משהו מרענן בכנותו: בקשות בודדות יכולות לקחת 2–4 שניות "כאשר צריך לנסות שוב את הבקשה מול Google", וזה זנב השהיה אמיתי שכדאי לתכנן סביבו, ולא בנצ'מרק שצריך להילחץ ממנו.
מתאים במיוחד ל: צוותים שכבר משלבים SERP API רחב יותר ורוצים ש־Shopping יהיה בונוס, לא מוצר ייעודי.
3. SearchAPI — פירוט חזק ברמת הצעות, עם בעיית תיעוד קטנה
SearchAPI מפעיל תהליך דו־שלבי שבאמת שימושי אם אתם צריכים השוואות מחירים ברמת מוכר. נקודת הקצה של Shopping מחזירה את שדות הכרטיס הרגילים, ועוד product_token — והטוקן הזה פותח Product Offers API נפרד שמחזיר מערך offers עם קישור למוכר, מחיר, מחיר משלוח, מחיר כולל, מצב מלאי ושיטות תשלום לכל מוכר. אם המקרה שלכם הוא "תראו לי כל מחיר שבו המוצר המדויק הזה נמכר אצל מוכרים שונים", זו הדרך הישירה ביותר ברשימה.
יש כאן מלכודת אמיתית שחשוב לסמן: נכון ל־15 במאי 2026, השינויים של Google חייבו את SearchAPI לדרוש product_token חדש לכל בקשה — הפרמטרים הישנים product_id/prds מחזירים כעת שגיאת 400 פשוטה. אם אתם משלבים לפי דוגמאות קוד או מדריכים ישנים, זה ישבור עד שתבחינו.
SearchAPI גם מזהיר במפורש שמסננים בשפה טבעית בתוך השאילתה (כמו "מתחת ל־$30" או "משומש") הם רמזים, לא פילטרים קשיחים — Google עדיין עשויה להחזיר תוצאות מחוץ להם כשיש מעט התאמות. מסנני shoprs מקודדים הם המסלול הקשיח. ויש גם סתירה תיעודית פתוחה שכדאי להכיר: SearchAPI משווק את הנקודה כ־"real-time", אבל הסכם עיבוד הנתונים שלו עצמו אומר שהוא שומר תוצאות ב־cache לשיפור ביצועים. גם כאן אין TTL ציבורי מתועד בשום צד, אז אם מחירים משתנים במהירות חשוב לכם, בדקו בעזרת שאילתות חוזרות לפני שבונים צינור נתונים על הנחת freshness.
המחיר (נבדק ב־2026-08-13) מתחיל ב־$40 לחודש במסלול Developer, ב־$4 ל־1,000 חיפושים, ויורד בנפחים גבוהים יותר, עם מגבלת שעה מתועדת של 20% ממכסת הקרדיטים החודשית.
מתאים במיוחד ל: צוותים שעושים השוואה ברמת מוכר/הצעה ויכולים לסבול תהליך של שתי בקשות ולבדוק freshness בעצמם.
4. DataForSEO — נתוני Merchant ו־Shopping בקנה מידה גדול, דרך תור
DataForSEO הוא באמת החריג בקבוצה הזו, כי הוא לא API של בקשה/תגובה בזמן אמת — אלא תור מבוסס משימות. אתם שולחים task עם מילת מפתח, מיקום ושפה, מקבלים task ID, ואז או שמבצעים polling לתוצאות או מגדירים כתובת callback. שליפה סטנדרטית בלבד; אין מצב live לנקודות הקצה המרכזיות של Shopping, לא משנה מה שפת השיווק הכללית מרמזת.
זה חשוב כי זה משנה את חישוב מורכבות ההגדרה. זה לא קשה, בדיוק, אבל זו תפיסה מנטלית שונה מ־"קוראים ל־API ומקבלים JSON בחזרה" — אתם מנהלים מצב של משימות, והתיעוד של DataForSEO עצמו אומר ששרת callback שלא מגיב בתוך 10 שניות מעביר את המשימה לתור "Tasks Ready", ואז צריך לבצע polling ידני.
הוא נכנס לרשימה בגלל מחקר בתפזורת: נקודת הקצה Products מחזירה rank, domain, title, price, old price, rating ומספר הצבעות, עם מזהי סוג תוצאה שמבדילים בבירור בין google_shopping_sponsored_carousel, google_shopping_paid ותוצאות אורגניות — ממש אחד ההבדלים הכי ברורים בין ממומן לאורגני בכל הרשימה הזו. הוא גם מזהיר במפורש ש־product_id הוא דינמי ויכול להיות null, ושגורמי דירוג מותאמים אישית (היסטוריית משתמש, העדפות מיקום) מוצאים במכוון מהתוצאות — בדיקת כנות שימושית שרוב הספקים מדלגים עליה.
התמחור מחושב לפי בלוקים של תוצאות (40 ל־Products, 10 ל־Sellers/Reviews) במהירות תור רגילה של עד 45 דקות, או תור עדיפות של עד דקה אחת במחיר כפול. חשבונות חדשים מקבלים קרדיט ניסיון של $1 ללא תפוגה.
מתאים במיוחד ל: צוותים שנוחים להם תהליכי עבודה בתור/משימה וצריכים נתוני merchant/product בתפזורת ובתזמון.
5. Bright Data — שלושה מוצרים עם אותה תגית שם
כאן אני צריך להאט, כי Bright Data מציעה בעצם שלוש דרכים שונות לגמרי להשיג נתוני Google Shopping, והן לא מתנהגות אותו דבר בכלל. יש dataset שנאסף מראש (משווק עם יותר מ־7.4 מיליארד רשומות, ומסופק כ־JSON/CSV/Parquet למחסן הנתונים בענן שלכם לפי לוח זמנים), יש Google Scraper API עם מזהי scraper ייעודיים ל־Shopping שמריץ משימות סינכרוניות או אסינכרוניות, ויש SERP API שפוגע בכתובות Shopping חיות ומנתח תוצאות בזמן אמת. להתייחס אליהם כמוצר אחד זה המקום שבו הרבה כתבות השוואה נעשות רשלניות — אני לא אעשה את זה כאן.
נתוני הדוגמה של הדataset עצמו מציגים ערכי null עבור מזהה מוצר, תיאור, דירוג ומספר ביקורות בחלק מהרשומות — הוכחה ישירה מהספק ש־"dataset מובנה" לא אומר ש"כל שדה תמיד מאוכלס". ה־SERP API מתעד בנפרד Product Listing Ads כסוג תוצאה משלהם (top_pla, bottom_pla, jackpot_pla) עם כותרת, מחיר, חנות ודירוג — הבחנה שימושית באמת בין ממומן לאורגני אם אתם עובדים ספציפית עם ה־SERP API, ולא עם הדataset.
משימות אסינכרוניות דרך Scraper API יכולות להחזיר "success" כללי בזמן שבתוך אותו batch יש בקשות בודדות שנכשלו — התיעוד אומר במפורש לבדוק שדה errors ולנסות שוב כל אחת מהן בנפרד, וזה פרט תחזוקה שכדאי לתכנן עבורו אם אתם מריצים batches גדולים.
התמחור (נבדק ב־2026-08-13) משתנה מאוד לפי הממשק: ה־dataset הראה $250 ל־100,000 רשומות חד־פעמיות, ה־SERP API הציג 5,000 בקשות חודשיות חינם עם pay-as-you-go של $1.50 ל־1,000, ו־Shopping Scraper API הייעודי הציג בנפרד מסלול חינמי וקצב משלו. אל תניחו שהמספרים ניתנים להחלפה — בדקו את דף המוצר הספציפי שבו אתם באמת משתמשים.
מתאים במיוחד ל: צוותי enterprise שרוצים פלטפורמה אחת שמשלבת גם datasets מוכנים וגם גישה חיה ל־API, ושמוכנים לתמחר כל ממשק בנפרד.
6. Oxylabs — שרשרת דו־שלבית הכי ברורה בין חיפוש לפרטי מוצר
Oxylabs מחלקת את Shopping לשני יעדים ייעודיים: google_shopping_search לתוצאות ברמת רשימה, ו־google_shopping_product לנתונים מפורטים ברמת מוצר, מחוברים דרך product token. תגובת החיפוש מפרידה בצורה נקייה בין pla (מודעות Listing בתשלום) לבין מוצרים organic — כנראה הפיצול הכי ברור מתועד בין ממומן לאורגני בכל הרשימה — בעוד שנקודת הקצה של המוצר מוסיפה הצעות לפי מוכר עם מחיר מספרי, מצב, מס, מחיר כולל ומשלוח.
הבעיה, והיא ממשית: שרשרת הטוקנים הזו עובדת רק אם בקשת החיפוש כוללת גם render: "html" וגם parse: true. דלגו על אחד מהם, ולא תקבלו product token, וכל שלב פרטי המוצר יתפרק. Oxylabs גם מזהירה במפורש שבקשות החיפוש והבקשות למוצר חייבות להשתמש בערכי לוקליזציה זהים — אם ה־geo_location שונה בין שתי הקריאות, תוצאות המוצר עלולות לחזור חלקיות או שגויות. ואם אתם רוצים שהפאנל "More stores" ייפתח להצעות מוכרים נוספות, צריך להפעיל rendering גם עבורו, מה שמוסיף עלות.
פרט שקל לפספס: ה־FAQ של התמחור ב־Oxylabs מגדיר בקשות "מוצלחות" (ולכן ברות חיוב) ככאלה שכוללות גם תגובות 2xx וגם 4xx. אם הבקשה שלכם לא תקינה, ייתכן שעדיין תחויבו עליה.
ביקורות מוצר מתועדות רק ללוקליזציית US, ו־locale/language ו־locale/results-language הם באמת בקרות נפרדות — הגדרה של אחת לא מגדירה אוטומטית את השנייה.
מתאים במיוחד ל: צוותים טכניים שצריכים גם רמת דירוג וגם פירוט הצעות לפי מוכר, ויכולים להתמודד עם שרשור טוקנים ועקביות לוקליזציה כחלק מההגדרה.
7. Scrapingdog — נקודת קצה פשוטה, עם מעט מאוד פירוט ציבורי
Scrapingdog מציעה נקודת קצה ייעודית אחת ל־Google Shopping שלוקחת מפתח API ושאילתה, ומחזירה JSON עם כותרת, מחיר וגם מחיר מספרי שחולץ, מחיר ישן, דירוג, ביקורות, מקור/מוכר, משלוח ומיקום. הדף גם מציין סינון לפי מחיר, מותג, מדינה ושפה, וכן קטגוריית תגובה נפרדת של "ads" למעקב אחר רשימות ממומנות — אבל סכמת המודעות המדויקת ושמות הפרמטרים המדויקים לסינון לפי מיקום לא מתועדים במלואם בדף הציבורי, אז כדאי להקדיש זמן לבדיקה מול המקרה שלכם לפני שבונים על זה אוטומציה.
זהו הפריט היחיד ברשימה הזו שבו מתמטיקת עלות הקרדיטים פשוט לא מסתדרת מתוך התיעוד הציבורי בלבד: דף התמחור של Scrapingdog מציג מכסות חודשיות של קרדיטים (LITE ב־$40 לחודש עבור 200,000 קרדיטים, STANDARD ב־$90 לחודש עבור 1,000,000) אבל לא מציין בבירור כמה קרדיטים בדיוק עולה בקשה אחת ל־Google Shopping. אל תניחו שזה 1:1 כמו בדוגמאות של search API הכללי שלהם — בדקו ישירות מול הספק לפני שאתם מחשבים עלות אמיתית לשאילתה.
כמו רוב הספקים כאן, Scrapingdog משווקת פרוקסי מגורים מסתובבים מובנים וטיפול אוטומטי ב־CAPTCHA כמשהו שמטופל על ידי הספק. התייחסו לזה כהצהרה על גבול האחריות בתחזוקה, לא כהוכחה לגישה מובטחת.
מתאים במיוחד ל: מפתחים שמודעים לתקציב, רוצים נקודת קצה צרה וייעודית, ומוכנים לאמת עלויות קרדיטים ישירות לפני התחייבות.
8. Apify — תדונו באקטור, לא בשוק עצמו
אני צריך להיות גלוי לגבי משהו: Apify הוא לא סקרייפר יחיד ל־Google Shopping — אלא שוק של "Actors" שמתוחזקים עצמאית, והאחד שבדקתי מקרוב (Google Shopping Insights, שפורסם על ידי המפתח epctex ומסומן כ־"Maintained by Community") מתנהג אחרת לגמרי מהכלים המנוהלים על ידי ספקים למעלה. Apify מספקת את ה־runtime, את תשתית הפרוקסים ואת כלי הייצוא/ה־dataset. לוגיקת החילוץ עצמה ל־Shopping — והתחזוקה שלה — שייכת ל־epctex, לא ל־Apify עצמה.
ההבחנה הזו חשובה כי בדוגמת הפלט הרשמית של ה־Actor הזה מופיע שדה מחיר כ־null. לא "לפעמים", לא "למוצרים שאזלו" — רשומת הדוגמה המתועדת עצמה מציגה price: null וגם withoutDiscountPrice: null לצד שדות מאוכלסים של שם מוצר, מוכר ודירוג. זו הראיה הראשונה-יד של הספק הכי חזקה בכל הסקירה הזו לכך שאי אפשר להניח שנתוני מחיר יהיו מלאים, והיא מגיעה ישירות מהתיעוד של הכלי.
יש לכם קלטים להגדרה — includeSponsoredResults, includeComparisonPrices להשוואת מחירים בין מוכרים, יעד מדינה, maxItemsPerQuery — וגם הגדרת פרוקסי חובה (שלכם, או של Apify). התוצאות ניתנות לייצוא כ־JSON, XML, CSV או Excel דרך מערכת Dataset של Apify. ברישום ב־Store שבדקתי הופיעו בערך 2,300 משתמשים בסך הכול, אבל רק 2 משתמשים פעילים חודשית באותו זמן — מדד ששווה לשים לב אליו, כי "מתוחזק על ידי קהילה" עובד לשני הכיוונים: גמיש, אבל אמין רק כמו מי שבאמת משתמש בו ומדווח על בעיות.
מתאים במיוחד ל: מפתחים שנוח להם להעריך פעילות תחזוקה של Actor מסוים ולבדוק את סכמת הפלט האמיתית שלו לפני התחייבות — לא למי שמצפה ש־Apify כמותג תבטיח התנהגות עקבית.
9. Thunderbit — איסוף בלי קוד למשווקים, עם הסתייגות של אימות דף
Thunderbit מייצגת את הקצה השני של הרשימה הזו: תהליך עבודה בדפדפן, בלי קוד, לאנשים שרוצים לסקור את הדף שהם רואים ולהפוך אותו לטבלה מובנית, במקום לשלב Google Shopping API. זה הופך אותה להתאמה טבעית למשווקים, לאנשי PPC ולצוותי ecommerce קטנים שעושים בדיקות אד־הוק ולא צינור backend בנפח גבוה.
יש כאן הסתייגות ראייתית שלא הייתי מסתיר. כתובת המוצר הספציפית ל־Google Shopping שסופקה לאימות החזירה 404 כאשר נתפסה ב־13 באוגוסט 2026. האתר של Thunderbit עדיין מציג את תוסף הדפדפן, אפליקציית האינטרנט, תיעוד ה־API, ה־CLI, שרת MCP ו־scraper לפרטי מוצר, אבל עדות הניווט הזו לא מוכיחה באופן עצמאי קיומו של workflow ייעודי ל־Google Shopping, מסלול ייצוא מסוים, או API מובטח לפי מיקום. התייחסו לתוצאה כאיסוף מבוסס דף/סשן, ואמתו את ה־workflow החי מול דף ה־Shopping המדויק שבו אתם מתכננים להשתמש לפני שתסטנדרטיזו אותו לכל הצוות.
מתאים במיוחד ל: צוותים לא טכניים שמעריכים חילוץ גלוי ונבדק בדפדפן יותר מצינור JSON מנוהל על ידי מפתחים — בתנאי שה־workflow הנוכחי של Google Shopping מאומת לפני ההטמעה.
איזה נתונים באמת אפשר לסמוך עליהם? בעיית האמינות של השדות
זה החלק שרוב כתבות ההשוואה על Google Shopping מדלגות עליו לגמרי, וזו כנראה הנקודה החשובה ביותר שצריך להבין לפני שמבצעים אוטומציה כלשהי: לא כל שדה מופיע בכל רשימה, והנחה ש"חסר" פירושו "אפס" תזהם לכם את הנתונים בשקט.
| שדה | אמינות | המלכוד |
|---|---|---|
| כותרת | גבוהה | נרמלו וריאנטים/חבילות לפני התאמת מוצרים בין מקורות |
| מזהה מוצר | מותנה | DataForSEO מתעד אותו במפורש כדינמי ולפעמים null |
| מחיר | מותנה | הדוגמה הרשמית של Apify עצמה מציגה price: null ברשומה מלאה |
| מוכר/סוחר | לרוב קיים | רשימות מרובות מוכרים אומרות שלאותו מוצר יכולות להיות כמה הצעות נפרדות |
| דירוג/מספר ביקורות | מותנה | מוצרים חדשים או בלי דירוג פשוט עלולים לא לכלול אותו — אל תהפכו ל־0 |
| משלוח/אספקה | לא עקבי | יכול להיות תלוי ביעד, מלאי המוכר והסשן |
| סימון ממומן | תלוי בכלי | Oxylabs מפרידה בצורה נקייה בין pla ל־organic; כמה אחרים מאפשרים לכלול/להחריג תוצאות ממומנות בלי לתת תיוג אמין לכל שורה |
הכלל המעשי: לפני שמבצעים אוטומציה על כל תהליך, שלפו דוגמה אמיתית עם מילות המפתח שלכם ובדקו מה באמת null, משוכפל או חסר — לא מה שהתיעוד מרמז שצריך להיות שם.
Google Merchant Center רשמי לעומת סקרייפר Google Shopping: מה אתם באמת צריכים?
זו שאלה שצוותי ecommerce שואלים עוד לפני שהם מתחילים להשוות ספקים, ושווה לענות עליה בצורה ישירה: אם אתם מנהלים את רשימות המוצרים, התמחור או מודעות Shopping שלכם, זו עבודה לכלי Merchant Center הרשמיים של Google — לא לסקרייפר של צד שלישי. כלי הסקרייפינג ברשימה הזו מיועדים לצפייה ברשימות של אנשים אחרים: מחירי מתחרים, נראות שוק, מחקר קטגוריות, ניטור מקומות ממומנים. אל תערבבו בין השניים. בדקו ישירות את התיעוד הרשמי של Google כדי לראות את השם וההיקף העדכניים של ה־API הראשון-יד, כי הדברים האלה עוברים שינויים ושמות מחדש מדי פעם.
איך הכלים האלה מתמודדים עם מנגנוני ההגנה נגד בוטים של Google
אנסח את זה כשאלה של ממשל ותפעול, לא כמדריך "איך לעקוף את Google", כי זו הדרך הכנה לחשוב על זה. כמה מהספקים כאן — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — מצהירים בפומבי שהם מטפלים בעצמם ברוטציית פרוקסים, רינדור בדפדפן ו־טיפול ב־CAPTCHA. זו באמת נקודת גבול תחזוקתית ששווה להעריך: זה אומר שאתם לא אלה שמבזבזים לילה ב־2 לפנות בוקר על IP חסום. זה לא, ולא צריך להתפרש כ, הבטחה לגישה קבועה או אוניברסלית.
מה שלא נעלם גם עם ספק מנוהל לגמרי: בקרת קצב והוצאות, סיווג שגיאות, ניסיונות חוזרים, ומעקב אחר שינויים של Google (שעל פי ה־changelogs שמצאתי גם ב־SearchAPI וגם ב־Oxylabs, קורים לא מעט). Bright Data מתעדת מפורשות כישלונות חלקיים בתוך batch; DataForSEO מתעדת התנהגות של timeout ב־callback; Oxylabs מתעדת כישלונות של טוקן לא תקין. שום דבר מזה אינו הוראה לעקיפה — זו פשוט תיעוד הוגן של מי אחראי על איזה אופן כישלון.
איך לבחור את סקרייפר Google Shopping הטוב ביותר לצוות שלכם
עברו על זה לפי הסדר:
- זהו את הפרסונה שלכם. האם אתם מפתחים שבונים צינור, או איש שיווק/אופרציה שרוצה תוצאות בלי לגעת בקוד?
- הגדירו את השדות שאתם באמת צריכים. נתונים ברמת דירוג שונים מפירוט מחיר ברמת מוכר/הצעה — SearchAPI ו־Oxylabs מרוויחות את מקומן במיוחד בגלל השכבה הזו.
- היו כנים לגבי יכולת התחזוקה שלכם. מיפוי API וטיפול בשגיאות, הגדרת Actor והקמת פרוקסי, או חילוץ מבוסס דף שעבר סקירה — בחרו את מה שהצוות באמת יכול להחזיק לאורך זמן.
- בדקו התנהגות לפי locale/device עם שאילתות אמיתיות לפני שמתחייבים לספק, כי התיעוד הציבורי לא תמיד תואם בדיוק להתנהגות החיה.
- אמתו שמסלול הייצוא מתאים לסטאק הקיים שלכם — dump של JSON לתוך data warehouse הוא תהליך שונה לגמרי מגיליון שאפשר לפתוח ישירות.
מסקנה: איזה סקרייפר Google Shopping כדאי לכם להשתמש בו?
אין כאן מנצח יחיד, ואם כתבה מסוג רשימה אומרת לכם אחרת — תהיו סקפטיים. אם אתם מפתחים שבונים צינור נתונים ורוצים את הסכמה הכי עשירה בתיעוד עם שליטה מפורשת על cache ועל locale, התחילו עם SerpApi. אם המטרה האמיתית שלכם היא השוואת מחירים ברמת הצעה, לפי מוכר, SearchAPI או שרשרת הטוקנים של Oxylabs יקחו אתכם לשם בצורה ישירה יותר. אם אתם מריצים מחקר בתפזורת, מתוזמן, ויכולים לחיות עם תור משימות, DataForSEO מתאימה מאוד להתרחבות. אם אתם רוצים פלטפורמת enterprise אחת שמכסה גם datasets מוכנים וגם שאילתות חיות, Bright Data מכסה הכי הרבה שטח — רק תתמחרו כל ממשק בנפרד.
ואם אתם צוות PPC או שיווק שלא רוצה לגעת במפתח API, הקטגוריה מבוססת הדפדפן שמיוצגת על ידי Thunderbit היא התשובה הישירה ל־"אני רק צריך את הנתונים, לא פרויקט קוד". אבל קודם אמתו את ה־flow הספציפי של Google Shopping ואת מסלול הייצוא: כתובת המוצר הייעודית שסופקה לסקירה הזו החזירה 404 ב־13 באוגוסט 2026. תיעוד ה־API וה־CLI של Thunderbit נשארים ממשקים נפרדים המיועדים למפתחים; עצם קיומם לא הופך את תהליך הדפדפן ל־API ל־Shopping עם target גאוגרפי.
לא משנה מה תבחרו — שלפו קודם דוגמה אמיתית. כל ספק כאן מתעד לפחות שדה אחד שלא תמיד קיים — בדקו את שלכם לפני שאתם בונים עליו משהו.
שאלות נפוצות
האם מותר מבחינה חוקית לסקרייפ נתוני Google Shopping? זו לא שאלה שאפשר לענות עליה באופן גורף, וגם כתבת רשימה לא אמורה לעשות זאת. נתונים גלויים לציבור וטענות של ספקים על תאימות לא הופכים אוטומטית כל שימוש לחוקי. לפני שבונים משהו, בדקו את תנאי השימוש הנוכחיים של Google, את הדין הרלוונטי בתחום השיפוט שלכם, וודאו ששיטת האיסוף שלכם מורשית. התייחסו לזה כאל מצב של "לכו לאמת עם ייעוץ משפטי משלכם", לא כמשהו שבלוג יכול להכריע בו.
מה ההבדל בין SERP API לסקרייפר של Google Shopping? API של SERP או Shopping מקבל פרמטרים מובנים של בקשה ומחזיר JSON מנותח — הספק מטפל ברוב תשתית השליפה. סקרייפר מבוסס דפדפן (כמו Thunderbit) מחלץ מדף שיש לכם או למשתמש פתוח בפועל. מוצרים מסוג dataset (כמו חלק מההיצע של Bright Data) מספקים רשומות שנאספו מראש לפי לוח זמנים במקום בקשות חיות. הם חופפים במטרה, אבל שונים מאוד בטריות, בשליטה במיקום, ובכמה תחזוקה אתם באמת מנהלים.
האם צריך ידע בקוד כדי לסקרייפ Google Shopping? לא תמיד. כל הפיץ' של Thunderbit הוא workflow בלי קוד ולחיצות, בדיוק מהסיבה הזו. טכנית אפשר להריץ את Apify גם דרך ממשק האינטרנט שלו בלי לכתוב קוד, אבל כדי להוציא ממנו התאמה אישית אמיתית כדאי שיהיה לכם נוחות טכנית מסוימת. כל כלי מבוסס API ברשימה הזו — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — דורש לפחות מיומנויות בסיסיות של מפתחים: אימות, טיפול בפרמטרים, ובדיקת שגיאות.
באיזו תדירות נתוני Google Shopping משתנים? לעיתים קרובות יותר ממה שהרבה אנשים מניחים, אבל אין כלל אוניברסלי של "זה מתעדכן כל X שעות" שאפשר לסמוך עליו. מחירים, מלאי, מיקומים ממומנים ודירוגים יכולים להשתנות לפי סשן, מיקום וזמן ביום. כמה מהספקים כאן מציעים מצבי live/real-time בדיוק בגלל שנתונים שמורים ב־cache מתיישנים מהר בקטגוריה הזו. אם ההחלטות שלכם תלויות במחיר עדכני, הריצו שוב את השאילתה במקום לסמוך על תוצאה מאתמול.
למדו עוד
