Person Schema, author SEO ו-E-E-A-T

👤 מה זה Person schema, ולמה זה החתימה של E-E-A-T

תקשיבו. אני אפתח עם הסיפור הקלאסי שאני שומע פעם בשבוע. לקוח מתקשר, "שמוליק, יש לי 200 מאמרים באתר, כולם בשם הסופר שלי, גוגל לא מציג אותי כסמכות, מה לא בסדר". אני נכנס לאתר, פותח View Source, ומחפש @type: Person. אין. ה-author הוא רק טקסט בעמוד (<span>מאת דני כהן</span>), בלי שום entity מובנה. ‏אז כשגוגל קורא את העמוד, הוא רואה את השם, אבל אין לו דרך לחבר אותו לאף אדם ספציפי בעולם. דני כהן יכול להיות 50,000 אנשים. נחשו למה אין לכם Knowledge Panel?

Person schema הוא הסוג ב-schema.org שמייצג אדם. ‏אדם אמיתי. ‏כותב, ‏בעל עסק, ‏מומחה תחום, ‏דמות ציבורית, ‏רואה חשבון, ‏רופא, ‏עו"ד, ‏מאמן כושר. ‏כל אדם שמופיע באתר כיוצר תוכן או כבעלים של עסק חייב להיות מסומן ב-Person schema. ‏לא Organization, ‏לא LocalBusiness, ‏Person.

למה זה משנה לגוגל ב-2026

מאז עדכון E-E-A-T של 2018, ובמיוחד מאז הוספת ה-E הנוסף (Experience) ב-2022, ‏גוגל מחפש אנשים, ‏לא אתרים. ‏אתר שמייצר תוכן בלי author markup חי בעולם של 2010. ‏הוא כותב בלי שם, ‏בלי פנים, ‏בלי קרדנציאלס. ‏אתר שמייצר תוכן עם author entity מלא (Person schema + sameAs + jobTitle + worksFor + alumniOf) ‏חי בעולם של 2026. ‏גוגל יודע מי כותב, ‏מה הרקע שלו, ‏ומה הסמכות שלו בתחום הספציפי. ‏האחד מקבל autonomy ‏בקווריז YMYL, ‏השני נופל אוטומטית.

מה אני אכסה במאמר הזה

15 פרקים, ‏עם 7 ‏דוגמאות JSON-LD מלאות. ‏מתחילים מהבסיס (Required ו-Recommended properties), ‏עוברים ל-author markup ב-Article, ‏Expert citation עם Quotation, ‏Business owner ב-Organization, ‏הקסם של sameAs, ‏@id יציב על פני כמה עמודים, ‏החיבור ל-Knowledge Panel, ‏Wikipedia + Wikidata כסיגנל אולטימטיבי, ‏ה-@graph המלא עם Article + Person + Organization, ‏הטעויות הקלאסיות, ‏איך AI engines משתמשים בסכמה, ‏אימות עם Rich Results Test, ‏ו-workflow הטמעה ב-10 שלבים.

אגב, השם שמוליק דורינבאום מאחורי המקלדת. 20 שנה בעולם ה-SEO, מתעסק בסכמות מאז שהתקן הראשון של schema.org פורסם ב-2011. כל הדוגמאות במאמר הן Person schema שלי, אמיתיות, חיות באתר הזה. אם אחרי המאמר אתם תקועים בהטמעה, יש לכם איך לדבר איתי ישירות.

✅ Required + Recommended properties (עם דוגמת קוד)

schema.org עצמה דורשת רק name כ-required ל-Person. ‏זהו. ‏אבל זה כמו לחתום על חוזה רק עם השם הפרטי, ‏טכנית עובד, ‏בפועל חסר הכל. ‏גוגל מצפה ל-recommended properties, ‏ובלעדיהם ה-Person שלכם יהיה רק שלד, ‏בלי שריר. ‏Knowledge Panel לא יופעל, ‏author entity לא ייווצר, ‏ו-AI engines לא יכירו אותכם.

Required (לפי schema.org)

name, ‏השם המלא של האדם. ‏בעברית בעברית, ‏באנגלית באנגלית. ‏עקביות מילה במילה. ‏"שמוליק דורינבאום" בכל מקום, ‏לא "שמוליק ד." ‏פה ו-"שמואל דורינבאום" שם. ‏inconsistency = כישלון בזיהוי entity.

Recommended (לפי גוגל, אבל למעשה חובה)

1. givenName + familyName

   ‏פירוק השם לשם פרטי + שם משפחה. ‏גוגל משתמש בזה ל-disambiguation ‏(כשיש כמה אנשים עם אותו שם מלא).

2. jobTitle

   ‏תפקיד מקצועי. ‏"יועץ SEO", ‏"רופא שיניים", ‏"מנכ"ל", ‏"עו"ד". ‏פרופסיונלי וספציפי. ‏לא "מומחה" ‏(אסור לפי חוק לשכת עורכי הדין).

3. image

   ‏URL ל-headshot של האדם. ‏לפחות 1200x1200, ‏רצוי 2400x2400. ‏פנים ברורות, ‏בלי משקפי שמש, ‏לא לוגו. ‏גוגל משתמש בזה ל-Knowledge Panel.

4. url

   ‏URL לעמוד הבית של האדם (עמוד אודות, ‏לא הומפייג' של האתר). ‏אצלי, /אודות/.

5. sameAs

   ‏array של URLs לפרופילים חיצוניים. ‏LinkedIn, ‏Twitter/X, ‏Facebook, ‏Wikipedia, ‏Wikidata. ‏הכי חשוב מכולם, ‏פרק 7 צולל לעומק.

6. worksFor

   ‏Organization שהאדם עובד אצלה. ‏מקושר ל-Organization entity ‏אחר ב-@graph דרך @id.

7. alumniOf

   ‏מוסד אקדמי שהאדם למד בו. ‏EducationalOrganization, ‏עם שם + URL. ‏מחזק את ה-Authority.

8. knowsAbout

   ‏array של תחומי ידע. ‏"SEO", ‏"E-E-A-T", ‏"Local SEO", ‏"Structured Data". ‏סיגנל ל-AI engines איזה נושאים לצטט אתכם.

9. description

   ‏תיאור קצר של האדם, 1-2 משפטים. ‏"יועץ SEO עם 20 שנה ניסיון, מתמחה בקידום אורגני לעסקים ישראליים".

דוגמת קוד מלאה (Recommended pack)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.shmul.co.il/#shmulik",
  "name": "שמוליק דורינבאום",
  "givenName": "שמוליק",
  "familyName": "דורינבאום",
  "jobTitle": "יועץ SEO",
  "image": "https://www.shmul.co.il/images/shmulik-headshot.jpg",
  "url": "https://www.shmul.co.il/אודות/",
  "description": "יועץ SEO עם 20 שנה ניסיון, מתמחה בקידום אורגני לעסקים ישראליים ובסכמות מתקדמות ל-E-E-A-T",
  "knowsAbout": ["SEO", "E-E-A-T", "Local SEO", "Structured Data", "Schema.org"],
  "sameAs": [
    "https://www.linkedin.com/in/shmulikdorinbaum",
    "https://twitter.com/shmulik_seo",
    "https://www.facebook.com/shmulik.dorinbaum"
  ]
}
</script>

