Knowledge Graph של גוגל, איך הוא נבנה ואיך מופיעים בו

🧠 ‏מה זה Knowledge Graph, ולמה זה הדבר הכי חשוב שלא לימדו אתכם ב-SEO

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

‏גוגל השיקה את Knowledge Graph במאי 2012, עם הסלוגן "things, not strings". הרעיון, עד אז גוגל ראתה את האינטרנט כשרשורים של מילים (strings). מהמהפכה הזאת והלאה, גוגל ראתה אותו כרשת של דברים (things), ישויות עם קשרים ביניהן. כשאתם מחפשים "דודי וייסמן", גוגל לא רק מחפשת את הצירוף הזה במאמרים, היא מחפשת ב-Knowledge Graph שלה מי האדם הזה, איפה הוא עובד, מה הוא עשה, ומראה לכם Knowledge Panel בצד הימני (או השמאלי בעברית RTL).

‏במאמר הזה אני עובר איתכם על כל מה שצריך לדעת על Knowledge Graph של גוגל. איך הוא נבנה (מ-Freebase של 2010, מ-Wikidata, ומ-web mining), איך גוגל מוסיפה אליו entities, מה תפקיד הסכמות, איך משיגים Knowledge Panel, ואיך בונים נוכחות entity לעצמכם או לעסק שלכם. 15 פרקים, צ'ק ליסט חודשי, ועתיד הגראף בעידן ה-AI. אם אחרי המאמר אתם עדיין לא בטוחים מה לעשות, יש לכם איך לדבר איתי.

‏אגב, אני שמוליק דורינבאום, 20 שנה ב-SEO. בניתי entities ללקוחות מ-2014 (השנה שבה Knowledge Graph באמת התחיל להשפיע על SERP). ראיתי אנשים שעברו מ-"לא קיימים" ל-Knowledge Panel תוך 6 חודשים עם עבודה ממוקדת, וראיתי חברות שלמות שהקדישו 100K שקל ל-SEO תוכן בלי לבנות שום entity, וסיגרו את העסק כשAI Overviews השתלטו על ה-SERP. ההבדל בין שתי הקבוצות, הבנה של איך גוגל באמת רואה את העולם. זאת בדיוק ההבנה שאתם הולכים לקבל כאן.

‏מה לא תקראו כאן

‏לא תקראו כאן "7 טיפים מהירים לקבל Knowledge Panel". זה לא קיים. לא תקראו כאן הבטחות לתוצאה תוך חודש. זה שקר. לא תקראו על כלים מנדלים שמייצרים entity באוטומציה. לא קיים, וגם אם היה, גוגל הייתה מזהה ופוגעת בכם. מה שכן תקראו, ההיגיון העמוק של איך גוגל בונה את הגראף, אילו מקורות היא סופרת, ואיך לבנות נוכחות שתחזיק לאורך 5-10 שנים, לא חודש אחד. אם זה מה שאתם מחפשים, אתם במקום הנכון. אם אתם מחפשים shortcut, צאו עכשיו, יש 50 בלוגים אחרים שיבטיחו לכם שמיים.

🏗 ‏ההיסטוריה של הגראף, מ-Freebase של MetaWeb עד היום

‏Knowledge Graph לא נבנה מאפס. הוא תוצר של רכישה אסטרטגית של גוגל ב-2010, שינוי תפיסה ב-2012, ושילוב מתמשך של מקורות עד היום. כל מי שרוצה להבין איך להיכנס לגראף חייב להבין קודם איך הגראף עצמו נבנה.

‏ציר הזמן של הגראף

• 2007
  MetaWeb משיקה את Freebase, מסד נתונים פתוח ושיתופי של ישויות, מתחרה תיאורטי ל-Wikipedia ברמה הסטרוקטורלית
• יולי 2010
  ‏גוגל רוכשת את MetaWeb עם 12 מיליון entities ב-Freebase, ההתחלה האמיתית של מה שיהפוך ל-Knowledge Graph
• מאי 2012
  ‏Knowledge Graph מושק רשמית באנגלית, מסד של 500 מיליון entities עם 3.5 מיליארד עובדות וקשרים
• דצמ' 2012
  ‏הרחבת Knowledge Graph לעוד 7 שפות, רוסית, ספרדית, פורטוגזית, גרמנית, צרפתית, איטלקית, יפנית. עברית עדיין לא
• דצמ' 2014
  ‏גוגל סוגרת את Freebase ומעבירה את התוכן ל-Wikidata, החל מאז Wikidata הוא הציר המרכזי של מקורות פתוחים לגראף
• 2016
  ‏Knowledge Graph חוצה את ה-70 מיליארד עובדות לפי הצהרת גוגל, ומאז נכלל בכמעט כל שאילתת ישות
• 2020+
  ‏Knowledge Graph הופך לעמוד שדרה של AI features של גוגל, כולל Search, ‏Assistant, ‏Lens, ולאחר מכן SGE ו-AI Overviews

‏מ-strings ל-things, מה הרעיון העמוק

‏לפני 2012, גוגל אינדקסה עמודים. אם חיפשתם "רותם אבוהב", גוגל החזירה לכם עמודים שבהם מופיע הצירוף הזה. הבעיה, גוגל לא ידעה מי האדם, מה הוא עשה, על מה הוא ידוע, או מה ההקשרים שלו. אחרי 2012, גוגל יודעת לזהות שרותם אבוהב היא שחקנית ישראלית, נולדה בתאריך X, שיחקה ב-Y וב-Z, ולפי זה היא יכולה לבנות Knowledge Panel ולענות על שאלות עקיפות כמו "בת כמה רותם אבוהב".

‏Freebase, החלוץ הנשכח

