נתונים מובנים (Structured Data): שלוש טעויות שמחסלות מאות הזדמנויות להופיע בחיפוש

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

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

כשאני בודק תקלה כזאת, אני לא ממהר להוסיף עוד שדות ל־JSON-LD. קודם אני בודק מהיכן מגיע כל נתון, איזו תבנית מדפיסה אותו, מה רואה משתמש שאינו מחובר והאם הבעיה מוגבלת לכתובת אחת או חוזרת בכל קבוצת העמודים. לא פעם הקוד הוא רק המקום שבו התקלה נחשפת. המקור האמיתי נמצא במערכת המסחר, במטמון, בתוסף נוסף או בתהליך עדכון שאינו מסונכרן.

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

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

רגע לפני הטעויות: מה באמת אומר הסימון הירוק?

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

Google תומכת ב־JSON-LD, ב־Microdata וב־RDFa. ברוב המקרים היא ממליצה על JSON-LD, בעיקר משום שקל יותר ליישם ולתחזק אותו בקנה מידה גדול. זה יתרון תפעולי אמיתי, אבל הפורמט אינו פותר בעיות תוכן. גם JSON-LD נקי יכול להכיל מידע שגוי, מיושן או לא רלוונטי.

כדי להבין מה כלי הבדיקה מאשר, צריך להפריד בין שלוש שכבות:

• תקינות תחבירית: האם אפשר לקרוא את הקוד ולפענח אותו בלי להיתקע בגלל מבנה פגום.
• התאמה ל־Schema.org: האם הסוגים והמאפיינים קיימים במילון, והאם הקשרים ביניהם סבירים.
• כשירות לתצוגה ב־Google: האם סוג התוצאה נתמך כרגע, האם כל המאפיינים הנדרשים קיימים והאם הסימון עומד בהנחיות התוכן והאיכות.

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

כשירות היא אפשרות, לא התחייבות.

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

טעות ראשונה: הקוד מספר סיפור אחד, והעמוד מספר סיפור אחר

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

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

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

מחיר ומלאי: זו כבר לא רק בעיית SEO

נניח שב־JSON-LD מופיעים מחיר של 99 ש״ח וסטטוס InStock, אבל בעמוד מוצגים 119 ש״ח ו״אזל מהמלאי״. כל אחד מהערכים יכול להיות כתוב בצורה תקינה, ובכל זאת הסימון אינו מייצג את המידע שהמשתמש מקבל בפועל.

איך זה קורה? בדרך כלל לא בגלל טעות דרמטית אחת, אלא בגלל חיבור לא נכון בין מערכות:

• המטמון מחזיר גרסה ישנה של הנתונים המובנים.
• המחיר הגלוי נטען באופן דינמי, בזמן שה־Schema נוצר בצד השרת.
• תוסף ה־SEO קורא שדה אחד, ותוסף המסחר משתמש בשדה אחר.
• הסימון מתאר וריאציה מסוימת, אבל העמוד מציג כברירת מחדל וריאציה אחרת של צבע, מידה או חבילה.
• המלאי עודכן במערכת המסחר, אך עותק שנשמר במנגנון נוסף נשאר מאחור.

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

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

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

דירוגים וביקורות: הכוכבים אינם שכבת איפור

אם מסמנים AggregateRating, הדירוג המצטבר ומספר הביקורות צריכים להיות גלויים וברורים למשתמש. ערך של 4.9 בקוד אינו תואם לעמוד שמציג 4.7. גם 214 ביקורות בקוד אינן מתיישבות עם 187 ביקורות שמופיעות באתר.

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

לעסקים מקומיים ולנותני שירות יש מוקש נוסף. ביקורות על LocalBusiness או על Organization, כאשר העסק עצמו שולט בהצגתן באתר שלו, אינן כשירות להצגת כוכבי ביקורת עבור אותו עסק. הכלל חל גם אם הביקורות אמיתיות וגם אם הן מוצגות באמצעות וידג׳ט של צד שלישי.

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

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

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

כשבוחרים את הסוג לפי התוצאה שרוצים לקבל

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

זה נשמע יצירתי, אבל היצירתיות הזאת עובדת נגד האתר. @type צריך לתאר את הישות האמיתית ואת התכלית האמיתית של העמוד. הוא לא אמור לתאר את העיצוב שהיינו רוצים לקבל בתוצאות.

{ "@type": "LocalBusiness", "name": "העסק שלנו", "aggregateRating": { "@type": "AggregateRating", "ratingValue": 5, "reviewCount": 214 }
}

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

טעות שנייה: מניחים שכל מה שקיים ב־Schema.org יוצג ב־Google

Schema.org הוא מילון רחב שמתאר ישויות, מאפיינים וקשרים. במועד בדיקת המקורות, 18 באוגוסט 2026, הגרסה היציבה שלו הייתה 30.0. המילון רחב בהרבה מגלריית התוצאות העשירות של Google, וזה מכוון.

לכן צריך לשאול שאלה פשוטה: מהי מטרת הסימון? אם המטרה היא נראות ב־Google Search, התיעוד העדכני של Google הוא המקור הקובע לגבי ההתנהגות בחיפוש. סוג מסוים יכול להיות תקין לפי Schema.org ושימושי למערכות אחרות, בלי להפעיל שום תצוגה מיוחדת ב־Google.

אין כאן סתירה. Schema.org מתאר מה אפשר לבטא; Google מחליטה באילו חלקים להשתמש במוצרי החיפוש שלה.

נדרש או מומלץ? ההבדל קובע במה מטפלים קודם

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

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

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

התמיכה משתנה, והתקציב צריך להשתנות איתה

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

