נתונים מובנים הם תיאור קריא למכונה של מה שמופיע בעמוד. הם אינם תחליף לתוכן שהקורא רואה, ואינם מקום להוסיף ביקורות, תארים או שירותים שאינם קיימים באמת. כדי לבדוק שהם מספרים את אותו הסיפור, משווים בין טקסט העמוד, פרטי העסק והמחבר, קוד הסכמה והפלט הסופי של העמוד. לאחר מכן מתקנים רק אי התאמות שאומתו.
התשובה הקצרה: בחרו עמוד אחד, רשמו את העובדות הגלויות בו, בדקו אילו ישויות ותכונות מופיעות בנתונים המובנים, ואז סמנו לכל תכונה מקור גלוי ועדכני. שדה שאי אפשר לאמת אינו צריך להישאר רק מפני שהוא עובר בדיקת תחביר. מנגד, אין צורך להוסיף כל פרט גלוי לסכמה. המטרה היא ייצוג מדויק של התוכן העיקרי, לא צבירת סוגי סכמה.
ההנחיות הכלליות של Google לנתונים מובנים מבחינות בין תקינות טכנית לבין איכות: תוכן שאינו מייצג את העמוד או מוסתר מהמשתמש עלול להיות בעייתי גם כאשר הקוד תקין. הבדיקה המוצעת כאן היא תהליך בקרת איכות, לא הבטחה לתוצאה עשירה בחיפוש או לאזכור במנוע AI.
קודם מבינים מה העמוד אמור לייצג
עמוד שירות, מאמר מקצועי, עמוד מחבר ועמוד הבית משרתים מטרות שונות. לכן הם אינם צריכים להציג את אותה סכמה בדיוק. מאמר יכול לשאת נתוני Article עם כותרת, מחבר, תמונה ותאריכים נכונים. עמוד מחבר עשוי להציג פרטי Person או ProfilePage כאשר הדבר מתאים למבנה ולעיקר התוכן. עמוד עסקי יכול להציג את זהות הארגון והפרטים הרלוונטיים לו. אין להסיק מכך שכל סוג חייב להופיע בכל עמוד.
לפני פתיחת כלי בדיקה, שאלו מהו התוכן העיקרי: האם העמוד מסביר שירות, עונה על שאלה או מציג אדם? אחר כך רשמו את הכותרת, שם המחבר, פרטי השירות, פרטי העסק והתאריכים שהקורא רואה. אל תתחילו מהשדות בקוד; התחלה כזאת עלולה לגרום לכם להתאים את הטקסט לטעות שכבר קיימת במערכת.
בדוגמה להמחשה, עמוד מאמר מציין בכותרת ״איך לבדוק נתונים מובנים״ ומציג מחבר אחד. אם JSON-LD שלו מכיל כותרת אחרת או מחבר ישן, קיימת אי התאמה שצריך לברר. אם הוא מכיל גם סכמת שירות משום שתוסף גלובלי הוסיף אותה, אין להסיר אותה אוטומטית; בודקים אם היא באמת מייצגת שירות שמופיע בעמוד ואם מדובר בכפילות או בסימון לא רלוונטי.
ממפים את העובדות הגלויות לפני בדיקת קוד
צרו גיליון קצר לכל עמוד שנבדק. אין צורך בפרויקט טכני גדול כדי לזהות רוב הפערים. מטרת הטבלה היא להפריד בין עובדה שניתן להצביע עליה לבין מסקנה או הנחה. אפשר לצרף כתובת מדויקת של העמוד והמיקום שבו הפרט מופיע, כדי שאדם נוסף יוכל לאמת את הבדיקה.
| פרט לבדיקה | היכן בודקים בעמוד | היכן בודקים בנתונים המובנים | דגל אזהרה |
|---|---|---|---|
| כותרת מאמר | H1 וכותרת הדפדפן | headline או name | כותרת של מאמר אחר |
| מחבר | שורת מחבר ופרופיל קיים | author ו־@id | אדם לא קיים או פרופיל שגוי |
| תאריך | מועד פרסום או עדכון גלוי | datePublished ו־dateModified | תאריך שאינו משקף שינוי אמיתי |
| תמונה | תמונה ראשית בפועל | image | קובץ שבור או תמונה לא קשורה |
| שירות | תיאור השירות והיקפו | Service או provider | שירות שלא מוצע בעמוד |
| פרטי עסק | שם, כתובת ודרכי קשר גלויות | Organization או LocalBusiness | מספר או כתובת לא מעודכנים |
לא כל שדה בטבלה חייב להופיע בכל סוג עמוד. למשל, אין טעם לחפש מחיר כאשר האתר אינו מציג מחיר קבוע, ואין להמציא מחיר לצורך סימון. אם יש פרטי קשר שונים בכותרת האתר, בפוטר ובעמוד השירות, קודם פותרים את הסתירה בתוכן הגלוי ורק אחר כך מוודאים שהסכמה עקבית. אחרת, הקוד יהיה ״נכון״ רק ביחס לגרסה אחת של מידע סותר.
בודקים את הפלט שמנוע החיפוש מקבל
מערכת WordPress עשויה לייצר סכמה ממספר מקורות: תוסף SEO, תבנית Elementor, תוסף ייעודי או תוספת בקוד. לכן מסך ההגדרות של תוסף יחיד אינו הוכחה לפלט הסופי. פתחו את העמוד כפי שהוא מוגש לציבור ובדקו את תגי JSON-LD וה־HTML אחרי טעינה. את הקוד יש לקרוא בזהירות; שינוי שגוי ברכיב גלובלי עלול להשפיע על עשרות עמודים.
כלי בדיקת תוצאות עשירות של Google מסייע לזהות חלק משגיאות הסכמה והזכאות לתכונות נתמכות, אך אינו תחליף לקריאת העמוד. Google מדגישה שבדיקת תחביר מוצלחת אינה מבטיחה הופעה מיוחדת, ושיש בעיות איכות שכלי אוטומטי לא יזהה. לכן משווים ידנית את הערכים לקורא ורק אחר כך משתמשים בכלי לאימות טכני.
הסתכלו גם על canonical ועל מצב האינדוקס, אך אל תשנו אותם רק מפני שמצאתם שדה סכמה שגוי. אלה מנגנונים שונים. אם העמוד חסום לאינדוקס בכוונה, הסרת החסימה דורשת החלטה נפרדת. אם יש גרסת מובייל או דף שונה במערכת, בדקו את הכתובת הקנונית שהאתר מפרסם ואת התוכן שהיא מציגה, ולא רק תצוגה מקדימה בעורך.
מבחינים בין שתי ישויות לבין כפילות אמיתית
שני בלוקים של JSON-LD אינם בהכרח כפילות. אחד יכול לתאר Article ואחר את העסק. גם אותה ישות יכולה להיות מקושרת באמצעות @id ממספר רכיבים. השאלה היא האם קיימות שתי הגדרות סותרות או מיותרות של אותו דבר. לדוגמה, שני אובייקטים נפרדים של Article עם מחברים ותאריכים שונים לאותו מאמר מצריכים בירור. לעומתם, Article שמפנה ל־Person שהוגדר פעם אחת יכול להיות מבנה תקין.
חפשו קודם את מזהי הישויות, הסוגים והמאפיינים המרכזיים. בדקו האם תוסף SEO ותוסף סכמה ייעודי פועלים במקביל, האם Elementor מייצר רכיב נוסף, ומה קורה רק בתצוגה המחוברת לעומת הציבורית. אל תנטרלו תוסף באתר פעיל על בסיס מספר האובייקטים בלבד. תעדו דוגמה, מקור משוער והשפעה אפשרית לפני שינוי.
התיעוד הרשמי לסכמת Article מציג את הקשר בין מאמר, מחבר, תאריכים ותמונה. הוא מסביר כיצד הסימון עשוי לעזור ל־Google להבין את העמוד, ולא קובע שיותר בלוקים יביאו יותר חשיפה. שדות נכונים ועקביים חשובים יותר מריבוי תוויות.
בודקים פרטי מחבר ועסק בלי להמציא סמכות
שם מחבר צריך להתאים לאדם או לגוף שאכן חתום על המאמר. קישור לפרופיל מחבר צריך להוביל לפרופיל קיים, שבו המידע הגלוי אינו סותר את מאמריו. אם אין תואר, ניסיון או הסמכה שניתן לאמת, לא מוסיפים אותם לסכמה כדי ליצור רושם סמכותי. המדריך ליצירת עמוד אודות ופרופיל מחבר מסביר כיצד לאסוף עובדות אמיתיות לפני ניסוחן באתר.
גם פרטי עסק דורשים מקור אחד מוסכם. שם מסחרי, שם משפטי, לוגו, כתובת וקישורי פרופיל יכולים להיות שונים במערכות שונות מסיבות לגיטימיות, אך יש להסביר את היחסים ביניהם ולא להציג שתי זהויות סותרות. אם כתובת פיזית אינה מוצגת או אינה רלוונטית לשירות, לא ממציאים אותה לצורך LocalBusiness. אם עמוד שירות מציג טווח פעילות או תהליך עבודה, אל תסמנו מחיר או דירוג לקוחות שלא מופיעים בו.
עמוד מחבר ועמוד אודות אינם בהכרח אותו דבר. הנחיות Google ל־ProfilePage קובעות שעיקרו של עמוד כזה צריך להיות אדם או ארגון המזוהה עם האתר. אל תסמנו כל דף צוות כפרופיל אישי אם עיקרו אינו פרופיל של ישות אחת. התאמת סוג הסכמה לתפקיד העמוד עדיפה על שימוש אוטומטי בכל סוג זמין.
משווים FAQ ומידע גלוי לקורא
שאלות ותשובות הן מקום שכיח לאי התאמה: תוכן גלוי משתנה בעריכת Elementor, בעוד נתונים מובנים נשארים בגרסה קודמת או נוצרים ממקור אחר. ודאו שהשאלות, סדרן והתשובות בקוד משקפים את מה שהמשתמש יכול לקרוא בפועל. אקורדיון אינו בעיה כשאפשר להגיע לתשובות והן זמינות ב־HTML; תוכן שאינו נגיש לקורא אינו בסיס מתאים לסימון.
אין להוסיף שאלות ותשובות רק כדי ליצור FAQPage. בסוגי אתרים רבים Google אינה מציגה כיום תוצאה עשירה של FAQ, גם כאשר הסימון תקין. לכן הערך של השאלות צריך להיות לקורא עצמו. אם שני תוספים יוצרים FAQPage לאותן שאלות, בדקו את הפלט והעדיפו מקור אחד. אל תשנו סכמה תקינה רק בשל היעדר תוצאה עשירה בדוח החיפוש.
מתקנים לפי סדר סיכון ובודקים שוב
התחילו משגיאות שמשנות עובדה משמעותית: זהות עסק, מחבר, הצעת שירות, תאריך או מידע מטעה על ביקורות. אחר כך בדקו כפילויות וסוגים לא רלוונטיים. שינוי גלובלי בתבנית או בתוסף מחייב בדיקת מדגם רחב של עמודים, משום שתיקון של מאמר אחד עלול למחוק סכמה תקינה בעמודי שירות. אם אין מקור ברור לסכמה, עוצרים וממפים את רכיבי האתר במקום למחוק קוד בניחוש.
לאחר כל שינוי, בדקו שוב את HTML הציבורי של העמוד ואת ערכי הסכמה. ודאו שהטקסט שהקורא רואה, הכותרת, המחבר והתמונה עדיין נכונים. אחר כך בדקו את המאמר, עמוד השירות ועמוד המחבר במדגם, בהתאם להיקף השינוי. תעדו לפני ואחרי: כתובת, שדה בעייתי, מקור השגיאה, פעולה שבוצעה ותוצאת בדיקה. מדד הצלחה כאן הוא היעדר סתירות מאומתות, לא הבטחה לתוצאה עשירה.
טעויות ומגבלות שכדאי לזכור
בדיקת סכמה אינה בדיקת איכות מלאה של תוכן. עמוד יכול להיות מסומן היטב ועדיין לענות חלקית על שאלת הקורא. גם הסכמה המושלמת ביותר לא מבטיחה דירוג, ציטוט במנוע AI או כניסה לאינדקס. מנגד, סכמה שאינה נתמכת כתוצאה עשירה יכולה עדיין לשמש תיאור של ישות, אך אין לטעון להשפעה מסוימת בלי מדידה מתאימה.
עוד טעות היא לפרש כל התרעה בכלי כמצב חירום. חלק מהשדות הם מומלצים ולא חובה, חלק מהסוגים אינם זכאים לתצוגה מיוחדת, ולעיתים הבעיה נמצאת רק בכתובת בדיקה שאינה גרסת הציבור. בדקו מקור, חומרה והשפעה לפני התערבות. אם הנתונים נוצרו על ידי תוסף, עדכון התוסף עצמו עלול לשנות את הפלט ולכן נדרשת בדיקת רגרסיה אחרי עדכון משמעותי.
שאלות ותשובות
האם כל פרט גלוי בעמוד חייב להופיע בסכמה?
לא. הסכמה צריכה לתאר את הישות והתוכן המרכזיים באופן מדויק. לא כל פסקה, קישור או פרט עיצובי דורשים שדה מתאים.
האם שני בלוקים של JSON-LD הם בהכרח כפילות?
לא. בדקו אילו ישויות הם מתארים, האם הן מקושרות והאם יש ערכים סותרים. מספר הבלוקים לבדו אינו מדד לאיכות.
מה עושים כששם המחבר בסכמה שונה מהשם באתר?
מבררים איזה מקור מעודכן ומי אחראי על הפרסום, מתקנים את המידע השגוי ובודקים מדגם נוסף. אין לבחור שם רק לפי מה שמופיע בכלי הבדיקה.
האם אפשר לסמן ביקורות שאינן מוצגות בעמוד?
לא נכון להוסיף ביקורות או דירוגים שלא ניתנים לאימות ושאינם עומדים בהנחיות הספציפיות. סימון מטעה עלול לפגוע בזכאות לתוצאות עשירות.
האם בדיקה שעברה בכלי Google מבטיחה תוצאה עשירה?
לא. הבדיקה מסייעת באיתור בעיות טכניות, אך Google אינה מבטיחה הופעה מיוחדת גם בסימון תקין. יש לבדוק גם איכות, רלוונטיות ותוכן גלוי.
האם צריך לשנות canonical כאשר יש שגיאת סכמה?
לא באופן אוטומטי. canonical וסכמה פותרים שאלות שונות. שינוי כתובת קנונית דורש ראיה עצמאית לגבי גרסאות העמוד והעדפת האינדוקס.
מה בודקים אחרי שינוי בתוסף SEO?
בודקים את פלט הסכמה הציבורי במאמר, בעמוד שירות ובעמוד מחבר מייצגים, יחד עם כותרות, תאריכים, קישורים והיעדר כפילות חדשה.
סיכום
בדיקת נתונים מובנים טובה היא השוואה בין עובדות שהקורא רואה לבין התיאור שהמכונה מקבלת. התחילו במיפוי תוכן, בדקו את הפלט הציבורי, הבחינו בין ישויות שונות לכפילויות ותקנו רק אי התאמות שניתן להצביע עליהן. אם אתם צריכים תהליך רחב יותר של בדיקת נראות, תוכן ואמינות האתר, אפשר לקרוא על שירות קידום GEO ולהחליט אילו בדיקות מתאימות למצב האתר שלכם.
