WebSite Schema + SearchAction, איך משיגים את ה-sitelinks searchbox

🌐 מה זה WebSite schema, ולמה זה לא WebPage

תקשיבו. אני אפתח עם הסיפור שאני שומע פעם בשבועיים. מקדם מתקשר, "שמוליק, יש לי schema באתר, הטמעתי Article ו-FAQPage על כל עמוד. למה גוגל לא מציג לי את ה-searchbox כשמחפשים את הברנד שלי?" אני בודק את האתר. אין WebSite schema בכלל. רק WebPage על כל עמוד בנפרד. נחשו למה ה-sitelinks searchbox לא מופיע?

WebSite זה לא WebPage. WebPage הוא עמוד יחיד, WebSite הוא האתר כישות שלמה. ההבדל קריטי, גוגל צריך לדעת "מי האתר הזה, מה השם הברנדי שלו, איפה החיפוש הפנימי שלו, מי ה-publisher". אלה דברים שלא נמצאים בעמוד יחיד, הם נמצאים ברמת האתר.

WebSite היא ה-foundational schema של כל אתר. בלי זה, גוגל בונה את הזהות של האתר מסיגנלים פחות אמינים (title של homepage, NAP, social profiles). עם WebSite schema תקין, יש לכם declaration ברור, "זה האתר שלי, זה השם שלו, ככה מחפשים בו, וזה ה-publisher שעומד מאחוריו". זה ההבדל בין אתר שגוגל מבין לבין אתר שגוגל מנחש.

למה זה foundational

ה-WebSite schema הוא ה-anchor לכל שאר ה-schemas באתר. כשאתם מטמיעים Article schema על מאמר, אתם מקשרים אותו ל-WebSite דרך isPartOf. כשאתם מטמיעים WebPage, אותו דבר. כל ה-schemas באתר מצביעים בחזרה ל-WebSite דרך reference. בלי WebSite, ה-graph שלכם נשבר, וכל schema עומד בפני עצמו בלי context.

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

15 פרקים שמתחילים מהבסיס (מה זה WebSite, למה הוא foundational, ה-properties החיוניים), עוברים ל-pattern של SearchAction (איך לבנות נכון את ה-target template), צוללים ל-sitelinks searchbox (מה זה, מי מקבל, איך בודקים), ומסיימים בדוגמאות קוד JSON-LD מלאות עם @graph, ב-validation, ובטעויות נפוצות. בסוף, אם תטמיעו את הקוד הנכון, אתם תהיו בשטח הקטן של 5% מהאתרים בישראל עם WebSite schema תקין עם SearchAction. רוב המקדמים בארץ מטמיעים רק Article/FAQPage, ‏זה advantage אמיתי.

השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO. אישית טיפלתי בהטמעת schema במאות אתרים, ובכל פעם שהוספנו WebSite + SearchAction תקין לאתר שלא היה לו, ראינו את ה-sitelinks searchbox מופיע על הברנד תוך 2-6 שבועות. אם אחרי המאמר אתם תקועים בהטמעה, יש לכם איך לדבר איתי ישירות.

⚡ למה זה foundational, ‏sitelinks searchbox + Organization knowledge panel + AI engines

WebSite schema הוא לא רק עוד schema. הוא ה-prerequisite ל-3 features שונים, וכל אחד מהם משפיע על SERP אחר. אם אתם מטמיעים schemas אחרים בלי WebSite, אתם מפספסים 3 הזדמנויות במקביל.

1. Sitelinks searchbox ב-Brand SERP

כשמישהו מחפש את הברנד שלכם בגוגל, אתם רוצים שיופיע sitelinks searchbox מתחת לכותרת של האתר שלכם. זה תיבת חיפוש שמאפשרת לגולש לחפש בתוך האתר שלכם ישירות מ-Google. הוא מקליד שם הברנד + מילת חיפוש + Enter, ונופל ישר על תוצאות החיפוש הפנימיות שלכם. ה-feature הזה דורש WebSite schema עם SearchAction. בלי זה, גם אם הברנד שלכם מקבל 50,000 חיפושים בחודש, הוא לא יופיע.

2. Organization knowledge panel enhancement

כשגוגל מזהה אתכם כ-Organization, הוא יכול להציג Knowledge Panel ימני (בעיקר לברנדים גדולים, ‏אבל גם לעסקים קטנים אם יש לכם signals טובים). ה-WebSite schema, ‏בעיקר כשהוא מקושר ל-Organization דרך publisher, ‏מחזק את ה-signal הזה. הוא אומר לגוגל "זה האתר הרשמי של ה-Organization הזה". בלעדיו, גוגל יכול לבלבל בין האתר שלכם לבין אתרים אחרים שמזכירים אתכם.

3. AI engines, ‏הבנת זהות האתר

ChatGPT, Perplexity, Claude, Gemini, Copilot, כולם משתמשים ב-structured data כדי להבין מה האתר שלכם. כשהם נשאלים "מה זה shmul.co.il", הם הולכים ל-homepage, סורקים את ה-JSON-LD, ומחפשים את ה-WebSite entity כדי להבין את הזהות. בלעדיו, הם נופלים על parsing של ה-HTML, וזה פחות אמין. עם WebSite schema, ‏יש להם תשובה מובנית, "זה אתר X, של Organization Y, עם url Z". הסיכוי שהם יצטטו אתכם מדויק עולה משמעותית.

למה רוב המקדמים מפספסים

אני מבין למה. WebSite schema נראה "בנאלי". יש לו רק 2 properties required (url + name), והוא לא מציג rich result מיידי כמו Article או Recipe. אז מקדמים מדלגים. אבל הם מפספסים את הנקודה, WebSite הוא לא schema שמציג rich result בעצמו, הוא ה-foundation שמאפשר ל-features אחרים להופיע. בלי הבסיס, הכל קורס.

📋 Required + Recommended properties, ‏מה חובה ומה מומלץ (עם קוד)