‏Freebase היה הניסיון הראשון לבנות מסד ישויות בקנה מידה אינטרנטי. הוא היה פתוח, שיתופי, ומובנה ב-RDF. כשגוגל קנתה את MetaWeb, היא קיבלה 12 מיליון ישויות מהיום הראשון. זה היה הזרע. הגראף של 2012 היה כבר 500 מיליון, כי גוגל הוסיפה web mining מסיבי על גבי הזרע של Freebase. הסיבה שגוגל סגרה את Freebase ב-2014, היא רצתה לאחד עם Wikidata, שהיה גדול יותר וקהילתי יותר.

🆚 ‏Knowledge Graph מול Knowledge Panel, ההבדל שכולם מבלבלים

‏אחד הבלבולים הכי נפוצים שאני שומע מלקוחות, "שמוליק, איך אני מקבל Knowledge Graph?". התשובה, אתם לא. Knowledge Graph היא לא משהו שמופיע במסך, היא מסד נתונים שגוגל מחזיקה בשרתים שלה. מה שאתם רוצים זה Knowledge Panel, הקופסה שצפה בצד ה-SERP. שתי המילים נשמעות דומות, אבל הן שני דברים שונים לחלוטין. כדאי לסדר את זה לפני שממשיכים.

‏Knowledge Graph (המסד)

• ‏מסד נתונים גרף שגוגל מחזיקה פנימית
• ‏מכיל מיליארדי ישויות וטריליוני קשרים (לפי הצהרת גוגל)
• ‏לא נגיש ישירות לציבור, אבל יש API מוגבל (Knowledge Graph Search API, נסגר ב-2024)
• ‏מזין הרבה features של גוגל, ‏Search, Assistant, Maps, Shopping, וכמובן AI Overviews ו-AI Mode
• ‏ישויות שם מסומנות עם MID (Machine ID), מחרוזת כמו /m/0jrh2j5

‏Knowledge Panel (התצוגה)

• ‏הקופסה שגוגל מציגה בצד ה-SERP (או למעלה במובייל) לישויות מוכרות
• ‏מציגה פרטים כמו תמונה, תיאור, תאריכי לידה, שיוך עסקי, ספרים, סרטים, וכו'
• ‏מוצגת רק לחלק מהישויות בגראף, אלה שגוגל החליטה שיש להן מספיק ביקוש או מספיק מידע מאומת
• ‏ניתן לתבוע בעלות (claim) דרך תהליך אימות, ואז העצמאי יכול לעדכן פרטים מסוימים
• ‏Wikipedia הוא לא המקור היחיד, אבל הוא המקור הכי דומיננטי בפועל

‏האנלוגיה הקלאסית שלי

‏אני אוהב להסביר את זה ככה. Knowledge Graph היא רשימת תושבים של מדינה (המסד), ו-Knowledge Panel היא תעודת הזהות שמדפיסים לכמה תושבים. תוכלו להיות בגראף בלי שיש לכם Panel (גוגל יודעת מי אתם אבל עוד לא מציגה Panel), ותוכלו להיות בלי Panel ובלי גראף בכלל (גוגל לא יודעת שאתם קיימים כישות, רק כעמודים סתם). המטרה האולטימטיבית, שיהיה לכם גם וגם, וש-Panel ייתבע על ידכם.

‏איך לבדוק אם יש לכם Panel

‏פשוט מאוד. פתחו דפדפן anonymous (incognito, כדי לעקוף את ההיסטוריה שלכם), חפשו את השם המלא שלכם או את שם העסק. אם הופיע בצד הימני (או למעלה במובייל) קופסה עם תמונה ופרטים שלכם, יש לכם Panel. אם מופיע רק קישורים כחולים רגילים, אין. הבדיקה הזאת חשובה כי לפעמים יש Panel לחיפוש על השם המלא אבל לא לחיפוש על השם הקצר (או להפך). מומלץ לבדוק את 3 הוריאציות הנפוצות של השם שלכם. אם יש Panel לפחות באחת, יש לכם נקודת התחלה לתביעת בעלות.

📋 ‏סוגי entities שגוגל עוקבת, מ-Person ועד MedicalCondition

‏Knowledge Graph לא רק רושם דברים, היא מתייגת אותם לפי סוג. כל ישות מסווגת ל-type מסוים, שמגדיר אילו תכונות יש לה ואיזה קשרים אפשריים. הסיווג הזה תואם בערך לסכמות של schema.org, וזאת בדיוק הסיבה ש-schema.org קריטי לקידום entity.

‏סוגי entities עיקריים בגראף

1. ‏Person

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

2. ‏Place

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

3. ‏Organization

   ‏ארגון, חברה, מוסד. תכונות, מייסדים, תאריך הקמה, גודל, כתובת, מנכ"ל. תת-סוגים, ‏LocalBusiness, ‏NewsMediaOrganization, ‏GovernmentOrganization, ועוד עשרות

4. ‏CreativeWork

   ‏יצירה אינטלקטואלית. ספר, סרט, אלבום, מאמר, תוכנה, רשת אפליקציות. תכונות, יוצר, תאריך פרסום, נושא, ז'אנר

5. ‏Event

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

6. ‏Product

   ‏מוצר. רכב, מכשיר, אפליקציה. תכונות, יצרן, מודל, מחיר, ביקורות

7. ‏MedicalCondition

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

8. ‏Species

   ‏מין ביולוגי. צמח, חיה, חרק. תכונות, סיווג מדעי, בית גידול

‏היררכיה

‏הסיווג בגראף הוא היררכי. Thing הוא הסוג העליון, וכל שאר הסוגים יורשים ממנו. Place יורש מ-Thing, ו-City יורש מ-Place. ירושה אומרת שכל תכונה של Thing חלה גם על City. הירושה הזאת זהה למבנה של schema.org, ולא במקרה, schema.org נבנה במידה רבה כדי לתת לבעלי אתרים דרך לסמן ישויות באופן שגוגל תזהה אותן לגראף שלה.

‏סוגים שגוגל מאוד אוהבת

