אם אתם בעלי עסק, פרילנסרים או יועצים, כנראה שאתם מכירים את ההתלבטות: האם למתג את עצמכם כארגון או להדגיש את המומחיות האישית שלכם? בעולם שבו גוגל ומנועי AI כמו Perplexity ו-ChatGPT מנתחים אתרים כדי לספק תשובות ישירות, לשאלה הזאת יש תשובה טכנית מדויקת שמשפיעה ישירות על אותות E-E-A-T, על זיהוי הישות שלכם ועל הנראות בתוצאות. במדריך זה נסביר בדיוק למי מתאימה כל סכמה, כיצד להימנע מטעויות נפוצות, ואף נראה מקרים מתקדמים שבהם שילוב נכון בין שתיהן יוצר יתרון תחרותי משמעותי.

הכתבה פורסמה ע"י רעות ברקוביץ, בתאריך 06/05/2026.   עדכון אחרון: 06/05/2026.

למי מתאימה סכמת Person ולמי סכמת Organization באתר

כשהאתר מייצג עסק, מותג או חברה, הבחירה הנכונה היא Organization. כשמדובר בעמוד שמציג מומחה, יועץ או יוצר תוכן הפועל תחת שמו האישי, הסימון המתאים הוא Person. ואם יש גם עסק וגם פנים אנושיות מאחוריו, משלבים בין השתיים ומחברים ביניהן באמצעות JSON-LD. מניסיון של מעל 15 שנה בקידום אתרים לשוק הישראלי, הבהירות הזו מול גוגל ישראל היא שמפרידה בין אתר שנתפס כישות עסקית אמיתית לבין אתר שנשאר עמום.

איך מחליטים לפי מטרת העמוד

הישות היא הדרך שבה גוגל וכלי AI מזהים מי או מה עומד מאחורי האתר. כמו שבאנשי הקשר בטלפון יש הבדל בין "דנה לוי" לבין "קליניקת דנה", גם מנועי החיפוש צריכים להבין אם מדובר באדם פרטי או בארגון. דף הבית של משרד עורכי דין, מרפאה או סוכנות דיגיטל יסומן כמעט תמיד כ-Organization, בעוד שדף אודות של יועצ/ת או מאמנ/ת יסומן כ-Person.

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

ההבדל בין שני סוגי השדות

במבט על השדות המרכזיים, ניתן לראות את ההבחנה בצורה הכי ברורה: Organization מתמקדת בזהות מסחרית דרך name, logo, url, sameAs, contactPoint ו-foundingDate. Person מתמקדת בזהות אנושית באמצעות name, jobTitle, worksFor, knowsAbout ו-image. העיקרון שמנחה אותנו הוא שקיפות, וסכמה היא בדיוק הכלי שמייצר שקיפות מול גוגל.

סוג הסכמה איפה בדרך כלל שמים באתר שדות מומלצים כמינימום
Organization דף הבית, דף צור קשר, פוטר name, url, logo, sameAs
Person דף אודות, דף מחבר/ת, עמוד פרופיל name, jobTitle, image, knowsAbout

מה עושים כשיש רק אדם אחד בעסק

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

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

איזו סוג סכמה לבחור

אילו טעויות נפוצות בסימון סכמה פוגעות בנראות במנועי AI

הטעויות הכואבות ביותר הן שדות חובה חסרים, סוג ישות שגוי, וסימון מידע שלא מופיע בפועל בעמוד. אלו בדיוק הכאבים שזיהינו בשוק, אשר הובילו אותנו לבנות תהליכי סריקה שמזהים את הבעיות הללו מראש. מבדיקות שעורכים באופן שוטף, יותר מ-40 אחוז מכשלי הסכמה מתחילים בשדות בסיסיים חסרים כמו name, url או logo.

שדות חסרים וסוג ישות שגוי

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

כדי לעזור להימנע מראש מהטעויות הכי כואבות, ריכזנו את צ'קליסט הבדיקה שמיישמים בכל סקירת אתר:

  • חסרים name, logo או url ב-Organization
  • חסרים jobTitle או worksFor ב-Person
  • הסכמה לא תואמת את התוכן הגלוי בעמוד
  • קוד JSON-LD עם תחביר שבור
  • אין קישור בין ישויות באמצעות @id
  • המטמון לא נוקה אחרי שינוי

JSON-LD שבור וכפילויות בין תוספים

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

איך מאמתים ומתקנים מהר

אצלנו חשוב להקפיד על בדיקה מיידית אחרי כל שינוי בסכמה - כך מוודאים שהכל עובד כמו שצריך. רצוי להריץ שני כלים משלימים: Google Rich Results Test שבודק אם גוגל מצליחה לקרוא את הסימון ואם יש סיכוי להופעה בתוצאות עשירות, ולצידו Schema Markup Validator שבודק אם הקוד בנוי נכון לפי התקן של Schema.org. התהליך המלא, כולל ניקוי מטמון ובדיקה בקוד המקור, לוקח בין 10 ל-15 דקות.

ההבדל בין 2 הסכמות

איך מיישמים ומחברים בין שתי הסכמות ב-JSON-LD

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

המבנה המומלץ לרוב האתרים

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

דוגמת קוד עם הסברים בעברית

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

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.co.il/#organization",
      "name": "סטודיו לוי שיווק דיגיטלי",
      "url": "https://example.co.il/",
      "logo": "https://example.co.il/logo.webp",
      "foundingDate": "2021",
      "sameAs": [
        "https://www.linkedin.com/company/studio-levy",
        "https://www.facebook.com/studiolevy"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.co.il/about/#person",
      "name": "נחמה לוי",
      "jobTitle": "יועצת קידום אורגני",
      "image": "https://example.co.il/nech.webp",
      "knowsAbout": ["SEO", "GEO", "Schema.org"],
      "worksFor": { "@id": "https://example.co.il/#organization" }
    }
  ]
}

 

פענוח מהיר של השדות המרכזיים: name הוא שם העסק או האדם כפי שמוצג באתר. sameAs מחבר את האתר לפרופילים הרשמיים ברשתות חברתיות ומאחד את הזהות הדיגיטלית. worksFor מקשר את האדם לעסק דרך ה-@id של הארגון. @id עצמו הוא מזהה קבוע שמאפשר לגוגל להבין שמדובר באותה ישות לאורך כל האתר.

מסלול החלטה בשלוש שאלות

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

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