Content API for Shopping של Google הגיע לסוף דרכו ב-18 באוגוסט 2026. Google לא מעבירה חיבורים קיימים בעצמה: מי שבנה או רכש חיבור לממשק הישן צריך להעביר אותו ל-Merchant API, הממשק החדש לעבודה תכנותית מול Merchant Center.

לפי התיעוד של Google, ההשבתה הדרגתית, ומספטמבר חיבורים ישנים עלולים להתחיל לקבל שגיאות HTTP 410 Gone, בהתאם למצב ההארכה של כל חשבון.

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

מי בכלל מושפע?

לא כל חנות משתמשת ישירות ב-Content API. יש כמה דרכים להעביר מוצרים ל-Merchant Center:

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

מה קרה באוגוסט 2026?

Google קבעה את סוף החיים (sunset) של Content API for Shopping ל-18 באוגוסט 2026. המסלול היחיד להמשך הוא Merchant API.

לפי התיעוד, ההשבתה כוללת גם כשלים הדרגתיים בחיבורים ישנים. לכן חיבור שעבד עד עכשיו אינו הוכחה שהוא עדיין בטוח.

סימנים שצריך לבדוק

מוצרים חדשים שלא נכנסים ל-Merchant Center

מחירים ישנים

מלאי שגוי

זמינות שלא משתנה

שגיאות 410 בלוגים של השרת

משימות מתוזמנות שנכשלות

רכיב חיבור שמפנה ל-shoppingcontent.googleapis.com

פער בין נתוני החנות לבין Merchant Center

אם אחד הסימנים מופיע, מבררים מאיפה הנתונים מגיעים ומי מעביר אותם.

קודם כל: מהו מקור האמת?

בוחרים עשרה מוצרים ורושמים לכל אחד את המק"ט (SKU), המחיר, המלאי, הזמינות, הכתובת, הכותרת, המותג וה-GTIN אם קיים.

משווים את הנתונים בין מערכת החנות, הפיד ו-Merchant Center. כך מזהים מהר איפה נוצר הפער.

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

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

לא משנים דבר בסביבת הייצור לפני שיודעים מי משתמש בחיבור.

מהו Merchant API?

Merchant API הוא הממשק ש-Google מייעדת לעבודה תכנותית מול Merchant Center. המודל שלו אינו העתק של Content API, ולכן מעבר אמיתי אינו רק החלפת כתובת.

Google ממליצה למפות כל פעולה ישנה לממשק המשנה (sub-API) המתאים במבנה החדש.

עוברים בשלבים

במערכת גדולה לא מעבירים הכול ביום אחד. ממפים את החלקים שהחיבור משתמש בהם: Accounts, Products, Data Sources, Reports וכל שאר החלקים הרלוונטיים.

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

בדיקת מוצר מלאה

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

מוודאים שהשינויים מגיעים ל-Merchant Center בזמן הצפוי. לא מספיק לראות שהממשק מחזיר תשובת הצלחה; בודקים את התוצאה במערכת היעד.

Shopify, WooCommerce ופלטפורמות אחרות

לא כל חנות על Shopify או WooCommerce מושפעת. כשתוסף או פלטפורמה מנהלים את החיבור, האחריות הטכנית אצל הספק, אבל בעל החנות עדיין צריך לוודא שהמערכת מעודכנת. שאלו את הספק:

  • האם עברתם ל-Merchant API, ומתי?
  • באיזו גרסה?
  • איך אתם מזהים כשלים בעדכון מוצרים?
  • מה קורה כשמוצר לא מתעדכן?
  • מי אחראי לטיפול בתקלה?

תשובה ברורה שווה הרבה יותר מ"הכול אמור לעבוד".

למה זה קשור ל-SEO?

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

לא צריך לטעון שכל שגיאת ממשק תגרום לירידה בדירוג. הבעיה היא אמינות הנתונים שהלקוחות רואים.

בודקים גם אחרי המעבר

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

בתקופה הראשונה כדאי לבצע בדיקה שבועית. כך תופסים בעיות לפני שהן הופכות לפגיעה במכירות.