‏מהניסיון שלי, גוגל הכי טובה בזיהוי Person, Organization, Place, CreativeWork, ו-Event. סוגים יותר ייחודיים כמו MedicalCondition, ChemicalCompound, ו-Species מטופלים גם הם אבל בעיקר ע"י feeds מיוחדים (PubMed, ChEMBL וכו'), פחות ע"י web mining פתוח. אם אתם עסק, סביר להניח שהישות שלכם תהיה Organization או LocalBusiness, ובעל העסק יהיה Person. ככה תתכננו את ה-schema.

‏מה ה type שגוגל לא משתמשת בו

‏ה-type של ה-schema שלכם חייב להיות מתוך המילון הרשמי של schema.org. אם תמציאו מילה ממציאה כמו "Consultant" או "SEOExpert", גוגל תתעלם ממנה. המילון קיים ב-schema.org/docs/full.html וזה ה-source of truth. טעות נפוצה, לרשום type באותיות גדולות או עם לויין אלפא-ביתי, גוגל מתייחסת לזה כשגיאת תחביר ומתעלמת מה-schema. תמיד תבדקו ב-Schema.org Validator לפני הפרסום, זה חינם וחוסך לכם שעות של דיבאג.

⚙ ‏איך גוגל מוסיפה entities לגראף, אוטומציה + Wikidata + feeds

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

‏3 מקורות עיקריים

‏1. Web Mining אוטומטי

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

‏2. Wikidata (המקור הכי דומיננטי)

‏Wikidata היא מסד הנתונים השיתופי של ויקימדיה. כל ישות בו מקבלת Q-number (כמו Q3037321), ותכונות בפורמט סטרוקטורלי. גוגל סוחבת מ-Wikidata באופן רציף, וכל ערך חדש או עדכון ב-Wikidata יכול להתעדכן בגראף תוך שבועות. זה הניסיון הכי קצר ויעיל להופיע בגראף, יצירת ערך Wikidata.

‏3. Verified Data Feeds

‏גוגל מקבלת feeds סטרוקטורליים ממקורות מהימנים. ספריות רפואיות (PubMed), בורסות ניירות ערך (NYSE, NASDAQ), מסדי ספרים (Library of Congress), מסדי מוסיקה (MusicBrainz), מסדי סרטים (IMDb, אם כי גוגל פיתחה גם feeds משלה אחרי שעבר ל-Amazon). הישויות שמגיעות מ-feeds מהימנים מקבלות trust גבוה ונכנסות לגראף מהר.

‏הקריטריון, הוכחה במספר מקורות עצמאיים

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

🏷 ‏תפקיד הסכמות (schema.org) ב-Entity Recognition

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

‏3 הסכמות הכי חשובות ל-entity

‏Person schema

‏לכל אדם שיש לו עמוד אודות באתר, חייבת להיות סכמת Person מלאה. תכונות חשובות, name, jobTitle, worksFor, image, url, sameAs, birthDate (אם רלוונטי), alumniOf, knowsAbout. תכונת ה-sameAs היא הקריטית, שם תכניסו את כל הפרופילים החיצוניים של האדם, LinkedIn, ‏Twitter, ‏Wikidata, ‏Crunchbase, ‏GitHub, וכו'. למדריך מעמיק לסכמת Person, ראו Person schema ו-Author EEAT.

‏Organization schema

‏לכל חברה, חייבת להיות סכמת Organization על עמוד הבית או על עמוד "אודותינו". תכונות חשובות, name, legalName, foundingDate, founder, logo, address, contactPoint, sameAs. אם זה עסק מקומי, להחליף ל-LocalBusiness עם תכונות נוספות. למדריך מעמיק, Organization schema ו-LocalBusiness schema.

‏sameAs, גשר הזיהוי

‏תכונת sameAs אומרת לגוגל, "הישות הזאת היא בדיוק הישות שמתוארת ב-URLs האלה". אם אתם מצרפים את הויקיפדיה שלכם, את ה-Wikidata Q-number שלכם, את ה-LinkedIn שלכם, גוגל מבינה שכל המידע ממקורות אלו מתייחס לאותה ישות. זה ה-disambiguation החזק ביותר שאתם יכולים לתת.

‏JSON-LD ב-@graph

‏הדרך המודרנית לפרסם schema היא JSON-LD ב-@graph בלוק. אתם יוצרים גרף קטן של ישויות שמקושרות זו לזו דרך @id stable. הישות של העמוד מקשרת לישות של הכותב (Person) שמקשר לישות של הארגון (Organization). גוגל קוראת את הגרף כולו ובונה ממנו רשת ישויות. זאת הסיבה שעמודים שמיישמים @graph נכון מקבלים entity recognition מהיר משמעותית מעמודים עם schemas נפרדים.

‏ה-author schema, הגשר ל-EEAT

‏כל מאמר שאתם מפרסמים בבלוג צריך להיות עם author ב-Article schema, וה-author הזה צריך להיות Person schema מוצהר עם @id stable שמצביע לעמוד האודות של הכותב. כך כל מאמר מחזק את ה-entity של הכותב, ולא רק מוציא תוכן טוב. זה קריטי במיוחד אם אתם ממקדים בלוג או אתר תוכן, כל מאמר באורגן מחזק את סמכות הכותב, וזה מזין את ה-Knowledge Graph שלהם. למי שהמדריך ל-Person schema לא מספיק, זה הטיק החזק ביותר להאיץ את תהליך הזיהוי בגראף.

🎯 ‏איך משיגים Knowledge Panel, ה-workflow הלא רשמי

‏גוגל לא מוכרת Knowledge Panels. גוגל גם לא מקבלת בקשות "תוסיפו לי Panel". יש workflow לא רשמי שאני בניתי על בסיס 10 שנים של ניסיון, מי שעובר אותו במלואו, יש לו סיכוי טוב להופיע. מי שמדלג על שלבים, יחכה לנצח.

‏ה-workflow ב-7 שלבים (לפי סדר)

