Schema בוורדפרס: מה מסמנים ואיך בודקים נכון
מדריך לנתונים מובנים באתר עסקי: בחירת סוג הסימון, מניעת כפילויות, בדיקת התאמה לתוכן והבחנה בין קוד תקין לתצוגה בחיפוש.
מה נתונים מובנים עושים בפועל
Schema.org הוא אוצר מונחים לתיאור מידע, כגון ארגון, מאמר ומוצר. JSON-LD הוא אחת הדרכים לכתוב את התיאור בתוך עמוד. הסימון יכול לעזור למערכות להבין מה מוצג, אבל אינו מחליף תוכן שימושי, אינו מבטיח דירוג ואינו הבטחה לציטוט בתשובת AI. יש להבחין בין סוג שקיים ב־Schema.org לבין תכונת חיפוש ש־Google תומכת בה.
הסבר Google על נתונים מובנים מפרט את ההבחנה בין סימון, דרישות ותוצאות עשירות.
ממפים את העמודים לפני שמוסיפים קוד
- עמוד חברה: בדקו מי הארגון, מה שמו, כתובתו ופרטי הקשר האמיתיים שלו.
- מאמר: בדקו כותרת, כותב אמיתי, תמונה ומועדי פרסום ועדכון נכונים.
- חנות: תארו מוצר, מחיר וזמינות בהתאם למה שהגולש יכול לראות ולרכוש בפועל.
- ניווט: פירורי לחם צריכים לשקף מסלול הגיוני באתר, לא רשימת ביטויי קידום.
הכינו רשימה של תבניות האתר ולא רק של כתובות. אם מאמרים רבים משתמשים באותה תבנית, תיקון במקור הנתונים יכול לעדכן אותם יחד. לעומת זאת, עמוד שירות וחנות אינם צריכים לקבל אותו סימון רק משום שהם נבנו באותו עורך.
בודקים מה כבר נוצר בוורדפרס
פתחו את קוד המקור של עמוד לדוגמה וחפשו application/ld+json. תעדו אילו ישויות מופיעות, מי מייצר אותן ואילו פרטים מגיעים מהגדרות האתר. תוסף SEO, תבנית ותוסף ביקורות עלולים להפיק חלקים חופפים. כמה קטעי JSON-LD אינם בהכרח תקלה; הבעיה היא מידע סותר, ישויות כפולות או קשרים שגויים ביניהן. הגדירו מקור אחראי לכל סוג מידע לפני שמתקינים כלי נוסף.
תהליך יישום שאפשר למסור למפתח
- בחרו עמוד מייצג ותעדו את הסימון הקיים ואת המידע הגלוי.
- רשמו את השדות הדרושים ואת מקורם בוורדפרס. אל תמציאו ערכי דירוג, כתובת או הסמכה כדי להשלים שדה.
- שנו בסביבת בדיקה ושמרו דרך להחזיר את ההגדרה הקודמת.
- אמתו את הקוד ואת התאמתו לתוכן; בדקו גם עמוד שבו חסרים שדות אופציונליים.
- אחרי הפרסום בדקו שוב את כתובת האתר הציבורית ואת גרסת המטמון, לא רק את התצוגה בעורך.
מה לא נכון להבטיח לגבי FAQ ותיבת חיפוש
FAQ כתוב היטב עדיין עוזר לקוראים, אך אין להציג FAQPage כדרך לקבל תוצאת FAQ ב־Google. ביומן העדכונים הרשמי Google מציינת שהצגת תוצאות FAQ הופסקה ב־7 במאי 2026. גם תיבת החיפוש של sitelinks הוסרה בעבר; אין טעם למכור SearchAction כהבטחה להצגתה. שמות של סוגי Schema אינם חוזה לתצוגה מסוימת.
דוגמת בדיקת קבלה
נניח שבאתר יש מאמר על בחירת מערכת דיוור. בדקו שכותרת המאמר בקוד תואמת לכותרת הגלויה, שהכותב אינו שם ברירת מחדל ושהתמונה שייכת למאמר. אם קיימת שאלת לקוח בגוף הטקסט, אין להפוך אותה לביקורת או לציון. בדיקה תחבירית יכולה לעבור גם כשהמידע שגוי; לכן איש תוכן צריך לאשר את המשמעות לצד הבדיקה הטכנית.
השתמשו ב־Rich Results Test לבדיקת תכונות נתמכות וב־Schema Markup Validator לבדיקת המבנה. היעדר תוצאה עשירה אינו כשלעצמו הוכחה שה־JSON אינו תקין.
שאלות לפני שמתחילים
האם צריך תוסף Schema נוסף?
רק אם קיים צורך שהמערכת הנוכחית אינה פותרת. בדקו קודם מה כבר מופק, כדי לא להוסיף כפילויות ותחזוקה מיותרת.
האם להסיר את השאלות מהאתר?
לא. שאלות ותשובות יכולות לעזור לאדם להבין שירות. הערך שלהן אינו תלוי בהופעה מיוחדת בגוגל.
מתי רואים שינוי בחיפוש?
אין מועד או תצוגה שאפשר להבטיח. אחרי השינוי בודקים את הקוד הציבורי וממשיכים לוודא שהמידע נכון ומתוחזק.
מדריכים וכלים להמשך
ממפים סוגי עמודים לפני בחירת תוסף
Schema בוורדפרס הוא דרך לתאר מידע שכבר מופיע בעמוד במבנה שמנועי חיפוש יכולים לפרש. לפני בחירת תוסף, מיפו סוגי עמודים: ארגון, מאמר, מוצר, שירות או אירוע אם הוא באמת קיים. לכל סוג בדקו מה המידע הגלוי ומה מקורו באתר. אל תוסיפו דירוג כוכבים או שאלות שאינם מוצגים לקוראים, ואל תסמנו כל עמוד כאילו הוא אותו סוג ישות. קוד תקין מבחינה תחבירית אינו הוכחה שהמידע נכון או שהתוצאה העשירה תופיע בחיפוש.
בדקו מה התבנית, תוסף SEO, מערכת החנות ובונה העמודים כבר מייצרים. שני רכיבים יכולים ליצור סימון כפול או סותר: שם ארגון שונה, כתובת לא מעודכנת או כמה BreadcrumbList לא תואמים. פתחו עמוד מכל תבנית ובדקו את הפלט בפועל, לא רק את מסך ההגדרות. אם העסק שינה טלפון, כתובת או לוגו, עדכנו מקור מידע אחד ובחנו את כל המקומות שבהם הוא מופיע. מבנה נתונים טוב נשען על תחזוקת תוכן ולא על הדבקת קוד חד־פעמית.
ביישום מאמר בדקו כותרת, מחבר, מועד ועדכון כפי שהם מוצגים. במוצר בדקו מחיר וזמינות שמתאימים לחנות; מידע שאינו מעודכן עלול לפגוע באמון. סימון שאלות נפוצות ייבחן מול מדיניות התצוגה העדכנית של Google, שאינה מבטיחה הופעה לכל אתר. אם סוג תוצאה עשירה אינו מתאים לעמוד, אין טעם להוסיף שדות כדי ״לזכות״ בה. בחרו סימון שמסביר את המציאות, לא כזה שמבטיח קליקים.
בדיקות לאחר פרסום כוללות כלי אימות מתאים, בדיקת קוד מקור ודגימת עמודים חיים. חזרו עליהן אחרי עדכון תוסף או תבנית, משום שפלט יכול להשתנות בלי שינוי בתוכן. תעדו עבור כל תבנית מי אחראי למידע, באיזה מקום עורכים אותו ומהי בדיקת הקבלה. אם מופיעה שגיאה, בדקו אם היא משפיעה על מידע חיוני או על תכונה שאינה בשימוש לפני שמתקנים הכול בלחץ. Search Console עשוי לעזור למצוא דפוסים, אך אינו מחליף בדיקת עמוד ספציפי.
דוגמת החלטה: אתר שירותים מציג שעות פעילות, אזור שירות ודרך קשר. קודם מאמתים שהפרטים נכונים בכל העמודים; אחר כך בודקים אם סימון Organization או LocalBusiness מתאים למבנה ולזכאות של העסק. אם אין כתובת פיזית שמקבלת לקוחות, אל תמציאו אחת לצורך שדה נדרש. מידע חסר עדיף על מידע כוזב. באותו אופן, מדריך מקצועי אינו הופך למוצר רק כדי לקבל מחיר בתוצאה.
מסמך מסירה קצר יפרט סוגי סימון, כתובות לדוגמה, מקור כל שדה, כלי בדיקה ומועד אימות אחרון. כך צוות תוכן יודע איזה שינוי בעמוד דורש עדכון בסכמה. הצלחה אינה מספר סוגי הנתונים המובנים; היא עקביות בין מה שהאדם קורא, מה שהאתר משדר ומה שאפשר לתחזק באופן אמין.
בדיקת דוגמה אחרי עדכון תוסף חשובה יותר מרשימת שדות ירוקה במסך הניהול. פתחו מאמר, מוצר ועמוד שירות, השוו את JSON-LD או הסימון האחר לתוכן שמוצג, ובדקו שאין שתי גרסאות שונות של מחיר או לוגו. אם הודעת כלי בדיקה מציינת שדה מומלץ חסר, שאלו אם אפשר למלא אותו מתוך מידע אמיתי; אין להמציא ערך כדי להעלים אזהרה. תעדו שינוי כדי שעורך הבא יבין למה שדה מסוים נשאר ריק.
שאלות נפוצות: האם Schema מעלה דירוג ישירות? אין הבטחה כזאת; תפקידו לתאר מידע שעשוי לתמוך בתכונות חיפוש כאשר מתקיימים תנאים. האם צריך תוסף נוסף לכל סוג סימון? לא לפני שבודקים מה כבר נוצר. האם כדאי לסמן FAQ בכל עמוד? רק אם השאלות גלויות, מתאימות ומועילות לקורא, תוך בדיקת זכאות עדכנית. מי אחראי לעדכון? מי שמעדכן את הנתון הגלוי צריך לדעת גם היכן הוא מופיע במבנה.
רשימת בדיקות לסכמה תתחיל במה שהלקוח רואה: אם התאריך מוצג כעודכן, האם הוא משקף עריכה אמיתית? אם מוצר מסומן כזמין, האם אפשר לקנות אותו? אם עסק מציג כתובת, האם לקוחות יכולים להגיע אליה? רק אחר כך בודקים שם שדה וסוגריים בקוד. הטכניקה חשובה, אך הסיכון המרכזי הוא סתירה בין מידע ציבורי לבין מה שהקוד מספר. הבדיקה תתבצע על עמוד חי, כי מערכת מטמון או תבנית יכולה לשנות את הפלט אחרי סביבת הפיתוח.
לפני שינוי סכמה באתר גדול, בחרו תבנית אחת ובדקו בה כמה כתובות בעלות נתונים שונים. אם כל הדוגמאות נראות נכון, הרחיבו לשאר העמודים ובדקו מדגם נוסף. תהליך מדורג מקטין סיכון שעדכון אוטומטי יכניס מחיר ישן או שם מחבר לא נכון במאות דפים. שמרו דרך חזרה לגרסה הקודמת אם הפלט החי אינו תואם לבדיקה.
להמשך בדיקה: שירותי SEO לעסקים — קידום אורגני בגוגל. מקור רשמי 1
