האם Schema עוזרת לאינדוקס? מדריך מעשי לוורדפרס

האם Schema עוזרת לאינדוקס? נתונים מובנים יכולים לעזור ל־Google להבין את סוג התוכן ואת פרטי המאמר, אבל הוספת Article או NewsArticle אינה מבטיחה שהעמוד יאונדקס, ואינה מבטיחה אינדוקס מהיר או מיידי. עמוד שלא מאונדקס דורש תחילה בדיקת גישה, הוראות אינדוקס, canonical, גילוי ואיכות התוכן. מקור: תיעוד Article של Google; Google על בקשת סריקה ואי־הבטחת אינדוקס.

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

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

סריקה, אינדוקס ונתונים מובנים: שלושה דברים שונים

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

Google מציינת ש־Article עשוי לסייע בהבנת מאמר ובהצגת פרטים כגון כותרת, תמונה ותאריך. במקביל, הנחיות הנתונים המובנים מבהירות שתקינות אינה מבטיחה תצוגה עשירה. אלה יכולות תיאור ותצוגה, לא התחייבות למהירות אינדוקס. מקור: Article; הנחיות כלליות לנתונים מובנים.

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

מה לבדוק לפני שמנסים לפתור אינדוקס באמצעות Schema?

  1. גישה ותוכן: הכתובת הנכונה מחזירה עמוד אמיתי ותקין, ללא התחברות, שגיאת שרת, חסימת אבטחה או הפניה לא צפויה. בדקו גם שהתוכן החשוב זמין לרינדור ולא רק שהשרת מחזיר 200.
  2. סריקה מול noindex: בדקו גם robots.txt וגם meta robots ו־X-Robots-Tag. חסימת סריקה אינה תחליף ל־noindex; Google צריכה לסרוק את העמוד כדי לקרוא את הוראת noindex. אם העמוד אמור להתאנדקס, אל תשאירו הוראה שאוסרת זאת. מקור: Google, Block Search indexing with noindex.
  3. canonical: ודאו שהכתובת המוצהרת היא הגרסה שאתם רוצים לקדם, ושקישורים פנימיים ומפת האתר תומכים באותה גרסה. canonical הוא אות לבחירת גרסה מועדפת, לא הוראה שמבטיחה ש־Google תבחר בה. מקור: Google, canonicalization.
  4. גילוי: הוסיפו קישור פנימי ענייני מעמוד נגיש, ובדקו שהכתובת המיועדת לאינדוקס נמצאת ב־XML sitemap המתאימה. מפת אתר יכולה לסייע בגילוי, אבל אינה מבטיחה סריקה או אינדוקס. מקור: Google, Sitemaps overview.
  5. URL Inspection: בדקו ב־Search Console מה ידוע על הכתובת, מהו ה־canonical שנבחר ומה קרה בסריקה האחרונה. בדיקת Live יכולה לעזור לזהות בעיה נוכחית, אבל אינה אישור שהעמוד כבר באינדקס.
  6. ערך התוכן: אם העמוד נגיש אך לא מאונדקס, בדקו כפילות, תוכן דל והאם הוא באמת עונה על צורך מובחן. הוספת אובייקט Article אינה הופכת תוכן חסר ערך למאמר מועיל. מקור: הנחיות Google לתוכן מועיל.

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

איזו סכמה מתאימה: Article, BlogPosting או NewsArticle?

  • Article: תיאור כללי למאמר, כולל מדריך מקצועי כשהוא משקף את התוכן.
  • BlogPosting: מתאים לפוסט בבלוג.
  • NewsArticle: מתאים לתוכן חדשותי בפועל — לא לכל מדריך או עמוד רק משום שרוצים אינדוקס מהיר.

Google מתעדת את שלושת הסוגים במסגרת Article. היא גם מציינת שאין דרישת markup לצורך כשירות לתכונות Google News כגון Top stories. אין להפוך בחירת סוג Schema ל“כרטיס כניסה לחדשות”. בחרו תיאור נאמן לתוכן. מקור: הסוגים הנתמכים וההסבר על Google News.

גם FAQ אינו פתרון אינדוקס: אפשר לכתוב שאלות ותשובות שימושיות, אך Google הודיעה שתצוגת FAQ rich results הופסקה בחיפוש החל מ־7 במאי 2026. אין להסתמך על מדריכים ישנים שמבטיחים את התצוגה הזאת. מקור: יומן עדכוני Google.

איך מגדירים Schema בוורדפרס בלי ליצור כפילויות?

אין צורך להתחיל מהתקנת תוסף נוסף. תוספי SEO ותבניות עשויים כבר להפיק גרף JSON-LD. תחילה בדקו את ה־HTML הציבורי, חפשו application/ld+json וראו אילו ישויות כבר קיימות. כמה בלוקי JSON-LD אינם בהכרח בעיה; כפילויות סותרות או מזהים לא עקביים כן דורשים בדיקה.

1. ממפים את הספק הקיים ושומרים גיבוי