1. ‏בניית נוכחות אתר חזקה

   ‏עמוד אודות מלא + עמוד יצירת קשר + Person/Organization schema + תוכן שמדגים את התחום שלכם. בלי בסיס באתר, אין על מה לבנות

2. ‏הצהרה עקבית בכל הרשתות

   ‏פרופילים זהים ב-LinkedIn, ‏Twitter, ‏Facebook, ‏YouTube, ‏GitHub (לפי הרלוונטיות), עם אותו תיאור, אותה תמונה, אותו שם

3. ‏יצירת ערך Wikidata

   ‏זה הצעד המכריע. ערך Wikidata מקבל Q-number, וגוגל מושכת ממנו ישירות לגראף. הערך חייב להיות מגובה במקורות חיצוניים (אזכורים בעיתונות, ראיונות, ספרים)

4. ‏השגת אזכורים בעיתונות מקצועית

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

5. ‏ערך Wikipedia (לא חובה, אבל מאוד עוזר)

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

6. ‏הבנייה של "brand SERP" נקי

   ‏גוגל בודקת מה מופיע כשמחפשים את השם שלכם. עמוד הבית שלכם בעמדה 1, LinkedIn ב-2, Wikidata ב-3, YouTube ב-4, וכו'. אם ה-SERP על השם שלכם מבולגן (תוצאות לא קשורות), גוגל לא תהיה בטוחה מי אתם

7. ‏זמן

   ‏Knowledge Panel לא מופיע ביום אחד. גם אחרי שעשיתם הכל, גוגל לוקחת 2-9 חודשים להציג Panel. סבלנות, או הסתפקו בהופעה ב-AI Overviews בינתיים

‏הסדר הוא חשוב, לא רק התוכן

‏שמתי לב משהו אצל לקוחות שניסו לעשות הכל במקביל, כל המאמץ נופל בין הכיסאות. גוגל צריכה לראות פרוגרסיה לוגית, קודם אתר, אז פרופילים, אז Wikidata, אז אזכורים, אז Wikipedia (אם רלוונטי). אם אתם יוצרים ערך Wikipedia לפני שיש לכם 5 אזכורים, הוא יימחק. אם אתם יוצרים Wikidata לפני שיש לכם פרופיל LinkedIn מאומת, התכונות שאתם מוסיפים נראות מפוקפקות לסוקרים. הצעד הראשון תמיד תשתית באתר ה-canonical שלכם. הצעד האחרון תמיד תביעת בעלות על ה-Panel. בלי הסדר הזה, מבזבזים זמן וכסף.

‏מה לא לעשות

• ‏אל תקנו אזכורים. גוגל מזהה PBNs ואזכורים סנתטיים, ופוגעת בכל הפרופיל
• ‏אל תיצרו ערך Wikipedia בעצמכם בלי תשתית. הוא יימחק תוך שעות, וזה משאיר עקבות לא טובים
• ‏אל תשנו את השם שלכם בין הפלטפורמות. עקביות 100% היא חוק
• ‏אל תניחו שזה משחק one-shot. בניית entity היא תהליך מתמשך לכל החיים, לא פרויקט של חודשיים

📚 ‏Wikipedia + Wikidata, המקור האולטימטיבי לגראף

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

‏Wikidata, התשתית הפתוחה

‏Wikidata היא מסד הנתונים השיתופי של ויקימדיה, מאז 2012. שלא כמו Wikipedia שדורשת אנגלית/עברית רהוטה ואותיות גדולות של notability, Wikidata מקבלת ישויות ברמה הרבה יותר נמוכה. מספיק שאתם מקצוען רשום בתחומכם, יש לכם אזכור ב-2-3 מקורות עצמאיים, וערך Wikidata לרוב יעבור את הסקירה.

‏איך יוצרים ערך Wikidata

1. ‏הירשמו ב-wikidata.org

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

2. ‏וודאו notability

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

3. ‏צרו את הישות

   ‏לחצו "Create a new item". הוסיפו label (השם בעברית + אנגלית), description קצר ("יועץ SEO ישראלי"), ו-aliases (וריאציות שם שאתם מוכרים בהן)

4. ‏הוסיפו תכונות (statements)

   ‏instance of (Q5 לאדם, Q4830453 לחברה), occupation, country of citizenship, date of birth, employer, וכל מה שרלוונטי. כל סטייטמנט עם מקור, אחרת הוא יסומן לסקירה

5. ‏הוסיפו identifiers

   ‏Twitter ID, LinkedIn ID, GitHub username, IMDB ID (אם רלוונטי), ORCID (אם אקדמאי). ככל שיותר identifiers חיצוניים, ככה יותר disambiguation

6. ‏הוסיפו תמונה

   ‏העלו תמונה ל-Wikimedia Commons (חינם, רישיון CC), ואז שייכו ל-Wikidata. גוגל מושכת את התמונה הזאת ל-Panel

‏הקשר ל-Knowledge Graph

‏גוגל מושכת מ-Wikidata אוטומטית, בערך פעם בשבועיים-חודש. אם הוספתם תכונה חדשה ל-Wikidata, היא תופיע בגראף תוך תקופה זו. ערך Wikidata חדש לישות שלא הייתה בגראף, יתחיל לבנות לה presence בגראף תוך 1-3 חודשים. זה לא ערובה ל-Panel, אבל זה ערובה כמעט מוחלטת לכניסה לגראף.

‏Wikipedia, השכבה העליונה

‏Wikipedia דורשת "notability" משמעותית בהרבה. הקריטריונים שלה, נושא הערך צריך להיות "significantly covered in reliable, independent sources". זה אומר שצריך לכם לפחות 5-10 כתבות עמוקות מעיתונים מובילים, או ספרים שכותבים עליכם, או הופעות בסרטים תיעודיים. אם אתם בעל עסק קטן, סביר להניח שלא תעברו את הרף ל-Wikipedia. אם אתם דמות ציבורית או חברה מבוססת, כן.