במהלך 2025 הפסיקה Google לתמוך בתצוגות חיפוש שהתבססו על Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement ו־Vehicle Listing. התמיכה ב־Practice Problem הופסקה גם היא, והמסמכים הוסרו בתחילת 2026. זה לא אומר שהסוגים נמחקו מ־Schema.org או שאף מערכת אחרת אינה יכולה להשתמש בהם. זה כן אומר שלא נכון למכור את היישום שלהם כהבטחה לתוצאה עשירה בחיפוש הכללי.

יש גם חריג שממחיש מדוע לא מסתפקים בפוסט עדכון ישן. Book Actions נכלל תחילה בהודעה על הוצאה משימוש, אך Google חזרה בה מאוחר יותר מפני שעדיין נותרה תכונת חיפוש שהסתמכה עליו. בתחום הקורסים חשוב להבחין בין שמות קרובים: Course Info הוצא משימוש, בעוד הסימון Course list עדיין הופיע בגלריית הסוגים הנתמכים במועד הבדיקה.

Dataset מחדד נקודה נוספת. הסימון משמש את Google Dataset Search, אך אינו מיועד לייצר תוצאה מיוחדת בחיפוש הכללי. השאלה הנכונה אינה רק ״האם Google משתמשת בזה?״ אלא ״באיזה מוצר, באיזה מסך ולאיזו מטרה עסקית?״

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

FAQ ו־HowTo: קוד תקין, ציפייה שכבר התיישנה

תוצאות עשירות מסוג FAQ הפסיקו להופיע ב־Google Search ב־7 במאי 2026, והמסמכים הוסרו לאחר מכן. לכן ההמלצה להוסיף FAQPage כדי ״לתפוס יותר מקום בגוגל״ כבר אינה המלצה עדכנית.

האם צריך למחוק מיד כל סימון FAQPage? לא בהכרח. הסוג עדיין קיים ב־Schema.org, ומערכות אחרות עשויות להיעזר בו. עם זאת, אין בסיס רשמי להבטיח שהוא יוצר כיום הרחבה בחיפוש או מעניק יתרון מיוחד ב־AI Overviews או ב־AI Mode.

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

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

לפני שמשלמים למקדם אתרים פרילנסר על יישום חדש, בקשו לראות איזו תוצאה פעילה הוא אמור לאפשר. אם התשובה נשענת על צילום מסך ישן או על אמירה כללית כמו ״Schema תמיד טוב ל־SEO״, עדיין אין הצדקה מקצועית להשקעה.

טעות שלישית: מתייחסים ל־Schema כאל קטע קוד חד־פעמי

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

עדכון תבנית יכול להסיר מאפיין. תוסף אחר עלול להדפיס אובייקט Product שני. המטמון עשוי להחזיק מחיר ישן, וקוד JavaScript עלול שלא לרוץ בתנאים מסוימים. גם WAF או מערכת אבטחה אחרת עלולים להגיש לבוט גרסה שונה מזו שהמשתמש מקבל.

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

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

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

איך תקלה אחת יכולה לפגוע במאות הזדמנויות?

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

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

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

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

כך בונים ובודקים יישום שאפשר לסמוך עליו

לפני שכותבים שורת JSON-LD אחת, מחליטים מה העמוד באמת מייצג. האם זה מוצר יחיד, רשימה, אירוע, מאמר או עמוד של עסק? אחר כך בודקים אם Google תומכת כיום בתצוגה המתאימה ומהם המאפיינים הנדרשים והמומלצים.

רק אז ממפים כל נתון למערכת שמנהלת אותו:

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

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

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

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

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

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

אחרי העלייה לאוויר בודקים את הגרסה המרונדרת, סורקים מדגם רחב ועוקבים אחר הדוחות ב־Search Console. עלייה חדה במספר המופעים של אותה שגיאה עשויה להצביע על תקלה אחת בתבנית. גם ירידה במספר הפריטים התקינים מצדיקה בדיקה, במיוחד לאחר שינוי ב־CMS, בתוסף או בתבנית.

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

טעויות נוספות שכדאי לחפש בביקורת

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

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

נקודות שחשוב לברר לפני שמאשרים את היישום

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

• מה אנחנו מנסים לאפשר? בלי מטרה מוגדרת קל להוסיף סוגים שאין להם שימוש מעשי.
• האם התוצאה נתמכת כיום ב־Google Search? לא מספיק שהיא קיימת ב־Schema.org או מוזכרת במדריך ישן.
• מאיזו מערכת מגיע כל שדה דינמי? צריך לדעת מי מנהל את המחיר, המלאי, הדירוג, הכתובת והתאריך.
• האם כל המידע המסומן גלוי למשתמש? אם הוא משתנה לפי התחברות, מיקום או וריאציה, צריך לדעת איזו גרסה מקבלת Google.
• מה קורה כשנתון חסר או מתיישן? עדיף להשמיט רכיב לא תקין מאשר להדפיס ערך ברירת מחדל מטעה.
• אילו תבניות וכתובות מושפעות? כך מבינים אם תקלה אפשרית מוגבלת לעמוד אחד או מתפשטת לכל הקטלוג.
• מי אחראי לתחזוקה לאחר העלייה לאוויר? מישהו צריך לעקוב גם אחר שינויי תמיכה וגם אחר שינויים בקוד ובמערכות האתר.
• איך מודדים הצלחה? לא רק לפי היעדר שגיאות, אלא לפי דיוק, יציבות וכשירות לתצוגה שבאמת רלוונטית לעסק.

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

איפה נכון להתחיל לתקן?

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

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

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

הטיפ האישי שלי: שני תוספים, שתי גרסאות לאמת

במבט חוזר: הבעיה כמעט אף פעם אינה רק סוגר חסר

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

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

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

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