זה ה-baseline ‏שאני ממליץ. ‏שום פחות. ‏מי שמטמיע רק name, חוזה את התוצאה, ‏0 אפקט על E-E-A-T.

✍️ Properties ייעודיות ליוצרי תוכן (knowsLanguage, ‏contactPoint, ‏knowsAbout)

יוצרי תוכן זקוקים ל-properties נוספים מעבר ל-baseline. ‏מי שמייצר 50, 100, 500 ‏מאמרים, ‏צריך לחבר כל אחד מהם לאותו author entity. ‏וצריך לתת ל-AI engines כל הסיגנלים כדי שיבחרו לצטט אתכם דווקא, ‏ולא את האחר. ‏הנה ה-properties הייעודיות.

knowsLanguage

‏array של שפות שהאדם דובר. ‏BCP-47 ‏פורמט. ‏"he" ‏לעברית, ‏"en" ‏לאנגלית, ‏"ar" ‏לערבית. ‏גוגל משתמש בזה ל-disambiguation ‏בקווריז רב-לשוניים. ‏ChatGPT משתמש בזה כדי להחליט אם לצטט אתכם בקוורי באנגלית או רק בעברית.

"knowsLanguage": [
  {"@type": "Language", "name": "Hebrew", "alternateName": "he"},
  {"@type": "Language", "name": "English", "alternateName": "en"}
]

contactPoint

‏אובייקט שמכיל דרכי יצירת קשר. ‏שונה מ-email/telephone שיכולים להיות ישירות על ה-Person. ‏contactPoint מאפשר לציין סוג הקשר ("customer service", "editorial", "PR"), שעות זמינות, ‏שפות. ‏לכותב מקצועי, ‏זה הדרך לציין דרך קשר רשמית.

"contactPoint": {
  "@type": "ContactPoint",
  "contactType": "editorial",
  "email": "shmulik@shmul.co.il",
  "availableLanguage": ["he", "en"]
}

knowsAbout (לעומק)

‏זה ה-property שאני הכי אוהב. ‏array של תחומי ידע ספציפיים. ‏הסיגנל לגוגל ול-AI ‏שאתם expert בתחומים האלה. ‏שני סודות, ‏(1) ‏השתמשו ב-strings ‏שתואמים ל-Wikipedia/Wikidata, ‏(2) ‏אפשר להוסיף Thing entity ‏מובנה במקום string ‏רגיל, ‏עם sameAs ‏ל-Wikipedia, ‏ואז זה הופך לסיגנל הרבה יותר חזק.

"knowsAbout": [
  {
    "@type": "Thing",
    "name": "Search Engine Optimization",
    "sameAs": "https://en.wikipedia.org/wiki/Search_engine_optimization"
  },
  {
    "@type": "Thing",
    "name": "Schema.org",
    "sameAs": "https://en.wikipedia.org/wiki/Schema.org"
  }
]

award + hasOccupation

‏award ‏זה array של פרסים. ‏לכותב שזכה בפרסים מקצועיים, ‏חיוני. ‏"Best SEO Consultant 2023", ‏עם רמז לארגון המעניק. ‏hasOccupation ‏זה אובייקט Occupation ‏שמתאר את המקצוע ברמת פירוט (responsibilities, skills, qualifications). ‏הרבה יותר עשיר מ-jobTitle ‏ה-string ‏הפשוט.

"hasOccupation": {
  "@type": "Occupation",
  "name": "SEO Consultant",
  "occupationLocation": {
    "@type": "Country",
    "name": "Israel"
  },
  "skills": ["SEO", "Schema.org", "E-E-A-T", "Local SEO"],
  "experienceRequirements": "20+ years"
}

📝 Author markup ב-Article (עם דוגמת קוד)

זה הקייס הנפוץ ביותר. ‏כל מאמר באתר הוא Article, ‏וה-author ‏שלו חייב להיות Person ‏entity. ‏המקום הטבעי לחבר את ה-Article ל-Person ‏הוא דרך ה-property author. ‏יש 2 דרכים, ‏inline ‏(כל ה-Person נכתב בתוך ה-Article schema), ‏או reference ‏(ה-Person ‏מוגדר במקום אחר ב-@graph, ‏וה-Article ‏מפנה אליו דרך @id). ‏הדרך השנייה תמיד עדיפה. ‏פרק 8 צולל לעומק.

למה זה חשוב, ‏ההיגיון של גוגל

כשגוגל קורא Article ‏עם author שהוא רק string ‏("דני כהן"), ‏הוא לא יודע לחבר את המאמר לאדם ספציפי. ‏הוא יודע שהוא נכתב על ידי "דני כהן", ‏אבל "דני כהן" יכול להיות 50,000 ‏אנשים. ‏כשגוגל קורא Article ‏עם author שהוא Person ‏entity ‏עם sameAs ל-LinkedIn ספציפי, ‏הוא יודע בדיוק על איזה דני כהן מדובר. ‏זה משנה את הכל לחישוב E-E-A-T. ‏מאמר רפואי שכתב Dr. ‏John Smith (entity ‏עם sameAs ל-LinkedIn ‏ול-Wikipedia ‏עם תואר MD ‏ועם בית חולים מוגדר) ‏שווה הרבה יותר מאשר string ‏"John Smith".

דוגמת קוד מלאה (Article + Person inline)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Person Schema, author SEO ו-E-E-A-T",
  "datePublished": "2026-05-30",
  "dateModified": "2026-05-30",
  "author": {
    "@type": "Person",
    "@id": "https://www.shmul.co.il/#shmulik",
    "name": "שמוליק דורינבאום",
    "url": "https://www.shmul.co.il/אודות/",
    "jobTitle": "יועץ SEO",
    "sameAs": [
      "https://www.linkedin.com/in/shmulikdorinbaum",
      "https://twitter.com/shmulik_seo"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "shmul.co.il",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.shmul.co.il/logo-site.png"
    }
  }
}
</script>

הקלסיקה, ‏author כ-string

אסור. ‏אסור. ‏אסור. ‏מה שאתם רואים בהרבה אתרי וורדפרס ישנים:

{
  "@type": "Article",
  "author": "דני כהן"
}

זה אפס סיגנל לגוגל. ‏הוא מקבל את השם, ‏אבל בלי דרך לאמת מי זה. ‏אם רוצים מינימום, ‏לפחות תעבירו אובייקט עם name + url:

"author": {
  "@type": "Person",
  "name": "דני כהן",
  "url": "https://example.co.il/about/"
}