‏איך לא להיכשל בערך Wikidata

‏הטעות הכי נפוצה שאני רואה היא יצירת ערך עם תיאור כללי מדי. "מומחה SEO" זה לא טוב מספיק, יש מיליון. "שמוליק דורינבאום, יועץ SEO ישראלי שמתמחה בקידום entity ובאתרי תוכן" זה ספציפי וייחודי. ערך עם תיאור ספציפי שורד יותר טוב את הסקירה הראשונה. טעות שניה, חוסר מקורות. בלי 2-3 מקורות חיצוניים שמאמתים את הסטייטמנטים, הערך מסומן לסקירה ובלי טיפול ימחק תוך שבועות. אחרון, חוסר identifiers. ערך בלי קישור ל-Twitter/LinkedIn/GitHub נראה ריק. תוסיפו כל identifier שיש, אפילו אם לא נראה לכם רלוונטי.

✅ ‏Claimed Knowledge Panel, איך תובעים בעלות

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

‏מי יכול לתבוע

• ‏אדם פרטי שיש לו Panel על עצמו
• ‏בעל עסק רשמי שיש לו Panel על העסק
• ‏נציג של ארגון שיש לו Panel
• ‏בעל ערוץ YouTube (ערוצים עם 10K+ סאבסקרייברים בדרך כלל מקבלים Panel אוטומטית)

‏תהליך התביעה ב-5 שלבים

1. ‏היכנסו לגוגל עם חשבון Google רשמי

   ‏חשבון של ההמייל הראשי של העסק/האדם, לא חשבון ערוץ או חשבון משני

2. ‏חפשו את עצמכם בגוגל

   ‏אם הופיע Panel, מתחתיו תראו "Claim this knowledge panel". אם לא רואים, ה-Panel עוד לא קיים או לא נמצא בו

3. ‏הזדהו דרך פרופיל ציבורי

   ‏גוגל תבקש לוודא דרך אחד מהפרופילים המקושרים, YouTube, Twitter, Wikipedia, או דרך אתר רשמי. צריכה להיות הפניית קישור הדדית בין הפרופיל לבין האתר

4. ‏השלימו את האימות

   ‏גוגל תשלח אימות נוסף דרך הפרופיל המאומת. תהליך לוקח עד 14 ימים

5. ‏עדכנו פרטים

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

‏מה אתם יכולים ולא יכולים לשנות

‏Public Figures, אומנים, יזמים

‏לאומנים יש Knowledge Panel מיוחד שכולל discography, ראיונות, סרטונים. נציגי האומן (לרוב חברת ההפקה) צריכים לתבוע דרך "Music Knowledge Panel" או "Video Knowledge Panel". עבור יזמים ובעלי עסקים, התביעה היא דרך Google Business Profile אם זה עסק מקומי, או דרך פרופיל ציבורי אם זה דמות עסקית.

‏עוד נקודה חשובה, מה קורה כשגוגל דוחה את התביעה

‏לפעמים גוגל דוחה תביעת בעלות, גם כשאתם באמת הבעלים. הסיבה הנפוצה ביותר, פרופיל ה-Google שאתם משתמשים בו לא מקושר לישות. דוגמה, אתם מנסים לתבוע Panel של חברה תחת שם אישי, או של דמות ציבורית תחת חשבון שלא קשור לאתר הרשמי. הפתרון, פותחים חשבון Google תחת המייל הראשי של העסק/האדם, מוודאים שהמייל הזה מופיע באתר הרשמי, מוסיפים את הפרופיל לאתר, ואז מנסים שוב. גוגל מאשרת כשיש שרשרת אימות ברורה. במקרים מורכבים (דמויות ידועות עם חברות הפקה), כדאי לפנות לתמיכה של Google דרך Google My Business support, הם מטפלים בבקשות תביעה גם של Knowledge Panels.

🤖 ‏Knowledge Graph ו-AI Overviews, הקשר ההדוק

‏אם לא מתעניינים ב-AI Overviews, אפשר לדלג על הפרק הזה. אבל כל מי שעוקב אחרי ה-CTR שלו ב-2024-2026 רואה שירידה ב-clicks חרף עליה ב-impressions. הסיבה, AI Overviews חוטפים את ה-click. והאיך של מי מצוטט שם, הולך ישר ל-Knowledge Graph.

‏איך AI Overviews בוחרות מקורות

‏ההנדסה של AI Overviews לא חשופה במלואה, אבל מתוך ניתוח מאות מקרים ראיתי שלושה דפוסים חוזרים. אחד, ישויות מהגראף מקבלות עדיפות כמקור. שתיים, עמודים מאתרים עם authority גבוהה ועם schema מלא מצוטטים יותר. שלוש, גוגל בוחרת לרוב 3-5 מקורות, מהם 1-2 הם entity sources (Wikipedia, אתר רשמי של הישות) ו-2-3 הם content sources (בלוגים, מאמרים שמסבירים).

‏אם אתם entity, אתם בעמדה

‏לקוחות שלי שעבדו על entity SEO ב-2 השנים האחרונות מקבלים בממוצע פי 4-7 ציטוטים ב-AI Overviews מלקוחות שלא עבדו. הסיבה היא לא כי הם כותבים תוכן טוב יותר, אלא כי גוגל מזהה אותם כמקור entity. הכותב המצוטט הופך ל-entity, האתר המצוטט הופך ל-entity, החברה המצוטטת הופכת ל-entity. רשת ההכרה הזאת מזינה את עצמה.

‏Knowledge Graph כשכבת אמת

‏בעיני AI Overviews, Knowledge Graph היא שכבת האמת. אם תכתבו על עצמכם בפסקה ופסקה אחרת באתר אחר תכתוב משהו אחר, גוגל תפנה לגראף שלה לראות מה האמת. הישות בגראף היא קביעת הקרקע. אם בגראף אתם מסומנים כ-"יועץ SEO ישראלי", AI Overviews תצטט אתכם בהקשרי SEO. אם אין אתם בגראף, AI Overviews לא תדע איך לסווג אתכם, ולכן לא תצטט.

