Schema Markup למנועי AI: כך תסייעו להם להבין טוב יותר את התוכן שלכם

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

הסכמה לא מוכרת את התוכן שלכם. היא רק מונעת מהמכונה לנחש

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

Schema Markup למנועי AI הוא בסך הכל בלוק קוד קריא-מכונה, ברוב המקרים JSON-LD, שמצהיר בצורה חד משמעית מי כתב את העמוד, מה הוא מתאר, מתי הוא עודכן ולאיזו ישות עסקית הוא שייך.

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

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

Structured Data או Schema Markup? רוב האנשים מבלבלים, וזה עולה להם בזמן

Structured Data הוא הרעיון הכללי, כלומר כל דרך לתאר מידע בצורה שמכונה יכולה לפרק לשדות. Schema Markup הוא היישום הספציפי, אוצר המילים של schema.org שמגדיר טיפוסים כמו Article, Organization או FAQPage ואת השדות שלהם.

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

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

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

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

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

ומה שמעצבן? חלק מהעמודים החלשים היו עם סכמה עשירה בהרבה.

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

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

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

Article Schema, והשדה שכולם משאירים ריק ומשלמים עליו

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

השדות שאני דורש מהצוות שלי בכל עמוד הם headline שתואם לכותרת הגלויה, image אמיתית מהעמוד, datePublished, dateModified, author עם טיפוס Person ושם מלא, publisher שמקושר ל-Organization, ו-mainEntityOfPage עם ה-URL הקנוני.

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

איך מקשרים Article ל-Organization בלי ליצור שתי ישויות נפרדות

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

FAQPage הפכה למלכודת. מתי בכל זאת אני עדיין מטמיע אותה

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

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

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

HowTo כמעט נעלמה מהתוצאות העשירות. אז למה אני עדיין משתמש בה?

כי מנוע שמנסה לענות על "איך עושים X" מחפש רצף שלבים מובנה, וסכמת HowTo מגישה לו את זה מוכן עם step, tool ו-supply. ההצגה החזותית נעלמה, ההבנה נשארה.

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

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

מי אתם בכלל? Organization היא הסכמה הכי מוזנחת ביחס לתרומה שלה

Organization ו-LocalBusiness עונות על השאלה שמנוע AI שואל לפני שהוא מצטט אתכם. מי אמר את זה, והאם הישות הזאת קיימת ועקבית בכל האינטרנט.

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

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

BreadcrumbList נראית קוסמטית. בפועל היא מלמדת על מה העמוד הזה בכלל

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

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

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

Schema Stacking, או איך להפסיק לפזר שישה בלוקים שמסוכסכים זה עם זה

Schema Stacking הוא שילוב של כמה סכמות משלימות באותו עמוד כדי לתת תמונה שלמה. מאמר שמקושר לכותב, שמקושר לארגון, שיושב בתוך היררכיה מוגדרת.

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

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

שלושה כללים שאני מיישם בכל גרף

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

head או body? זו השאלה הלא נכונה

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

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

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

איך כותבים JSON-LD בלי להשאיר למכונה מקום לפרשנות

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

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

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

חמש טעויות שאני רואה בכל אבחון של אתר חדש

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

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

הטעויות השקטות שעוברות בוולידציה ופוגעות בהמשך

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

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

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

איך בודקים שהסכמה באמת עובדת, ולא רק שהיא קיימת

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

Schema Markup Validator רחב יותר ובודק גם טיפוסים שגוגל לא תומכת בהם בתוצאות עשירות, וזה חשוב במיוחד כשעובדים לקראת מנועי AI ולא רק לקראת SERP.

ו-Search Console נותן את התמונה ברמת האתר, עם דוחות שוטפים שמראים מגמות של שגיאות ואזהרות לאורך זמן.

להמציא סכמה כדי לקבל יותר חשיפה? ראיתי איך זה נגמר

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

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

מה באמת מייצר ציטוט במנוע AI, לפי מה שאני רואה בפרויקטים

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

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

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

הטמעתם הכול והוולידציה ירוקה. אז למה עדיין שקט?

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

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

מה לעשות מחר בבוקר, בסדר הזה בדיוק

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

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

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

שאלות שחוזרות אצל כל לקוח, לפני שהם מתחילים איתנו