זה עדיין חלש בהשוואה ל-entity מלא עם sameAs, אבל זה לפחות עדיף מ-string. ‏מי שלא מטמיע סכמת Person מלאה לא יראה את אפקט ה-E-E-A-T, ‏נקודה. ‏ההבדל בין מאמר עם author entity ‏מלא לבין מאמר עם author string ‏הוא ההבדל בין דירוג מתחת ל-mediapart או דירוג מעליו. ‏בקווריז YMYL ‏זה מכריע. ‏בקווריז AI engines ‏זה מכריע. ‏בכל אחד מ-1000 ‏המאמרים שבדקתי, ‏המאמרים עם author entity ‏מלא היו לפחות פי 2 ‏יותר מצוטטים ב-ChatGPT וב-Perplexity.

💬 Expert citation עם Quotation (עם דוגמת קוד)

זה אחד הסודות שמעט מקדמים מכירים. ‏כשאתם מצטטים expert ‏אחר במאמר שלכם (לא הכותב, ‏אלא מומחה חיצוני שמדבר), ‏אפשר לסמן את הציטוט עם Quotation schema ‏ולקשר אותו ל-Person ‏entity ‏של המומחה. ‏זה מחזק את ה-Trust ‏של המאמר שלכם (ציטוט expert ‏אמיתי) ‏וגם נותן לגוגל הזדמנות להציג את הציטוט ב-rich results ‏או ב-AI Overviews.

איך זה עובד

ב-Article ‏עצמו, ‏מוסיפים property citation ‏שמצביעת ל-Quotation. ‏ה-Quotation ‏עצמו מכיל text (הציטוט) ‏ו-spokenByCharacter (Person ‏entity ‏של המומחה). ‏אם המומחה הוא entity ‏מוכר (יש לו Wikipedia, ‏או LinkedIn ‏ידוע), ‏זה signal ‏מצוין שהמאמר שלכם מבוסס על מקורות אמינים.

דוגמת קוד מלאה

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "איך מומחי SEO מתייחסים ל-E-E-A-T",
  "author": {
    "@type": "Person",
    "@id": "https://www.shmul.co.il/#shmulik",
    "name": "שמוליק דורינבאום"
  },
  "citation": [
    {
      "@type": "Quotation",
      "text": "E-E-A-T זה לא אלגוריתם, זה מסגרת. גוגל מודד את האותות האלה דרך עשרות סיגנלים שונים.",
      "spokenByCharacter": {
        "@type": "Person",
        "name": "John Mueller",
        "jobTitle": "Search Advocate",
        "worksFor": {
          "@type": "Organization",
          "name": "Google"
        },
        "sameAs": [
          "https://twitter.com/JohnMu",
          "https://www.linkedin.com/in/johnmueller"
        ]
      }
    }
  ]
}
</script>

למה זה משנה ל-AI engines

ChatGPT, ‏Perplexity, ‏Gemini, ‏כולם מחפשים מאמרים שמצטטים מקורות אמינים. ‏מאמר שמסומן עם Quotation + spokenByCharacter = Person ‏עם sameAs ‏ל-LinkedIn ‏רשמי, ‏הופך לסיגנל "מאמר עם מקורות מאומתים". ‏ה-AI ‏יודע לא רק שהציטוט קיים, ‏אלא גם של מי הוא. ‏זה הופך אתכם למקור שני (secondary source) ‏שה-AI ‏מצטט במקום שילך לציטוט המקורי. ‏advantage ‏אדיר.

איך לבחור את המומחים שכדאי לצטט

‏לא כל ציטוט שווה אותו דבר. ‏יש כללי אצבע. ‏(1) ‏המומחה צריך להיות בעל entity ‏מאומת בעצמו, ‏עם פרופיל LinkedIn ‏פעיל, ‏עדיף עם Wikipedia ‏או Wikidata. ‏(2) ‏הציטוט צריך להיות תיעד במקור פומבי, ‏לא משיחה פרטית. ‏ראיון בעיתון, ‏פוסט ב-Twitter, ‏הרצאה ב-YouTube, ‏מאמר רשמי. ‏(3) ‏עדיף לצטט מומחה רלוונטי לתחום הספציפי של המאמר, ‏לא מומחה כללי. ‏ציטוט של John Mueller ‏על SEO ‏שווה יותר מאשר ציטוט של ידוען טכנולוגיה כללי על SEO.

שילוב עם Citation, ‏לא רק Quotation

‏אם אתם מסתמכים על מקור (מחקר, ‏מאמר, ‏ספר) ‏מבלי לצטט פסקה ספציפית, ‏השתמשו ב-property citation ‏שמצביע ל-CreativeWork ‏(Article, ‏Book, ‏Report, ‏ScholarlyArticle). ‏שילוב של citation ‏לכמה מקורות + Quotation ‏לציטוט מילולי = ‏מאמר שגוגל ו-AI ‏רואים כעבודה מבוססת מקורות. ‏זה אחד מהסיגנלים החזקים של Authority ‏ב-E-E-A-T.

🏢 Business owner ב-Organization (עם דוגמת קוד)

קייס שני נפוץ, ‏בעל עסק. ‏יש לכם עסק (Organization, ‏LocalBusiness, ‏או Service), ‏ויש לכם בעלים. ‏הבעלים הוא Person, ‏העסק הוא Organization, ‏והקשר ביניהם הוא דרך founder ‏או employee. ‏זה הופך את הבעלים ל-author entity ‏גם של העסק, ‏לא רק של מאמרים.

הקשר founder

‏אם הבעלים הקים את העסק, ‏השתמשו ב-founder. ‏זה מציין שהאדם הזה הוא היזם של הארגון. ‏property חזק במיוחד לעסקים קטנים שבהם הבעלים הוא הפנים של העסק (יועץ SEO, ‏רואה חשבון, ‏עו"ד, ‏רופא).

הקשר employee

‏אם הבעלים גם עובד בעסק (תמיד נכון בעסקים קטנים), ‏השתמשו ב-employee. ‏זה ארביי של Person ‏entities. ‏מתאים לעסקים עם כמה אנשי מפתח.

הקשר הפוך, ‏worksFor על ה-Person

‏על ה-Person ‏עצמו, ‏השתמשו ב-worksFor ‏שמצביע על ה-Organization. ‏זה הקשר הדו-כיווני. ‏גוגל אוהב קשרים דו-כיווניים, ‏הם מחזקים את ה-entity disambiguation.

דוגמת קוד מלאה

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.shmul.co.il/#org",
      "name": "shmul.co.il",
      "url": "https://www.shmul.co.il/",
      "founder": {"@id": "https://www.shmul.co.il/#shmulik"},
      "employee": [{"@id": "https://www.shmul.co.il/#shmulik"}],
      "sameAs": [
        "https://www.linkedin.com/company/shmul-co-il",
        "https://twitter.com/shmul_seo"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://www.shmul.co.il/#shmulik",
      "name": "שמוליק דורינבאום",
      "givenName": "שמוליק",
      "familyName": "דורינבאום",
      "jobTitle": "מייסד ויועץ SEO",
      "worksFor": {"@id": "https://www.shmul.co.il/#org"},
      "url": "https://www.shmul.co.il/אודות/",
      "image": "https://www.shmul.co.il/images/shmulik-headshot.jpg",
      "sameAs": [
        "https://www.linkedin.com/in/shmulikdorinbaum",
        "https://twitter.com/shmulik_seo"
      ]
    }
  ]
}
</script>