‏AI Mode, הצעד הבא

‏AI Mode (שגוגל החלה להפיץ ב-2025) הולך לעמיק את התלות בגראף. במקום SERP של 10 קישורים כחולים, אנחנו מקבלים שיחה שלמה עם תקצירים, וכל תקציר מצטט מקורות. הציטוטים בכמעט כל פעם מסתמכים על entity recognition. אתם לא entity, אתם לא בשיחה. נקודה.

‏מה לעשות עכשיו

‏תתחילו במה שמתורגם בקלות, הטמעת סכמת Person + Organization מלאה בכל עמוד אודות, יצירת ערך Wikidata אם אין לכם, והוספת sameAs לכל הפרופילים החיצוניים. זה מה שתוכלו לעשות היום, בלי לחכות חודשים. אחר כך, תבדקו את ההופעות שלכם ב-AI Overviews לשאילתות המרכזיות שלכם. אם אין תשובה, זה האות שלכם, צריך לחזק את ה-entity. אם אתם מופיעים, תמשיכו לעדכן מה שעובד.

🎓 ‏Entity SEO כדיסציפלינה נפרדת, מה זה ולמה זה לא keyword SEO

‏רוב אנשי ה-SEO גדלו על keyword research. בחרת מילת מפתח, אופטמזת עמוד, רדפת אחרי backlinks, וקיבלת דירוג. זה עבד עד 2018. החל מ-2019, וביתר שאת מ-2024, נכנס לחיים שלנו ענף חדש, Entity SEO. תקשיבו, זה לא אותו דבר ולא דומה. זאת דיסציפלינה אחרת לחלוטין.

‏Keyword SEO מול Entity SEO

‏למה אתם צריכים את שניהם

‏Entity SEO לא מחליפה Keyword SEO. היא משלימה. בלי תוכן טוב, אין לכם מה להציע. אבל בלי entity recognition, התוכן שלכם לא יזוהה כסמכותי. ב-2026, אסטרטגיית SEO שלמה כוללת את שני העולמות. תוכן ממוקד מילת מפתח, מקושר לישות חזקה, עם schema מלא, אזכורים חיצוניים. זאת השלמות.

‏המעבר התפיסתי

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

‏איך מתחילים מ-keyword ל-entity

‏אם אתם איש SEO ותיק שרוצה לעבור, ההמלצה שלי, התחילו בלקוח אחד, ובחרו אדם או חברה ספציפיים שאתם רוצים לבנות להם entity. במקום לתכנן 50 מאמרים על מילות מפתח, תכננו את הישות. כתבו את ה-canonical description שלה, רשמו את כל הפרופילים שיש לה, זהו את הפערים (איפה אין לה presence). אז בנו תוכנית לבניית הפערים. כעבור 12 חודשים, תראו את ההבדל. ה-impact של בניית entity אחת חזקה גדול יותר מ-50 מאמרי SEO גנריים, וזה ההכשרה הכי טובה למעבר התפיסתי.

‏הכלים שמפרידים בין שני העולמות

‏כלי keyword SEO רגילים (Ahrefs, Semrush) לא עוזרים ל-entity. הם בנויים לdomain-level analysis, לא לישויות. ל-entity SEO צריך כלים שונים, Wikidata Query Service (SPARQL), schema.org validators, brand monitoring tools. רוב הסוכנויות עוד לא הצטיידו בכלים האלה, וזאת ההזדמנות של מקדמים בודדים, להכנס לתחום שעוד פתוח.

💬 ‏brand mentions ו-implicit links, איך גוגל סופרת אזכורים בלי קישור

‏לפני 2014, אם רציתם אישור מאתר אחר, היה צריך קישור. עם קישור = פוטר. בלי קישור = נשכח. מאז ש-Knowledge Graph בגרה, גוגל סופרת גם brand mentions ללא קישור ("implicit links"). זה שינה את מערכת הסיגנלים לחלוטין, ומאפשר ל-entities לבנות סמכות בלי לרדוף אחרי backlinks.

‏מה זה implicit link

‏אזכור של ישות (שם של אדם, חברה, מוצר) בטקסט, גם בלי קישור hyperlink. גוגל מזהה את הישות בטקסט (דרך NLP), מקשרת אותה ל-entity בגראף, וסופרת את האזכור כסיגנל סמכות לאותה ישות. לפי פטנט של גוגל מ-2014 (Ranking Search Results), implicit links עשויים לקבל אותו משקל כמו backlinks קלאסיים בהקשרים מסוימים.

‏איך לוודא שגוגל מזהה את האזכור

• ‏השם של הישות חייב להופיע במלואו, לא רק בחלקים. "שמוליק דורינבאום" ולא רק "שמוליק"
• ‏האתר המאזכר צריך להיות סורק (לא noindex, לא robots.txt blocking)
• ‏האזכור חייב להיות בהקשר רלוונטי. "שמוליק דורינבאום, יועץ SEO" ייספר. "שמוליק יום הולדת שמח" לא ייספר כסיגנל מקצועי
• ‏עדיף שיופיע ב-content, לא רק ב-comments או ב-footer

‏Co-occurrence, אזכור משותף

‏בעידן Entity SEO, גוגל גם בוחנת אזכור משותף. אם השם שלכם מופיע באופן עקבי ליד שמות של מותגים מובילים אחרים בתחום, גוגל מסיקה שאתם בליגה דומה. דוגמה, אם שמוליק דורינבאום מוזכר בכתבה ליד Rand Fishkin ו-Aleyda Solis, גוגל מסיקה שהוא בלוקיישן דומה. זה לא קישור, זה co-occurrence, וזה סיגנל חזק.

‏הסיפור האישי

