דף חיפוש בודד של Google Shopping יכול להחביא מודעות ממומנות בתוך התוצאות האורגניות, להשמיט לגמרי מחירים עבור מוצרים שאזלו מהמלאי, ואפילו לשכפל את אותו מוצר אצל חמישה מוכרים שונים. בשבועות האחרונים פירקתי לגורמים תשעה כלים שטוענים שהם יודעים להפוך את הבלגן הזה לנתונים נקיים ושימושיים — והתשובה הכנה היא שה"כי טוב" תלוי לגמרי בשאלה אם אתם מפתחים שבונים צינור נתונים, או אנשי שיווק שרק רוצים את המספרים בגיליון אלקטרוני עד יום שישי.
הפער הזה מופיע בכל מקום במחקר. ב־r/learnpython וב־r/node אנשים מחליפים הערות על Puppeteer, Playwright ו־proxy rotation. ב־r/PPC, לעומת זאת, אנשים מבקשים משהו קרוב יותר ל"תנו לי פשוט את הנתונים, לא רוצה לגעת בקוד". לכן במקום לדרג את תשעת הכלים לפי אלפבית או להדביק תגית "הטוב ביותר" על כל ספק עם דף הבית הכי נוצץ, דירגתי כל אחד מהם לפי שישה קריטריונים מוחשיים וסידרתי אותם לפי תהליך העבודה — קודם APIs מנוהלים ל־SERP, אחר כך תשתיות של proxies ו־scrapers, אחר כך פלטפורמת actors למפתחים, ולבסוף כלי דפדפן ללא קוד.
מה הופך "Google Shopping Scraper" ל"הטוב ביותר"? קריטריוני הדירוג שלנו
המילה "הטוב ביותר" עושה עבודה כבדה מאוד ברוב רשימות ההשוואה, אז הנה מה שהיא באמת אומרת כאן. דירגתי את כל תשעת הכלים לפי אותם שישה גורמים במקום לחזור על מה שכל דף שיווק של ספק טוען:
- כיסוי נתונים — האם הסכמה המתועדת מחזירה באופן אמין מחיר, מוכר, דירוג, מספר ביקורות, משלוח, והבחנה אמיתית בין תוצאות ממומנות ואורגניות?
- תמיכה בלוקאל/גיאוגרפיה — האם אפשר באמת לכוון למדינה, שפה או מכשיר מסוימים, או שהכול תלוי במקרה ב־IP של ה־proxy?
- מורכבות ההגדרה — האם מדובר במפתח API וב־GET request, או במשימה בתור עם callbacks, או בתהליך דו־שלבי עם token, או פשוט בדף שלוחצים עליו?
- עומס תחזוקה — מי אחראי כש־Google משנה את מבנה ה־HTML או זורק CAPTCHA: אתם או הספק?
- נתיב ייצוא/אינטגרציה — ייצוא JSON, או חיבור ישיר ל־Sheets, ל־Airtable, או למחסן הנתונים שלכם?
- שקיפות תמחור — האם הספק מפרסם עלות אמיתית ליחידה שאפשר לחשב ממנה, או שצריך "לפנות למכירות" כדי לדעת כמה זה עולה בכלל?
דבר אחד שלא אעשה כאן הוא להמציא שיעורי הצלחה, מדדי מהירות או אחוזי דיוק. אף אחד ברשימה הזו לא ביצע בנצ'מרק עצמאי מול אחרים, וטענות ספקים על "99.9% הצלחה" או "מהיר בטירוף" הן טקסט שיווקי, לא מדידה. במקום זה תקבלו את מה שהמסמכים של כל ספק באמת מוכיחים — ובפועל, זה מספיק לעבודה.
מפתחים רוצים קוד, משווקים רוצים אפס קוד
אם ביליתם זמן כלשהו בפורומים שקשורים ל־scraping, אתם כבר יודעים שהפער הזה קיים, אבל שווה לומר אותו במפורש כי הוא מסביר את סדר הרשימה. מפתחים שבונים צינור נתונים רוצים מפתח API, JSON צפוי, פרמטרים ברורים ללוקאל, וסכמה שאפשר לאמת ולנרמל בהמשך. הם אלה ששואלים על proxy rotation ועל headless browser rendering.
אנשי שיווק ו־PPC רוצים משהו קרוב יותר ל"כוון לדף, קבל את הגיליון." הם לא רוצים לתחזק סקריפט של Puppeteer כש־Google משנה את פריסת הקניות שלה בפעם השלישית ברבעון הזה (וזה יקרה — Google משנה markup של Shopping לעיתים קרובות מספיק כדי שאפילו ספקי ה־API מפרסמים על זה changelog).
לכן הרשימה הזו נעה מספקי SERP API מנוהלים (SerpApi, Serper, SearchAPI, DataForSEO) — JSON מובנה, בלי עבודה על proxies, אבל עדיין דורש קוד — דרך תשתיות proxy ו־scraper (Bright Data, Oxylabs) שנותנות יותר שליטה במחיר של יותר הגדרה, אל פלטפורמת actors גמישה לחלוטין למפתחים (Apify), ומסתיימת ב־Thunderbit, כלי דפדפן agentic ללא קוד לאנשים שבאמת לא רוצים לכתוב או לתחזק קוד scraping.
9 ה־Google Shopping Scrapers הטובים ביותר במבט אחד
| כלי | מודל איסוף | מורכבות הגדרה | תמיכה בלוקאל | מי הכי מתאים | עומס תחזוקה |
|---|---|---|---|---|---|
| SerpApi | Shopping API מנוהל | נמוכה (מפתח API) | חזקה (location, gl, hl, device) | מהנדסי נתונים, כלי SEO | מנוהל על ידי הספק |
| Serper | SERP API כללי, Shopping כסוג תוצאה אחד | נמוכה | בינונית (מדינה/שפה מתועדות) | מפתחים רגישים לעלות | מנוהל על ידי הספק |
| SearchAPI | Shopping + Product Offers API מנוהל | נמוכה–בינונית (דו־שלבי ל־offers) | בינונית | צוותי השוואת הצעות/סוחרים | מנוהל על ידי הספק |
| DataForSEO | Merchant API מבוסס משימות | בינונית (תור/callback) | חזקה | צינורות bulk/מתוזמנים | מנוהל על ידי הספק |
| Bright Data | Dataset + Scraper API + SERP API | בינונית (תלוי בממשק) | חזקה מאוד | צוותי נתונים ארגוניים | משותף |
| Oxylabs | חיפוש דו־שלבי + API לפרטי מוצר | בינונית (שרשור token) | חזקה מאוד | צוותי נתונים ארגוניים | משותף |
| Scrapingdog | Endpoint ייעודי ל־Shopping | נמוכה–בינונית | בינונית | מפתחים עם תקציב מוגבל | מנוהל על ידי הספק |
| Apify | פלטפורמת actor/מפתחים | בינונית–גבוהה | תלוי ב־actor | בוני צינורות מותאמים | מנוהל על ידי המשתמש |
| Thunderbit | חילוץ דפדפן ללא קוד, מבוסס agent | נמוכה מאוד (One Click Extract) | תלוי בדף היעד | משווקים/PPC, לא־מתכנתים | נמוך, תלוי בדף |
(כדאי לאמת מחירים עדכניים, מגבלות קרדיטים וכיסוי לוקאל במסמכים החיים של כל ספק לפני שמתחייבים — הדברים האלה משתנים מהר, ולכמה מהספקים האלה כבר היו שינויים ששברו תאימות ב־2026.)
1. SerpApi — מנוהל, עשיר בפיצ'רים, ומודע במפורש ל־cache
SerpApi מפעיל מנוע ייעודי ל־Google Shopping (engine=google_shopping) שלוקח את השאילתה שלכם ומחזיר shopping_results מובנים — מיקום, כותרת, מזהה מוצר, מחיר וגם מחיר מספרי מחולץ, מחיר ישן/בתשלומים, משלוח, מצב המוצר, דירוג, ביקורות ותמונות. זו סכמה חזקה מאוד, ו־SerpApi מתעדת בנפרד גם תוצאות Shopping ממומנות דרך סכמת Google Ads Shopping, כך שאפשר לזהות מיקומים ממומנים — פשוט לא כ־sponsored: true/false יחיד ואמין שמוטמע בתשובת Shopping הייעודית.
מה שמייחד את SerpApi הוא עד כמה היא שקופה לגבי הדברים שבדרך כלל נושכים אותך מאוחר יותר. כיוון מיקום תומך ב־location קנוני ברמת עיר או ב־uule מדויק, בנוסף ל־gl (מדינה), hl (שפה) ו־device (desktop, tablet, mobile). והיא גם אומרת במפורש ששאילתות זהות יכולות להיענות מקאש עד שעה כברירת מחדל — פניות מהקאש הן חינמיות, ו־no_cache=true כופה שליפה חדשה. זו רמת גילוי שרוב הספקים קוברים או מדלגים עליה.
התמחור (נבדק ב־2026-08-13) ציבורי וחודשי: תכנית Free עם 250 חיפושים, Starter ב־$25 עבור 1,000, ועד Big Data ב־$275 עבור 30,000. רק חיפושים מוצלחים נספרים נגד המנוי — בקשות מהקאש ובקשות שנכשלו לא נספרות. שווה לדעת: Google הגישה בתחילת 2026 תביעה נגד SerpApi על שיטות הגישה לנתונים; SerpApi חולקת על ההגדרה ואומרת שהיא ניגשת לתוצאות ציבוריות ללא אימות. זו סיטואציה משפטית חיה, לא פסק דין, אז כדאי להתייחס לזה כגורם סיכון למעקב ולא כסיבה להימנע מהכלי.
הכי מתאים ל: מפתחים שרוצים את סכמה ה־Shopping העשירה ביותר המתועדת, ויותר שליטה מפורשת על cache ועל לוקאל.
2. Serper — מהיר, ידידותי לתקציב, ובעל טענת freshness הכי נקייה
Serper מציבה את עצמה כ־Google SERP API כללי, שבו Shopping יושב לצד Search, Images, News, Maps ועוד חצי תריסר סוגי תוצאות. אם כבר אתם מושכים תוצאות חיפוש רגילות ופשוט צריכים להוסיף נתוני Shopping, זה תוספת פחות חיכוכית מאשר להרים ספק ייעודי נוסף.
הדוגמה הציבורית ל־Shopping מחזירה title, source, קישור ישיר למוכר, מחיר בפורמט, משלוח, דירוג, מספר דירוגים, מספר הצעות, product ID ומיקום — סביר מאוד לניטור בסיסי של כרטיסי מוצר, למרות שהמסמכים הציבוריים לא חושפים את אותה רמת פירוט של הצעות מוכר או שדות של תמחור קידומי ש־SearchAPI או Oxylabs מתעדים. נקודת המכירה הכי נקייה של Serper היא הבטחת freshness שלה: היא אומרת שכל קריאה שואלת את Google בלייב ושום דבר לא נשמר בקאש, מה שמוריד את החלטת ניהול הקאש שמשתמשי SerpApi צריכים לקבל (אבל במחיר של תשלום על כל שאילתה חוזרת, בין אם הייתה בקאש ובין אם לא).
התמחור מבוסס על חבילות קרדיטים משולמות מראש ולא על מנויים — 2,500 שאילתות חינם להתחלה, ואז $50 עבור 50,000 קרדיטים, עם ירידה עד ל־$0.30 ל־1,000 ברמה הגבוהה ביותר, וקרדיטים תקפים לשישה חודשים. דף התמחור גם חושף משהו ישיר בצורה נעימה: בקשות בודדות יכולות לקחת 2–4 שניות "כאשר יש צורך לנסות שוב מול Google," וזה זנב latency אמיתי שכדאי לתכנן סביבו, לא מדד שצריך להילחץ ממנו.
הכי מתאים ל: צוותים שכבר מחברים SERP API רחב יותר ורוצים ש־Shopping יהיה בונוס, לא מוצר ייעודי.
3. SearchAPI — פירוט חזק ברמת הצעה, עם טוויסט בתיעוד
SearchAPI מפעילה תהליך דו־שלבי שבאמת שימושי אם אתם צריכים השוואות מחיר ברמת מוכר. ה־Shopping endpoint מחזיר את שדות הכרטיס הרגילים יחד עם product_token — והטוקן הזה פותח Product Offers API נפרד שמחזיר מערך offers עם קישור למוכר, מחיר, מחיר משלוח, מחיר כולל, סטטוס מלאי ושיטות תשלום לכל מוכר. אם מקרי השימוש שלכם הם "תראו לי כמה בדיוק עולה המוצר הזה אצל כל מוכר", זו הדרך הכי ישירה ברשימה.
יש כאן מלכודת אמיתית שכדאי לסמן: נכון ל־15 במאי 2026, שינויים של Google חייבו את SearchAPI לדרוש product_token חדש לכל בקשה — הפרמטרים הישנים product_id/prds מחזירים עכשיו שגיאת 400 פשוטה. אם אתם משתלבים על בסיס קוד לדוגמה או מדריכים ישנים, זה ישבר בשקט עד שתשימו לב.
SearchAPI גם מזהירה במפורש שמסננים בשפה טבעית בתוך השאילתה (כמו "מתחת ל־$30" או "משומש") הם רמזים, לא פילטרים נוקשים — Google עדיין עשויה להחזיר תוצאות מחוץ להם כשההתאמות דלות. מסנני shoprs מקודדים הם המסלול המחמיר. ויש גם סתירה לא פתורה בתיעוד שחשוב להכיר: SearchAPI משווקת את ה־endpoint כ"real-time", אבל הסכם עיבוד הנתונים שלה עצמו אומר שהיא שומרת תוצאות בקאש לשם ביצועים. אין גם TTL ציבורי מתועד כך או כך, אז אם מחירים שנעים מהר חשובים לכם, בדקו עם שאילתות חוזרות לפני שבונים צינור סביב הנחת freshness.
התמחור (נבדק ב־2026-08-13) מתחיל ב־$40 לחודש ב־Developer tier עם $4 ל־1,000 חיפושים, ויורד ברמות נפח גבוהות יותר, עם תקרת שימוש מתועדת של 20% מהקרדיטים החודשיים לשעה.
הכי מתאים ל: צוותים שעושים השוואת מוכרים/הצעות ברמת offer ויכולים לסבול workflow של שתי בקשות ולבדוק freshness בעצמם.
4. DataForSEO — נתוני Merchant ו־Shopping בקנה מידה גדול, דרך תור
DataForSEO היא באמת החריגה בקבוצה הזו כי זו לא API של request/response בזמן אמת — אלא תור מבוסס משימות. שולחים POST עם מילת המפתח, המיקום והשפה, מקבלים task ID, ואז או שמבצעים polling לתוצאות או מגדירים callback URL. מדובר בשליפה סטנדרטית בלבד; אין מצב live עבור נקודות הקצה המרכזיות של Shopping, לא משנה מה השיווק הכללי רומז.
זה חשוב כי זה משנה את חישוב מורכבות ההגדרה. זה לא קשה, בדיוק, אבל זה מודל חשיבה אחר מ־"קוראים ל־API, מקבלים JSON" — אתם מנהלים מצב של משימות, והמסמכים של DataForSEO עצמם אומרים ששרת callback שלא מגיב תוך 10 שניות מעביר את המשימה לתור "Tasks Ready" ואז צריך לבצע polling ידני.
היא מרוויחה את מקומה ברשימה בעיקר במחקר בקנה מידה גדול: ה־Products endpoint מחזיר rank, domain, title, price, old price, rating ו־vote count, עם מזהי סוג תוצאה ברורים שמבחינים בין 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 חיות ומנתח את התוצאות בזמן אמת. להתייחס אל אלה כמוצר אחד זה בדיוק המקום שבו הרבה מאמרי השוואה מחפפים — אני לא הולך לעשות את זה כאן.
נתוני הדוגמה של ה־dataset עצמו מראים ערכי null עבור product ID, description, rating ו־reviews count בחלק מהרשומות — הוכחה ישירה טובה לכך ש"dataset מובנה" לא אומר "כל שדה תמיד מלא". ה־SERP API מתעד בנפרד Product Listing Ads כסוגי תוצאה משלהם (top_pla, bottom_pla, jackpot_pla) עם title, price, shop ו־rank — הבחנה שימושית באמת בין ממומן לאורגני אם עובדים ספציפית עם ה־SERP API, ולא עם ה־dataset.
משימות async דרך ה־Scraper API יכולות להחזיר "success" כולל, בזמן שבקשות בודדות בתוך ה־batch נכשלות — המסמכים אומרים במפורש לבדוק שדה errors ולבצע retry לכל אחת בנפרד, וזה פרט תחזוקתי שכדאי לתכנן עבורו אם אתם מריצים 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 (מודעות מוצרים בתשלום) לבין מוצרים organic — כנראה ההפרדה המתועדת הכי ברורה בין ממומן לאורגני בכל הרשימה הזו — בעוד ש־endpoint של המוצר מוסיף הצעות לכל מוכר עם מחיר מספרי, מצב מוצר, מס, מחיר כולל ומשלוח.
המלכוד, והוא אמיתי: תהליך ה־token הזה עובד רק אם בבקשת החיפוש משתמשים גם ב־render: "html" וגם ב־parse: true. תפספסו אחד מהם, לא תקבלו product token, וכל שלב פירוט המוצר קורס. Oxylabs גם מזהירה במפורש שבקשות חיפוש ומוצר חייבות להשתמש בערכי לוקאל זהים לחלוטין — אם geo_location לא תואם בין שתי הקריאות, תוצאות המוצר עלולות לחזור חלקיות או שגויות. ואם אתם רוצים שהפאנל "More stores" יורחב להצעות מוכרים נוספות, צריך גם rendering פעיל, מה שמוסיף עלות.
פרט שקל לפספס: ה־FAQ של התמחור של Oxylabs מגדיר בקשות "successful" (ולכן חיוביות) ככוללות גם תשובות 2xx וגם 4xx. אם הבקשה שלכם עצמה שגויה, עדיין ייתכן שתחויבו עליה.
ביקורות מוצר מתועדות רק עבור לוקאל של ארצות הברית, ו־locale/language ו־locale/results-language הם באמת פקדים נפרדים — הגדרה של אחד לא מגדירה אוטומטית את השני.
הכי מתאים ל: צוותים טכניים שצריכים גם נתוני דירוג וגם פרטי הצעה לכל מוכר, ויכולים להתמודד עם שרשור token ועקביות לוקאל כחלק מההגדרה.
7. Scrapingdog — Endpoint פשוט, מעט פירוט ציבורי
Scrapingdog מציעה endpoint ייעודי אחד ל־Google Shopping שמקבל מפתח API ושאילתה, ומחזיר JSON עם title, price וגם price מספרי מחולץ, old price, rating, reviews, source/seller, delivery ומיקום. העמוד גם מציין סינון לפי מחיר, מותג, מדינה ושפה, וגם קטגוריית תגובה נפרדת של "ads" למעקב אחרי רשימות ממומנות — אבל סכמת ה־ads המדויקת ושמות הפרמטרים המדויקים לסינון לוקאל לא מתועדים במלואם בעמוד הציבורי, לכן כדאי להקדיש זמן לבדיקה מול המקרה שלכם לפני שבונים אוטומציה סביבו.
זהו הערך ברשימה הזו שבו מתמטיקת עלות הקרדיטים פשוט לא מסתדרת על סמך התיעוד הציבורי בלבד: דף התמחור של Scrapingdog מציג הקצאות קרדיטים חודשיות (LITE ב־$40 לחודש עבור 200,000 קרדיטים, STANDARD ב־$90 לחודש עבור 1,000,000) אבל לא מציין בבירור כמה קרדיטים כל בקשת Google Shopping צורכת. אל תניחו שזה 1:1 עם דוגמאות ה־search API הכלליות שלהם — בדקו ישירות מול הספק לפני שאתם מחשבים את העלות האמיתית לכל שאילתה.
כמו רוב הספקים כאן, Scrapingdog משווקת proxies סלולריים מסתובבים מובנים וטיפול אוטומטי ב־CAPTCHA כמנוהל על ידי הספק. קחו את זה כהצהרה על גבול האחריות בתחזוקה, לא כהוכחה לגישה מובטחת.
הכי מתאים ל: מפתחים עם תקציב מוגבל שרוצים endpoint צר וייעודי, ומוכנים לאמת את עלויות הקרדיטים ישירות לפני שמתחייבים.
8. Apify — תשפטו את ה־Actor, לא את המרקטפלייס
אני צריך להיות כן לגבי משהו: Apify היא לא Google Shopping scraper אחת — זו מרקטפלייס של "Actors" שמתוחזקים באופן עצמאי, וה־Actor שבדקתי מקרוב (Google Shopping Insights, שפורסם על ידי המפתח epctex ומסומן "Maintained by Community") מתנהג אחרת לגמרי מכלי הספק המנוהלים למעלה. Apify מספקת את סביבת הריצה, תשתית ה־proxy וכלי ה־dataset/ייצוא. לוגיקת החילוץ עצמה ל־Shopping — וגם התחזוקה שלה — שייכות ל־epctex, לא ל־Apify עצמה.
ההבחנה הזו חשובה כי בדוגמת הפלט הרשמית של ה־Actor הזה יש שדה price ריק (null). לא לפעמים, לא רק למוצרים שאזלו מהמלאי — הרשומה המדוגמת עצמה מציגה price: null ו־withoutDiscountPrice: null לצד שדות מלאים של שם מוצר, מוכר ודירוג. זו באמת ההוכחה הראשונה הכי טובה בכל הסקירה הזו לכך שאי אפשר להניח שנתוני מחיר תמיד מלאים, והיא מגיעה ישירות מהתיעוד של הכלי.
מקבלים קלטים ניתנים להגדרה — includeSponsoredResults, includeComparisonPrices להשוואת מחירים בין מוכרים, קוד מדינה, maxItemsPerQuery — וגם הגדרת proxy נדרשת (שלכם או של Apify). התוצאות יוצאות כ־JSON, XML, CSV או Excel דרך מערכת ה־Dataset של Apify. ברשימת ה־Store שבדקתי הופיעו בערך 2,300 משתמשים בסך הכול אבל רק 2 משתמשים פעילים חודשיים באותו זמן — מדד ששווה לשים לב אליו, כי "מתוחזק על ידי הקהילה" עובד לשני הכיוונים: גמיש, אבל אמין רק כמו מי שבאמת משתמש בו ומדווח על תקלות.
הכי מתאים ל: מפתחים שנוח להם להעריך את פעילות התחזוקה של Actor ספציפי ולבדוק את סכמת הפלט האמיתית שלו לפני התחייבות — לא למי שמצפה שהמותג Apify יבטיח התנהגות עקבית.
9. Thunderbit — איסוף ללא קוד עבור משווקים
Thunderbit מייצגת את הקצה השני של הרשימה הזו: workflow מבוסס דפדפן וללא קוד, לאנשים שרוצים לעבור על הדף שהם רואים ולהפוך אותו לטבלה מובנית, במקום לשלב Google Shopping API. לכן היא מתאימה באופן טבעי למשווקים, אנשי PPC וצוותי ecommerce קטנים שמבצעים בדיקות אד־הוק ולא צינור backend בנפח גבוה.
מה שמקבלים הוא חילוץ בצד הדפדפן: פותחים את דף תוצאות ה־Shopping שמעניין אתכם, נותנים ל־Thunderbit לקרוא את הדף המעובד בלחיצה אחת, ומייצאים את השדות ישירות ל־Excel, Google Sheets, Airtable או Notion. יש כאן הסתייגות אמיתית, אבל היא שייכת ל־Shopping ולא לכלי מסוים — כי החילוץ רץ מול הדף שמולכם, התוצאה יורשת את המיקום, השפה וה־session של הדפדפן הזה. קבעו את ההגדרות האלה לפני שאתם מתייחסים למשיכה של השבוע הזה כמשהו שניתן להשוות למשיכה של שבוע שעבר. זו אותה בעיית אמינות שדות שהסעיף הבא מכסה, והיא חלה על כל אפשרות ברשימה.
הכי מתאים ל: צוותים לא־טכניים שמעריכים חילוץ דפדפן גלוי ונבדק על פני צינור JSON שמנוהל על ידי מפתחים — ושמושכים דפי Shopping מסוימים לפי צורך במקום להריץ crawl בנפח גבוה ובכמה גיאוגרפיות.
איזה נתונים אפשר באמת לסמוך עליהם? בעיית אמינות השדות
זה החלק שרוב מאמרי ההשוואה ל־Google Shopping מדלגים עליו לגמרי, וזה הדבר החשוב ביותר להבין לפני שמבצעים אוטומציה למשהו: לא כל שדה מופיע בכל רשומה, והתייחסות ל"חסר" כאל "אפס" תשחית את הנתונים שלכם בשקט.
| שדה | רמת אמינות | המלכוד |
|---|---|---|
| כותרת | גבוהה | לנרמל וריאציות/חבילות לפני התאמת מוצרים בין מקורות |
| product ID | מותנה | DataForSEO מתעדת זאת במפורש כדינמי ולעיתים null |
| מחיר | מותנה | בדוגמה הרשמית של Apify עצמו מופיע null למחיר ברשומה מלאה |
| מוכר/merchant | בדרך כלל קיים | רשימות מרובי מוכרים אומרות שלמוצר אחד יכולות להיות כמה הצעות נפרדות |
| דירוג/מספר ביקורות | מותנה | מוצרים חדשים או בלי דירוג פשוט עלולים לא לכלול אותו — אל תכפו אפס |
| משלוח/Delivery | לא עקבי | יכול להיות תלוי ביעד, במלאי המוכר וב־session |
| דגל ממומן | תלוי בכלי | Oxylabs מפרידה בצורה נקייה בין pla ל־organic; כמה אחרים מאפשרים לכלול/להחריג תוצאות ממומנות בלי לספק תווית אמינה לשורה עצמה |
הכלל המעשי: לפני שמבצעים אוטומציה לכל workflow, תמשכו דגימה אמיתית עם מילות המפתח האמיתיות שלכם ותבדקו מה באמת null, משוכפל או חסר — לא מה שהתיעוד רומז שאמור להיות שם.
Google Merchant Center הרשמי מול Google Shopping Scraper: מה באמת צריך?
זו שאלה שצוותי ecommerce שואלים עוד לפני שהם מתחילים להשוות ספקים, ושווה לתת עליה תשובה ישירה: אם אתם מנהלים את רשימות המוצרים, התמחור או מודעות ה־Shopping שלכם, זו עבודה עבור הכלים הרשמיים של Google Merchant Center — לא עבור scraper של צד שלישי. כלי scraping ברשימה הזו מיועדים לצפייה ברשימות של אחרים: תמחור מתחרים, נראות שוק, מחקר קטגוריות, וניטור מיקומים ממומנים. אל תבלבלו ביניהם. בדקו ישירות את התיעוד הרשמי העדכני של Google כדי להבין את השם והתחום הנוכחיים של ה־API הראשון שלה, כי הדברים האלה עוברים שינויי שם ומבנה מעת לעת.
איך הכלים האלה מתמודדים עם ההגנות של Google נגד בוטים
אני אנסח את זה כשאלה של ניהול ובקרה, לא כמדריך ל"איך לעקוף את Google", כי זו הדרך הכנה לחשוב על זה. כמה מהספקים כאן — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — מצהירים בפומבי שהם מטפלים אצלם ב־proxy rotation, browser rendering ו־CAPTCHA handling. זו נקודת אחריות חשובה באמת: זה אומר שאתם לא אלה שמדבגים IP חסום ב־2 בלילה. זה לא, ולא צריך להתפרש כ, הבטחה לגישה קבועה או אוניברסלית.
מה שלא נעלם גם עם ספק מנוהל לחלוטין: בקרות קצב והוצאה, סיווג שגיאות, retries, ומעקב אחרי מצבים שבהם Google משנה משהו (מה שלפי ה־changelogs שמצאתי גם ב־SearchAPI וגם ב־Oxylabs קורה די בקביעות). Bright Data מתעדת במפורש כשלים חלקיים ב־batch; DataForSEO מתעדת התנהגות של timeout ל־callback; Oxylabs מתעדת כשלי token לא חוקי. שום דבר מזה אינו הוראות לעקיפה — זו פשוט תמונת אחריות אמיתית לגבי מי מחזיק באיזה מצב כשל.
איך לבחור את Google Shopping Scraper הטוב ביותר לצוות שלכם
עברו על זה לפי הסדר:
- זהו את הפרסונה שלכם. אתם מפתחים שבונה צינור, או איש שיווק/אופרציה שרוצה תוצאות בלי לגעת בקוד?
- הגדירו את השדות שבאמת דרושים לכם. נתוני רמת דירוג שונים מפרטי מחיר ברמת merchant/offer — ו־SearchAPI ו־Oxylabs מרוויחות את המקום שלהן בדיוק עבור הסעיף האחרון.
- היו כנים לגבי כושר התחזוקה שלכם. מיפוי API וטיפול בשגיאות, הגדרת Actor והגדרת proxy, או חילוץ מבוסס דף שעובר בדיקה — בחרו את מה שהצוות שלכם יכול להחזיק לאורך זמן.
- בדקו התנהגות לוקאל/מכשיר עם שאילתות אמיתיות לפני התחייבות לספק, כי התיעוד הציבורי לא תמיד תואם בול להתנהגות בפועל.
- וודאו שנתיב הייצוא מתאים לסטאק הקיים שלכם — ייצוא JSON למחסן נתונים הוא מאמץ אחר לגמרי מגיליון אלקטרוני שמשווק יכול לפתוח ישירות.
סיכום: איזה Google Shopping Scraper כדאי לכם להשתמש בו?
אין כאן "הכי טוב" אחד, ואם רשימת השוואה אומרת אחרת, כדאי להיות סקפטיים. אם אתם מפתחים צינור נתונים ורוצים את הסכמה המתועדת העשירה ביותר עם שליטה מפורשת על cache ולוקאל, התחילו עם SerpApi. אם השוואת מחירים ברמת offer, לכל מוכר, היא המטרה האמיתית שלכם, אז SearchAPI או ה־workflow של Oxylabs עם שרשור token יובילו אתכם לשם באופן ישיר יותר. אם אתם מריצים מחקר מתוזמן ובכמות גדולה ויכולים לסבול תור משימות, DataForSEO מתאימה היטב. אם אתם רוצים פלטפורמת enterprise אחת שמכסה גם datasets מוכנים וגם שאילתות חיות, Bright Data נותנת את הכיסוי הרחב ביותר — רק תתמחרו כל ממשק בנפרד.
ואם אתם בצוות PPC או שיווק שלא רוצה לגעת במפתח API, הקטגוריה מבוססת הדפדפן שמיוצגת על ידי Thunderbit היא התשובה הישירה ל"אני רק צריך את הנתונים, לא פרויקט קוד". רק תדעו בדיוק באיזה ממשק אתם בוחרים: workflow בדפדפן בנוי לדפים שאתם פותחים ובודקים בעצמכם, בעוד ש־תיעוד ה־API של Thunderbit ו־CLI הם מסלולים נפרדים שמיועדים למפתחים. בחרו את מה שמתאים לאופן שבו הצוות שלכם באמת עובד.
לא משנה מה תבחרו, משכו קודם דגימה אמיתית. כל ספק כאן מתעד לפחות שדה אחד שלא תמיד קיים — בדקו את שלכם לפני שאתם בונים עליו משהו.
שאלות נפוצות
האם חוקי לבצע scraping לנתוני Google Shopping?
זו לא שאלה שאפשר לענות עליה באופן מוחלט, וגם לא כל רשימת השוואה צריכה לנסות. נתונים גלויים לציבור וטענות התאמה של ספק לא הופכים אוטומטית כל שימוש לחוקי. לפני שבונים משהו, בדקו את תנאי השימוש העדכניים של Google, עברו על החוק החל בתחום השיפוט שלכם, וודאו ששיטת האיסוף שלכם מותרת. תתייחסו לזה כמצב של "ללכת לבדוק מול היועץ המשפטי שלכם", לא כמשהו שבלוג יכול להכריע.
מה ההבדל בין SERP API לבין Google Shopping scraper?
SERP או Shopping API מקבל פרמטרים מובנים של בקשה ומחזיר JSON מנותח — הספק מטפל ברוב תשתית האיסוף. scraper מבוסס דפדפן (כמו Thunderbit) מחלץ מתוך דף שאתם או משתמש אמיתית פתחתם. מוצרים מבוססי Dataset (כמו חלק מההצעה של Bright Data) מספקים רשומות שנאספו מראש לפי לוח זמנים במקום בקשות חיות. הם חופפים במטרה, אבל שונים מאוד ב־freshness, בשליטה בלוקאל, ובכמה אתם באמת צריכים לתחזק.
האם צריך כישורי תכנות כדי לבצע scraping ל־Google Shopping?
לא תמיד. כל המיקוד של Thunderbit הוא זרימה ללא קוד ובקליק, בדיוק בגלל זה. אפשר טכנית להריץ Apify דרך ממשק הווב שלה בלי לכתוב קוד, אבל קסטומיזציה אמיתית כבר דורשת קצת נוחות טכנית. כל כלי מבוסס API ברשימה הזו — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — דורש לפחות מיומנויות מפתחים בסיסיות: אימות, טיפול בפרמטרים ובדיקת שגיאות.
באיזו תדירות נתוני Google Shopping משתנים?
לעיתים קרובות יותר ממה שהרבה אנשים מניחים, אבל אין כלל אוניברסלי של "זה מתעדכן כל X שעות" שאפשר להסתמך עליו. מחירים, מלאי, מיקומים ממומנים ודירוגים יכולים להשתנות לפי session, לוקאל ושעת היום. כמה מהספקים כאן מציעים מצבי live/real-time בדיוק כי נתונים שמורים בקאש מתיישנים מהר בקטגוריה הזו. אם ההחלטות שלכם תלויות במחיר עדכני, תריצו את השאילתה מחדש במקום לסמוך על תוצאה מאתמול.
למידע נוסף