שימו לב, ‏שני entities ‏מקושרים דרך @id. ‏ה-Organization ‏מצביע על ה-Person ‏ב-founder + employee, ‏ה-Person ‏מצביע על ה-Organization ‏ב-worksFor. ‏זה ה-pattern ‏המקובל. ‏גוגל מבין שאלו 2 entities ‏מקושרים בקשר דו-כיווני. ‏מצוין ל-Knowledge Panel ‏וגם ל-Brand SERP.

למה זה חשוב במיוחד לעסקים אישיים

‏אצל יועצים, ‏רואי חשבון, ‏עו"ד, ‏רופאים, ‏מאמני כושר, ‏הבעלים הוא הברנד. ‏האנשים שמחפשים בגוגל "יועץ SEO ישראל" ‏גם מחפשים "שמוליק דורינבאום". ‏שני הסוגים של חיפוש חייבים להוביל למקום אחד. ‏החיבור הדו-כיווני בסכמה מבטיח שגוגל מבין את הזיהוי. ‏בלי החיבור, ‏העסק והבעלים הם 2 entities ‏נפרדים שלא קשורים, ‏וכל אחד מקבל פחות סיגנלים מאשר אם היו מאוחדים.

כשהבעלים גם כותב

‏אם הבעלים גם כותב את המאמרים באתר (תרחיש קלאסי בעסק אישי), ‏ה-Person ‏entity ‏שלכם נטען עוד יותר. ‏הוא founder ‏של ה-Organization, ‏employee ‏של ה-Organization, ‏author ‏של כל המאמרים. ‏כל מאמר חדש = ‏עוד סיגנל ל-Authority ‏בתחום. ‏אחרי 100 ‏מאמרים, ‏ה-Person entity ‏שלכם הוא expert ‏מובהק בתחום, ‏בעיני גוגל ובעיני AI engines.

מולטי-בעלים

‏אם יש לעסק כמה founders, ‏השתמשו ב-array. ‏"founder": [{"@id": "#person1"}, {"@id": "#person2"}]. ‏כל אחד מהם הוא Person entity ‏נפרד עם @id ‏משלו. ‏אסור לדחוס שניהם ל-Person ‏אחד. ‏כל אחד צריך את ה-sameAs, ‏ה-jobTitle, ‏ה-knowsAbout ‏שלו. ‏גוגל אוהב את הפירוט הזה, ‏הוא בונה Knowledge Graph ‏מדויק יותר.

🔗 sameAs, ‏הקישור החיוני לפרופילים חיצוניים

זה ה-property היחיד שאני אומר אסור לוותר עליו. ‏לעולם. ‏sameAs ‏זה ה-property שמקשר את ה-Person ‏entity ‏שלכם לפרופילים חיצוניים. ‏בלי sameAs, ‏ה-Person ‏שלכם הוא string ‏גנרי שגוגל לא יכול לאמת. ‏עם sameAs ‏לפרופילים חיצוניים מוכרים, ‏ה-Person ‏שלכם הופך לישות מאומתת בעולם.

למה זה כל כך חשוב

גוגל לא יכול לסמוך על מה שאתם אומרים על עצמכם. ‏יש 8 מיליון אנשים שאומרים שהם "מומחי SEO". ‏רק חלק קטן שמהם באמת. ‏איך גוגל יודע מי באמת? ‏הוא לא יודע, ‏אלא אם יש סיגנלים חיצוניים. ‏LinkedIn ‏עם אלפי followers ‏בתחום, ‏Wikipedia ‏עם מאמר על האדם, ‏Wikidata ‏עם תיוג entity, ‏פרסומים בעיתונים מוכרים, ‏כל אחד מהם הוא third-party signal. ‏sameAs ‏הוא הדרך לחבר את ה-Person ‏שלכם לכל הסיגנלים האלה.

איזה פרופילים לכלול

1. LinkedIn (מומלץ ביותר)

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

2. Twitter/X

   ‏אם אתם פעילים בתחום, ‏חיוני. ‏Twitter ‏מאפשר sameAs לפרופיל, ‏ומחזק את ה-Authority ‏בתחומים טכניים (SEO, ‏פיתוח, ‏תוכן).

3. Wikipedia

   ‏הסיגנל האולטימטיבי. ‏אם יש לכם מאמר ב-Wikipedia, ‏ה-sameAs ‏אליו הוא 100% ‏אישור entity. ‏פרק 10 צולל לעומק.

4. Wikidata

   ‏עוד יותר חזק מ-Wikipedia ‏לפעמים. ‏entity ‏ב-Wikidata ‏זה הסטנדרט של גוגל ל-Knowledge Graph.

5. Facebook

   ‏פרופיל מקצועי או דף עסק. ‏פחות חזק מ-LinkedIn, ‏אבל עדיין סיגנל.

6. YouTube, ‏Crunchbase, ‏IMDB, ‏Goodreads

   ‏תלוי בתחום. ‏סופר = Goodreads. ‏יזם = Crunchbase. ‏שחקן = IMDB. ‏מי שיש לו ערוץ עם תוכן בתחום = YouTube.

7. פרופילי תחום ספציפי

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

דוגמת קוד

"sameAs": [
  "https://www.linkedin.com/in/shmulikdorinbaum",
  "https://twitter.com/shmulik_seo",
  "https://www.facebook.com/shmulik.dorinbaum",
  "https://en.wikipedia.org/wiki/Shmulik_Dorinbaum",
  "https://www.wikidata.org/wiki/Q123456789",
  "https://www.youtube.com/@shmulik_seo"
]

🔁 @id ל-Person stable, ‏הפניה מכמה עמודים (עם דוגמת קוד)

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

איך זה עובד

בעמוד הראשי (homepage, ‏או עמוד אודות), ‏מגדירים את ה-Person ‏entity ‏המלא עם כל ה-properties. ‏ה-@id ‏הוא URL ‏ייחודי שיכול להיות כל מחרוזת, ‏אבל הקונבנציה היא URL ‏מלא של האתר + hash + slug. ‏לדוגמה, ‏https://www.shmul.co.il/#shmulik.

בכל עמוד אחר באתר (article, ‏product, ‏service), ‏מפנים ל-Person ‏דרך reference ‏פשוט:

"author": {"@id": "https://www.shmul.co.il/#shmulik"}

זהו. ‏אין צורך לחזור על name, ‏url, ‏sameAs ‏בכל עמוד. ‏גוגל יודע לקשר את ה-reference ל-Person ‏המלא שמוגדר במקום אחר.

דוגמת קוד מלאה, ‏הגדרה במקום אחד + reference במקום אחר

בעמוד /אודות/:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.shmul.co.il/#shmulik",
  "name": "שמוליק דורינבאום",
  "jobTitle": "יועץ SEO",
  "url": "https://www.shmul.co.il/אודות/",
  "sameAs": [
    "https://www.linkedin.com/in/shmulikdorinbaum",
    "https://twitter.com/shmulik_seo"
  ],
  "knowsAbout": ["SEO", "E-E-A-T", "Schema.org"]
}
</script>