‏ב-2017, לקוח שלי, חברת תוכנה ישראלית, לא הצליחה להגיע לדירוגים גבוהים על מילות המפתח שלה. סקרנו את ה-backlinks, היו 200, רובם איכותיים. אבל אז זיהינו שיש לה 1,200 אזכורים בלי קישור באתרי news ובבלוגים מקצועיים בארה"ב. עברנו לאסטרטגיית entity, יצרנו Wikidata, עדכנו schema, ויצרנו עמוד אודות חזק. תוך 9 חודשים, החברה קיבלה Knowledge Panel וקפצה לדירוגים גבוהים על כל המילים. ה-implicit links היו שם כל הזמן, רק שגוגל לא הצליחה לקשור אותם לישות מאחר ולא היה לה profile entity מובהק. זאת הסיבה ש-schema + Wikidata קריטיים, הם הגשר בין האזכורים שיש לכם לבין ה-entity recognition.

‏כלים למעקב אחר brand mentions

‏יש כלים יעודיים למעקב אחר אזכורים בלי קישור. Mention, Brand24, ‏Brandwatch ‏(בתשלום), ‏Google Alerts (חינם, לא הכי מדויק). הקריטריון הראשי שאני מחפש, האם הכלי תופס גם אזכורים בלי קישור (text-only mentions). רוב הכלים הזולים יודעים רק אזכורים עם קישור, וזה לא עוזר ב-entity SEO. בדקו לפני שאתם נרשמים. בנוסף, חיפוש ידני ב-Google עם quoted name ("שמוליק דורינבאום") מראה את כל האזכורים ב-public web, וזאת בדיקה חינמית טובה לתחילה.

‏השאלה החשובה לכל מאמר

‏בכל פעם שאתם כותבים מאמר על מישהו או על משהו, שאלו את עצמכם, "האם הזכרתי את השם המלא?". "שמוליק" לא נחשב, "דורינבאום" לא נחשב, רק "שמוליק דורינבאום" נחשב. "בלוג של שמול" לא נחשב, "shmul.co.il של שמוליק דורינבאום" כן נחשב. עקביות בשמות מלאים היא ההבדל בין סיגנל ל-entity לבין רעש אקראי בעיני גוגל. אל תקצרו שמות בכתבות שלכם, ואל תרשו לעיתונאים שכותבים עליכם לקצר. נקודה.

🌍 ‏אתגרי MENA, איך עברית וערבית מטופלות בגראף

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

‏המצב בעברית

• ‏Knowledge Graph קיים בעברית מ-2017 בערך, אבל הכיסוי קטן משמעותית מאשר באנגלית
• ‏Wikipedia בעברית הוא מקור עיקרי, אבל הוא קטן (כ-365K ערכים מול 6.9M באנגלית)
• ‏Wikidata תומך בעברית מצוין, אז ערך Wikidata בעברית כן יוצר entity recognition
• ‏Knowledge Panels בעברית מופיעים פחות, ופחות עשירים מאשר באנגלית
• ‏AI Overviews בעברית עדיין מתפתחות (החלו 2025), אבל פחות עקביות מהאנגלית

‏המצב בערבית

• ‏Wikidata תומך בערבית, וערך ערבי הוא חובה ליצירת entity לישות ערבית
• ‏Wikipedia בערבית גדול יותר מהעברי (כ-1.2M ערכים), אז הוא מקור משמעותי
• ‏ישויות ערביות שמופיעות גם באנגלית מקבלות כיסוי טוב יותר בגראף
• ‏Knowledge Panels בערבית פחות נפוצים אבל יש

‏האסטרטגיה ל-MENA

‏1. דאגו לערך Wikidata בעברית/ערבית + אנגלית

‏ערך Wikidata אחד יכול להיות multilingual. השדה label תומך בעשרות שפות. תוסיפו את השם בעברית, אנגלית, וערבית (אם רלוונטי). זה יתפוס בכל הגאוגרפיות.

‏2. עברו לאתר דו-לשוני

‏אם אתם יועצים/חברה שמכוונים גם לישראל וגם לארה"ב, תיצרו גרסה דו-לשונית של עמוד האודות. שני עמודים, אותה ישות, מקושרים זה לזה דרך hreflang ו-sameAs בסכמה. גוגל תקשר ביניהם.

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

‏אזכור באנגלית באתר עם authority גבוה (TechCrunch, Forbes, Reuters) שווה פי 10 מאזכור בעברית מאתר ישראלי קטן. גוגל מתייחסת אליו יותר רצינית.

‏סינים, יפנים, וקוריאנים

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

‏איך מותגים ישראלים גדולים פתרו את זה

‏Wix, Fiverr, Monday.com, Lemonade, כל המותגים האלה התחילו ישראלים, אבל כולם בנו את ה-entity שלהם בעיקר באנגלית. הסיבה, גוגל מכירה אותם הרבה יותר טוב באמצעות אזכורים באמריקאיים ובאירופאיים. ערך Wikidata באנגלית, ערך Wikipedia באנגלית, אזכורים ב-TechCrunch, Forbes, Bloomberg. אחרי שהאנגלית התבססה, אז הם הוסיפו labels עבריים ל-Wikidata, ועברו לפעול בעברית. ההמלצה הזאת לא יושמת רק לסטרטאפים, כל עסק ישראלי שיש לו שאיפה בינלאומית כדאי שיתחיל באנגלית, גם אם הקהל העיקרי בעברית. הכניסה לגראף תהיה מהירה ועמוקה יותר.

‏הממשלה הישראלית והגראף

‏גם אתרי ממשלה ישראליים מקבלים טיפול מעולה בגראף, כי הם מעוגנים ב-Open Data feeds של הממשלה. משרד הבריאות, משרד החינוך, הלמס, כל אלה מזינים feeds שהגראף אוכל. אם אתם ממסוד ישראלי רשמי, יש לכם יתרון גדול בשעת הכניסה לגראף, המידע שלכם מגיע ממקור מהימן בעיני גוגל, וקיומו בגראף מהיר יותר.

