5 טעויות Schema שהורסות לכם את ה-GEO (ואיך graph@ פותר את זה)

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

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

הגדרה · Schema @graph

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

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

טעות 1: פיזור בלוקים מנותקים של JSON-LD בעמוד

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

התוצאה? שלושה בלוקים נפרדים בקוד script.

עבור Perplexity או Claude, אלה שלוש ישויות שונות לגמרי. אין שום סמן שמסביר שבעל המאמר הוא גם בעל העסק שיושב ברחוב אבן גבירול בתל אביב.

איך מתקנים?

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

טעות 2: היעדר שימוש במזהים ייחודיים (id@)

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

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

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://justbettersite.com/#organization",
      "name": "ג'סט בטר"
    },
    {
      "@type": "WebSite",
      "@id": "https://justbettersite.com/#website",
      "publisher": {"@id": "https://justbettersite.com/#organization"}
    }
  ]
}

ראו כמה זה פשוט. הקשר נקבע בשורה אחת.

💡

מנועי AI לא מנחשים. אם לא קישרתם בין השירות לבעלים דרך id@ מפורש, הקשר הזה לא קיים עבורם.

טעות 3: סתירות בנתוני NAP (שם, כתובת, טלפון)

שיניתם כתובת? עברתם ממתחם שרונה לרוטשילד?

אם בעמוד ה-Google Business Profile כתובה כתובת אחת, ב-Footer של האתר כתובה כתובת שנייה, ובקוד הסכמה נשארה הכתובת הישנה — יש לכם סתירה.

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

טעות 4: התעלמות מהשדה sameAs

איך Claude יודע שאדיר בן יעקב שכתב את המאמר הזה הוא אותו אדיר בן יעקב שמנהל סוכנות דיגיטל?

התשובה היא השדה sameAs.

השדה הזה מקשר את הישות שלכם לפרופילים חיצוניים סמכותיים: פרופיל LinkedIn, ערוץ YouTube, ערך בוויקיפדיה או דף ה-Google Maps שלכם. בלעדיו, אתם פשוט עוד מחרוזת טקסט אקראית ברשת.

• קשרו את פרופיל ה-LinkedIn של המייסדים בתוך סכמת Person
• הוסיפו את דף העסק ב-Google Maps לתוך סכמת LocalBusiness
• אל תוסיפו קישורים לרשתות חברתיות לא פעילות

טעות 5: העמסת נתונים מיותרים בטקסט חופשי

ניסיון להכניס מילות מפתח לתוך שדות ה-description של הסכמה קורה הרבה. אנשים חושבים שאם הם ידחפו 20 מילות מפתח לתוך ה-JSON-LD, ה-AI יאהב את זה.

זה משיג את התוצאה ההפוכה.

נתונים מובנים מיועדים לעובדות יבשות. תיאור העסק ב-Schema צריך להיות חד, מדויק ונקי מסיסמאות שיווקיות. תאירו את המציאות, אל תמציאו אותה.

השורה התחתונה

ב-2026, הבניית נתונים היא לא פריווילגיה או תוספת נחמדה ל-SEO. היא התשתית הבלעדית שמאפשרת למנועי תשובות להבין מי אתם.

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