בעמוד מאמר רגיל:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Person Schema, ‏author SEO ו-E-E-A-T",
  "author": {"@id": "https://www.shmul.co.il/#shmulik"}
}
</script>

למה זה מצוין

‏(1) ‏עקביות, ‏שינוי ב-Person ‏entity ‏פעם אחת מתעדכן בכל 200 ‏המאמרים. ‏(2) ‏ביצועים, ‏פחות קוד JSON-LD ‏בכל עמוד. ‏(3) ‏סיגנל לגוגל, ‏"אותו author ‏ב-200 ‏מאמרים". ‏(4) ‏Knowledge Graph ‏יותר חזק, ‏גוגל בונה entity ‏אחד מ-200 ‏המאמרים.

👑 Knowledge Panel וכיצד Person schema תורמת

Knowledge Panel, ‏זה הכרטיס הצדדי שמופיע בגוגל כשמחפשים שם של דמות, ‏עסק, ‏או חברה. ‏מצד ימין במחשב, ‏מעל התוצאות בנייד. ‏זה ה-trophy ‏האולטימטיבי של branded search. ‏הוא לא נופל מהשמיים, ‏הוא נבנה מאות סיגנלים, ‏ו-Person schema ‏הוא אחד מהחשובים שבהם.

איך גוגל בונה Knowledge Panel

גוגל אוסף מידע מ-3 מקורות: ‏(1) ‏Knowledge Graph (פנימי, ‏שגוגל בונה ממקורות שונים), ‏(2) ‏Wikidata, ‏(3) ‏Wikipedia. ‏בתוספת, ‏גוגל קורא Person schema ‏מאתרים, ‏בעיקר מאתר ה-official ‏של האדם. ‏ה-Person schema ‏הוא איך גוגל יודע מי האדם, ‏מה הוא עושה, ‏ולמה הוא רלוונטי. ‏בלי Person schema, ‏גוגל יסתמך רק על Wikipedia/Wikidata, ‏ואם אין לכם entity ‏שם, ‏לא תהיה לכם Knowledge Panel ‏בכלל.

איך לאופטם ל-Knowledge Panel

1. Person schema ‏מלא בעמוד אודות

   ‏עם כל ה-properties שדיברנו עליהם, ‏בעיקר sameAs.

2. sameAs ‏לפרופילים סמכותיים

   ‏LinkedIn, ‏Twitter, ‏Wikipedia, ‏Wikidata. ‏ככל שיש יותר, ‏ככה גוגל יותר בטוח שזה entity ‏אמיתי.

3. תוכן מעלמכם, ‏באתרים אחרים

   ‏ראיונות, ‏הופעות בפודקסטים, ‏מאמרים בעיתונים. ‏כל אזכור באתר רב-קוראים = סיגנל אישור.

4. תמונת headshot ‏עקבית

   ‏אותה תמונה בכל הפרופילים. ‏זה עוזר לגוגל לקשר את כל הפרופילים לאותה entity.

5. שם עקבי

   ‏"שמוליק דורינבאום" בכל מקום. ‏לא "שמוליק ד." ‏פה ו-"S. ‏Dorinbaum" ‏שם.

כמה זמן זה לוקח

אין מספר מובטח. ‏גוגל בונה Knowledge Panel ‏רק כשיש לו מספיק סיגנלים חזקים. ‏לאדם ידוע (מי שיש לו Wikipedia ‏ופעילות גבוהה ב-LinkedIn ‏ו-100 ‏מאזכורים בעיתונים), ‏זה יכול לקרות תוך שבועות. ‏לאדם פחות ידוע, ‏זה יכול לקחת שנים, ‏ולפעמים לעולם לא יקרה. ‏ה-Person schema ‏לבד לא יביא Knowledge Panel, ‏אבל הוא תנאי בסיסי. ‏בלי Person schema ‏מלא, ‏גם אם תעשו את כל השאר, ‏ה-Knowledge Panel ‏פחות סביר להופיע.

🌍 Wikipedia + Wikidata, ‏הסיגנל האולטימטיבי

בעולם של schema ‏ו-entity recognition, ‏יש 2 ‏entities ‏שהן הרבה יותר חזקות מכל השאר, ‏Wikipedia ‏ו-Wikidata. ‏אם יש לכם מאמר באחד מהם, ‏ובמיוחד אם יש לכם entity ‏בשניהם, ‏אתם משחקים בליגה אחרת. ‏גוגל בונה את ה-Knowledge Graph ‏שלו במידה רבה מהם. ‏AI engines ‏מצטטים אנשים עם entity ‏שם הרבה יותר מאחרים.

Wikipedia

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

Wikidata

‏זה הדבר היפה. ‏Wikidata ‏הוא קל יותר להיכנס אליו מ-Wikipedia. ‏אתם יכולים ליצור entity ‏ב-Wikidata ‏גם בלי מאמר ב-Wikipedia, ‏בתנאי שאתם יכולים להוכיח שיש לכם פעילות מסוימת (פרסומים, ‏אזכורים, ‏חברה). ‏ה-entity ‏ב-Wikidata ‏הופך לסיגנל חזק כי גוגל סורק Wikidata ‏בתדירות גבוהה ומעדכן את ה-Knowledge Graph ‏בהתאם.

איך לקשר ל-sameAs

"sameAs": [
  "https://en.wikipedia.org/wiki/שמוליק_דורינבאום",
  "https://www.wikidata.org/wiki/Q123456789"
]

שימו לב לפורמטים, ‏Wikipedia ‏צריך URL ‏מלא לערך, ‏Wikidata ‏צריך URL ‏עם Q-ID ‏הספציפי. ‏ה-Q-ID ‏הוא הזהות הייחודית של ה-entity ‏ב-Wikidata. ‏אפשר למצוא אותו על ידי חיפוש ב-wikidata.org ‏ולקיחת ה-Q ‏מה-URL.

מה אם אתם לא ב-Wikipedia/Wikidata

‏90% ‏מהיועצים והבעלי עסקים לא יהיו שם. ‏זה בסדר. ‏עדיין יש לכם sameAs ‏ל-LinkedIn ‏ו-Twitter, ‏שזה סיגנל חזק (פחות מ-Wikipedia, ‏אבל עדיין). ‏אם אתם משאיפים, ‏אפשר לעבוד לעבר Wikidata ‏entity ‏אם יש לכם מספיק פרסומים ואזכורים (5-10 ‏אזכורים בעיתונים מוכרים בדרך כלל מספיק). ‏אם אתם רחוקים מזה, ‏התמקדו ב-sameAs ‏לפרופילים החיים שלכם וקל לבנות עם הזמן.

איך בונים entity ב-Wikidata בעצמכם