אם תזכרו רק שני דברים מהמאמר הזה, שיהיו אלה, url + name. אלה ה-required properties של WebSite לפי schema.org ולפי גוגל. אם תכתבו רק את שני אלה, ה-schema יעבור validation. אבל אם תוסיפו את ה-recommended (potentialAction עם SearchAction, ‏alternateName, ‏publisher, ‏inLanguage), תקבלו את ה-features המלאים.

Required, ‏url + name

url, ‏ה-URL הקנוני של האתר. תמיד עם https, ‏תמיד עם www או בלי www (לפי הקנוני שלכם, אבל עקבי), ‏תמיד עם slash בסוף. דוגמה, "url": "https://www.shmul.co.il/".

name, ‏שם האתר. השם המסחרי, ‏לא ה-URL. דוגמה, "name": "shmul.co.il" או "name": "שמוליק דורינבאום, SEO". תהיו עקביים עם איך שאתם מציגים את שם האתר ב-title, ‏ב-logo, ‏וב-Google Business Profile (אם רלוונטי).

דוגמת קוד מינימלית

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://www.shmul.co.il/",
  "name": "shmul.co.il"
}
</script>

זה ה-schema המינימלי שיעבור validation. אבל הוא לא יקבל sitelinks searchbox (חסר SearchAction) ולא יחזק Knowledge Panel (חסר publisher). זה ה-baseline בלבד.

Recommended, ‏potentialAction (SearchAction)

זה ה-property שמפעיל את ה-sitelinks searchbox. potentialAction הוא array של פעולות שהמשתמש יכול לבצע באתר, ובמקרה של WebSite זה תמיד SearchAction עם target template ו-query input.

Recommended, ‏alternateName

שם משני של האתר. אם הברנד שלכם נקרא ב-2 שמות (לדוגמה "Shmul" וגם "Shmul.co.il", או "שמוליק דורינבאום" וגם "Shmul SEO"), כתבו את הראשי ב-name ואת השני ב-alternateName. גוגל יקלוט את שני השמות וייתן sitelinks searchbox על שניהם.

Recommended, ‏publisher

reference ל-Organization שמפרסם את האתר. ב-@graph, ‏הוא יצביע על Organization entity נפרד דרך @id. ב-script נפרד, ‏זה יכול להיות nested object. בעמוד הבא נצלול לפרטים על ה-relationship הזה.

Recommended, ‏inLanguage

השפה הראשית של האתר. לאתר בעברית, "inLanguage": "he" (ISO 639-1). לאתר באנגלית, "en". לאתר רב-לשוני, ‏ארגון של inLanguage לפי כל subdomain או path נפרד.

Recommended, ‏description

תיאור קצר של האתר. עוזר ל-AI engines להבין על מה האתר. שמרו את זה תחת 160 תווים, ‏עברית טבעית, ‏בלי מפתחות-עץ סתם.

🔍 SearchAction pattern, ‏הקוד שמפעיל את ה-sitelinks searchbox

ה-SearchAction הוא לב לבו של ה-WebSite schema, וגם החלק שמקדמים הכי טועים בו. ה-pattern עצמו לא מסובך, אבל יש בו 3 components שכולם חייבים להיות תקינים, אחרת ה-feature לא יופיע.

המבנה

"potentialAction": {
  "@type": "SearchAction",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://www.shmul.co.il/?s={search_term_string}"
  },
  "query-input": "required name=search_term_string"
}

1. @type, ‏SearchAction

תמיד "@type": "SearchAction". לא Action כללי, ‏לא ReadAction, ‏לא ViewAction. רק SearchAction. כי זה הטיפוס שגוגל מחפש כדי להפעיל sitelinks searchbox.

2. target, ‏ה-URL template של החיפוש

זה ה-component הכי קריטי. ה-target הוא EntryPoint object עם urlTemplate שמתאר איך ה-URL של תוצאות החיפוש נראה באתר שלכם. ה-placeholder {search_term_string} הוא איפה גוגל יחליף את המחרוזת שהמשתמש הקליד.

הדוגמאות הנפוצות לפי פלטפורמה,

• WordPress, ‏https://www.example.co.il/?s={search_term_string}
• Shopify, ‏https://www.example.co.il/search?q={search_term_string}
• Wix, ‏https://www.example.co.il/search-results?q={search_term_string}
• Static site עם custom search, ‏מה שאתם בניתם, לדוגמה https://www.example.co.il/search?query={search_term_string}

3. query-input, ‏ההצהרה על הפרמטר

תמיד "query-input": "required name=search_term_string". זה אומר לגוגל, "הפרמטר ב-URL נקרא search_term_string והוא חובה". אם אתם משתמשים בשם פרמטר אחר ב-urlTemplate (לדוגמה {q} או {query}), חייבים לעדכן גם פה כדי שיהיו עקביים.

דוגמה מלאה לאתר WordPress עברית

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://www.shmul.co.il/",
  "name": "shmul.co.il",
  "inLanguage": "he",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://www.shmul.co.il/?s={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

איך לבדוק שה-search URL באמת עובד

לפני שאתם מטמיעים את ה-schema, ‏פתחו את ה-urlTemplate במשתמש מבחנה, ‏החליפו {search_term_string} במילה אמיתית (לדוגמה "בדיקה"), ‏וגלשו ל-URL. אם הוא מחזיר תוצאות חיפוש תקינות, ‏ה-schema יעבוד. אם הוא 404 או מציג עמוד ריק, ‏הקודים שלכם לא נכונים והשם הזה לא יעזור.

🔎 Sitelinks searchbox, ‏מה זה ומי מקבל

sitelinks searchbox הוא feature ספציפי בתוצאות החיפוש של Google שבא בעיקר על Brand SERP. כשמישהו מחפש את שם הברנד שלכם בגוגל (לדוגמה "שמוליק דורינבאום" או "shmul.co.il"), אם זכיתם ב-feature הזה, הוא יראה את התוצאה הראשית שלכם, ומתחת לה תיבת חיפוש נוספת עם הטקסט "חיפוש ב-shmul.co.il". כשהוא מקליד מילת חיפוש בתוך התיבה ולוחץ Enter, גוגל מפנה אותו ישירות לעמוד תוצאות החיפוש הפנימי שלכם, לא לעמוד תוצאות של Google.

