🌐 3 הפורמטים של structured data, סקירה ראשונית
תקשיבו. אני אפתח עם הסיפור הקלאסי שאני שומע מלקוחות. "שמוליק, התקנתי תוסף schema לוורדפרס, יש לי schema בכל עמוד, אז הכל בסדר, נכון?" אני פותח את הקוד של העמוד, ורואה מצב מעניין. בחלק מהעמודים יש JSON-LD נקי, יפה, באלגנטיות מובחנת ב-head. בעמודים אחרים יש Microdata, attributes פרוסים בתוך ה-HTML. ולפעמים, באתרים ישנים יותר, יש גם RDFa בכלל, מקננים בתוך divs. ואני שואל, "אתה יודע למה זה ככה?" התשובה הצפויה, "לא, התוסף עשה את זה לבד". וזה החלק שגורם לי לקרוע את הלב, כי הבעלים של האתר מתקשר אלי כשהמיקומים שלו צונחים, ואני צריך להסביר לו שהבלגן הזה של פורמטים מעורבים זה חלק מהסיבה.
זה התסכול הקלאסי בעולם ה-structured data ב-2026. יש 3 פורמטים שונים שכולם אומרים את אותו דבר לגוגל, אבל בצורות שונות לגמרי. JSON-LD, שזה JavaScript Object Notation for Linked Data, הפורמט המודרני שגוגל ממליצה עליו רשמית מ-2015. Microdata, פורמט מבוסס HTML5 שמשרבב את ה-schema ישירות בתוך ה-markup. ו-RDFa, פורמט מבוסס XML שמקורו אקדמי, מורכב יותר, ובכל זאת עדיין בשימוש באקדמיה, במוזיאונים, ובאתרי ממשלה.
הבעיה היא שאם אין לכם הבנה ברורה של ההבדל בין 3 הפורמטים, אתם לא יודעים מה לעשות כשהתוסף שלכם פולט פורמט אחד, התבנית שלכם דוחפת פורמט אחר, וה-AI שלכם בודק את העמוד ומקבל מסר מעורבב. הסכמה לא תפסיק לעבוד, אבל גם לא תהיה אופטימלית. ובעידן שבו AI engines מצטטים תוכן לפי איכות ה-structured data, אופטימליות זה לא ניס to have.
גוגל הצהירה רשמית שכל 3 הפורמטים מקבלים יחס שווה לעניין דירוג. אבל באותה נשימה, היא ממליצה רשמית על JSON-LD לכל implementation חדש. ההמלצה הזאת לא נופלת מהשמיים. JSON-LD נקי יותר, קל יותר לתחזוקה, ופחות נוטה לשגיאות. אם אתם מטמיעים schema חדש ב-2026 ובחרתם Microdata או RDFa, אתם הולכים נגד הזרם.
במאמר הזה אני אעבור איתכם על 3 הפורמטים בפירוט. נראה את אותה schema בכל פורמט בנפרד כדי שתוכלו להשוות, נסביר את ההיסטוריה של כל אחד, נצלול לחוזקות ולחולשות, ובסוף תדעו בדיוק איזה פורמט לבחור ולמה. ואם יש לכם אתר עם Microdata ישן, אני אראה לכם איך להמיר אותו ל-JSON-LD צעד אחרי צעד עם workflow מעשי שעבד אצלי בעשרות פרויקטים. וגם נסקור את המקרה המוזר של Open Graph tags, שלכאורה נראים כמו RDFa אבל הם לא בדיוק זה. הרבה אנשים שמדברים על schema לא יודעים את ההבחנה, וזה גורם לבלבול שמשפיע על איך הם בונים את האתר. שמוליק דורינבאום, נתחיל.
⭐ JSON-LD, מה זה ולמה זה המודרני
JSON-LD זה Javascript Object Notation for Linked Data. הפורמט פותח על ידי W3C כתת-קבוצה של JSON רגיל, עם תוספות שמאפשרות לתאר Linked Data, כלומר מידע שמקושר לישויות אחרות באינטרנט. הפורמט הוצג רשמית ב-2010, וב-2014 הפך לסטנדרט W3C מומלץ. ב-2015 גוגל הכריזה רשמית, JSON-LD הוא הפורמט המומלץ לכל schema חדש שמטמיעים על אתרים. מאז, התעשייה זזה לכיוון JSON-LD בהדרגה, ואתרים מודרניים החדשים כמעט תמיד משתמשים בו בלעדית. אם תפתחו היום את הקוד של כל אתר מודרני שנבנה אחרי 2018, יש סיכוי טוב מאוד שתמצאו JSON-LD בתוך ה-head, ולא יותר מ-Microdata מקונן עמוק בתוך divs של ה-body.
איך זה נראה
JSON-LD יושב בתוך תג script ב-head של ה-HTML, עם type מסומן בבירור. הוא לא מערבב את עצמו עם המבנה החזותי של העמוד, אלא חי כשכבת מטא-דאטה נפרדת לחלוטין. הנה הדוגמה הבסיסית ביותר, schema של Person, בלי קישוטים מיותרים, רק התוכן הנקי.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"name": "שמוליק דורינבאום",
"jobTitle": "יועץ SEO",
"url": "https://www.shmul.co.il/"
}
</script>למה זה המודרני
3 סיבות עיקריות. ראשית, ההפרדה המלאה מה-HTML. כשאתם בונים עמוד, המעצב לא צריך לדעת כלום על schema. ה-schema יושב בקובץ נפרד או בתחתית התבנית, ה-HTML נשאר נקי. שנית, קלות התחזוקה. כשרוצים לעדכן schema (להוסיף property, לשנות ערך), פותחים את ה-JSON ועורכים. בלי לחפש את ה-tags המתאימים בתוך אלפי שורות HTML. שלישית, פחות פוטנציאל לטעויות. כשה-schema לא משובץ בתוך ה-markup, אין סיכון שעריכת CSS או refactor של HTML ישבור את ה-schema. בעולם של פיתוח מודרני, שבו cmsים, פלאגינים, ועדכוני תבניות עוברים על הקוד שלכם בקצב מטורף, היציבות הזאת היא הזהב.
גוגל הסבירה במספר דיונים רשמיים שהיא מעדיפה JSON-LD כי הוא יציב יותר. כשהיא מנתחת structured data על אתר, JSON-LD פחות נוטה להישבר עם שינויים בעמוד. בנוסף, ה-parsing שלו פשוט יותר, מהיר יותר, ועם פחות edge cases. בעולם שבו גוגל סורק מיליארדי עמודים, פשטות זה הכל. וגם, JSON-LD הוא הפורמט המקורי של RDF המודרני, מה שאומר שכל פיסת מידע מתורגמת בקלות לגרף ידע גלובלי.
בפרקים הבאים נראה איך נראה אותו תוכן בפורמטים האחרים, ותראו במו עיניכם למה JSON-LD ניצח את המלחמה הזאת. ההבדל הוויזואלי לבד מספיק כדי להבין למה רוב המפתחים בוחרים בו, ואת ההבדלים הסמויים נגלה תוך כדי.
📜 Microdata, ההיסטוריה של HTML5 microdata
Microdata הוא פורמט של structured data שפותח כחלק מ-HTML5. הוא הוצג ב-2009 כדרך משובצת לסמן מידע סמנטי ישירות בתוך ה-HTML של העמוד, באמצעות attributes מיוחדים. הרעיון היה אלגנטי בזמנו, במקום לכפול את התוכן (פעם ב-HTML לעיני המשתמש, פעם ב-schema למנועי חיפוש), אתה משבץ את ה-schema ישירות סביב הטקסט הקיים. הפורמט אומץ במהירות על ידי גוגל, מיקרוסופט, Yahoo, ו-Yandex, וב-2011 הקימו ביחד את schema.org כדי לתקנן את אוצר המונחים. בלי schema.org, Microdata היה נשאר רק רעיון תאורטי, אבל עם vocabulary סטנדרטי שגב גדולי המנועים, הוא הפך לכלי הקנוני של structured data באתרים מסחריים.
איך זה נראה
Microdata משתמש ב-3 attributes עיקריים על תגי HTML רגילים. itemscope מסמן שאלמנט מכיל ישות, itemtype מצביע לסוג הישות (URL של schema.org), ו-itemprop מסמן property בודד. הנה אותה Person schema שראינו קודם, אבל ב-Microdata, עם 3 ה-attributes פרוסים על כל יסוד.
<div itemscope itemtype="https://schema.org/Person">
<span itemprop="name">שמוליק דורינבאום</span>
<span itemprop="jobTitle">יועץ SEO</span>
<a itemprop="url" href="https://www.shmul.co.il/">האתר</a>
</div>למה זה היה מהפכני
בשנים 2009 עד 2014, Microdata היה הפורמט הדומיננטי. הסיבה הייתה היופי של הרעיון, התוכן והמטא-דאטה חיים יחד, בלי כפילות. אם אתה משנה את שם המוצר ב-HTML, ה-schema מתעדכן אוטומטית כי הם אותו דבר. וורדפרס, Shopify, Magento, וכל פלטפורמת CMS גדולה בנו תמיכה ב-Microdata ב-2011 עד 2013, וזה מה שעדיין יושב בהרבה אתרים ישנים עד היום. תבניות פרימיום של ThemeForest מהתקופה הזאת כולן הטמיעו Microdata בליבה, ועכשיו, כעבור עשור, הקוד הזה עדיין רץ במיליוני אתרים. זה אומר שאם אתם פותחים אתר וורדפרס שמיושן, יש סיכוי גבוה למצוא Microdata בלי שום פעולה מצד הבעלים.
למה זה איבד את המלחמה
הבעיה התגלתה כשהאתרים גדלו. כשאתה משבץ schema בתוך כל אלמנט HTML, ה-markup הופך לעמוס. תבנית פשוטה של מאמר הופכת ל-soup של divs ו-spans, כל אחד עם itemscope, itemtype, itemprop. ה-debugging מבעית, חלוקה לעבודה בין מפתחים קשה (המעצב נוגע ב-schema של ה-developer), וכשמשהו נשבר, קשה לאתר את הסיבה. בנוסף, אם תרצה להוסיף property שאין מקום ויזואלי בעמוד עבורו, אתה צריך להוסיף span נסתר עם meta content, וזה גנרי ולא אלגנטי.
ב-2015 גוגל הכריזה רשמית שהיא מעדיפה JSON-LD על פני Microdata. ההכרזה הזאת הייתה רעידת אדמה. הסיבה שגוגל נתנה, JSON-LD מאפשר ל-AI שלהם לעבד את ה-schema הרבה יותר ביעילות, וברוב המקרים יש פחות שגיאות parsing. מאז 2015, Microdata נמצא בירידה הדרגתית, אבל הוא לא נעלם, הוא עדיין יושב בעשרות אלפי אתרים שלא עברו רענון מאז.
בפרקים הבאים נראה דוגמאות מפורטות יותר, ותראו במו עיניכם למה Microdata עמוס יותר מ-JSON-LD ולמה ההכרזה של גוגל ב-2015 הייתה אך טבעית, ולא איזה ויכוח פוליטי שרירותי.
🏛 RDFa, המקור האקדמי
RDFa זה Resource Description Framework in Attributes. הפורמט פותח על ידי W3C כתת-קבוצה של RDF, הסטנדרט המרכזי של Semantic Web. RDF עצמו פותח באמצע שנות ה-90 על ידי קהילת המחקר של W3C, כדרך לתאר ידע ולקשר ישויות באינטרנט בצורה מאוד מאוד פורמלית. RDFa, שהוצג ב-2008, היה ניסיון להביא את הכוח של RDF אל תוך עולם ה-HTML הפרקטי, כדי שאפשר יהיה להטמיע structured data באתרים רגילים. החזון של Tim Berners-Lee, ממציא ה-Web ויו"ר W3C, היה Semantic Web שבו כל פיסת ידע באינטרנט מקושרת בצורה רשמית לידע אחר, וכל המכונות יכולות להסיק מסקנות חדשות באופן אוטומטי. RDFa היה צעד מרכזי בכיוון הזה.
איך זה נראה
RDFa משתמש בכמה attributes עיקריים, vocab מצביע לאוצר המונחים (schema.org או אחר), typeof מציין את סוג הישות, ו-property מסמן property בודד. הפורמט תומך גם בכמה תכונות מתקדמות שאין ב-Microdata, כמו prefix, about, ו-resource, שמאפשרים תיאור ישויות מורכבות יותר. הנה Person schema ב-RDFa, נראה דומה ל-Microdata אבל עם attributes שונים.
<div vocab="https://schema.org/" typeof="Person">
<span property="name">שמוליק דורינבאום</span>
<span property="jobTitle">יועץ SEO</span>
<a property="url" href="https://www.shmul.co.il/">האתר</a>
</div>למה זה אקדמי
RDF, האב של RDFa, פותח עבור Semantic Web, חזון שבו כל המידע באינטרנט מקושר בצורה מובנת לכל מכונה. הקהילה המקורית הייתה אקדמית במהותה, מחקרים, מוזיאונים, ספריות, פרויקטים ממשלתיים גדולים. הם רצו להוסיף הרבה semantics לתוכן, ו-RDF הציע גמישות אדירה, אבל גם מורכבות אדירה. RDFa ירש מ-RDF את הגמישות ואת המורכבות, וזה מה שעשה אותו פחות פופולרי במגזר המסחרי. מפתח שרק רצה להוסיף Article schema בלוג שלו, RDFa היה overkill. מפתח של מוזיאון שרצה לתאר 5,000 פריטים עם 12 vocabularies שונות, RDFa היה הבחירה ההגיונית היחידה.
איפה הוא חי היום
אתרי אקדמיה, מוזיאונים, ספריות לאומיות, אתרי ממשלה (במיוחד באירופה), והפרויקטים של איחוד האירופי, כולם עדיין משתמשים ב-RDFa הרבה. הסיבה, להם יש דרישות פורמליות לתיאור הידע שלא מסתפקות ב-schema.org הבסיסי. הם משתמשים גם ב-Dublin Core, FOAF, ו-vocabularies אחרים מעבר ל-schema.org, ו-RDFa מטפל בערוב פורמטים בהרבה יותר אלגנטיות.
אם Microdata פותח בידי קבוצה תעשייתית פרקטית שרצתה דרך פשוטה לסמן מידע, RDFa פותח על ידי קהילה אקדמית שרצתה כוח מקסימלי לתאר ידע מורכב. שני העולמות שונים, ולכן הפורמטים שונים. JSON-LD למעשה לקח את הכוח של RDF (הוא RDF סדרתי כ-JSON) והוסיף לו פשטות ה-Microdata, ולכן ניצח את שניהם.
בפרקים הבאים נראה איך כל אחד מ-3 הפורמטים מטפל בסכמות שונות, וההבדלים יהיו ברורים. נדגיש את הפער על דוגמאות אמיתיות מהמגזר המסחרי, איפה JSON-LD זוהר ואיפה החלופות נפלו בצד הדרך.
👤 השוואת קוד צד בצד, Person schema ב-3 פורמטים
הדרך הכי טובה להבין את ההבדל בין 3 הפורמטים היא לראות את אותו תוכן בכל אחד מהם. בואו נתחיל עם Person schema, אחת הסכמות הפופולריות והפשוטות ביותר. שמוליק דורינבאום, יועץ SEO, שעובד בחברה שנקראת Shmul.co.il, עם פרופיל בלינקדאין וטוויטר, סט די פשוט של properties שכולנו מטמיעים בעמוד אודות. בואו נראה איך זה נראה בכל אחד מהפורמטים, צד בצד, כדי שתבינו מהיכן באה ההמלצה של גוגל.
JSON-LD
הפורמט הנקי. ה-schema יושב בנפרד מה-HTML, בתוך תג script. שימו לב לקריאות הכמעט מושלמת, כל property הוא key-value פשוט, הקינון של worksFor הוא JSON רגיל, sameAs הוא array של URLs, הכל אינטואיטיבי גם למי שלא יודע schema.org.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"name": "שמוליק דורינבאום",
"jobTitle": "יועץ SEO",
"worksFor": {
"@type": "Organization",
"name": "Shmul.co.il"
},
"url": "https://www.shmul.co.il/",
"sameAs": [
"https://www.linkedin.com/in/shmul",
"https://twitter.com/shmul"
]
}
</script>Microdata
אותו תוכן, אבל משובץ בתוך ה-HTML. שימו לב כמה attributes צריך להוסיף, ואיך זה משפיע על קריאות ה-markup. תספרו כמה פעמים מופיע itemprop, ותהרהרו על איך זה ייראה אם תוסיפו עוד 20 properties.
<div itemscope itemtype="https://schema.org/Person">
<span itemprop="name">שמוליק דורינבאום</span>
<span itemprop="jobTitle">יועץ SEO</span>
<div itemprop="worksFor" itemscope itemtype="https://schema.org/Organization">
<span itemprop="name">Shmul.co.il</span>
</div>
<a itemprop="url" href="https://www.shmul.co.il/">האתר</a>
<link itemprop="sameAs" href="https://www.linkedin.com/in/shmul">
<link itemprop="sameAs" href="https://twitter.com/shmul">
</div>RDFa
אותו תוכן ב-RDFa. שימו לב לדמיון עם Microdata, אבל גם להבדלים העדינים (vocab במקום itemtype, typeof במקום itemscope). הדמיון הזה מטעה, ה-parsing של RDFa הוא הרבה יותר מורכב, וכל מנוע צריך לתמוך בערוב של vocabularies אם רוצים לנצל את הכוח האמיתי של הפורמט.
<div vocab="https://schema.org/" typeof="Person">
<span property="name">שמוליק דורינבאום</span>
<span property="jobTitle">יועץ SEO</span>
<div property="worksFor" typeof="Organization">
<span property="name">Shmul.co.il</span>
</div>
<a property="url" href="https://www.shmul.co.il/">האתר</a>
<link property="sameAs" href="https://www.linkedin.com/in/shmul">
<link property="sameAs" href="https://twitter.com/shmul">
</div>JSON-LD תופס פחות מקום בעין, נקרא יותר נוח, ויש בו פחות אזכורים חוזרים של schema-ספציפיים בתוך ה-HTML. ב-Microdata וב-RDFa תראו itemprop או property בכל שורה, ואלמנטים נסתרים (link) כדי להוסיף sameAs בלי שיוצג למשתמש. JSON-LD פותר את זה בלי overhead. לפרטים נוספים על schema.org במהותו יש לי מבוא ל-schema.org.
בפרק הבא נראה דוגמה מורכבת יותר, Article schema, ויהיו עוד יותר הבדלים בעין. ככל שהסכמה מורכבת יותר, ההפרש בין JSON-LD ל-Microdata וRDFa גדל באופן אקספוננציאלי, וזה למה ההמלצה של גוגל ב-2015 הייתה מבוססת לא רק על העדפה אסתטית אלא על עקרון תכנוני אמיתי. בעת שאתם מוסיפים עוד ועוד ישויות, JSON-LD נשאר קריא, Microdata הופך לג'ונגל של divs. תהיה את זה בחשבון בכל פעם שאתם מתלבטים איזה פורמט להטמיע על אתר חדש.
📄 השוואת קוד, Article schema ב-3 פורמטים
Article schema הוא מורכב יותר מ-Person. יש בו author, publisher, image, ולפעמים גם mainEntityOfPage. ההבדל בין הפורמטים נעשה דרסטי יותר. ראו עוד פרטים על article schema ב-מדריך Article schema. הסיבה לכך פשוטה, Article שזורה בתוכה Person (המחבר), Organization (המוציא לאור), ImageObject (התמונה), ולעיתים גם BreadcrumbList ו-CreativeWork נוספים. ככל שיש יותר ישויות מקושרות, היתרון של JSON-LD גדל בצורה ויזואלית מובהקת.
JSON-LD
הסכמה מסודרת היטב, קל לראות את ההיררכיה של Article, ומי הם המחבר וההוצאה לאור.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "איך לבחור פורמט structured data",
"datePublished": "2026-05-30",
"author": {
"@type": "Person",
"name": "שמוליק דורינבאום",
"url": "https://www.shmul.co.il/אודות/"
},
"publisher": {
"@type": "Organization",
"name": "Shmul.co.il",
"logo": {
"@type": "ImageObject",
"url": "https://www.shmul.co.il/logo.png"
}
},
"image": "https://www.shmul.co.il/article-cover.jpg"
}
</script>Microdata
שימו לב לקינון העמוק שמוצק לתוך ה-HTML, מה שהופך את העריכה למסובכת. כל ישות מקוננת היא div נוסף.
<article itemscope itemtype="https://schema.org/Article">
<h1 itemprop="headline">איך לבחור פורמט structured data</h1>
<meta itemprop="datePublished" content="2026-05-30">
<div itemprop="author" itemscope itemtype="https://schema.org/Person">
<span itemprop="name">שמוליק דורינבאום</span>
<link itemprop="url" href="https://www.shmul.co.il/אודות/">
</div>
<div itemprop="publisher" itemscope itemtype="https://schema.org/Organization">
<span itemprop="name">Shmul.co.il</span>
<div itemprop="logo" itemscope itemtype="https://schema.org/ImageObject">
<link itemprop="url" href="https://www.shmul.co.il/logo.png">
</div>
</div>
<img itemprop="image" src="https://www.shmul.co.il/article-cover.jpg" alt="">
</article>RDFa
במבט ראשון נראה דומה ל-Microdata, אבל ל-RDFa יש כוח נוסף שלא רואים פה, היכולת להחליף vocabularies באמצע (vocab attribute חדש).
<article vocab="https://schema.org/" typeof="Article">
<h1 property="headline">איך לבחור פורמט structured data</h1>
<meta property="datePublished" content="2026-05-30">
<div property="author" typeof="Person">
<span property="name">שמוליק דורינבאום</span>
<link property="url" href="https://www.shmul.co.il/אודות/">
</div>
<div property="publisher" typeof="Organization">
<span property="name">Shmul.co.il</span>
<div property="logo" typeof="ImageObject">
<link property="url" href="https://www.shmul.co.il/logo.png">
</div>
</div>
<img property="image" src="https://www.shmul.co.il/article-cover.jpg" alt="">
</article>שימו לב לבעיה הקלאסית עם Microdata ו-RDFa, כל ישות מקוננת (author, publisher, logo) מצריכה עוד div עם itemscope itemtype או typeof. אם יש לכם article עם author שיש לו organization שיש לו logo, אתם מקבלים 3 רמות של קינון מקוננים בתוך ה-HTML. ב-JSON-LD זה רק JSON מקונן, נקי, וקריא. זה הבדל מהותי שמשפיע על תחזוקה לטווח ארוך.
הבדל נוסף שראיתם בקוד, מאיפה השם של ה-author מגיע. ב-JSON-LD זה ערך גנרי של property בתוך אובייקט. ב-Microdata וב-RDFa, הוא נשאב מתוך span שמוצג למשתמש. זה אומר שאם הסטיילן ינסה לערוך את הטקסט, הוא עלול לשבור את ה-schema. עוד נקודה בעד JSON-LD, אין צורך לתאם בין מי שבונה את ה-UI לבין מי שאחראי על ה-SEO. כל אחד עובד על השכבה שלו, בלי להיתקל בשני.
🏪 השוואת קוד, LocalBusiness ב-3 פורמטים
LocalBusiness הוא schema קריטי לעסקים מקומיים. הוא מכיל address, contactPoint, openingHours, ולפעמים aggregateRating. למידע מלא יש לי מדריך LocalBusiness. כל עסק מקומי שמכבד את עצמו ב-2026 חייב להטמיע LocalBusiness schema אם הוא רוצה להופיע ב-Google Business Profile ו-Google Maps כראוי. ואם הוא רוצה גם להופיע ב-AI Overviews ובציטוטים של ChatGPT, ההטמעה צריכה להיות מדויקת. בואו נראה איך 3 הפורמטים מטפלים בעסק מקומי בסיסי, מסעדה בתל אביב עם כתובת, טלפון, שעות פתיחה, וטווח מחירים.
JSON-LD
בולט בקריאות, כל property יושב במקום הברור שלו, ו-PostalAddress מקונן בתוך address בלי overhead.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "מסעדת אבי",
"address": {
"@type": "PostalAddress",
"streetAddress": "דיזנגוף 142",
"addressLocality": "תל אביב",
"postalCode": "6432605",
"addressCountry": "IL"
},
"telephone": "+972-3-5234567",
"openingHours": "Mo-Th 12:00-22:00",
"priceRange": "$$"
}
</script>Microdata
שימו לב לכמות ה-attributes שמופיעים על כל אלמנט, ולשימוש ב-meta tags נסתרים להעברת מידע שאינו ויזואלי כמו addressCountry או openingHours בפורמט ISO.
<div itemscope itemtype="https://schema.org/LocalBusiness">
<h1 itemprop="name">מסעדת אבי</h1>
<div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
<span itemprop="streetAddress">דיזנגוף 142</span>
<span itemprop="addressLocality">תל אביב</span>
<span itemprop="postalCode">6432605</span>
<meta itemprop="addressCountry" content="IL">
</div>
<span itemprop="telephone">+972-3-5234567</span>
<meta itemprop="openingHours" content="Mo-Th 12:00-22:00">
<span itemprop="priceRange">$$</span>
</div>RDFa
כמעט זהה ל-Microdata בעין, אבל ה-parser שונה. property במקום itemprop, typeof במקום itemtype, ו-vocab שמוגדר פעם אחת ברמת הראש של הישות.
<div vocab="https://schema.org/" typeof="LocalBusiness">
<h1 property="name">מסעדת אבי</h1>
<div property="address" typeof="PostalAddress">
<span property="streetAddress">דיזנגוף 142</span>
<span property="addressLocality">תל אביב</span>
<span property="postalCode">6432605</span>
<meta property="addressCountry" content="IL">
</div>
<span property="telephone">+972-3-5234567</span>
<meta property="openingHours" content="Mo-Th 12:00-22:00">
<span property="priceRange">$$</span>
</div>שימו לב לטריק החסר באמת אסתטיקה, addressCountry בעברית הוא IL (קוד ISO). אבל ב-HTML לא רוצים להציג IL למשתמש, אז שמים meta tag נסתר עם content=IL. זה pattern נפוץ ב-Microdata וב-RDFa, ויוצר הרבה meta tags ריקים שלא משרתים את המשתמש, רק את מנועי החיפוש. ב-JSON-LD זה פשוט key-value, בלי overhead ויזואלי. דוגמה ברורה לסיבה שגוגל אוהבת יותר את JSON-LD.
עוד דבר ששווה לציין על LocalBusiness, ה-opening hours הוא formatted string מאוד ספציפי. ב-JSON-LD זה רק string רגיל בתוך quotes. ב-Microdata וב-RDFa זה meta tag נסתר עם content. אם אתם רוצים שהמשתמש יראה את שעות הפתיחה בפורמט פשוט ("שני עד חמישי, 12:00 עד 22:00"), צריך להוסיף עוד אלמנט HTML בנוסף ל-meta. בקיצור, יותר עבודה, יותר מקום לטעויות, פחות שליטה. בעוד ב-JSON-LD זה פיסת מטא-דאטה אחת ופיסת UI נפרדת, כל אחד עצמאי לחלוטין.
🛒 השוואת קוד, Product ב-3 פורמטים
Product schema הוא קריטי לאתרי איקומרס. הוא מכיל offers, price, availability, ולפעמים aggregateRating ו-review. בואו נראה איך 3 הפורמטים מטפלים בו. דוגמה רגילה, מוצר אחד עם brand, sku, price, ו-availability. נראה בפרק על Product למה היופי הוא לא רק אסתטיקה, אלא משפיע באמת על תפקוד האתר. בעת שמחירים משתנים, מלאים מתעדכנים, ו-availability מתחלפת ב-real time, הפורמט המודרני הוא הרבה יותר עמיד לשינויים.
JSON-LD
קל לעדכן, קל לחקור, וקל לדבג. ה-Offer מקונן בתוך Product, ולא בולש פעמים על HTML הוויזואלי.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "גלגל אוויר לאופניים",
"image": "https://example.co.il/wheel.jpg",
"description": "גלגל אוויר עמיד 28 אינץ׳",
"sku": "BIKE-W-28",
"brand": {
"@type": "Brand",
"name": "BikePro"
},
"offers": {
"@type": "Offer",
"price": "450",
"priceCurrency": "ILS",
"availability": "https://schema.org/InStock",
"url": "https://example.co.il/wheel"
}
}
</script>Microdata
כל Offer חייב להיות div נוסף עם itemscope וטעון ב-link tags למידע שלא מוצג למשתמש, כמו availability URL.
<div itemscope itemtype="https://schema.org/Product">
<h1 itemprop="name">גלגל אוויר לאופניים</h1>
<img itemprop="image" src="https://example.co.il/wheel.jpg" alt="">
<p itemprop="description">גלגל אוויר עמיד 28 אינץ׳</p>
<meta itemprop="sku" content="BIKE-W-28">
<div itemprop="brand" itemscope itemtype="https://schema.org/Brand">
<meta itemprop="name" content="BikePro">
</div>
<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
<span itemprop="price" content="450">450</span>
<meta itemprop="priceCurrency" content="ILS">
<link itemprop="availability" href="https://schema.org/InStock">
<link itemprop="url" href="https://example.co.il/wheel">
</div>
</div>RDFa
אותה בעיה כמו ב-Microdata, רק עם attributes בשם אחר. הקריאות עדיין נופלת מול JSON-LD בשעה שיש Offer מקונן.
<div vocab="https://schema.org/" typeof="Product">
<h1 property="name">גלגל אוויר לאופניים</h1>
<img property="image" src="https://example.co.il/wheel.jpg" alt="">
<p property="description">גלגל אוויר עמיד 28 אינץ׳</p>
<meta property="sku" content="BIKE-W-28">
<div property="brand" typeof="Brand">
<meta property="name" content="BikePro">
</div>
<div property="offers" typeof="Offer">
<span property="price" content="450">450</span>
<meta property="priceCurrency" content="ILS">
<link property="availability" href="https://schema.org/InStock">
<link property="url" href="https://example.co.il/wheel">
</div>
</div>היתרון התיאורטי של Microdata ו-RDFa עבור Product, ההצמדה לתוכן הנראה למשתמש. אם המחיר משתנה ב-HTML, ה-schema מתעדכן אוטומטית. אבל בפועל, רוב אתרי הקומרס מעדכנים מחיר דרך JavaScript בעלייה, וזה שובר את שני הפורמטים בכל מקרה. אז היתרון נשאר תיאורטי בלבד, בעוד שה-overhead שלהם הוא מאוד פרקטי.
אם אתם מנהלים אתר Shopify, יש לכם תבנית קלאסית עם Microdata על Product, ואתם רוצים לעבור ל-JSON-LD, יש פלאגינים שעושים את זה אוטומטית (כמו SEO Manager או JSON-LD for SEO). הם כותבים את ה-JSON-LD למעלה ולא נוגעים ב-Microdata הקיים. הבעיה היא שאז יש לכם שני schemas באותו עמוד, מה שגוגל לא אוהבת. עדיף לבחור פעם אחת ולמחוק את השני, לא לערבב.
❓ השוואת קוד, FAQPage ב-3 פורמטים
FAQPage schema הוא אחד הפופולריים ביותר ב-SEO היום. הוא מבוסס על מבנה של mainEntity שמכיל array של Questions, וכל אחת עם acceptedAnswer. השימוש בו הוא חובה לכל עמוד שמכיל סקציית שאלות ותשובות, אבל יש מלכודת, גוגל הוריד את ה-Rich Result של FAQPage עבור אתרים שאינם ממשלתיים או מוסדות מוכרים בשנת 2023. עדיין, ה-schema רלוונטי ל-AI engines, ל-Voice Assistants, ול-Knowledge Panel. ראו עוד פרטים על הטמעת FAQ עם schema יש לי מדריך FAQ schema באלמנטור. בואו נשווה איך 3 הפורמטים מטפלים ב-FAQ עם 2 שאלות, מה שמעשי לבדיקה.
JSON-LD
קל לקרוא, mainEntity הוא array של Questions, כל Question יש לו acceptedAnswer בקינון פשוט. אם תוסיפו עוד 10 שאלות, רק תוסיפו עוד 10 אובייקטים ל-array, בלי overhead.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "איזה פורמט עדיף, JSON-LD או Microdata?",
"acceptedAnswer": {
"@type": "Answer",
"text": "JSON-LD מומלץ על ידי גוגל לכל implementation חדש מ-2015."
}
},
{
"@type": "Question",
"name": "האם RDFa עוד רלוונטי?",
"acceptedAnswer": {
"@type": "Answer",
"text": "RDFa עדיין בשימוש באתרים אקדמיים וממשלתיים, פחות במגזר המסחרי."
}
}
]
}
</script>Microdata
כל שאלה היא div נוסף עם 3 attributes. כל answer מקונן בעוד div. עם 10 שאלות, יש לכם 40 divs רק עבור ה-FAQ. ה-HTML הופך לבלגן.
<div itemscope itemtype="https://schema.org/FAQPage">
<div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question">
<h3 itemprop="name">איזה פורמט עדיף, JSON-LD או Microdata?</h3>
<div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
<p itemprop="text">JSON-LD מומלץ על ידי גוגל לכל implementation חדש מ-2015.</p>
</div>
</div>
<div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question">
<h3 itemprop="name">האם RDFa עוד רלוונטי?</h3>
<div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
<p itemprop="text">RDFa עדיין בשימוש באתרים אקדמיים וממשלתיים, פחות במגזר המסחרי.</p>
</div>
</div>
</div>RDFa
אותו רעיון כמו ב-Microdata אבל עם attributes שונים. הקריאות עדיין נופלת מול JSON-LD, וההכנסה של ההסבר אדמיניסטרטיבי בכל פעם שיש Question חדש מציקה ל-developers.
<div vocab="https://schema.org/" typeof="FAQPage">
<div property="mainEntity" typeof="Question">
<h3 property="name">איזה פורמט עדיף, JSON-LD או Microdata?</h3>
<div property="acceptedAnswer" typeof="Answer">
<p property="text">JSON-LD מומלץ על ידי גוגל לכל implementation חדש מ-2015.</p>
</div>
</div>
<div property="mainEntity" typeof="Question">
<h3 property="name">האם RDFa עוד רלוונטי?</h3>
<div property="acceptedAnswer" typeof="Answer">
<p property="text">RDFa עדיין בשימוש באתרים אקדמיים וממשלתיים, פחות במגזר המסחרי.</p>
</div>
</div>
</div>תספרו כמה פעמים מופיע itemprop או property בכל גרסה. ב-JSON-LD זה מבנה תוכן בלבד, ב-Microdata וב-RDFa זה דיווח חוזר על כל פיסת מידע. עבור FAQPage עם 10 שאלות, ההפרש הופך לעצום.
אם יש לכם FAQ באלמנטור עם widget פנימי שלהם, יש סיכוי טוב שהוא פולט Microdata. תצטרכו להחליט אם להסיר ולהוסיף JSON-LD ידני, או להישאר עם Microdata. ההמלצה שלי תמיד, להחליף ל-JSON-LD ידני בתוך header.php של התבנית, כי השליטה גדולה יותר. אבל אם אתם לא נוחים עם קוד, להישאר עם הפלאגין זה לא קטסטרופלי, פשוט פחות אופטימלי.
🕰 מתי לראות Microdata עוד (CMSs ישנים)
למרות שגוגל ממליצה על JSON-LD מ-2015, Microdata עדיין נפוץ. הסיבה, יש המון אתרים ישנים שלא עברו עדכון, ויש פלטפורמות שעדיין מספקות Microdata בברירת מחדל. ההיסטוריה היא שלפני 2015, Microdata היה הסטנדרט הברור. תוכלו לצפות שכל אתר שנבנה לפני אז יכיל אותו, ושכל פלטפורמה שלא רעננה את הליבה שלה מאז, עדיין משתמשת בו. הנה איפה תיתקלו בו עוד היום בפועל.
וורדפרס עם תבניות ישנות
תבניות וורדפרס פופולריות שנכתבו בין 2011 ל-2015 הטמיעו Microdata בתבנית עצמה. תבניות כמו Twenty Twelve, Twenty Thirteen, ועוד עשרות תבניות פרימיום מהתקופה, כולן עם itemscope itemtype בכל מאמר ובכל לולאה. אם אתם רואים שתבנית פולטת Microdata, רוב הסיכוי שהתבנית עצמה ישנה. הפתרון הוא לעדכן תבנית, או להשתמש בתוסף שכותב JSON-LD על גביו (כמו Yoast SEO או RankMath). אבל אז יש לכם 2 schemas על אותו עמוד, וזה לא אופטימלי. עדיף להסיר את ה-Microdata מהתבנית או לעבור לתבנית חדשה לגמרי.
Shopify ותבניות ישנות
Shopify הטמיע Microdata בתבניות הקלאסיות, וחלק מהתבניות הפרימיום עדיין מציעות Microdata בלבד. אם אתם מקבלים Microdata על מוצרים בלי לבקש, סביר להניח שהתבנית שלכם נכתבה לפני 2017. תבניות חדשות יותר של Shopify (Dawn, Sense, Refresh) כן עברו ל-JSON-LD, אבל ה-conversion לא מלא, ולכן אתם עלולים לראות פיסות של שני הפורמטים על אותו עמוד.
פלטפורמות איקומרס ישנות
Magento 1.x (לפני 2018), OpenCart בגרסאות ישנות, PrestaShop בגרסאות 1.6 ומטה. כולן הטמיעו Microdata בליבת הקוד. אם האתר שלכם עדיין על אחת מהן, סביר שיש Microdata שאין דרך פשוטה להסיר.
אתרי HTML5 שנבנו ידנית בין 2010 ל-2015
אתרים שמפתחים בנו ידנית בעידן הזה, לפי המלצות הזמן, השתמשו ב-Microdata. הקוד שלהם עוד יושב באוויר היום, ולפעמים גם עם בעיות אחרות (תאימות מובייל, מהירות).
אתם לא חייבים למחוק אותו מיד. הוא עובד, גוגל עדיין מכבדת אותו, ה-AI engines עוד יכולים לעבד אותו. אבל אם אתם עושים refactor של האתר או של תבנית, זאת הזדמנות מצוינת לעבור ל-JSON-LD. אל תערבבו פורמטים בלי סיבה, אם כבר עוברים, עוברים לגמרי. בפרק 14 של המאמר הזה נעבור צעד אחרי צעד על איך להמיר Microdata ל-JSON-LD.
בפרק הבא נראה איפה RDFa עוד חי, וזה יהיה מקור פחות מסחרי. אבל לפני זה, שווה לציין שיש פלטפורמות שמערבבות פורמטים, הן פולטות גם Microdata בתבנית הליבה וגם JSON-LD בפלאגין SEO. זה מצב לא אופטימלי, ואני ממליץ לבחור פעם אחת ולהיצמד לו.
🎓 מתי לראות RDFa (אקדמיה, ממשלות)
RDFa תמיד היה פחות פופולרי במגזר המסחרי, אבל הוא חי וקיים בעולמות מסוימים שדורשים תיאור פורמלי וגמיש של ידע. אם אתם נתקלים ב-RDFa על אתר, יש סיכוי טוב שהוא נמצא באחת מהקטגוריות הבאות. ההפצה שלו מאוד תחומה, ולכן יוזרים רגילים שעובדים עם אתרים מסחריים כמעט לא נתקלים בו. אבל אם תפתחו אתר של אוניברסיטה או של ספרייה לאומית, אתם בסיכון גבוה לראות אותו.
אתרי אקדמיה ומוסדות מחקר
אוניברסיטאות מובילות, מוסדות מחקר, ארכיוני מאמרים מדעיים, כולם משתמשים ב-RDFa לתיאור מקיף של פרסומים, חוקרים, פרויקטים, ומאגרי מידע. הסיבה, יש להם vocabularies מיוחדים שמעבר ל-schema.org, כמו Bibo (Bibliographic Ontology) ל-citations מדעיים, ו-FOAF (Friend of a Friend) לאנשי מקצוע. RDFa מטפל בערוב vocabularies הרבה יותר אלגנטית מ-Microdata.
אתרי מוזיאונים וספריות
הספרייה הלאומית בישראל, הספרייה הלאומית של ארה"ב (LOC), Europeana הספרייה הדיגיטלית של אירופה, כולם משתמשים ב-RDFa עבור התיאור של פריטים בקולקציה. הם משתמשים ב-Dublin Core עבור metadata בסיסי, ב-FOAF עבור אישים, וב-CIDOC-CRM עבור מוזיאון. הערוב הזה דורש את הכוח של RDFa.
אתרי ממשלה (במיוחד באירופה)
הממשלות של אנגליה, גרמניה, צרפת, והאיחוד האירופי כולן השקיעו ב-Open Data בעידן 2010-2015. הפלטפורמות שלהן נבנו עם RDFa כסטנדרט, כי הוא תאם את החזון של Semantic Web ש-W3C קידם. אתרי data.gov.uk, data.europa.eu, ועוד רבים, כולם פולטים RDFa.
אתרים שמטרתם Linked Open Data
פרויקטים כמו DBpedia (גרסה ה-RDF של ויקיפדיה), Wikidata, ו-LOD Cloud בכלל, כולם מבוססים על RDF, ו-RDFa הוא דרך טבעית להציג את המידע באתרים שלהם. הם נחשבים לציר המרכזי של Semantic Web בפועל, ולכל מי שעובד בעולמות knowledge graphs ו-data integration, הם ספריות בלתי ניתנות לוויתור.
אם אתם בונים אתר מסחרי, אתר שירותים, אתר עורך דין, אתר רופא שיניים, אתר איקומרס, או באמת כל סוג של אתר יומיומי, RDFa הוא לא רלוונטי. גוגל מבינה אותו, אבל אין לכם סיבה לבחור בו על פני JSON-LD. RDFa מתאים רק במקרים שבהם אתם זקוקים לערוב vocabularies מעבר ל-schema.org, וזה לא ב-SEO רגיל.
בפרק הבא נדבר על המקרה הספציפי של Open Graph tags, שנראה כמו RDFa אבל הוא בעצם לא בדיוק זה. זה ארבעה meta tags בלי תיאוריה שמשפיעים על איך התוכן שלכם נראה כשמשתפים בלינקדאין או בוואטסאפ, ויש בלבול חוזר על הקשר ביניהם לבין schema.org. נעשה סדר בנושא.
🔖 OG tags, האם זה RDFa? (לא בדיוק)
אם אתם פותחים את ה-head של אתר מודרני, יש סיכוי טוב שתראו את ה-tags האלה. הם נראים מוזרים במבט ראשון, כי הם משתמשים ב-property attribute שמקובל ב-RDFa, ויש להם prefix מיוחד בשם og. הבלבול בין Open Graph לבין RDFa הוא נפוץ, ושווה לעשות סדר.
<meta property="og:title" content="כותרת העמוד">
<meta property="og:description" content="תיאור העמוד">
<meta property="og:image" content="https://example.co.il/image.jpg">
<meta property="og:url" content="https://example.co.il/page">
<meta property="og:type" content="article">אלה Open Graph tags. הם משמשים את פייסבוק, לינקדאין, וואטסאפ, וכל פלטפורמת social media אחרת כדי לדעת מה להציג כשעמוד שלכם משותף. הם נראים כמו RDFa במבט ראשון, וזאת לא טעות, יש להם משהו דומה. אבל הם לא בדיוק RDFa.
למה הם נראים דומה
פייסבוק הציגה את Open Graph ב-2010 כדרך של אתרים לתאר את עצמם ל-social media. הם בחרו בתחביר שדומה ל-RDFa, כי RDFa היה הסטנדרט המוביל באותו זמן ל-structured metadata בתוך HTML. ה-attribute property בתוך meta tag הוא תחביר RDFa תקני. בעצם, Open Graph אפשר להגדיר כתת-קבוצה של RDFa, עם prefix מיוחד (og) ו-vocabulary מיוחד.
למה הם לא לגמרי RDFa
הם לא לגמרי RDFa כי הם לא משתמשים ב-vocabulary של schema.org. הם משתמשים ב-vocabulary של Open Graph, שזה משהו של פייסבוק, לא של W3C. בנוסף, ה-parsing שלהם פשוט יותר, וגוגל לא משתמש ב-Open Graph tags כ-schema לעניין SERP (אבל הוא כן משתמש בהם להבנת התוכן ולפעמים לתמונה ב-Rich Results).
מה זה אומר בפועל
שמרו על Open Graph tags באתר שלכם, הם חיוניים ל-social media. במקביל, הטמיעו JSON-LD לכל ה-schema.org structured data שלכם. שני הסטים יחיו זה לצד זה בלי קונפליקט, כל אחד עושה את שלו. אסור לבלבל בין שני סוגי המידע, Open Graph אומר "איך אני נראה כשמשתפים אותי", schema.org JSON-LD אומר "מה אני בעיני המכונה".
ראיתי לקוחות שחושבים שאם הם הטמיעו Open Graph tags, אין צורך ב-schema. זאת טעות מהותית. Open Graph לא מתפקדים כ-schema. אסור לוותר על JSON-LD שמתאר את התוכן. ולהפך, גם אם יש לכם JSON-LD מעולה, אל תוותרו על Open Graph, אחרת התוכן שלכם יראה מכוער כשישתפו אותו.
טיפ קטן, יש גם Twitter Cards שדומים ל-Open Graph אבל ספציפיים לטוויטר. הם נראים אותו דבר טכנית, רק שה-prefix שונה (twitter במקום og). שלושת המערכות (Open Graph, Twitter Cards, schema.org JSON-LD) חיות יחד באתר מודרני, וכל אחת מטפלת באחריות אחרת. Open Graph לפייסבוק וואטסאפ, Twitter Cards לטוויטר, JSON-LD לגוגל ול-AI. בלי כפילות, בלי קונפליקט. עכשיו שיש בידיכם הבנה של כל הפורמטים, נדבר על אימות. איך בודקים שה-schema תקין, בלי תלות בפורמט שבחרתם.
✅ אימות וכלים, Rich Results Test לכל פורמט
בלי קשר לפורמט שבחרתם, חייב לאמת שה-schema תקין לפני העלאה לפרוד. אני ראיתי לקוחות שהטמיעו schema במשך חודשים בלי לבדוק פעם אחת, ואז שמו לב ב-Search Console שיש שגיאות בכל עמוד. החיפוש אחורה והתיקון לקח להם שבועות. כל הסיפור הזה היה מתבטל אם היו בודקים מההתחלה. אז הכלים שאני משתמש בהם בכל פרויקט, ואני ממליץ לכל מי שמטמיע schema להכיר אותם.
Rich Results Test (search.google.com/test/rich-results)
הכלי הרשמי של גוגל. תומך בכל 3 הפורמטים, JSON-LD, Microdata, RDFa. מזינים URL או מדביקים HTML, ומקבלים דוח על מה זוהה ועל שגיאות. הכלי לא רק בודק תקינות, הוא גם אומר אם ה-schema רלוונטי ל-Rich Result של גוגל. אם הסכמה שלכם תקנית אבל לא מספיק עשירה ל-Rich Result, הכלי יגיד את זה.
Schema.org Validator (validator.schema.org)
הכלי הרשמי של schema.org. בודק תאימות מלאה לסכמה, גם properties שגוגל לא משתמש בהם. אם אתם רוצים שה-schema יהיה תקני לכל מנוע, לא רק לגוגל, זה הכלי. הוא אומר על properties שחסרים, על values לא נכונים, ועל בעיות מבניות שגוגל מתעלם מהן.
JSON-LD Playground (json-ld.org/playground)
רלוונטי רק ל-JSON-LD. מאפשר לראות את ה-JSON שלכם בכמה תצוגות שונות, כולל הצורה ה-normalized של RDF. שימושי ל-debugging של schemas מורכבות עם הרבה ישויות מקושרות דרך @id.
בדיקה במובייל
גוגל הציגה לפני שנה Mobile-Friendly Test (search.google.com/test/mobile-friendly) שגם בודק structured data בהקשר מובייל. רלוונטי במיוחד עבור HowTo schema שעדיין מציג Rich Results במובייל.
בדיקה ב-Search Console
אחרי שהעמוד באוויר, ב-Search Console > Enhancements, גוגל מציגה את ה-schema שזוהה. אם משהו לא בסדר, יוצגו שגיאות עם דוגמאות של עמודים. זאת הדרך לבדוק אם ה-schema באמת עובד בפרוד לאורך זמן. תיכנסו פעם בחודש לפחות לבדוק, גם אם לא שיניתם דבר, כי לפעמים גוגל מעדכן את הדרישות שלהם והופך structured data שעבד לפני חודש לבעייתי. ההיסטוריה של HowTo schema ב-2023 היא דוגמה מובהקת לזה.
בפיתוח, בדיקה ב-JSON-LD Playground (אם זה JSON-LD) ו-Schema.org Validator. לפני העלאה, בדיקה ב-Rich Results Test. אחרי העלאה, בדיקה שוב ב-Rich Results Test עם ה-URL החי. אחרי שבועיים, בדיקה ב-Search Console > Enhancements.
בפרק הבא נראה את התהליך המעשי להמרת Microdata ל-JSON-LD, אם יש לכם אתר ישן ורוצים לשדרג. זה לא סקסי, אבל זאת ההשקעה שמשתלמת לטווח ארוך. אתר נקי הוא אתר שיציב יותר, סורק טוב יותר, וגם נראה טוב יותר ל-AI engines.
🔄 המרת Microdata ל-JSON-LD צעד אחרי צעד
אם יש לכם אתר עם Microdata ישן ורוצים לעבור ל-JSON-LD, התהליך לא מסובך, אבל דורש שיטתיות. הנה איך אני עושה את זה אצל לקוחות, צעד אחרי צעד. אל תנסו לעשות את זה בכל האתר בבת אחת, אלא תתחילו בעמוד אחד או שניים, אמתו שהכל עובד כמו שצריך, ואז התרחבו לשאר.
שלב 1, מיפוי הסכמות הקיימות
סורקים את האתר עם Screaming Frog (בהגדרות, Extraction > Custom > Microdata) ומקבלים רשימה של כל ה-Microdata באתר, לפי URL ולפי schema type. רואים בדיוק מה יש לכם, איפה, ובאיזה פורמט.
שלב 2, סדר עדיפויות
לא צריך להמיר הכל ביום אחד. תתחילו מהעמודים הכי חשובים, homepage, עמודי שירות מרכזיים, עמודי קטגוריה באיקומרס. עמודי מאמר ישנים יכולים לחכות. כל פעם שתעבירו עמוד, הוא יהיה נקי לחלוטין, בלי שאריות Microdata.
שלב 3, חילוץ הערכים
לכל schema ב-Microdata, רושמים את כל ה-properties ואת הערכים שלהם. למשל, אם יש Person עם name, jobTitle, ו-url, רושמים את שלושתם בטבלה.
שלב 4, בניית JSON-LD חלופי
פותחים editor של JSON, יוצרים structure של schema.org מהערכים שחילצתם. שומרים על מבנה זהה, אותם properties, אותם ערכים. רק הפורמט משתנה.
שלב 5, אימות ב-Rich Results Test
לפני שתמחקו את ה-Microdata הישן, בדקו ב-Rich Results Test שה-JSON-LD החדש תקין. הזינו את ה-HTML שיהיה אחרי השינוי, וודאו שהכל זוהה כראוי.
שלב 6, הסרת Microdata מה-HTML
כשה-JSON-LD החדש מאומת, מסירים את כל ה-attributes של Microdata מה-HTML. itemscope, itemtype, itemprop, כולם הולכים. ה-HTML הופך הרבה יותר נקי.
שלב 7, הוספת JSON-LD בתבנית
מכניסים את ה-script של JSON-LD לתוך head של התבנית. אם זה וורדפרס, יש את wp_head action שאפשר להזריק אליו. אם זה תבנית סטטית, ישירות ב-head.
שלב 8, בדיקה בפרוד
אחרי deploy, בודקים שוב ב-Rich Results Test עם ה-URL החי. וודאו שה-Microdata באמת הלך, ושה-JSON-LD שם.
שלב 9, בקשת reindexing
ב-Search Console, URL Inspection > Request Indexing על העמודים שעברתם. גוגל תעדכן את ה-index מהר יותר.
שלב 10, מעקב לאורך זמן
במשך החודש הבא, עקבו ב-Search Console > Enhancements שאין שגיאות, ושכל ה-schemas שזוהו תקינים. אם משהו לא בסדר, חזרו על התהליך.
אל תערבבו פורמטים על אותו עמוד. אם החלטתם להעביר ל-JSON-LD, מסירים את ה-Microdata לחלוטין מהעמוד. גוגל מתבלבל אם רואה את אותה schema בשני פורמטים, ולפעמים יראה כפילות. או הכל JSON-LD, או הכל Microdata. אסור בערבוב.
🎯 גוגל באמת אדישה? + ה-pillar וסיכום
השאלה הגדולה שאני מקבל מכל לקוח, "גוגל אמרה שכל 3 הפורמטים זהים לעניין דירוג, אז למה לטרוח לעבור ל-JSON-LD?" התשובה מורכבת, ושווה לדבר עליה ברצינות.
מה גוגל אמרה רשמית
בכמה Q&A sessions עם John Mueller ו-Martin Splitt, גוגל אישרה שכל 3 הפורמטים מקבלים יחס שווה לעניין דירוג. אין boost או הענשה לפורמט מסוים. אבל באותה נשימה, גוגל ממליצה רשמית על JSON-LD לכל implementation חדש. למה?
הסיבה האמיתית
JSON-LD פחות נוטה לשגיאות. כשגוגל סורקת מיליארדי עמודים, היא רוצה parsing נטול שגיאות. Microdata ו-RDFa, בגלל ההצמדה ל-HTML, יכולים להישבר בקלות. שינוי קטן ב-HTML, refactor של CSS, plugin שמוסיף div, כל אחד מהם יכול לשבש את ה-schema. JSON-LD לא נוגע ל-HTML, אז הוא יציב הרבה יותר.
מה זה אומר בפועל
גם אם גוגל לא נותנת boost ל-JSON-LD, היא נותנת אמון יותר ל-schema שתמיד עובד. אם ה-Microdata שלכם שבור לפעמים בגלל refactor, גוגל לא תסמוך עליו. JSON-LD יוצר עקביות. עקביות בונה אמון. אמון משפיע על איך גוגל מתייחסת לאתר שלכם בכלל.
פלוס, AI engines
זה הצד שגוגל לא מדברת עליו, אבל קריטי. ChatGPT, Perplexity, Gemini, כולם מעדיפים JSON-LD כשהם מצטטים תוכן. הסיבה, ה-parsing פשוט יותר, ויש פחות edge cases. כשמודל AI בוחר מה לצטט, הוא מעדיף תוכן עם schema יציב. בעולם שבו תנועה ממנועי AI הופכת קריטית, זה חשוב.
הסיכום, מה לבחור
אם אתם מטמיעים schema חדש ב-2026, השאלה לא קיימת, JSON-LD. אם יש לכם Microdata ישן ועובד, אתם לא חייבים למחוק אותו מיד, אבל בכל refactor או upgrade, תעברו ל-JSON-LD. אם אתם בונים אתר ל-Linked Open Data או אתר אקדמי עם vocabularies מורכבים, RDFa עוד יכול להתאים.
JSON-LD ניצח את המלחמה. הסיבות, פשטות תחזוקה, יציבות לאורך זמן, אמון של גוגל, ויעילות עבור AI engines. אם אתם מטמיעים structured data חדש, בחרו JSON-LD בלי לחשוב. אם יש לכם פורמט ישן, תכננו מעבר הדרגתי. החיים שלכם יהיו פשוטים יותר, וה-SEO שלכם יהיה חזק יותר.
למידע נוסף על שילוב schemas שונים, יש לי המדריך השלם לסכמות schema. למבוא רחב על schema.org במהותו, מבוא ל-schema.org. ולמדריכים ספציפיים על כל סכמה, יש לי Article, HowTo, Organization, LocalBusiness, AggregateRating, ו-BreadcrumbList. אם אתם רוצים לעבור על האסטרטגיה של schemas על האתר שלכם, דברו איתי.
📖 מילון מושגים
- JSON-LD
- JavaScript Object Notation for Linked Data, פורמט מבוסס JSON להטמעת structured data, הפורמט המומלץ של גוגל מ-2015
- Microdata
- פורמט של structured data שפותח כחלק מ-HTML5, משבץ attributes כמו itemscope ו-itemprop בתוך ה-HTML
- RDFa
- Resource Description Framework in Attributes, פורמט מבוסס RDF להטמעת structured data ב-HTML, נפוץ באקדמיה ובאתרי ממשלה
- itemscope
- attribute של Microdata המסמן שאלמנט HTML מכיל ישות מובנית
- itemtype
- attribute של Microdata המצביע לסוג הישות באמצעות URL של schema.org
- itemprop
- attribute של Microdata המסמן property בודד של ישות
- vocab
- attribute של RDFa המצביע לאוצר המונחים שבשימוש, בדרך כלל schema.org
- typeof
- attribute של RDFa המציין את סוג הישות, מקביל ל-itemtype של Microdata
- @context
- property של JSON-LD המצביע לסכמה שבשימוש, בדרך כלל https://schema.org
- Open Graph
- פורמט של meta tags לתיאור עמודים ל-social media, נראה כמו RDFa אבל לא בדיוק זהה לו
❓ שאלות נפוצות
מה זה structured data בכלל?
מה ההבדל בין JSON-LD ל-Microdata?
האם גוגל באמת מתייחסת לכל 3 הפורמטים שווה?
אם יש לי אתר עם Microdata, האם אני חייב להמיר ל-JSON-LD?
האם RDFa עוד רלוונטי ב-2026?
האם Open Graph tags זה RDFa?
האם אפשר לערבב פורמטים על אותו עמוד?
מה זה Linked Data וב-JSON-LD?
האם JSON-LD משפיע על מהירות העמוד?
איפה צריך לשים את ה-JSON-LD בעמוד?
האם schema.org הוא חובה?
מה קורה אם יש שגיאות ב-schema?
האם AI engines (ChatGPT, Perplexity) מעדיפים JSON-LD?
האם יש כלים שממירים אוטומטית בין הפורמטים?
מה הפורמט הכי טוב להטמעה ראשונית של schema באתר חדש?
צריכים לקפוץ למישהו שכבר ראה את הסרט?
שמוליק דורינבאום, 20 שנה ב SEO, 1,200 בוגרים בקורס. אם יש לכם אתר ולא בטוחים מאיפה להתחיל או שאתם תקועים במצב לא טוב, שלחו הודעה. תשובה תוך 24 שעות, בלי דמי ייעוץ למפגש הראשון.
שלחו הודעה