‏Wikidata ‏פתוח לכל אחד ליצור entities. ‏צריך חשבון, ‏Q-ID ‏מוקצה אוטומטית, ‏ומלאים שדות בסיסיים, ‏שם (label) ‏בעברית ובאנגלית, ‏תיאור קצר, ‏סטייטמנטים (instance of: human, ‏occupation: SEO consultant, ‏country of citizenship: Israel, ‏website: shmul.co.il). ‏Wikidata ‏מקפיד על מקורות, ‏לכל סטייטמנט צריך להיות reference ‏(URL ‏לאתר חיצוני שמאמת). ‏אזכור בעיתון מקצועי, ‏פרסום בעיתונות הראשית, ‏פרופיל באתר אוניברסיטה, ‏כל אחד מהם יכול להיות reference.

הסכנה של entity עם 0 references

‏אסור ליצור entity ב-Wikidata ‏בלי references. ‏הוא יימחק בתוך ימים על ידי moderators ‏שמסיירים. ‏יותר גרוע, ‏אם הוא יישאר, ‏הוא יוסיף סיגנל שלילי, ‏entity ‏לא מאומת שמופיע ב-Wikidata = ‏חשד לזיוף. ‏הכלל, ‏רק entity ‏עם references ‏אמיתיים מ-3+ ‏מקורות חיצוניים. ‏אם אתם לא עומדים בכך, ‏חכו עד שתעמדו.

Wikipedia בעברית מול אנגלית

‏אם אתם פעילים בעיקר בישראל, ‏entity ‏ב-Wikipedia ‏עברית עדיף על אנגלית מבחינת רלוונטיות לקוורי בעברית. ‏אבל Wikipedia ‏אנגלית חזקה יותר בעיני גוגל גלובלית. ‏השאיפה האולטימטיבית, ‏entity ‏בשתיהן + Wikidata. ‏אם צריך לבחור, ‏עברית אם הקהל הוא ישראלי, ‏אנגלית אם יש שאיפות בינלאומיות.

🕸 שילוב Person ב-@graph עם Article + Organization (עם דוגמת קוד)

הדבר היפה של schema ‏מודרנית הוא ה-@graph. ‏במקום לרשום 5 scripts ‏נפרדים בעמוד (Article, ‏Person, ‏Organization, ‏BreadcrumbList, ‏WebPage), ‏מאחדים את הכל ל-script ‏אחד עם @graph ‏שמכיל array ‏של entities. ‏גוגל קורא את כולם ביחד ומבין את הקשרים ביניהם. ‏זה הסטנדרט המומלץ של 2026.

למה @graph עדיף

‏(1) ‏קוד פחות, ‏פחות overhead. ‏(2) ‏גוגל מבין את הקשרים בין ה-entities (Article ‏שכתב Person ‏שעובד ב-Organization). ‏(3) ‏ה-@id ‏refs ‏עובדים יותר טוב ב-@graph ‏אחד מאשר ב-scripts ‏נפרדים. ‏(4) ‏רוב ה-CMSs ‏המודרניים (Yoast, ‏RankMath, ‏SEOPress) ‏מטמיעים @graph ‏כברירת מחדל. ‏(5) ‏ה-Validator ‏של גוגל אוהב @graph ‏יותר.

דוגמת קוד מלאה, ‏@graph עם 4 entities

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://www.shmul.co.il/#website",
      "url": "https://www.shmul.co.il/",
      "name": "shmul.co.il",
      "publisher": {"@id": "https://www.shmul.co.il/#org"}
    },
    {
      "@type": "Organization",
      "@id": "https://www.shmul.co.il/#org",
      "name": "shmul.co.il",
      "url": "https://www.shmul.co.il/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://www.shmul.co.il/logo-site.png"
      },
      "founder": {"@id": "https://www.shmul.co.il/#shmulik"}
    },
    {
      "@type": "Person",
      "@id": "https://www.shmul.co.il/#shmulik",
      "name": "שמוליק דורינבאום",
      "jobTitle": "יועץ SEO",
      "url": "https://www.shmul.co.il/אודות/",
      "worksFor": {"@id": "https://www.shmul.co.il/#org"},
      "sameAs": [
        "https://www.linkedin.com/in/shmulikdorinbaum",
        "https://twitter.com/shmulik_seo"
      ],
      "knowsAbout": ["SEO", "E-E-A-T", "Schema.org"]
    },
    {
      "@type": "Article",
      "@id": "https://www.shmul.co.il/person-schema-author-eeat/#article",
      "headline": "Person Schema, author SEO ו-E-E-A-T",
      "author": {"@id": "https://www.shmul.co.il/#shmulik"},
      "publisher": {"@id": "https://www.shmul.co.il/#org"},
      "datePublished": "2026-05-30"
    }
  ]
}
</script>

הקסם

שימו לב לאיך ה-@id ‏refs ‏מקשרים בין ה-entities. ‏ה-WebSite ‏מצביע על ה-Organization ‏בתור publisher. ‏ה-Organization ‏מצביע על ה-Person ‏בתור founder. ‏ה-Person ‏מצביע חזרה על ה-Organization ‏בתור worksFor. ‏ה-Article ‏מצביע על ה-Person ‏בתור author ‏ועל ה-Organization ‏בתור publisher. ‏רשת שלמה של קשרים ב-script ‏אחד. ‏זה ה-Knowledge Graph ‏הפנימי שלכם, ‏וגוגל בולע אותו עם תיאבון.

הוספת entities נוספות

‏אפשר להוסיף לגרף עוד entities ‏כדי להעשיר את התמונה. ‏BreadcrumbList ‏לניווט. ‏FAQPage ‏לשאלות נפוצות. ‏HowTo ‏להוראות. ‏ImageObject ‏לתמונות. ‏כל אחד מהם מקבל @id ‏ייחודי ויכול להפנות ל-entities ‏אחרות בגרף. ‏באתר שלי לדוגמה, ‏עמוד מאמר טיפוסי מכיל 12 entities ‏ב-@graph, ‏כולן מקושרות זו לזו.

טעות נפוצה, ‏כפילות @id

‏אסור לתת לשני entities ‏שונים את אותו @id. ‏זה מבלבל את גוגל ופותר את הסכמה. ‏הקונבנציה, ‏@id ‏ייחודי לכל entity ‏לאורך כל האתר. ‏אם יש לכם 2 ‏Persons (כותב + co-author), ‏שני @ids ‏שונים. ‏אם יש לכם 2 ‏Organizations (החברה שלכם + לקוח שמסומן ב-mentions), ‏שני @ids ‏שונים. ‏ה-@id ‏הוא הזהות הייחודית בעולם של schema, ‏מתייחסים אליו ברצינות.

סדר ה-entities ב-@graph

‏טכנית הסדר לא משנה לגוגל, ‏אבל לקריאות שלכם כמתכנתים, ‏יש קונבנציה. ‏(1) ‏WebSite ‏ראשון (root entity), ‏(2) ‏Organization שני, ‏(3) ‏Person שלישי, ‏(4) ‏WebPage רביעי, ‏(5) ‏Article או entity ‏עיקרי של העמוד חמישי, ‏(6) ‏BreadcrumbList, ‏FAQPage, ‏HowTo ‏ושאר ה-supporting entities ‏אחרי. ‏זה מקל על תחזוקה ועל debugging. ‏ראו גם Article schema, ‏מדריך מלא, ‏Organization schema, ‏ו-סכמות schema, ‏המדריך השלם.