🔮 ‏עתיד Knowledge Graph בעידן AI search

‏אנחנו ב-2026, נחזה ל-2030. תקשיבו, אני לא נביא, אבל יש 20 שנה של ניסיון שאומרים לי שכמה מגמות הולכות להעמיק. כמה ספציפית סובבות סביב Knowledge Graph.

‏4 מגמות שיעצבו את העתיד

‏1. הגראף יהפוך לעמוד שדרה של כל AI search

‏ChatGPT, ‏Claude, ‏Perplexity, ‏Gemini, כל מנועי AI הגדולים בונים גרפים של ישויות משלהם. גוגל היא היחידה שיש לה גראף מבוסס שמכסה את האינטרנט כולו, וזאת המנוף שלה. ב-5 השנים הקרובות, נראה איחוד בין מנועים שונים שיתחילו לעבוד עם המבנה Wikidata אבל ידחפו ה-MID של גוגל כמזהה אוניברסלי.

‏2. ישויות חיות יקבלו עדכוני real-time

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

‏3. Multimodal entities

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

‏4. Decentralized entity protocols

‏יש דיבורים על פרוטוקולים מבוזרים לזהות entities (לא בהכרח blockchain, אלא standards open). אם זה יקרה, גוגל לא תהיה מונופול על entity recognition. כל מנוע AI יוכל לקרוא את אותם entity profiles. זה ייתן יותר כוח לבעלי ישויות, פחות לפלטפורמות.

‏העובדה הקשה לעיכול

‏אתרים שלא יבנו entity ב-3 השנים הקרובות יהפכו כמעט בלתי-נראים בעידן ה-AI search. לא ייעלמו מהאינטרנט, אבל לא יקבלו תנועה אורגנית משמעותית. גוגל תפסיק לשלוח אליהם clicks (כי AI Overviews עונים על השאלות), ואחרים לא יודעים שהם קיימים. זה מעבר מאיטי אבל בלתי נמנע.

‏החזון שלי ל-2030

‏אני רואה את ה-SEO ב-2030 חצוי לשניים. Entity SEO מקצועני, שעוסק בבניית זהויות דיגיטליות חזקות לאנשים ולחברות. Content SEO מקצועני, שעוסק ביצירת תוכן שמיועד גם ל-humans וגם ל-AI engines ("Generative Engine Optimization"). שתי הדיסציפלינות יעבדו יחד, כל אחת חיונית לזולתה. הקשר ביניהן יהיה Knowledge Graph, שכבת האמת שמחברת בין הזהות לבין התוכן.

📅 ‏צ'ק ליסט חודשי + workflow ל-10 שלבים לבניית נוכחות entity

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

‏צ'ק ליסט חודשי, 8 משימות

• ‏בדקו את brand SERP שלכם (חיפוש על השם המלא), וודאו שהתוצאות העליונות הן עדיין שלכם
• ‏עדכנו ערך Wikidata עם תכונות חדשות, ראיון שעשיתם, פרס שקיבלתם, חברה חדשה שהצטרפתם אליה
• ‏סרקו את כל הפרופילים החיצוניים (LinkedIn, Twitter, GitHub) לוודאות שעקבי
• ‏פרסמו תוכן חדש על האתר עם schema מלא ועם הזכרה של השם המלא שלכם
• ‏בדקו את ה-Knowledge Panel (אם יש), עדכנו פרטים אם נדרש
• ‏בקשו ראיון/אזכור באתר אחד מקצועי בתחומכם (1 בחודש = 12 בשנה = הרבה implicit links)
• ‏בדקו את ה-schema validator על עמוד האודות שלכם, וודאו שאין שגיאות
• ‏עקבו אחרי הופעות ב-AI Overviews (Brand-mention monitoring tools או חיפושים ידניים)

‏workflow מלא ל-10 שלבים, לבניית entity מאפס

1. ‏הגדירו את הישות באופן ברור

   ‏מי אתם? אדם, חברה, מותג, מוצר? מה התואר הראשי? כתבו תיאור של 50-100 מילים שיהיה ה-canonical description שלכם בכל מקום

2. ‏בנו עמוד אודות איכותי

   ‏עמוד פני אחד שמתאר אתכם במלואו, עם תמונה, biography, חברות, פרסים, פרסומים, צוות, פרופילים חיצוניים

3. ‏הוסיפו Person/Organization schema מלא

   ‏JSON-LD ב-@graph עם כל התכונות הרלוונטיות. sameAs לכל הפרופילים החיצוניים. המדריך לסכמת Person

4. ‏צרו פרופילים בכל הרשתות הרלוונטיות

   ‏LinkedIn, Twitter, Facebook, YouTube, GitHub, Crunchbase (אם רלוונטי). אותו שם, אותה תמונה, אותו תיאור

5. ‏צרו ערך Wikidata

   ‏עם 3+ מקורות חיצוניים, כל התכונות הרלוונטיות, וכל ה-identifiers החיצוניים

6. ‏השיגו 3-5 אזכורים בעיתונות מקצועית

   ‏ראיונות, פוסטים אורחים, ציטוטים בכתבות. כל אחד מהם בונה את ה-trust בגראף

7. ‏וודאו שהאתר ה-canonical מקושר מכל הפרופילים

   ‏Twitter bio, LinkedIn profile, GitHub bio, כולם צריכים לקשר לאתר ה-canonical שלכם. זה מסגיר לגוגל איזה אתר רשמי

8. ‏בנו brand SERP נקי

   ‏עמודים על השם שלכם בעמדות 1-5 צריכים להיות שלכם. אם יש שם מתחרה, השקיעו ב-SEO ספציפי על השם

9. ‏חכו 3-9 חודשים

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

10. ‏תבעו את ה-Panel כשהוא מופיע

    ‏אם הופיע Knowledge Panel, תבעו עליו בעלות, ועדכנו פרטים כפי שתואר בפרק הקודם

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