תוכן העניינים
אפשר לקבל תוצאה ירוקה בכלי בדיקת Schema ועדיין למסור למנוע החיפוש מידע שגוי: מחיר שכבר השתנה, שם מחבר שאינו תואם למאמר או פרטי אירוע שבוטל. הקוד יכול להיות תקין מבחינה טכנית, בזמן שהמידע שבתוכו כבר אינו מתאר את העמוד.
הפער הזה מסביר מדוע עבודה על נתונים מובנים מתחילה בתוכן ובניהול המידע. לפני שמתקינים תוסף או מבקשים להוסיף סימון, צריך להחליט מה רוצים לתאר, לשם מה ומי ידאג שהפרטים יישארו נכונים.
נתונים מובנים הם דרך למסור מידע בפורמט שמערכות יכולות לעבד באופן מסודר. במקום להסתפק בטקסט שמופיע בעמוד, אפשר לציין במפורש שזהו מאמר, מי כתב אותו ומתי פורסם, או שזהו מוצר עם מחיר וזמינות מסוימים.
Schema.org מספק אוצר מילים לתיאור המידע הזה. JSON-LD, שמופיע לעיתים בהגדרות האתר או התוסף, הוא אחד הפורמטים שבהם אפשר לכתוב אותו. אלה מושגים קשורים, אבל הם ממלאים תפקידים שונים: האחד מגדיר מה מתארים, והשני כיצד מייצגים זאת בקוד.
שלוש הבטחות שכדאי לפרק לפני ההטמעה
״נוסיף Schema והדירוגים יעלו״
סימון יכול לעזור למנוע החיפוש לפרש את התוכן ולתמוך בתצוגות מסוימות. מכאן אי אפשר להסיק שהוספתו תעלה את מיקום העמוד. איכות התוכן, התאמתו לחיפוש, נגישותו לסריקה וגורמים נוספים ממשיכים להשפיע על הביצועים.
אם בעמוד מוצר חסרים פרטים שהקונה צריך כדי לבחור, הסימון לא ישלים עבורו את המידע החסר.
״הבדיקה תקינה, אז נקבל תוצאה עשירה״
תקינות היא אחד התנאים, אך אינה הבטחת הצגה. גם עמוד שעומד בדרישות עשוי להופיע כתוצאת טקסט רגילה. התצוגה תלויה בסוג התוכן, בתמיכה של Google ובנסיבות החיפוש.
צריך להפריד בין שלושה מצבים: הסימון ניתן לפענוח, הוא עומד בדרישות התכונה הרלוונטית, והתכונה מופיעה בפועל. מעבר של בדיקה טכנית אינו מוכיח את שלושתם.
״ככל שנוסיף יותר סוגים, האתר יהיה מובן יותר״
אפשר לתאר כמה דברים באותו עמוד, כאשר הם אכן קיימים וקשורים זה לזה. למשל, מאמר והגורם שפרסם אותו. התועלת תלויה בהתאמה ובדיוק של התיאור.
אין הצדקה להפעיל כל אפשרות שהתוסף מציע. כל שכבת מידע נוספת צריכה לייצג משהו אמיתי ולהישאר מעודכנת.
קודם בודקים מה יש בעמוד
נניח שבאתר מופיע מאמר מקצועי עם כותרת, תמונה, תאריך ושם כותב. סימון Article יכול לתאר את הפרטים האלה באופן מפורש. באתר מסחר, סימון Product עשוי לתאר מוצר ולתמוך בהצגת מידע כמו מחיר וזמינות, בהתאם לדרישות הרלוונטיות.
בשני המקרים, הפרטים צריכים להגיע מהתוכן ומהמערכת שמנהלת אותו.
אם המאמר חתום בשם אדם, הסימון צריך לשקף אותו. אם הוא נכתב מטעם מערכת או ארגון, אפשר לתאר מחבר ארגוני. אין צורך להמציא אדם כדי למלא שדה שהוגדר בצורה לא מתאימה בתוסף.
כך גם לגבי דירוגים: אם אין בעמוד ביקורות אמיתיות שמתאימות לדרישות הסימון, לא מייצרים ציון כדי לנסות לקבל כוכבים בתוצאות.
הבדיקה הראשונית יכולה להיות פשוטה: פותחים את העמוד לצד הנתונים שנוצרו עבורו ומשווים ביניהם. האם הם מספרים את אותו סיפור? האם המחיר, הכותרת, המחבר והתאריך תואמים? האם הכתובות והתמונות שייכות לתוכן הנכון?
פערים בשלב הזה מצביעים על צורך לתקן את מקור המידע או את אופן הפקת הסימון.
מסלול ההחלטה: להוסיף, לתקן או לוותר
במקום להתחיל מרשימה ארוכה של סוגי Schema, אפשר להתקדם לפי ההחלטה שצריך לקבל.
האם הסימון מתאר תוכן שקיים בפועל?
אם כן, ממשיכים לבדיקה הבאה. אם לא, עוצרים ומבררים האם חסר תוכן בעמוד או שנבחר סוג סימון שאינו מתאים לו.
למשל, עמוד כללי שמציג כמה שירותים אינו הופך לעמוד מוצר יחיד רק מפני שסימון Product מציע אפשרויות תצוגה מושכות.
האם יש מטרה מוגדרת להטמעה?
מטרה יכולה להיות זכאות לתצוגה נתמכת, תיאור פרטי המאמר או זיהוי מדויק יותר של הארגון.
לסימון Organization, למשל, יכול להיות תפקיד בהבהרת זהות הארגון ופרטיו. התועלת האפשרית שלו אינה מצטמצמת למדידה של תוספת חזותית ליד כל תוצאה.
כשמבקשים תצוגה מסוימת בחיפוש, צריך לבדוק שהסוג והיישום עדיין נתמכים. עצם קיומה של הגדרה בתוסף אינו מעיד על התמיכה הנוכחית של Google.
דוגמה חשובה היא FAQ. החל מ־7 במאי 2026, Google אינה מציגה עוד את תוצאות ה־FAQ העשירות. לכן, הוספת סימון מתוך ציפייה לקבל רשימת שאלות ותשובות מתחת לתוצאת החיפוש נשענת כיום על ציפייה שאינה תקפה.
שאלות ותשובות עדיין יכולות להיות תוכן שימושי לקוראים. ההחלטה לפרסם אותן צריכה להתבסס על השאלות שהן פותרות, גם בלי תצוגה מיוחדת בגוגל.
האם המידע זמין וניתן לתחזוקה?
אם מערכת המסחר מנהלת את המחיר והמלאי, רצוי שהסימון ישתמש באותם נתונים. העתקה ידנית למקום נוסף יוצרת סיכון לפערים בכל עדכון.
כאשר נתון מומלץ אינו קיים, בודקים אם אפשר להוסיף אותו בצורה אמינה. לא משלימים פרטים משוערים רק כדי להסיר אזהרה.
האם האתר כבר מפיק את הסימון?
מערכות ותוספים עשויים לעשות חלק מהעבודה אוטומטית. למשל, לפי התיעוד בעברית של Wix על הגדרות ה־SEO בבלוג, פוסטים בבלוג מגיעים עם סימון מובנה שאפשר לערוך בהגדרות.
גם באתר WordPress כדאי לבדוק מה כבר מפיקים התוסף והתבנית לפני שמוסיפים פתרון נוסף. התשובה יכולה להיות שהסימון הקיים מספיק, שנדרשת התאמה קטנה או שיש צורך בהשלמה ממוקדת.
העלות שמופיעה אחרי ההתקנה
הוספת הסימון היא רק תחילת העבודה. התחזוקה נבחנת כשהאתר משתנה.
מחיר מתעדכן, מאמר עובר לכותב אחר, תמונה מוחלפת או שם הארגון משתנה. אם התוכן הגלוי מתעדכן והסימון נשאר מאחור, נוצרות שתי גרסאות של אותו מידע.
לכן כדאי לקבוע לכל סוג נתון מקור מוסכם. כותרת המאמר תגיע משדה הכותרת המתאים, המחבר ממערכת הכותבים והמחיר ממערכת המסחר. ככל שיש פחות מקומות שבהם מקלידים את אותו פרט בנפרד, קל יותר לשמור על התאמה.
גם כמה רכיבים שמפיקים Schema במקביל דורשים תשומת לב. עצם קיומם של כמה פריטי נתונים באותו עמוד הוא מצב רגיל. הבעיה מתחילה כאשר הם מציגים גרסאות סותרות של אותה ישות, למשל שני מחירים שונים לאותו מוצר.
כדאי להגדיר מי אחראי להפקת כל חלק, ולבדוק שוב אחרי החלפת תבנית, שינוי תוסף SEO או שינוי במבנה התוכן. בדיקה של עמוד אחד אינה מספיקה כאשר באתר קיימות תבניות שונות למאמרים, מוצרים ועמודי שירות.
איך יודעים שהעבודה הועילה?
צריך לבדוק גם את היישום וגם את התוצאה.
בשלב הטכני, Schema Markup Validator מסייע לבחון סימון לפי אוצר המילים של Schema.org. Rich Results Test מתמקד בסוגי התוצאות העשירות שנתמכים בכלי של Google. אלה בדיקות בעלות מטרות שונות, ולכן הודעה שלא זוהו פריטים בכלי אחד אינה בהכרח הוכחה שאין בעמוד שום נתונים מובנים.
גם ההבדל בין שגיאה לאזהרה חשוב. שגיאה עשויה לפסול פריט מהתצוגה הרלוונטית. אזהרה עשויה להצביע על שדה מומלץ שחסר. הטיפול צריך להישען על משמעות ההודעה ועל המידע הזמין, בלי להוסיף נתונים לא מדויקים כדי להגיע לדוח נקי.
לאחר הפרסום בודקים את הכתובת החיה, ולא רק קטע קוד מבודד. אם התוכן או הסימון נוצרים באמצעות JavaScript, יש חשיבות גם לתוצאה שמתקבלת לאחר הרינדור. פערים כאלה נידונים במאמר על בעיות רינדור ואינדוקס באתרי JavaScript.
בהמשך אפשר לעקוב ב־Search Console אחרי דוחות רלוונטיים, ככל שהם זמינים, ואחרי ביצועי קבוצת העמודים ששונתה. כדאי לתעד את מועד ההטמעה ולבחון תקופה מספקת, תוך התחשבות בעונתיות, בשינויי מיקומים ובעדכוני תוכן שנעשו במקביל.
עלייה בשיעור ההקלקות עשויה להיות תוצאה רצויה, אבל היא אינה מוכיחה לבדה שהסימון גרם לה. גם היעדר שינוי מיידי אינו מחייב להוסיף עוד סוגי Schema.
באתר עם משאבים מוגבלים, כדאי להתחיל בתבניות שבהן יש מידע מוגדר, שימוש נתמך ודרך אמינה לתחזק אותו. לפני כל הרחבה נוספת, צריך להיות אפשר לענות על שלוש שאלות: מה הסימון מתאר, מי משתמש במידע, ואיך הוא יישאר נכון גם בעדכון הבא.