למה זה בעל ערך

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

מי מקבל את ה-feature

גוגל לא מתחייב להציג sitelinks searchbox לכל אתר עם WebSite + SearchAction schema. הוא בודק כמה תנאים,

1. חיפוש פנימי פעיל באתר

   חייב להיות חיפוש פנימי שעובד באתר, ב-URL שמתאים ל-urlTemplate שב-schema. גוגל בודק את זה אקטיבית. אם הוא נופל על 404, ‏ה-feature לא יופיע.

2. WebSite schema עם SearchAction

   WebSite + potentialAction (SearchAction) + target + query-input, ‏הכל תקין ועובר validation.

3. חיפושים brandedים על האתר

   גוגל בודק האם הברנד שלכם מקבל "branded searches" משמעותיים. אם 1000 איש בחודש מחפשים "shmul.co.il" או "שמוליק דורינבאום", זה signal חזק. אם 5 איש בחודש, גוגל לא יציג sitelinks searchbox כי אין מי שיחפש.

4. איכות כללית של האתר

   אתר עם תוכן איכותי, ‏סמכות, ‏ו-trust signals חזקים. גוגל לא יתן sitelinks searchbox לאתר ספאמי, גם אם הוא הטמיע schema מושלם.

איך זה נראה ב-mobile

ב-mobile, ‏ה-sitelinks searchbox מופיע מתחת לתוצאה הראשית שלכם, ‏במקום של ה-sitelinks הרגילים (4-6 קישורים פנימיים). על desktop, ‏זה תיבה רחבה. על mobile, ‏תיבה מותאמת לרוחב המסך. שניהם פותחים אותו פלואו, ‏הקלדה + Enter + נחיתה על עמוד תוצאות החיפוש שלכם.

אם אתם מאבדים את ה-feature

קורה לפעמים, ‏היה לכם sitelinks searchbox ופתאום הוא נעלם. הסיבות, ‏(1) שיניתם את URL של החיפוש הפנימי בלי לעדכן את ה-schema, (2) החיפוש הפנימי נשבר טכנית והחזיר 500 ל-Googlebot, (3) ירידה בכמות החיפושים הברנדיים שלכם, (4) שינוי באלגוריתם של Google. בדקו את ה-Search Console ל-warnings, ובדקו ידנית שה-urlTemplate שב-schema באמת עובד.

✅ Eligibility criteria, ‏מה צריך כדי להופיע באמת

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

1. חיפוש פנימי פעיל ב-URL שמתאים ל-schema

זה הקריטריון הכי טכני, וגם הכי קל לבדיקה. פתחו את ה-urlTemplate שב-schema. החליפו את {search_term_string} במילה אמיתית. גלשו ל-URL. אם הוא מחזיר עמוד תקין עם תוצאות חיפוש, ‏הקריטריון מתקיים. אם הוא 404, ‏או מציג עמוד ריק, ‏או מפנה לעמוד הבית, ‏אתם לא עומדים בו. תיקנו את החיפוש הפנימי לפני שאתם מצפים ל-feature.

2. WebSite schema תקין עם potentialAction