🚫 הטעויות הקלאסיות (missing sameAs, ‏inconsistent name, ‏fake persona)

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

1. ‏Missing sameAs

‏הכי נפוץ. ‏Person ‏עם name + jobTitle + image, ‏בלי שום sameAs. ‏כאמור, ‏בלי sameAs ‏לפרופילים חיצוניים, ‏גוגל לא יכול לאמת שזה אדם אמיתי. ‏ה-Person ‏הזה הוא string ‏פנימי, ‏בלי impact ‏על Knowledge Panel ‏או E-E-A-T. ‏תיקון, ‏הוסיפו לפחות LinkedIn ‏ו-Twitter ‏(אפילו אם אתם לא פעילים שם הרבה).

2. ‏Inconsistent name across pages

‏"שמוליק דורינבאום" בעמוד אודות, ‏"שמוליק ד." ‏בעמוד מאמר, ‏"S. ‏Dorinbaum" ‏ב-Person schema, ‏"Shmulik Dorenbaum" ‏ב-LinkedIn. ‏inconsistency ‏מבלבלת את גוגל. ‏איזה entity ‏זה? ‏אולי 4 ‏אנשים שונים? ‏תיקון, ‏בחרו פורמט אחד של השם, ‏והשתמשו בו בכל מקום, ‏מילה במילה.

3. ‏Schema לפרסונה מומצאת

‏ראיתי את זה אצל אתרי content farms ‏שהשתמשו ב-AI ‏ליצירת תוכן וסימנו את ה-author ‏כ-Person ‏עם תמונת stock ‏ופרופיל LinkedIn ‏מזויף. ‏גוגל בודק את זה. ‏הוא יזהה תמונת stock, ‏יזהה פרופיל LinkedIn ‏ריק, ‏ויפסיק לסמוך על האתר. ‏ההשלכות חמורות, ‏האתר כולו מתויג כ-low quality. ‏אסור. ‏אם אתם משתמשים ב-AI ‏לתוכן, ‏סמנו את ה-author ‏כאדם אמיתי שאחראי על העריכה (לדוגמה, ‏אתם עצמכם).

4. ‏Image לא קיים או broken link

‏Person ‏עם image ‏שמצביע על URL ‏שמחזיר 404. ‏זה רע מאוד. ‏גוגל בודק כל URL ‏בסכמה. ‏broken link ‏ל-image ‏זה אזהרה ב-Search Console ‏ו-validation error ‏ב-Rich Results Test. ‏תיקון, ‏וודאו שכל ה-URLs ‏בסכמה חיים. ‏השתמשו בדף הוואלידציה לבדוק.

5. ‏Author כ-string ‏ב-Article

‏הקלאסי של וורדפרס. ‏Article ‏עם "author": "דני כהן" ‏במקום אובייקט. ‏פרק 4 דיברנו על זה לעומק. ‏תיקון, ‏שדרגו לאובייקט Person ‏עם לפחות name + url.

6. ‏jobTitle ‏כללי מדי

‏"Professional", ‏"Expert", ‏"Entrepreneur". ‏כל הכלליות לא תורמת. ‏גוגל לא יודע מה אתם expert ‏בו. ‏תיקון, ‏"SEO Consultant", ‏"Dental Surgeon", ‏"Real Estate Investor", ‏ספציפי לתחום.

7. ‏knowsAbout ‏עם 50 נושאים‏ראיתי Person ‏עם knowsAbout ‏שכולל 50 ‏תחומים. ‏זה לא משחקי, ‏זה ההפך מהמטרה. ‏גוגל יודע שאי אפשר להיות expert ‏ב-50 ‏תחומים. ‏תיקון, ‏3-7 ‏תחומים מקסימום, ‏הספציפיים שאתם באמת מומחים בהם.

⚠️ הטעות הכי גרועה

‏Person schema ‏ל-AI persona ‏מומצאת. ‏ראיתי את זה אצל מותגי B2B ‏שיצרו "כותב מומחה" שלא קיים, ‏עם name, ‏headshot ‏מ-Stock, ‏ופרופיל LinkedIn ‏ריק. ‏גוגל יזהה את זה תוך זמן קצר ויעניש את כל האתר. ‏הסיכון של זה הוא לא מקומי, ‏הוא חוצה אתר. ‏Penalty ‏ל-fake author = ‏פגיעה בכל ה-domain. ‏אם אתם משתמשים ב-AI ‏ליצירת תוכן, ‏סמנו את האדם האמיתי שאחראי עליו כ-author. ‏אסור פרסונות מומצאות.

🤖 AI engines + Person schema, ‏ChatGPT מצטטת מומחים

זה החלק הכי מרגש של 2026. ‏ChatGPT, ‏Perplexity, ‏Gemini, ‏Google AI Overviews, ‏כולם משתמשים ב-Person schema ‏כדי להחליט את מי לצטט. ‏זה לא רק על ranking ‏בגוגל, ‏זה על visibility ‏בכל ה-AI ecosystem ‏החדש. ‏אם אתם רוצים שמנועי AI ‏יצטטו אתכם בתור מומחה בנושא, ‏Person schema ‏הוא המינימום.

איך AI engines משתמשים בסכמה

כש-AI engine ‏עונה לשאלה, ‏הוא לא רק קורא טקסט. ‏הוא קורא structured data, ‏בודק entities, ‏מאמת מקורות. ‏שאלה כמו "מי המומחה הטוב ביותר ל-SEO בישראל?" ‏עוברת בערך כך, ‏(1) ‏ה-engine ‏מחפש אנשים עם Person schema ‏שמכיל knowsAbout: SEO ‏ו-jobTitle: SEO Consultant. ‏(2) ‏מעדיף אנשים עם sameAs ‏לפרופילים חזקים (LinkedIn ‏עם הרבה followers, ‏Wikipedia). ‏(3) ‏מעדיף אנשים שמופיעים כ-author ‏בהרבה מאמרים בתחום. ‏(4) ‏מצטט את אלה שעברו את כל ה-checks.

מה זה אומר עבורכם

‏(1) ‏הוסיפו knowsAbout ‏מדויק לתחומים ספציפיים, ‏לא כלליים. ‏(2) ‏חזקו sameAs ‏לפרופילים מקצועיים. ‏(3) ‏וודאו ש-Person schema ‏מופיעה בכל המאמרים שלכם, ‏עם @id ‏ref ‏ל-entity ‏המלא. ‏(4) ‏ככל שיש לכם יותר מאמרים בתחום ספציפי, ‏ככה ה-AI ‏יותר בטוח שאתם מומחה בו.

הזדמנות של 2026

רוב המקדמים בעולם עדיין לא הבינו את זה. ‏הם עדיין חושבים שPerson schema ‏זה nice-to-have ‏ל-Knowledge Panel ‏שאולי יום אחד יהיה. ‏בפועל, ‏זה כבר היום הסיגנל הקריטי ל-AI citations. ‏מי שמטמיע Person schema ‏מלא ב-2026 ‏מקבל יתרון של 2-3 שנים על מתחרים. ‏עד ש-AI engines ‏יהפכו ל-default ‏לחיפוש (חצי שנה? ‏שנה?), ‏זה אדוונטג' אדיר.

