התשובה הקצרה
כאשר Merchant Center מדווח שמחיר או זמינות אינם תואמים, לא מתחילים בעריכה ידנית של הפריט ב־Google. מזהים קודם את יחידת המכירה המדויקת ואת הזמן שבו Google בדקה אותה, ואז משווים חמישה מצבים: נתון המקור בקטלוג, הווריאנט שנפתח ב־URL, המחיר והזמינות הגלויים בעמוד, נתוני Product/Offer, והערכים בפיד או ב־Merchant API. התיקון הנכון גורם לכולם להיגזר מאותו מקור ולהתעדכן באותו מחזור.
עדכוני פריטים אוטומטיים יכולים לצמצם דחיות כשהפיד התיישן, אבל הם שכבת הגנה ולא מנגנון הסנכרון הראשי. אם Google מתקנת שוב ושוב את אותו מוצר, יש בעיית מקור, מיפוי, תזמון או רינדור שצריך לפתור.
הודעה כמו “Mismatched price” נראית כתקלה בשדה אחד. בפועל היא מתארת מחלוקת בין שתי תמונות מצב לפחות: מה שהחנות שלחה ל־Google ומה שהסורק מצא בכתובת המוצר. כשהעמוד כולל וריאנטים, מבצע, מטבע מקומי, מחיר חבר מועדון או מלאי לפי אזור, מספר התמונות גדל. שינוי מהיר בפיד עשוי להעלים את ההתראה היום ולהחזיר אותה אחרי העדכון הבא.
היחידה שצריכה להתאים היא ההצעה, לא שם המוצר
Merchant Center בודק הצעה שאפשר לקנות: מוצר או וריאנט, בשוק ובמטבע מסוימים, בזמן מסוים. חולצה שחורה במידה M אינה בהכרח אותה הצעה כמו אותה חולצה במידה L. אם לכל מידה מלאי אחר ולכל צבע URL או פרמטר אחר, הבדיקה צריכה להישאר ברמת הווריאנט שנשלח בפיד.
לכל הצעה כדאי לנסח חוזה קטן: מזהה הפריט בפיד, URL, וריאנט ברירת המחדל, מחיר רגיל, מחיר מבצע אם פעיל, מטבע, זמינות ומועד העדכון האחרון. זהו המודל התפעולי שלי, לא שדה חדש ש־Google דורשת. מטרתו היא למנוע השוואה בין פריט אחד בפיד לבין מצב אחר בעמוד.
| שכבה | מה בודקים | כשל אופייני |
|---|---|---|
| קטלוג מקור | מזהה וריאנט, מחיר, מטבע ומלאי | מחיר מבצע או מלאי מעודכנים במערכת אחת בלבד |
| URL ומצב פתיחה | איזה וריאנט נבחר כשהכתובת נטענת | הפיד שולח מידה M והעמוד נפתח על מידה L |
| עמוד גלוי | המחיר הבולט, סטטוס הקנייה וכפתור הפעולה | טווח מחירים או מחיר חבר מסתירים את המחיר הרכיש |
| נתונים מובנים | price, priceCurrency ו־availability | JSON-LD נשאר עם ערך ישן או עם וריאנט אחר |
| מקור נתונים ל־Google | price, sale_price, תוקף וזמינות | ייצוא מתוזמן מפגר אחרי החנות או כלל מחליף ערך |
בתיעוד Merchant Center על אי־התאמה במחיר, Google מסבירה שהיא משווה את נתון המחיר במקור הנתונים למחיר בעמוד או בנתונים המובנים. בתיעוד על אי־התאמה בזמינות היא דורשת עקביות גם מול יכולת הרכישה וה־checkout. לכן “הפיד נראה נכון” אינו סוף הבדיקה.
לפני תיקון: שומרים את הראיה ואת רגע הבדיקה
פתחו ב־Merchant Center את Products & store → Products → Needs attention, סננו לפי הבעיה והורידו את רשימת הפריטים המושפעים. לכל שורה שמרו את מזהה הפריט, ה־URL, הערך שנשלח, הערך ש־Google דיווחה שמצאה ומועד הסריקה. אם ההתראה מגיעה מאירוע שכבר חלף, בדקו את מצב הפריט הנוכחי בלי למחוק את התיעוד. פער שנעלם מעצמו עדיין יכול להעיד על חלון זמן שבו העדכונים אינם מסונכרנים.
בחרו מדגם שמייצג דפוסים, לא רק את המוצר הראשון: מוצר בלי וריאנטים, מוצר עם מחירים שונים בין וריאנטים, מוצר במבצע, מוצר שאזל ומוצר בשוק או מטבע נוסף. אם אותה תקלה מופיעה בכולם, המקור כנראה תבניתי. אם היא מרוכזת בווריאנט או שוק מסוים, חפשו כלל מיפוי או URL שאינו מבטא את הבחירה הנכונה.
מחיר לא תואם: שישה מצבים שנראים אותו דבר בדוח
פער תזמון. החנות שינתה מחיר, אבל הפיד נשלח לפני השינוי או רק פעם ביום. Google ממליצה לתזמן העלאה או עדכון באמצעות Merchant API סמוך לעדכון באתר. תדירות גבוהה יותר מועילה רק אם אותו מקור מזין את שני הצדדים; שני תהליכים מהירים שמחשבים מחיר אחרת עדיין יתנגשו.
וריאנט פתיחה אחר. הפיד מתאר נעל במידה 42 ב־299 ₪, אך ה־URL פותח כברירת מחדל מידה 43 ב־329 ₪. התיקון הוא לקשר למצב שאפשר לשחזר או לוודא שמחיר הווריאנט שנשלח הוא המחיר הבולט כשהעמוד נטען. המאמר על ניהול וריאנטים באיקומרס מרחיב על הזהות המשותפת בין URL, בחירה, מלאי ופיד.
מבצע שיצא מסנכרון. sale_price פעיל בפיד אחרי שהמבצע הסתיים באתר, או להפך. אם משתמשים ב־sale_price_effective_date, טווח הזמן ואזור הזמן צריכים לתאר את חלון המבצע בפועל. Google מציינת גם שהמחיר המחוק בעמוד צריך להתאים ל־price כאשר קיים sale_price.
מחיר שאינו זמין לכל אחד. קופון שניתן רק בקופה, הנחת לקוח חדש או מחיר מועדון שמופיע רק לאחר התחברות אינם בהכרח המחיר הבולט שכל מבקר יכול לקבל בעמוד. אין להפוך הנחה מותנית למחיר הבסיס בפיד כדי לשפר אטרקטיביות. מבצעים, loyalty והנחות חד־פעמיות מקבלים מסלולי נתונים שונים לפי תנאי Merchant Center.
מטבע או התאמה לפי משתמש. ה־URL מציג שקל לגולש בישראל ודולר לסורק לפי IP, בעוד מקור הנתונים מכוון לישראל. Google מזהירה מפני שינוי דינמי של מחיר או זמינות לפי IP כאשר הוא גורם לסורק לקבל מצב אחר. בשווקים שבהם נדרש מחיר אזורי, מגדירים הצעה ושוק בהתאם למסלולים הנתמכים ולא מסתמכים על זיהוי שקט של המבקר.
כמות מינימום או מחיר יחידה. אם אפשר לרכוש רק מארז של שישה, המחיר שנשלח צריך לייצג את הכמות המינימלית שנמכרת לפי הדרישות. מחיר “ליחידה” גדול ובולט לצד מחיר מארז קטן עלול לגרום גם ללקוח וגם לסורק להבין הצעה אחרת.
זמינות לא תואמת: “יש מלאי” צריך להוביל לרכישה אפשרית
in_stock אינו תיאור של מספר חיובי במערכת המחסן בלבד. ההצעה צריכה להיות ניתנת לרכישה באותו יעד: הווריאנט זמין, כפתור הקנייה עובד, וההגבלות אינן הופכות אותה לאיסוף בלבד כאשר היעד דורש משלוח. אם העמוד מציג “במלאי” אבל ה־checkout חוסם את הכתובת, המידע אינו עקבי מבחינת הקונה.
במוצר עם וריאנטים בודקים את האפשרות שנשלחה, לא את המשפחה. אם צבע כחול קיים וצבע ירוק אזל, אין די בכך שהעמוד המשפחתי מציג כפתור פעיל. ה־URL, ה־schema והפיד צריכים לזהות את הצבע הנכון ולהציג את זמינותו. חיבור מדויק בין מזהה הפריט למקור המלאי מתואר גם במדריך על GTIN, MPN ו־SKU.
Google תומכת בין היתר בערכים in_stock, out_of_stock, preorder ו־backorder. ב־preorder או backorder נדרש גם availability_date, והמועד צריך להיות גלוי בעמוד. מוצר שחדל להימכר אינו “חסר זמנית” לצורך שמירתו בפיד; ומוצר זמין שרק רוצים לעצור מפרסום אינו צריך לקבל זמינות שקרית. לשם כך קיימים מנגנונים כמו pause או excluded_destination לפי המקרה.
איך בודקים מה Google יכולה לקרוא בעמוד
פתחו את ה־URL בחלון נקי, בלי התחברות ובלי נתוני אזור שמורים. ודאו שהווריאנט הנכון נבחר, שהמחיר והמטבע גלויים, שסטטוס הזמינות מופיע ושאפשר להתחיל קנייה. לאחר מכן בדקו את HTML המקור ואת תוצאת Rich Results Test. חפשו Product ו־Offer שמתארים את אותה הצעה, עם מחיר, מטבע וזמינות תואמים.
במסמך פתרון המחיר, Google מציינת שלצורך בדיקת Merchant Center המחיר צריך להופיע ב־HTML שמוחזר מהשרת, ושמחיר שנוסף רק באמצעות JavaScript לאחר הטעינה עלול לעורר שגיאה. זו דרישה בהקשר של התאמת נתוני המוצר; אין להסיק ממנה שכל structured data דינמי בכל הקשר אינו נקרא. הבדיקה כאן ממוקדת במה שסורק Merchant Center משווה.
טווח מחירים הוא מקרה רגיש. אם הכותרת מציגה “החל מ־199 ₪” אך ההצעה שנשלחה היא וריאנט ב־249 ₪, הטווח אינו מחליף את המחיר המדויק של הווריאנט. גם AggregateOffer שמתאר טווח אינו פותר פיד שמקשר להצעה ספציפית ומציג מצב פתיחה אחר.
עדכונים אוטומטיים: רשת ביטחון, לא מקור אמת
Automatic item updates מאפשרים ל־Merchant Center לעדכן מחיר או זמינות על בסיס העמוד כאשר נמצא פער. הם יכולים לשמור פריטים מאושרים בזמן שהמקור התיישן, במיוחד בקטלוג שמשתנה מהר. Google עצמה מבהירה שהמנגנון אינו תחליף לשליחה סדירה של נתוני מוצר.
לכן מודדים אותו כאות תקלה. אם מספר קטן של פריטים תוקן בזמן מבצע חד־פעמי, ייתכן שההגנה עבדה כמתוכנן. אם אותה משפחת מוצרים מקבלת תיקונים בכל יום, צריך לאתר את המחלוקת: תזמון, cache, מקור מחיר נוסף, schema ישן, וריאנט פתיחה או כלל שפועל לאחר הייצוא. כיבוי העדכונים האוטומטיים אינו מתקן את המחלוקת; הוא רק מסיר את רשת הביטחון.
גם ההפך נכון. Google עשויה לעצור עדכונים אוטומטיים כאשר ה־microdata שגוי או כאשר קיימת אי־התאמה רחבת היקף. לכן “Google כבר תתקן” אינו חוזה תפעולי שאפשר לבנות עליו.
דוגמה: מבצע על נעל עם שלוש מידות
נניח שמוצר נמכר בשלוש מידות. מידה 40 עולה 299 ₪ ונמצאת במלאי, מידה 41 עולה 329 ₪ ונמצאת במלאי, ומידה 42 אזלה. ביום ראשון מתחיל מבצע שמוריד 30 ₪ מכל מידה זמינה. הקטלוג מתעדכן מיד, הפיד נשלח בכל לילה, וה־schema מחושב מתבנית שנשמרה ב־cache.
במהלך היום הפיד עדיין מציג 299 ₪ למידה 40, העמוד מציג 269 ₪, וה־schema מציג 299 ₪. במידה 42 הפיד מציג out_of_stock, אבל ה־URL נפתח על מידה 40 ולכן נראה זמין. יש כאן שני כשלים שונים: חלון סנכרון במחיר וקישור שאינו משחזר את הווריאנט בזמינות.
הפתרון אינו לערוך שני פריטים ב־Merchant Center. מגדירים שהפעלת המבצע מפעילה יחד עדכון קטלוג, ניקוי cache ושליחת מקור נתונים; מוודאים שטווח המבצע כולל אזור זמן; ומתקנים את כתובת הווריאנט או את מצב הפתיחה. לאחר מכן משווים מדגם של כל שלוש המידות בארבע השכבות ומחכים לסריקה מחדש. זו דוגמה היפותטית שממחישה את שיטת האבחון, לא נתוני חנות.
סדר תיקון שמונע מהשגיאה לחזור
- מקפיאים עריכות ידניות: מוודאים שאיש אינו משנה את אותו שדה בפיד, באפליקציה וב־Merchant Center במקביל.
- מזהים יחידת מכירה: item ID, וריאנט, URL, שוק, מטבע וזמן הסריקה.
- קובעים מקור אמת: איזו מערכת אחראית למחיר ולמלאי ומי רשאי לשנות אותם.
- בודקים את שרשרת ההפקה: קטלוג → עמוד → structured data → פיד → checkout.
- מתקנים את המקור או המיפוי: לא את העותק האחרון שבו התגלתה הבעיה.
- מסנכרנים ומנקים cache: מעדכנים את העמוד ומקור הנתונים באותו חלון.
- מאמתים מדגם: מחיר רגיל, מבצע, וריאנטים, חוסר מלאי ושוק נוסף אם קיים.
- שולחים מחדש ועוקבים: בודקים Needs attention ואת סטטוס הפריטים לאחר הסריקה החוזרת.
Google מציינת שסריקה מחדש עשויה לקחת שעות או ימים, ובחלק מתהליכי הבדיקה גם יותר. אין לשלוח בקשות review חוזרות לפני שהשינוי חי וניתן לשחזור. אם הבעיה היא פער מדיניות ולא רק נתון טכני, בקשת בדיקה ללא תיקון יכולה לבזבז ניסיון ערעור.
מטריצת אבחון לפי הדפוס
| הדפוס | החשד הראשון | בדיקת אימות | תיקון מערכתי |
|---|---|---|---|
| השגיאה מופיעה מיד אחרי שינוי מחיר | פער תזמון או cache | חותמות זמן בקטלוג, בעמוד ובמקור הנתונים | אירוע עדכון משותף או שליחה תכופה יותר |
| רק וריאנטים מסוימים מושפעים | URL או מיפוי item ID | פתיחת כל URL בחלון נקי והשוואת הווריאנט | קישור ניתן לשחזור וחוזה וריאנט אחיד |
| רק מבצעים מושפעים | תוקף, אזור זמן או מחיר מחוק | price, sale_price וטווח התוקף | מקור זמן יחיד ותזמון משותף |
| העמוד נכון וה־schema שגוי | תבנית או cache של JSON-LD | HTML מקור ו־Rich Results Test | להפיק markup מאותה רשומת הצעה |
| Google מתקנת שוב ושוב אוטומטית | פער קבוע במקור או בייצוא | היסטוריית עדכונים מול קובצי הפיד | לתקן את הצינור, לא להסתמך על התיקון |
| הזמינות נכונה בעמוד אך הקנייה נחסמת | מגבלת אזור, משלוח או checkout | רכישת בדיקה ליעד הרלוונטי | ליישר זמינות והגבלות בכל השלבים |
QA קבוע למחיר ולמלאי
אחרי שהתיקון עבר, הפכו את המדגם לבדיקה חוזרת. בכל שינוי תבנית, אפליקציית פיד, מנוע מבצעים, שוק או מערכת מלאי, בדקו לפחות מוצר רגיל, מוצר במבצע, שני וריאנטים עם מחיר שונה, וריאנט שאזל ומוצר עם preorder אם החנות משתמשת בו. תעדו ערך צפוי וערך בפועל, לא רק “עבר”.
בדוח שבועי הפרידו בין פריטים שנדחו, פריטים שקיבלו automatic update, משך הזמן עד תיקון ושיעור החזרה של אותה סיבה. המספרים אינם KPI שיווקי בפני עצמם; הם מדדי אמינות של צינור נתוני המוצר. מגמה חוזרת לפי תבנית, ספק או שוק מועילה יותר מספירה מצרפית.
מתי לא כדאי לפתור את הבעיה בתוך Merchant Center
עריכה ידנית ב־Merchant Center מתאימה לבדיקת חריגה בודדת או לתיקון זמני מתועד. היא אינה מתאימה לקטלוג שמקבל עדכונים אוטומטיים ממקור אחר, מפני שהערך עלול להידרס או להפוך לעותק שלישי שאין לו בעלים.
גם שינוי המחיר בעמוד רק כדי להתאים לפיד הוא פתרון מסוכן אם הפיד עצמו שגוי. המחיר שהלקוח רואה צריך להיגזר מההצעה העסקית האמיתית. אם יש מחירי אזור, מנויים, כמות מינימום או הנחה מותנית, בוחרים את מבנה הנתונים שתואם לתנאי Google ולא משטחים את ההצעה למחיר מטעה.
כאשר הפער מערב קטלוג, Theme, structured data, פיד ו־checkout, זו כבר עבודת מערכת. במסגרת קידום אורגני לאתרי מכירות בודקים את צינור נתוני המוצר כחלק מהיכולת של החנות להופיע בצורה אמינה ב־Search, ב־Shopping ובתוצאות מוצר.
אם המחיר, הזמינות והכשירות תקינים אך המוצר עדיין אינו מקבל חשיפות, הבעיה כבר אינה אי־התאמה. עוברים לאבחון מוצר שלא מופיע בגוגל שופינג ובודקים סטטוס, שיטת שיווק, מדינת יעד וביצועים לפני שמשנים שוב את נתוני המוצר.
שאלות נפוצות
האם Automatic item updates פותרים את הבעיה?
הם יכולים לתקן זמנית מחיר או זמינות על סמך העמוד ולמנוע דחייה, אך Google מבהירה שאינם מחליפים עדכון שוטף של מקור נתוני המוצר. תיקונים חוזרים הם סימן לפער בצינור.
איזה מחיר צריך להופיע בפיד בזמן מבצע?
price מתאר את המחיר הרגיל ו־sale_price את מחיר המבצע. כאשר מגבילים את המבצע בזמן, משתמשים ב־sale_price_effective_date עם טווח ואזור זמן נכונים, והעמוד צריך להציג את אותם מחירים.
מה עושים כשמחירי הווריאנטים שונים?
כל פריט בפיד צריך להוביל למצב עמוד שמציג את הווריאנט והמחיר שלו. טווח “החל מ־” אינו תחליף להתאמה ברמת ההצעה.
האם מספיק שה־structured data תקין?
לא. הנתונים המובנים הם אחת מתמונות המצב. גם המחיר והזמינות הגלויים, מקור הנתונים וה־checkout צריכים לתאר את אותה הצעה.
מתי לבקש בדיקה מחדש?
רק אחרי שהתיקון חי, המקור נשלח מחדש ואפשר לשחזר התאמה במדגם. אם הבעיה היא מדיניות או השעיה, פועלים לפי מסלול הבדיקה שמופיע בחשבון ולא מגישים שוב בלי שינוי מהותי.
מקורות ובדיקה
המקורות נבדקו בעת העדכון האחרון. קישורים חיצוניים נפתחים באתר המקור.
כפיר אהרון, לולו דיגיטל
עוסק במשך שנים ב־SEO, CRO ו־PPC, ועבד עם עשרות אתרי איקומרס ובעלי עסקים בישראל. המאמר נבדק מול המקורות המופיעים בעמוד, ומפריד בין הנחיה רשמית, שיקול מקצועי ודוגמה היפותטית.