הריצו את ה-URL של ה-homepage שלכם ב-Rich Results Test (search.google.com/test/rich-results). וודאו ש-Google זיהה WebSite entity, ‏ושיש לו potentialAction עם SearchAction. אם Google לא מזהה את ה-schema, ‏יש בעיה בהטמעה (טעות תחבירית, ‏מיקום שגוי של ה-script, ‏וכו'). תקנו ואמתו שוב.

3. חיפושים brandedים בכמות מינימלית

גוגל לא חושף את הסף המינימלי, אבל לפי הניסיון של הקהילה, אתרים שמקבלים פחות מ-50-100 חיפושים brandedים בחודש לעיתים נדירות מקבלים sitelinks searchbox. בדקו ב-Google Search Console, Performance > Search Results, סננו לפי Queries המכילים את שם הברנד שלכם, וראו את הספירות. אם אתם חדשים בעולם או אם הברנד שלכם לא מוכר עדיין, ‏ה-feature לא יופיע גם עם schema מושלם. הוא יופיע כשהברנד יתחיל לקבל חיפושים.

4. trust signals חזקים

גוגל לא נותן sitelinks searchbox לכל אתר. הוא מעדיף אתרים עם,

• היסטוריה ארוכה (מעל שנה לרוב)
• תוכן איכותי שמקבל links חיצוניים
• זהות ברנד ברורה (Organization schema, ‏NAP עקבי, ‏social profiles)
• הימנעות מ-manual actions או מ-spam policy violations
• HTTPS מלא ללא mixed content
• core web vitals תקינים

אתר עם schema מושלם אבל עם תוכן ספאמי או עם manual action, לא יקבל sitelinks searchbox. גוגל לא מסתכן בלהפנות גולשים לאתר שהוא לא מאמין לו.

אם אתם עומדים בכל ה-4 ועדיין אין feature

חכו עוד. גוגל יכול לקחת 2-6 שבועות עד שהוא מציע feature חדש. אם אחרי 8 שבועות עדיין אין, חזרו לבדוק את ה-4 הקריטריונים שוב, וודאו שלא נשבר משהו בדרך (שינוי URL של חיפוש, ‏פגיעה ב-trust signals, ‏וכו').

🔬 איך בודקים אם זכיתם, ‏פשוט חפשו את הברנד ב-Google

אחרי שהטמעתם schema תקין ועברו 2-6 שבועות, איך תדעו אם זכיתם ב-sitelinks searchbox? הדרך הפשוטה ביותר היא לחפש את שם הברנד שלכם ב-Google ולראות בעיניים. אבל יש דקויות שצריך לדעת כדי לבדוק נכון.

שלב 1, ‏חיפוש בסיסי

פתחו דפדפן ב-incognito mode (חשוב, כי אם אתם מחוברים ל-account שלכם, ‏גוגל יציג פרסונליזציה ולא את ה-SERP הציבורי). חפשו את שם הברנד שלכם בדיוק כמו שגולש היה מחפש, לדוגמה "shmul.co.il" או "שמוליק דורינבאום" (לא URL).

שלב 2, ‏בדיקת התוצאה הראשית

אם זכיתם, אתם תראו תוצאה אורגנית גדולה של ה-homepage שלכם, ‏ומתחתיה (לפני sitelinks הרגילים, או במקומם) ‏תיבת חיפוש לבנה עם placeholder text "חפשו ב-X" (X = שם הברנד שלכם). אם רק יש sitelinks רגילים (4-6 קישורים פנימיים), ‏לא זכיתם.

שלב 3, ‏בדיקה במספר חיפושים

חפשו את הברנד שלכם ב-3-4 וריאציות שונות. "shmul.co.il", "shmul", "שמוליק דורינבאום", "שמוליק דורינבאום SEO". sitelinks searchbox יכול להופיע על אחת ולא על השאר, או על כולן. גוגל בוחר לכל וריאציה בנפרד.

שלב 4, ‏בדיקה ב-desktop וב-mobile

לפעמים sitelinks searchbox מופיע ב-desktop אבל לא ב-mobile, או הפוך. גוגל מתאים feature לפי device. בדקו את שני המכשירים. ‏ב-mobile, ‏פתחו Chrome ב-incognito והשתמשו ב-developer tools ל-toggle ל-mobile view, או חפשו על הטלפון עצמו.

שלב 5, ‏בדיקה ב-locales שונים

אם הברנד שלכם בינלאומי, sitelinks searchbox יכול להופיע ב-google.co.il אבל לא ב-google.com. החליפו locale (דרך google.com/?gl=us או דרך VPN) ובדקו.

בדיקת השימוש בפועל ב-Search Console

אחרי שזכיתם, ‏אפשר לבדוק כמה גולשים משתמשים בפועל ב-sitelinks searchbox. ב-Search Console, ‏Performance > Search Type > Web, ‏סננו ל-Queries המכילים את שם הברנד. ה-Impressions הם כל פעם שמישהו ראה את התוצאה שלכם (כולל את ה-sitelinks searchbox). ה-Clicks הם רק על קישורים אמיתיים, ‏לא על תיבת החיפוש. לכן הנתון של "כמה השתמשו ב-searchbox" לא נחשף ישירות, ‏אבל אפשר להסיק מ-traffic לעמוד תוצאות החיפוש הפנימי שלכם, כש-referrer הוא google.com.

טיפ מתקדם, ‏SerpAPI

אם אתם מנהלים אתרים רבים, ‏אפשר להשתמש בכלי כמו SerpAPI (תשלום) שמחזיר את ה-SERP בפורמט JSON ומראה אם יש sitelinks searchbox. זה חוסך זמן ידני וגם מאפשר ניטור היסטורי לאורך זמן.

🌳 WebSite + Organization, ‏איך לבנות @graph שמקשר את הכל

WebSite ו-Organization הם שני entities שונים אבל קשורים מאוד. WebSite הוא האתר עצמו. Organization הוא הגוף שמפעיל את האתר (החברה, ‏העסק, ‏הקבוצה). שניהם חייבים להיות באתר, ‏וחייבים להיות מקושרים דרך publisher.

למה צריך את שניהם

WebSite אומר "זה האתר". Organization אומר "זה מי שעומד מאחורי האתר". בלי Organization, ‏WebSite חסר context. גוגל יודע שזה אתר, ‏אבל לא יודע של מי. עם שניהם, ‏ה-graph מלא, ‏ו-Knowledge Panel יכול להציג מידע נכון על הברנד.

המבנה ב-@graph

ב-script JSON-LD אחד, ‏יש array של entities תחת property בשם @graph. כל entity מקבל @id ייחודי, ‏וה-WebSite מצביע על ה-Organization דרך publisher: { @id: "..." }.

דוגמת קוד מלאה ב-@graph

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.shmul.co.il/#organization",
      "name": "שמוליק דורינבאום, SEO",
      "url": "https://www.shmul.co.il/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://www.shmul.co.il/logo-site.png",
        "width": 600,
        "height": 200
      },
      "sameAs": [
        "https://www.linkedin.com/in/shmulik-dorinbaum",
        "https://www.facebook.com/shmul.co.il"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.shmul.co.il/#website",
      "url": "https://www.shmul.co.il/",
      "name": "shmul.co.il",
      "alternateName": "שמוליק דורינבאום",
      "inLanguage": "he",
      "publisher": {
        "@id": "https://www.shmul.co.il/#organization"
      },
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://www.shmul.co.il/?s={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

הקסם של ה-reference

שימו לב, ‏ה-WebSite מצביע על Organization דרך publisher, ‏וה-Organization יש לו @id שתואם. גוגל מבין את הקשר הזה ובונה graph של ישויות מקושרות. זה signal חזק שהאתר shmul.co.il שייך ל-Organization שמוליק דורינבאום SEO.

למה זה עדיף על nested objects

בעבר, ‏מקדמים היו כותבים את ה-Organization מקונן בתוך WebSite (כ-object מלא בתוך property publisher). זה עובד טכנית, ‏אבל יש לזה חסרונות, ‏(1) ה-Organization לא יכול להיות מוזכר ב-entities אחרים (Article, ‏WebPage), ‏(2) כפילות של נתוני Organization בכל schema script, ‏(3) קושי בתחזוקה. עם @graph + @id reference, ‏מגדירים את ה-Organization פעם אחת ומתייחסים אליו מכל מקום.

איפה לשים את ה-script הזה

ה-script של WebSite + Organization שייך אך ורק ל-homepage. אל תכפילו אותו על כל עמוד באתר. בכל עמוד אחר, תשתמשו ב-WebPage עם isPartOf reference ל-WebSite @id (פרק הבא). זה ההיגיון, ‏WebSite ו-Organization מוגדרים פעם אחת ב-homepage, ‏ושאר העמודים מצביעים עליהם.

🔗 @id stable + isPartOf reference, ‏המפתח ל-graph עקבי

ה-@id הוא ה-anchor של כל entity ב-schema. ב-WebSite, ‏הוא חשוב במיוחד, ‏כי כל שאר ה-schemas באתר (WebPage, ‏Article, ‏BreadcrumbList, ‏וכו') מצביעים אליו דרך isPartOf. אם ה-@id לא יציב או לא עקבי, ‏כל ה-graph נשבר.

מה זה @id יציב

@id יציב הוא URL מלא ייחודי שלא משתנה לאורך זמן. הוא מזהה את ה-WebSite entity בכל ה-schemas של האתר. הפורמט המקובל הוא, ‏URL של ה-homepage + hash + מזהה ה-entity. דוגמה, https://www.shmul.co.il/#website. ה-hash אחרי ה-URL הוא מה שמייחד את ה-entity, ‏כי אותו URL יכול לארח כמה entities (WebSite, ‏Organization, ‏WebPage של ה-homepage).

למה לא להשתמש ב-URL פשוט

אם תכתבו "@id": "https://www.shmul.co.il/" בלי hash, ‏זה יתנגש עם ה-@id של WebPage של ה-homepage (שזה הוא הוא). שני entities יש להם @id זהה, ‏ה-graph שבור. ה-hash פותר את זה, ‏Organization מקבל #organization, ‏WebSite מקבל #website, ‏WebPage של ה-homepage מקבל #webpage, ‏כל אחד ייחודי.

הפורמט המומלץ ל-@id

• Organization, ‏https://www.example.co.il/#organization
• WebSite, ‏https://www.example.co.il/#website
• Person (author), ‏https://www.example.co.il/#author או https://www.example.co.il/about/#person
• WebPage (homepage), ‏https://www.example.co.il/#webpage
• WebPage (other), ‏https://www.example.co.il/path/#webpage או פשוט URL מלא

isPartOf, ‏איך לקשר WebPage ל-WebSite

בכל WebPage באתר (לא רק ה-homepage), ‏הוסיפו property בשם isPartOf שמצביע על ה-WebSite דרך @id. זה אומר לגוגל "העמוד הזה הוא חלק מהאתר הזה".

{
  "@type": "WebPage",
  "@id": "https://www.shmul.co.il/article-name/#webpage",
  "url": "https://www.shmul.co.il/article-name/",
  "name": "שם המאמר",
  "isPartOf": {
    "@id": "https://www.shmul.co.il/#website"
  }
}

איך זה משתלב עם Article schema

גם ב-Article schema, ‏יש isPartOf שמצביע על ה-WebPage, ‏וה-WebPage מצביע על ה-WebSite. אז יש שרשרת, Article → WebPage → WebSite → Organization. כל entity מקושר ל-entity מעליו, ו-Google מבין את ה-hierarchy.

{
  "@type": "Article",
  "@id": "https://www.shmul.co.il/article-name/#article",
  "headline": "כותרת המאמר",
  "isPartOf": {
    "@id": "https://www.shmul.co.il/article-name/#webpage"
  },
  "author": {
    "@id": "https://www.shmul.co.il/#author"
  },
  "publisher": {
    "@id": "https://www.shmul.co.il/#organization"
  }
}

איך לבדוק שה-graph שלכם תקין

הריצו את ה-URL של דוגמה (homepage + מאמר פנימי) דרך Schema Validator של schema.org. הוא יציג את ה-graph בפורמט ויזואלי, ‏ותראו אם הקישורים בין ה-entities תקינים. אם הוא מציג entity "unreferenced", ‏זה אומר שהוא לא מקושר ל-entity אחר ולא משולב ב-graph. תקנו דרך הוספת @id reference במקום שצריך.

📝 דוגמת קוד basic, ‏WebSite + SearchAction מינימלי

הדוגמה הראשונה היא הפשוטה ביותר, ‏WebSite + SearchAction בלבד, ‏בלי Organization, ‏בלי alternateName, ‏בלי inLanguage. זה ה-baseline שאני ממליץ לכל אתר חדש להתחיל ממנו, ובהמשך לבנות עליו. הוא מספיק כדי לזכות ב-sitelinks searchbox אם שאר ה-criteria מתקיימים, ‏אם כי אני תמיד ממליץ לעבור לדוגמה המלאה בפרק הבא.

הקוד

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.co.il/#website",
  "url": "https://www.example.co.il/",
  "name": "שם האתר",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://www.example.co.il/?s={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

מה לשנות בדוגמה הזאת

1. example.co.il, ‏החליפו ב-domain שלכם (3 מקומות, ‏ב-@id, ‏ב-url, ‏וב-urlTemplate).
2. שם האתר, ‏החליפו בשם המסחרי של האתר.
3. ?s={search_term_string}, ‏החליפו ב-pattern שמתאים לפלטפורמת החיפוש הפנימי שלכם (WordPress = ?s=, ‏Shopify = /search?q=, ‏וכו'). עיינו בפרק 4 לדוגמאות פלטפורמות.

איפה לשים את ה-script

בתוך <head> של ה-homepage בלבד. אל תכפילו אותו על עמודים אחרים. בעמודים אחרים, ‏תשתמשו ב-WebPage עם isPartOf reference ל-WebSite דרך @id (ראו פרק 9).

אימות ב-Rich Results Test

אחרי הטמעה, ‏גלשו ל-search.google.com/test/rich-results, ‏הדביקו את ה-URL של ה-homepage שלכם, ‏ולחצו Test URL. גוגל יציג אם הוא זיהה את ה-schema. תחפשו את WebSite ב-list של ה-entities שזוהו. וודאו שאין warnings או errors. אם יש warnings על properties חסרים (לדוגמה "missing publisher"), ‏זה לא הורג את ה-feature, ‏אבל זה signal שאתם יכולים לשפר.

למה לא להוסיף יותר ב-baseline

לבסיס אני מעדיף לשמור על פשטות, ‏כי אם משהו נשבר, ‏יותר קל לאתר את הבעיה ב-script של 15 שורות מאשר ב-script של 80 שורות. אחרי שהבסיס עובד ועובר validation, ‏אפשר לבנות עליו את הדוגמה המלאה (פרק הבא). זה pattern מומלץ בכל הטמעת schema, ‏תתחילו פשוט ותבנו לאט.

🎯 דוגמת קוד עם alternateName + publisher, ‏ה-pattern המלא

הדוגמה השנייה היא ה-pattern המלא שאני ממליץ עליו לכל אתר עסקי או מקצועי. היא כוללת את כל ה-recommended properties, ‏ויש בה גם reference ל-Organization. זה ה-baseline המקצועי, ‏לא ה-minimum הטכני.

הקוד

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.shmul.co.il/#website",
  "url": "https://www.shmul.co.il/",
  "name": "shmul.co.il",
  "alternateName": [
    "שמוליק דורינבאום",
    "Shmul SEO"
  ],
  "description": "אתר ה-SEO של שמוליק דורינבאום, מדריכים ופילרים על קידום אתרים",
  "inLanguage": "he",
  "publisher": {
    "@id": "https://www.shmul.co.il/#organization"
  },
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://www.shmul.co.il/?s={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  },
  "copyrightYear": 2026,
  "copyrightHolder": {
    "@id": "https://www.shmul.co.il/#organization"
  }
}
</script>

מה חדש בדוגמה הזאת

• alternateName (array), ‏array של שמות משניים. הברנד שלי נקרא גם "שמוליק דורינבאום" וגם "Shmul SEO", ‏לא רק shmul.co.il. גוגל יקלוט את כל השמות וייתן sitelinks searchbox על כל וריאציה.
• description, ‏תיאור קצר של האתר. עוזר ל-AI engines להבין על מה האתר. שמרו תחת 160 תווים.
• inLanguage, ‏השפה הראשית של האתר. "he" לעברית, ‏"en" לאנגלית, ‏"ar" לערבית.
• publisher (reference), ‏מצביע על Organization entity דרך @id. ה-Organization עצמו מוגדר במקום אחר (בדוגמה הבאה תראו את ה-@graph המלא).
• copyrightYear + copyrightHolder, ‏מידע על זכויות יוצרים. לא חובה אבל מומלץ, ‏בעיקר ל-AI engines שלפעמים בודקים את זה.

הדוגמה הזאת חסרה את ה-Organization

שימו לב, ‏יש publisher שמצביע על Organization @id, ‏אבל ה-Organization עצמו לא מוגדר בדוגמה. זה אומר שצריך עוד script עם Organization, ‏או, ‏מה שאני ממליץ עליו, ‏לשלב את שניהם ב-@graph אחד (דוגמה הבאה).

איפה לשים את ה-script

גם הוא, ‏בתוך <head> של ה-homepage בלבד. בעמודים אחרים, ‏WebPage עם isPartOf reference. אל תכפילו את ה-WebSite schema על כל עמוד, ‏זה לא נכון ולא יעיל. גוגל מאינדקס את ה-homepage כ-source of truth ל-WebSite, ‏שאר העמודים פשוט מצביעים עליו.

🌐 דוגמת @graph מלאה, ‏Organization + WebSite + WebPage באותו script

הדוגמה השלישית היא ה-pattern המקצועי שמומלץ לכל אתר, ‏כל ה-entities של ה-homepage באותו script JSON-LD תחת @graph. זה ה-pattern שכל ה-CMSs המודרניים (WordPress + Yoast/RankMath, ‏Next.js, ‏וכו') מטמיעים כברירת מחדל. הוא נותן לגוגל ול-AI engines תמונה מקיפה של זהות האתר במקום אחד.

הקוד המלא

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.shmul.co.il/#organization",
      "name": "שמוליק דורינבאום, SEO",
      "url": "https://www.shmul.co.il/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://www.shmul.co.il/#logo",
        "url": "https://www.shmul.co.il/logo-site.png",
        "contentUrl": "https://www.shmul.co.il/logo-site.png",
        "caption": "shmul.co.il",
        "width": 600,
        "height": 200
      },
      "image": {
        "@id": "https://www.shmul.co.il/#logo"
      },
      "sameAs": [
        "https://www.linkedin.com/in/shmulik-dorinbaum",
        "https://www.facebook.com/shmul.co.il",
        "https://twitter.com/shmuldor"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.shmul.co.il/#website",
      "url": "https://www.shmul.co.il/",
      "name": "shmul.co.il",
      "alternateName": [
        "שמוליק דורינבאום",
        "Shmul SEO"
      ],
      "description": "אתר ה-SEO של שמוליק דורינבאום, מדריכים ופילרים על קידום אתרים",
      "inLanguage": "he",
      "publisher": {
        "@id": "https://www.shmul.co.il/#organization"
      },
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://www.shmul.co.il/?s={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.shmul.co.il/#webpage",
      "url": "https://www.shmul.co.il/",
      "name": "shmul.co.il, ‏שמוליק דורינבאום, ‏SEO ו-GEO",
      "isPartOf": {
        "@id": "https://www.shmul.co.il/#website"
      },
      "about": {
        "@id": "https://www.shmul.co.il/#organization"
      },
      "inLanguage": "he",
      "primaryImageOfPage": {
        "@id": "https://www.shmul.co.il/#logo"
      }
    }
  ]
}
</script>

הקסם של ה-references

שימו לב לכל ה-references בקוד הזה,

• WebSite מצביע על Organization דרך publisher
• WebPage מצביע על WebSite דרך isPartOf
• WebPage מצביע על Organization דרך about (זה אומר "העמוד הזה עוסק ב-Organization הזה")
• WebPage מצביע על ה-logo דרך primaryImageOfPage
• Organization מצביע על ה-logo דרך image (אותו logo, ‏reference אחד)

כל ה-references דרך @id. אין כפילות של נתוני logo. אין כפילות של נתוני Organization. ה-graph מקושר, ‏ו-Google מבין בדיוק את ה-hierarchy.

למה זה ה-pattern המומלץ

1. כל ה-foundation של האתר במקום אחד (Organization + WebSite + WebPage של ה-homepage). 2. AI engines מעדיפים את זה כי הם יכולים לקרוא את כל ה-context בקריאה אחת. 3. גוגל בונה Knowledge Graph עשיר יותר מ-graph מקושר. 4. עדכון של פרט אחד (לדוגמה שם Organization) מתבצע במקום אחד.

🔬 Validation, ‏איך לבדוק ש-schema תקין ב-Rich Results Test

הטמעה של schema בלי validation היא כמו לכתוב קוד בלי לקמפל. אתם לא יודעים אם זה עובד עד שאתם בודקים. וגוגל מציע 2 כלי validation חינמיים שאתם חייבים להכיר.

1. Rich Results Test של גוגל

הכלי הראשי, ‏search.google.com/test/rich-results. הוא בודק האם ה-schema באתר שלכם eligible ל-rich results לפי המפרט של גוגל. הוא לא רק בודק תחביר, ‏הוא בודק עמידה במדיניות של גוגל.

איך משתמשים, ‏(1) פתחו את הכלי, ‏(2) הדביקו את ה-URL של ה-homepage שלכם, ‏(3) לחצו Test URL, ‏(4) חכו 30-60 שניות, ‏(5) קבלו דוח מפורט.

מה הכלי מציג

• הסכמות שזוהו, ‏רשימה של כל ה-entities ב-schema. תחפשו את WebSite ב-list. אם הוא לא מופיע, ‏ה-schema לא נמצא או יש בעיה תחבירית.
• Eligible for rich results, ‏האם ה-schema eligible ל-feature מסוים. ב-WebSite, ‏זה יציין "Sitelinks search box" אם הכל תקין.
• Warnings, ‏אזהרות על properties שמומלץ להוסיף אבל לא חובה. תקנו אותן, ‏גם אם הן רק warnings.
• Errors, ‏שגיאות שמונעות eligibility. חייבים לתקן.

2. Schema Validator של schema.org

הכלי השני, ‏validator.schema.org. הוא בודק תקינות תחבירית בלבד (האם ה-JSON-LD תואם למפרט של schema.org), ‏לא תקינות לפי גוגל. השתמשו בו כשאתם רוצים לוודא שהקוד שלכם תקין מבחינת schema.org standard.

איך משתמשים

גם פשוט, ‏(1) פתחו את הכלי, ‏(2) הדביקו URL או הדביקו את הקוד JSON-LD ישירות, ‏(3) לחצו Validate. הוא יציג graph ויזואלי של ה-entities ושל ה-references ביניהם. אם entity נראה מנותק (לא מקושר ל-entity אחר), ‏זה signal שהוספתם entity חדש ושכחתם לקשר אותו דרך @id.

בדיקה בפועל אחרי deploy

לאחר deploy, ‏שתי בדיקות מינימליות, ‏(1) הריצו את ה-homepage שלכם ב-Rich Results Test ובוודאו שאתם eligible לכל ה-features שאתם מצפים להם (sitelinks searchbox). (2) שלחו URL Inspection ב-Google Search Console ובקשו re-crawl, ‏כדי שגוגל יקלוט את השינוי מהר.

טעויות שמופיעות רק ב-Rich Results Test

חלק מהטעויות שגוגל בודקת לא מופיעות ב-Schema Validator (כי הן לא טעויות תחביריות, ‏הן הפרות מדיניות). למשל, ‏urlTemplate שלא עובד (גוגל בודק את זה בפועל), ‏או SearchAction עם target המצביע על URL מ-domain אחר. תמיד תסמכו על Rich Results Test לוודא eligibility בפועל, ‏לא רק על Schema Validator.

🚫 הטעויות הנפוצות (target URL לא נכון, search_term_string חסר, אין search אמיתי)

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

טעות 1, ‏urlTemplate לא תואם לחיפוש האמיתי

הכי שכיחה. מקדם כותב ב-schema urlTemplate: "https://www.example.co.il/search?q={search_term_string}", ‏אבל באתר באמת החיפוש הוא ב-https://www.example.co.il/?s={search_term_string} (WordPress default). גולש מקליד ב-sitelinks searchbox, ‏נופל ל-/search?q=... שלא קיים, ‏מקבל 404. גוגל בודק את זה אוטומטית ומסיר את ה-feature. ‏הפתרון, ‏תמיד תוודאו ש-urlTemplate באמת עובד באתר שלכם, ‏לפני deploy.

טעות 2, ‏חסר ה-placeholder {search_term_string}

מקדם כותב urlTemplate: "https://www.example.co.il/search" בלי ה-placeholder. ה-schema לא יודע איפה להחליף את המחרוזת שהמשתמש הקליד. ‏גוגל מתעלם מה-SearchAction. הפתרון, ‏תמיד כלולו {search_term_string} ב-urlTemplate.

טעות 3, ‏שם פרמטר לא עקבי

מקדם משתמש ב-{q} ב-urlTemplate (?q={q}), ‏אבל ב-query-input הוא כותב name=search_term_string. השמות לא עקביים, ‏גוגל לא יודע איזה parameter להזין. הפתרון, ‏או שמרו על search_term_string בכל מקום, ‏או שמרו על q בכל מקום, ‏אבל תהיו עקביים בין urlTemplate ל-query-input. ‏ההמלצה של גוגל היא להשתמש ב-search_term_string תמיד, ‏כי זה השם שהמפרט מצפה לו ב-query-input.

טעות 4, ‏אין חיפוש פנימי באתר בכלל

זה הקריטי. מקדם מטמיע SearchAction על אתר שאין לו חיפוש פנימי. ה-URL ב-target מצביע ל-URL שלא קיים באתר. גוגל בודק, ‏מקבל 404, ‏ומסיר את ה-feature. ‏הפתרון, ‏אם אין לכם חיפוש פנימי, ‏אל תוסיפו SearchAction. תוסיפו רק WebSite עם url + name + publisher. ה-SearchAction הוא רק לאתרים עם חיפוש פנימי אמיתי.

טעות 5, ‏WebSite schema על כל עמוד

מקדם מטמיע WebSite schema על כל עמוד באתר. גוגל רואה 100 WebSite entities עם אותו @id, ‏מתבלבל, ‏ואולי גם מעניש על duplicate. ‏הפתרון, ‏WebSite schema רק ב-homepage. בעמודים אחרים, ‏WebPage עם isPartOf reference ל-WebSite @id.

טעויות נוספות (מהיר)

• השמטת @id מ-WebSite (אז שאר ה-schemas לא יכולים להצביע עליו)
• שימוש ב-@type "website" עם w קטנה (שגיאת case)
• שימוש ב-@type "WebSiteSchema" או "website" במקום "WebSite"
• השמטת @type: "SearchAction" בתוך potentialAction
• שימוש ב-"Action" במקום "SearchAction" (גוגל לא יזהה)
• השמטת @type: "EntryPoint" בתוך target (לפעמים עובד אבל לא מומלץ)
• קידוד שגוי של עברית ב-urlTemplate (במקום פרסנט-encoded פשוט עברית liter)
• שכפול potentialAction בכמה scripts על אותו עמוד
• פרמטר חסר ב-query-input ("required name=search_term_string" חייב להיות מלא)
• schema של WebSite ב-noscript או ב-iframe (גוגל לא יקלוט)

🤖 AI engines, ‏WebSite identity, ‏ו-audit checklist חודשי

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

WebSite identity ב-AI engines, ‏הזווית המתעוררת

ChatGPT, Perplexity, Claude, Gemini, Copilot. כולם משתמשים ב-WebSite schema כדי להבין מה האתר שלכם. כשהם נשאלים "מה זה shmul.co.il" או "מי שמוליק דורינבאום", הם הולכים ל-homepage שלכם, סורקים את ה-JSON-LD, ומחפשים את ה-WebSite entity. ההבדל בין אתר עם WebSite schema תקין לבין אתר בלי, הוא ההבדל בין AI engine שמצטט אתכם בדיוק לבין AI engine שמתבלבל בין אתכם לאתר אחר.

איך AI engines משתמשים ב-WebSite schema

• זיהוי הברנד, ‏השם המסחרי + alternateName + publisher = ‏הברנד שלכם בעיני AI
• זיהוי השפה הראשית, ‏inLanguage = ‏ב-AI יודע באיזו שפה להציג אותכם
• זיהוי ה-publisher, ‏publisher reference ל-Organization = ‏AI יודע מי עומד מאחורי האתר
• זיהוי החיפוש הפנימי, ‏potentialAction = ‏AI יודע איך להציע למשתמשים שלו לחפש באתר שלכם
• הקשר ל-graph, ‏כל ה-Articles, WebPages, ‏ו-FAQs באתר מקושרים חזרה ל-WebSite דרך isPartOf, ‏AI מבין את ההיררכיה

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

1. בדיקת חיפוש פנימי

   פתחו את החיפוש הפנימי שלכם, ‏חפשו מילה אמיתית, ‏העתיקו את ה-URL של דף תוצאות החיפוש. זה ה-URL שתשתמשו בו ב-urlTemplate.

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

   החליטו על @id ל-WebSite (לדוגמה https://www.example.co.il/#website) ול-Organization (#organization). תשמרו על אלה לתמיד.

3. בניית WebSite schema

   url, name, alternateName, inLanguage, description, publisher reference, potentialAction עם SearchAction.

4. בניית Organization schema

   name, url, logo, sameAs (social profiles).

5. שילוב ב-@graph

   שתי ה-entities באותו script JSON-LD תחת @graph.

6. הזרקה ל-homepage

   שמירת ה-script בתוך <head> של ה-homepage בלבד.

7. הוספת isPartOf בעמודים אחרים

   בכל WebPage באתר, ‏הוסיפו isPartOf reference ל-WebSite @id.

8. אימות ב-Rich Results Test

   הריצו את ה-homepage ובוודאו eligibility ל-sitelinks searchbox.

9. אימות ב-Schema Validator

   וודאו תקינות תחבירית ובלי entities unreferenced.

10. Request Indexing ב-GSC

    URL Inspection לעמוד הבית, Request Indexing. גוגל יקלוט תוך 24-48 שעות.

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

• בדיקת ה-schema ב-Rich Results Test, עדיין eligible?
• אימות שה-urlTemplate באמת עובד באתר (חיפוש פנימי לא נשבר)
• בדיקת Search Console Enhancements, ‏האם WebSite מופיע ולא נשבר
• חיפוש ידני של שם הברנד ב-Google, ‏וידוא ש-sitelinks searchbox עדיין מופיע
• אם שיניתם משהו בפלטפורמת החיפוש הפנימי (URL, ‏פרמטר), ‏עדכון ה-schema
• אם הוספתם alias חדש לברנד, ‏הוספה ל-alternateName
• בדיקת sameAs ב-Organization, ‏האם כל ה-social profiles עדכניים
• אם שיניתם את ה-logo, ‏עדכון URL ב-Organization.logo
• בדיקה שאין כפילות של WebSite schema (לדוגמה Yoast מטמיע אוטומטית + הטמעה ידנית)
• אחת לרבעון, ‏בדיקה אם schema.org פירסם properties חדשים ל-WebSite

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