ראו גם E-E-A-T ב-2026 ‏ו-E-E-A-T, ‏המדריך השלם ‏להבנה איך AI engines ‏מודדים expertise.

🔍 אימות עם Rich Results Test

‏אחרי שכתבתם את ה-Person schema ‏שלכם, ‏חייבים לאמת. ‏השלמה אחת חסרה או typo ‏יכול לפסול את כל הסכמה. ‏הכלים העיקריים, ‏Rich Results Test ‏של גוגל ‏ו-Schema Validator ‏של schema.org. ‏אל תדלגו על השלב הזה, ‏הוא לוקח 3 ‏דקות וחוסך שעות של בדיקה למה לא עובד.

Rich Results Test (search.google.com/test/rich-results)

‏זה הכלי הרשמי של גוגל. ‏מציג eligibility ‏ל-rich results. ‏מציין warnings ‏על properties ‏מומלצים שחסרים. ‏בודק את האתר החי או קוד JSON-LD ‏שאתם מדביקים. ‏לעבודה עם Person schema:

1. הכניסו את ה-URL ‏של עמוד האודות שלכם

   ‏הכלי קולט את ה-Person schema ‏המוטמע ומציג ניתוח.

2. בדקו ש-0 errors

   ‏error ‏פותר את כל הסכמה. ‏warnings ‏ניתנים לחיות איתם אבל עדיף לסגור.

3. בדקו את ה-properties ‏שזוהו

   ‏הכלי מציג את כל ה-properties ‏שהוא קולט. ‏וודאו שהכל נראה כפי שצריך.

Schema Validator (validator.schema.org)

‏הכלי של schema.org. ‏בודק תאימות תחבירית של JSON-LD ‏לסטנדרטים. ‏עוצמתי במיוחד לבדיקת structure ‏של @graph ‏ו-@id refs. ‏מציג עץ של ה-entities ‏עם הקשרים ביניהן. ‏מעולה לדיבוג.

Search Console, ‏Enhancements report

‏אחרי שהסכמה חיה באתר, ‏GSC ‏מציג את ה-Enhancements ‏שזיהה. ‏ל-Person schema ‏שמשולב ב-Article, ‏רואים את זה ב-Article report. ‏ל-Person schema ‏עצמאי, ‏רואים את זה ב-Sitelinks searchbox ‏או באזורים אחרים תלוי בהקשר. ‏עוקבים אחר ה-Coverage ‏כדי לוודא שכל העמודים נקלטים.

Chrome DevTools, ‏inspection ‏מקומית

‏לפני שאתם פורסים, ‏בדקו במקומי. ‏Chrome DevTools ‏עם extension ‏כמו "Schema App Highlighter" ‏או "Structured Data Testing Tool Bookmarklet" ‏מציג את הסכמה בעמוד. ‏מצוין לדיבוג ראשוני.

🛠 workflow הטמעה ל-author markup ב-10 שלבים

אם תקראתם עד כאן, ‏יש לכם את כל הידע. ‏עכשיו צריך תהליך מעשי להטמיע באתר אמיתי. ‏הנה ה-workflow ‏שאני עובד לפיו אצל כל לקוח חדש, ‏עם checklist ‏חודשי לתחזוקה.

10 הצעדים להטמעה ראשונית

1. איסוף נתונים

   ‏שם מלא, ‏שם פרטי, ‏שם משפחה, ‏jobTitle ‏מדויק, ‏שפות, ‏תחומי ידע (3-7), ‏image headshot (1200x1200+), ‏רשימת sameAs.

2. בחירת @id ‏יציב

   ‏פורמט קבוע, ‏https://www.domain.com/#firstname. ‏זה ה-ID ‏שיהיה לאדם בכל האתר.

3. כתיבת Person entity ‏מלא

   ‏בעמוד אודות, ‏Person schema ‏עם כל ה-recommended properties. ‏זה ה-source of truth.

4. אימות עם Rich Results Test

   ‏בדיקה ש-0 ‏errors ‏ושכל ה-properties ‏נקלטים נכון.

5. הוספת @id refs ‏לכל מאמר

   ‏בכל Article ‏באתר, ‏"author": {"@id": "https://www.domain.com/#firstname"}. ‏לא Person ‏מלא, ‏רק ref.

6. אינטגרציה עם Organization

   ‏אם יש לכם Organization schema, ‏הוסיפו founder ‏או employee ‏שמצביעים ל-Person ref. ‏ועל ה-Person, ‏הוסיפו worksFor ‏שמצביע ל-Organization ref.

7. חיזוק sameAs

   ‏עברו על LinkedIn, ‏Twitter, ‏Facebook, ‏וודאו שהם פעילים ומעודכנים. ‏אם יש לכם פרופיל ב-Wikipedia ‏או Wikidata, ‏הוסיפו. ‏אם לא, ‏שקלו אם אתם עומדים בקריטריונים.

8. בדיקת image consistency

   ‏אותו headshot ‏בכל הפרופילים, ‏ב-Person schema, ‏ב-LinkedIn, ‏ב-Twitter. ‏זה עוזר לגוגל לקשר את כל הפרופילים לאותה entity.

9. אימות ב-Search Console

   ‏שבועיים אחרי הפריסה, ‏בדקו את ה-Enhancements report. ‏וודאו שאין warnings ‏או errors ‏חדשים.

10. תחזוקה חודשית

    ‏calendar reminder ‏אחת לחודש. ‏בדקו שה-image ‏עדיין חי, ‏ה-sameAs ‏עדיין פעילים, ‏jobTitle ‏עדכני, ‏ולא הצטרפו אזכורים חדשים שאפשר להוסיף.

צ'ק ליסט תחזוקה חודשית

• ‏בדיקת ה-schema ‏ב-Rich Results Test, ‏עדיין eligible?
• ‏השוואה עם LinkedIn, ‏jobTitle ‏עדיין זהה?
• ‏בדיקת image, ‏ה-URL ‏עדיין חי? ‏ה-headshot ‏עדיין רלוונטי?
• ‏בדיקת sameAs, ‏כל הפרופילים פעילים? ‏יש פרופיל חדש להוסיף?
• ‏בדיקה אם הצטרף תחום knowsAbout ‏חדש בעקבות מאמרים שכתבתם
• ‏אם יש Knowledge Panel, ‏בדיקה שהמידע בו עדכני
• ‏בדיקה ב-Search Console ‏שאין אזהרות חדשות ל-author markup
• ‏השוואה עם author markup ‏של מתחרים, ‏האם הם הוסיפו properties שאתם חסרים
• ‏אם הוספתם מאמרים חדשים, ‏וודאו ש-author ref ‏מוטמע בכולם
• ‏אחת לרבעון, ‏בדיקה אם schema.org ‏פירסם properties ‏חדשים ל-Person

❓ שאלות נפוצות