זהו איזה תוסף או רכיב מייצר את Article, WebPage, Person ו־Organization. תעדו את הפלט ושמרו גיבוי של ההגדרות לפני שינוי. אין בסיס לקביעה גורפת ש־Yoast “לא עובד” או שתוסף Schema אחר תמיד טוב יותר; בודקים את הפלט של האתר המסוים.

2. ממלאים זהות אמיתית

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

3. בוחרים סוג ותנאי תחולה

בחרו Article או BlogPosting לפי התוכן והמודל הקיים. החילו את הכלל רק על סוגי התוכן המתאימים, ובדקו פוסט לדוגמה וגם עמוד שלא אמור לקבל את הסכמה. באתר רב־לשוני או עם סוגי תוכן מותאמים, בחירת post בלבד אינה מכסה בהכרח את כל המאמרים.

צילום ישן של מסך Placement לבחירת סוג התוכן שעליו תחול הסכמה
צילום מהגרסה המקורית של המדריך: המחשת תנאי תחולה ב־Schema & Structured Data. שמות המסכים עשויים להשתנות; בחירת post בתמונה אינה הוראה להחיל NewsArticle על כל פוסט.

4. ממפים שדות לתוכן הגלוי

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

אלו בדיקות תוכן ויישום; אין פירושן שכל שדה הוא תנאי חובה לכל תוצאה. תיעוד Google מפרט את המאפיינים המומלצים ל־Article. מקור: Recommended properties.

5. בודקים עמוד ציבורי לפני הרחבה

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

דוגמת Article ב־JSON-LD — לקריאה, לא להדבקה עיוורת

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

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/guide/#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/guide/"
  },
  "headline": "מדריך לדוגמה בנושא מקצועי",
  "image": ["https://example.com/images/guide.jpg"],
  "datePublished": "2026-01-10T09:00:00+02:00",
  "dateModified": "2026-02-03T11:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "שם המחבר לדוגמה",
    "url": "https://example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "שם האתר לדוגמה",
    "url": "https://example.com/"
  },
  "inLanguage": "he"
}

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

מה בדיקת סכמות מוכיחה — ומה לא?

  1. פתחו את Rich Results Test של Google ובדקו URL ציבורי מייצג. בשלב פיתוח אפשר לבדוק קוד, אבל צריך לבדוק גם את העמוד המפורסם.
  2. פתחו את הפריטים שהכלי זיהה, ולא רק את הסימון הירוק. בדקו סוג, כותרת, מחבר, תאריכים, תמונה והודעות שגיאה.
  3. השוו לתוכן הגלוי ולכל גרף ה־JSON-LD. סוג Schema שאינו נתמך כתצוגה עשירה לא חייב להופיע בכלי, ולכן הכלי אינו תחליף לבדיקה של הפלט כולו.
  4. לאחר תיקון אינדוקס מהותי אפשר לבקש סריקה דרך URL Inspection כשיש הרשאה. Google מזהירה שסריקה עשויה לקחת ימים עד שבועות ושאין הבטחת הכללה באינדקס. אין כאן זמן שירות מובטח. מקור: Ask Google to recrawl your URLs.

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

צ’קליסט לפני סיום

  • העמוד נגיש, ניתן לסריקה ואין בו noindex לא מכוון.
  • ה־canonical, הקישורים הפנימיים ומפת האתר עקביים עם הכתובת המיועדת.
  • בדקתי את פלט ה־Schema הקיים לפני שהוספתי רכיב נוסף.
  • בחרתי סוג תוכן נכון; NewsArticle נשמר לתוכן חדשותי בלבד.
  • המחבר, הכותרת, התמונה והתאריכים מתאימים לתוכן הגלוי.
  • בדקתי עמוד ציבורי מייצג ואת ההפניות בכל הגרף, לא רק הודעה בתוסף.
  • לא הצגתי תקינות Schema כהוכחת אינדוקס או כהבטחה לתוצאה עשירה.

שאלות נפוצות

האם קישורים מעמודים שכבר מאונדקסים יכולים לעזור?

קישור פנימי רלוונטי מסייע לגילוי ולהבנת הקשר בין עמודים. זו סיבה טובה לקשר למאמר חדש ממדריך קשור, אבל אין קשר קסם בין “עמוד עם Schema” לבין אינדוקס היעד. Google ממליצה על קישורים פנימיים גם בהנחיות לתכונות AI. מקור: Google.

האם כדאי להשתמש ב־Indexing API למאמרים?

לא כתחליף כללי לאינדוקס פוסטים. Google מגבילה את השימוש המתועד ב־Indexing API לעמודים עם JobPosting או BroadcastEvent המשולב ב־VideoObject. למאמר רגיל משתמשים בגילוי תקין, במפת אתר וב־URL Inspection לפי הצורך. מקור: היקף השימוש ב־Indexing API.

הוספתי Schema והעמוד אונדקס למחרת. האם זה מוכיח שהיא עזרה?

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

השורה התחתונה: השתמשו ב־Schema כדי לתאר נכון תוכן טוב. השתמשו באבחון אינדוקס כדי לפתור בעיית אינדוקס. אלה פעולות משלימות — לא הבטחת “אינדוקס מיידי”.