Service Schema, איך מעצבים סכמה לעסקי שירותים

🛎 מה זה Service schema, ולמה זה לא LocalBusiness

תקשיבו, אני אפתח עם הסיפור הקלאסי שאני שומע פעם בשבועיים. יועץ SEO מתקשר אליי, אומר "שמוליק, יש לי סכמה באתר, כתבתי LocalBusiness עם השם והכתובת והטלפון, אז למה גוגל לא מבין שאני נותן שירות של ייעוץ SEO?". אני בודק את האתר שלו. ה-schema שלו אומר "זה עסק לוקאלי בשם X ברחוב Y". זה לא אומר כלום על השירות עצמו. נחשו למה גוגל לא מצטט אותו ב-AI Overviews לשאילתת "יועץ SEO מומלץ"? כי הוא תיאר את העסק, לא את השירות.

Service זה Schema.org type שמתאר את ההצעה הספציפית, את השירות עצמו. LocalBusiness מתאר את הישות שמספקת את השירות. ההבדל לא קוסמטי, הוא קונספטואלי. LocalBusiness עונה על השאלה "מי אתם?". Service עונה על השאלה "מה אתם מציעים?". כשגוגל או ChatGPT מנסים להבין למה לצטט אתכם בתשובה לשאילתת שירות, הם רוצים את שני הסיגנלים, מי אתם + מה אתם מציעים.

איך זה משנה ל-AI engines

ChatGPT, Perplexity, ו-Google AI Overviews מסתמכים כבדות על schema כדי להבין מי מציע מה. כשמישהו שואל את ChatGPT "איזה יועץ SEO מומלץ בישראל", המנוע סורק אתרים שמופיעים בתוצאות גוגל. אתר עם Service schema מפורט (serviceType, areaServed, hasOfferCatalog) מקבל יתרון משמעותי על אתר עם רק LocalBusiness. ‏זה אחד הסיגנלים החזקים שאתר באמת עוסק בשירות הזה ולא רק מזכיר אותו.

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

15 פרקים שמתחילים מההבדל בין Service ל-LocalBusiness, עוברים על ההיררכיה של Service subtypes, ‏ה-properties החובה וה-recommended, איך לשלב Service עם Offer, ‏8 דוגמאות מלאות JSON-LD לסוגי שירות שונים (כולל הדוגמה האישית שלי, ייעוץ SEO), שילוב ב-@graph עם LocalBusiness, ההבדל בין Service ל-Product לשירותים דיגיטליים, ו-workflow תחזוקה חודשי. אם תקראו עד הסוף ותטמיעו את הקוד הנכון לעסק שלכם, אתם תהיו ב-5% של עסקי השירות בארץ שיש להם סכמה אמיתית ולא רק טיוטה גנרית.

אגב, השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO ובכל הסכמות שמסביבו. ‏אני אישית מטמיע ProfessionalService + Service על עמוד הבית של האתר הזה, ‏עם services ספציפיים לכל מודל ייעוץ. ‏זה משחק את ה-Knowledge Graph שגוגל מצייר עליי. אם אחרי המאמר אתם תקועים, יש לכם איך לדבר איתי ישירות.

⚖️ מתי לבחור Service vs LocalBusiness

זה ההחלטה הראשונה והכי מבלבלת. רוב המקדמים שואלים אותי "שמוליק, מה לכתוב, Service או LocalBusiness?". התשובה היא, שניהם. אבל הם בשני entities נפרדים, כל אחד עם תפקיד אחר. ההחלטה היא לא "או", היא "ואיך לשלב". תקשיבו, אסביר את שניהם בצורה ברורה.

LocalBusiness, ‏זה העסק עצמו

LocalBusiness (או subtype שלו, ProfessionalService למשל) מתאר את הישות העסקית. "שמוליק דורינבאום, יועץ SEO, רחוב X, תל אביב, טלפון Y". ‏הוא עונה לגוגל "מי אתם?". יש לכם name, address, telephone, ‏שעות פעילות, ‏ולעיתים reviews. ‏זה הכרטיס הדיגיטלי שלכם, הזהות העסקית הקבועה שלא משתנה גם אם אתם מציעים שירותים חדשים בכל רבעון.

Service, ‏זה השירות הספציפי שאתם מציעים

Service מתאר הצעת שירות מסוימת. "ייעוץ SEO חד-פעמי", "מודל ייעוץ חודשי", "audit + handoff". כל אחד מהם הוא entity נפרד עם name משלו, description, ‏serviceType, ‏areaServed, ‏ו-offers (המחיר). ‏הוא עונה לגוגל "מה אתם מציעים?". זה החלק שמשתנה לעיתים, נוסף, מתעדכן.

הקשר ביניהם, ‏ה-property בשם provider

Service מקושר ל-LocalBusiness דרך property בשם provider. ‏כלומר Service אומר "השירות הזה מסופק על ידי LocalBusiness X". ‏ב-@graph עם @id ייחודי, ‏הקישור הזה מתקיים אוטומטית בשני הכיוונים, ‏גוגל מבין ש-Service A מסופק על ידי Business B, וש-Business B מציע services A, C, D. זה הקסם של @id linking, מצב שכל ישות יודעת על הקיום של האחרות.

דוגמה ממני

על האתר הזה (shmul.co.il) יש לי ProfessionalService שמתאר את "שמוליק דורינבאום, יועץ SEO". יש לי Service entities נפרדים לכל מודל ייעוץ שאני מציע, "ייעוץ SEO חד-פעמי", "ייעוץ SEO חודשי", "ייעוץ פרויקט", "audit + handoff". כל אחד מהם מקושר אליי כ-provider. כך גוגל יודע ש-shmul.co.il מציע 4 services נפרדים, כל אחד עם מחיר וקהל יעד שונה, וכולם מסופקים על ידי אותו provider. ‏זה ההבדל בין "אני יועץ SEO" סתמי לבין מבנה מידע שמאפשר ל-AI להבין בדיוק איזה מודל מתאים לאיזו שאלה.

מה אם אני עסק שירות בלי מיקום פיזי

גם אז, השתמשו ב-Organization או ProfessionalService כ-provider (ProfessionalService טכנית subtype של LocalBusiness, אבל גוגל מקבל אותו גם בלי כתובת פיזית). הוסיפו areaServed = "Israel" או areaServed = "Online" ב-Service. גוגל יבין שאתם עסק שירות וירטואלי או רחב-טווח. המדריך השלם ל-LocalBusiness מסביר את הניואנס של ProfessionalService בפרטים, כולל מתי לבחור בו ומתי ללכת על Organization רגיל.

🌳 Service subtypes hierarchy, ‏הענפים הראשיים

ההיררכיה של Service פחות עשירה מ-LocalBusiness, אבל יש subtypes חשובים שצריך להכיר. תקשיבו, ‏רוב המקדמים שמטמיעים Service פותחים schema.org, רואים "Service", ועוצרים שם. הם מפספסים שיש subtypes כמו FinancialProduct, FoodService, TaxiService, ‏ובמיוחד, ‏יש את הקשר עם LocalBusiness subtypes שיכולים לתפקד כ-provider.

ה-subtypes הישירים של Service

1. FinancialProduct

   למוצרים פיננסיים. תת-טיפוסים, BankAccount, ‏CurrencyConversionService, ‏DepositAccount, ‏InvestmentOrDeposit, ‏LoanOrCredit, ‏PaymentCard, ‏PaymentService. השתמשו אם אתם בנק, ‏יועץ השקעות, ‏או נותני שירותים פיננסיים.

2. FoodService

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

3. GovernmentService

   שירותים ממשלתיים. ‏מתאים לגופים ציבוריים, ‏עיריות, ‏משרדי ממשלה.

4. BroadcastService

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

5. CableOrSatelliteService

   שירותי כבלים או לוויין. ‏HOT, ‏Yes, ‏וכו'.

6. TaxiService

   שירותי הסעה. ‏מוניות, ‏Uber, ‏Gett.

7. WebAPI

   שירות API ציבורי. ‏לחברות SaaS עם API פתוח.

ה-LocalBusiness subtypes שיכולים לתפקד כ-provider של Service

זה החלק הפחות מוכר. רוב ה-LocalBusiness subtypes יכולים לתפקד כ-provider של Service. כלומר Service על "ייעוץ SEO" יכול להיות עם provider של ProfessionalService, ‏ו-Service על "השתלת שיניים" יכול להיות עם provider של Dentist. הסכמה גמישה, אבל זה מבלבל מי שלא מבין את ההיררכיה.

ProfessionalService, ‏בחירת ברירת מחדל ליועצים

אם אתם יועץ, ‏freelance, ‏עו"ד עצמאי, ‏רואה חשבון פרטי, ‏או כל נותן שירות מקצועי, ‏ProfessionalService הוא ה-provider הנכון. ‏הוא טכנית subtype של LocalBusiness, ‏ויש לו את כל ה-properties של LocalBusiness, ‏אבל הוא מסמן לגוגל שזה שירות מקצועי, ‏לא חנות פיזית או מסעדה.

הקשר עם הסכמות האחרות

Service לא חי לבד. הוא מקושר ל-LocalBusiness דרך provider, ‏ל-Person דרך provider (אם זה freelance), ‏ל-Organization דרך provider (לחברות), ‏וב-@graph לעיתים גם ל-Article (אם השירות מוצג בעמוד content). ‏הגישה הנכונה היא תמיד @graph אחד עם כל ה-entities מקושרים. ‏ככה גוגל וה-AI engines קוראים את ההקשר המלא של מי-מציע-מה-באיזה-מקום-באיזה-מחיר במכה אחת.

למה ההיררכיה משנה לגוגל

תקשיבו, הסיווג של ה-subtype הוא לא קוסמטי. גוגל משתמש ב-@type כדי להבין באיזה bucket של תוצאות לשים אתכם. אם אתם מסמנים את עצמכם כ-FinancialProduct, גוגל מציע אתכם בשאילתות פיננסיות. אם אתם Service כללי, אתם מתחרים עם כל מה שזז. ה-subtype הספציפי מבדל אתכם, וזה ההבדל בין להופיע ב-AI Overviews לבין להישאר רק בעמוד 2 של תוצאות החיפוש הרגילות.

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

בניגוד ל-LocalBusiness שיש לו 3 required properties מחמירים (name + address + telephone), Service פחות נוקשה. ‏schema.org דורש רק name כ-required. ‏אבל גוגל וה-AI engines דורשים יותר כדי באמת להבין את השירות ולציין אותו. ‏הנה החלוקה האמיתית.

Required לפי schema.org

• name, ‏שם השירות. ‏"ייעוץ SEO חד-פעמי", ‏"השתלת שיניים", ‏"תיקון מזגן בבית".

Recommended חזק (כמעט חובה לציטוט AI)

• provider, ‏מי מספק את השירות. ‏Organization, ‏LocalBusiness, ‏ProfessionalService, ‏Person, ‏או reference ל-@id.
• description, ‏תיאור מלא של השירות, ‏מה כלול ומה לא.
• serviceType, ‏סיווג ה-string של השירות (לדוגמה "SEO Consulting", "Dental Implant Surgery", "Home Appliance Repair").
• areaServed, ‏האזור הגיאוגרפי או הקהל שמשרתים. ‏Country, ‏City, ‏AdministrativeArea, ‏או string פשוט.
• offers, ‏המחיר וההיצע. ‏Offer object עם price + priceCurrency.
• url, ‏ה-URL של עמוד השירות באתר.

Recommended (מוסיפים עוד עומק)

• image, ‏תמונה של השירות או הסמל שלו.
• audience, ‏קהל היעד (לדוגמה "חברות B2B", "בעלי עסקים קטנים").
• brand, ‏הברנד שמסונן (ארגון או Person).
• slogan, ‏סלוגן השירות.
• hasOfferCatalog, ‏אם השירות מציע sub-services או חבילות.
• sameAs, ‏קישורים לפרופילי שירות נוספים (LinkedIn, ‏Crunchbase, ‏פרופיל ב-Google Business).

דוגמת קוד בסיסית, Service מינימלי

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "ייעוץ SEO חד-פעמי",
  "description": "סשן ייעוץ SEO ממוקד של 2 שעות, מתאים לבעלי אתר שרוצים אבחון מהיר של בעיות וכיוון אסטרטגי",
  "provider": {
    "@type": "ProfessionalService",
    "name": "שמוליק דורינבאום"
  },
  "serviceType": "SEO Consulting",
  "areaServed": "IL",
  "offers": {
    "@type": "Offer",
    "price": "1500",
    "priceCurrency": "ILS"
  }
}
</script>

למה השלושה האחרונים קריטיים

בלי serviceType גוגל לא יודע באיזו קטגוריה השירות שלכם, אז ה-AI לא יציע אתכם לשאילתות בקטגוריה. ‏בלי areaServed ה-AI לא יודע מי הקהל הגיאוגרפי שלכם, אז שאילתת "יועץ SEO בתל אביב" לא תופיע אתכם. ‏בלי offers ה-AI לא יודע אם השירות חינמי, ‏יקר, ‏או בינוני, ‏וזה מידע שמשתמשים שואלים עליו. ‏שלושת ה-properties האלה הם ההבדל בין "schema תקין" ל-"schema שמופעל".

🌍 provider + areaServed, ‏מי נותן את השירות ולמי (עם דוגמת קוד)

שני ה-properties האלה הם הלב של Service. ‏provider אומר "מי" (מי מספק את השירות), ‏areaServed אומר "למי" (מי קהל היעד הגיאוגרפי). ‏בלי שני אלה, ‏ה-schema שלכם הוא רק שם של שירות בלי הקשר. תקשיבו, אני אסביר את שני ה-properties ואז אעבור לדוגמת קוד מלאה.

provider, ‏ה-options

אפשר לציין provider באחת מ-4 דרכים:

1. Organization

   לחברות מאוגדות. ‏"Acme SEO Agency", ‏סוכנות עם מספר עובדים וברנד עצמאי.

2. LocalBusiness או subtype (ProfessionalService, Dentist, וכו')

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

3. Person

   ל-freelancers עצמאיים שעובדים בשמם האישי בלי ישות עסקית רשמית. ‏"שמוליק דורינבאום, Person".

4. Reference ל-@id קיים

   אם כבר הגדרתם את ה-provider במקום אחר ב-@graph, ‏השתמשו ב-{"@id": "..."} כדי להפנות אליו. זה ה-pattern המומלץ כשיש כמה Service entities שמסופקים על ידי אותו provider.

areaServed, ‏ה-options

אפשר לציין areaServed באחת מ-5 דרכים:

• Country, ‏"IL" או Country object עם name="Israel"
• City, ‏עיר ספציפית, ‏לדוגמה City עם name="תל אביב"
• AdministrativeArea, ‏מחוז או אזור ("מחוז תל אביב", "מחוז חיפה")
• GeoCircle, ‏רדיוס סביב נקודה גיאוגרפית (geoMidpoint + geoRadius במטרים)
• String פשוט, ‏לדוגמה "Israel" או "Worldwide" (גוגל יקלוט אבל פחות מועדף)

דוגמת קוד מלאה, ‏Service עם provider + areaServed מפורט

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-monthly",
  "name": "ייעוץ SEO חודשי",
  "description": "מודל ליווי חודשי לבעלי אתרים, כולל סשן חודשי קבוע, מעקב מילות מפתח, ובדיקות שבועיות",
  "provider": {
    "@type": "ProfessionalService",
    "@id": "https://shmul.co.il/#consultant",
    "name": "שמוליק דורינבאום",
    "url": "https://shmul.co.il/אודות/",
    "telephone": "+972-54-7126629"
  },
  "serviceType": "SEO Consulting",
  "areaServed": [
    {
      "@type": "Country",
      "name": "Israel"
    },
    {
      "@type": "AdministrativeArea",
      "name": "מחוז תל אביב"
    }
  ],
  "offers": {
    "@type": "Offer",
    "price": "5000",
    "priceCurrency": "ILS",
    "availability": "https://schema.org/InStock"
  }
}
</script>

למה areaServed כ-array

שימו לב שעשיתי areaServed כ-array של 2 אזורים, Country = ישראל וגם AdministrativeArea = תל אביב. זה אומר לגוגל "אני משרת את כל הארץ אבל בעיקר את מחוז תל אביב". זה משחק את ה-AI שמחפש יועץ באזור ספציפי.

💰 הקשר Service ו-Offer (עם דוגמת קוד)

זה הקטע שמבלבל הכי הרבה מקדמים. ‏מה ההבדל בין Service לבין Offer? ‏הם נשמעים דומים. ‏האמת היא שהם דברים שונים לחלוטין, ‏ומשתמשים בהם יחד.

Service vs Offer, ‏ההבדל הקונספטואלי

• Service, ‏מה אתם מציעים. ‏השירות עצמו. ‏לדוגמה "השתלת שיניים", "ייעוץ SEO", "תיקון מזגן".
• Offer, ‏איך אתם מציעים אותו. ‏המחיר, ‏הזמינות, ‏תאריך הצעת המכירה, ‏תנאי התשלום. ‏זה ההיצע הספציפי, ‏לא השירות עצמו.

במילים פשוטות, ‏Service אומר "זה ייעוץ SEO". ‏Offer אומר "זה ייעוץ SEO בעלות 5,000 שקל לחודש, ‏זמין עכשיו, ‏עם תקופת ניסיון של 14 יום".

אז למה לא להשתמש רק ב-Service?

כי Offer הוא ה-property שגוגל וה-AI engines מחפשים כדי להבין את הצד המסחרי. ‏בלי Offer בתוך Service, ‏ה-AI לא יודע אם השירות חינמי, ‏יקר, ‏או בכלל זמין. ‏Offer הוא גם מה שמאפשר לגוגל להציג מחיר ב-rich results.

דוגמת קוד עם Offer מפורט

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-audit",
  "name": "Audit SEO + Handoff",
  "description": "audit מקיף של האתר עם דוח מפורט והעברה לצוות הפנימי שלכם, ללא מחויבות חודשית",
  "provider": {
    "@id": "https://shmul.co.il/#consultant"
  },
  "serviceType": "SEO Audit",
  "areaServed": "IL",
  "offers": {
    "@type": "Offer",
    "name": "Audit מלא + סשן Handoff של 3 שעות",
    "price": "8500",
    "priceCurrency": "ILS",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "validFrom": "2026-01-01",
    "category": "One-Time SEO Audit",
    "businessFunction": "https://schema.org/Sell",
    "seller": {
      "@id": "https://shmul.co.il/#consultant"
    }
  }
}
</script>

מה ה-properties החשובים ב-Offer

• price, ‏המחיר כמספר (לא string עם סימן מטבע). "5000" ולא "5,000 שקל".
• priceCurrency, ‏קוד ISO. "ILS" לשקלים, ‏"USD" לדולרים, ‏"EUR" ליורו.
• availability, ‏Schema.org enum. ‏InStock, ‏OutOfStock, ‏PreOrder, ‏Discontinued. ‏לשירות, ‏לרוב InStock.
• priceValidUntil, ‏עד מתי המחיר הזה תקף. ‏חשוב להראות שהמחיר עדכני.
• category, ‏קטגוריה של ההצעה. ‏לדוגמה "Subscription Service", ‏"One-Time Service".
• seller, ‏מי המוכר. ‏בדרך כלל reference ל-provider של Service.

businessFunction, ‏ה-property שכמעט אף אחד לא משתמש בו

שדה businessFunction מציין את סוג העסקה. לרוב Service יש ערך "https://schema.org/Sell" (מכירה), אבל יש גם ערכים כמו Lease (השכרה), LeaseOut (השכרה החוצה), Buy, ProvideService, ועוד. אם אתם משכירים שירותים במקום למכור (לדוגמה השכרת תוכנה ב-SaaS), השתמשו ב-LeaseOut. אם אתם מציעים שירות חינמי, אפשר להשתמש ב-ProvideService. תקשיבו, רוב המקדמים מתעלמים מהשדה הזה, וזה בסדר ברוב המקרים, אבל הוא הופך מקריטי כשיש לכם מודלים לא-שגרתיים של מכירה.

🎯 דוגמה מלאה, ‏ייעוץ SEO (עם דוגמת קוד מלאה)

הנה דוגמה מלאה לסוג השירות הראשון, ‏ייעוץ SEO. ‏זאת הסכמה שאני בעצמי מטמיע על עמוד /יועץ-קידום-אתרים/ של האתר הזה. ‏היא מתארת את מודל הייעוץ הראשי שלי, עם כל ה-properties הקריטיים לציטוט AI.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-monthly",
  "name": "ייעוץ SEO חודשי, ‏מודל ליווי שותפות",
  "description": "מודל ייעוץ SEO חודשי קבוע, ‏כולל סשן חודשי בן 90 דקות, ‏מעקב שבועי על מילות מפתח, ‏בדיקה חודשית של דוחות Search Console, ‏וייעוץ חופשי בוואטסאפ לאורך החודש. ‏מתאים לבעלי אתרים פעילים שרוצים שותפות לטווח ארוך עם יועץ SEO מקצועי",
  "provider": {
    "@type": "ProfessionalService",
    "@id": "https://shmul.co.il/#consultant",
    "name": "שמוליק דורינבאום",
    "url": "https://shmul.co.il/אודות/",
    "description": "יועץ SEO עם 20 שנות ניסיון, עבד עם החברות הגדולות בישראל",
    "telephone": "+972-54-7126629",
    "email": "shmulik@shmul.co.il",
    "image": "https://shmul.co.il/wp-content/uploads/shmul-profile.jpg"
  },
  "serviceType": "SEO Consulting",
  "areaServed": [
    {
      "@type": "Country",
      "name": "Israel"
    }
  ],
  "audience": {
    "@type": "BusinessAudience",
    "audienceType": "בעלי אתרים פעילים, סטארטאפים, חברות B2B ו-B2C"
  },
  "brand": {
    "@type": "Brand",
    "name": "שמוליק דורינבאום"
  },
  "slogan": "The SEO Scientist, מודד, לא מנחש",
  "offers": {
    "@type": "Offer",
    "name": "מנוי ייעוץ SEO חודשי",
    "price": "5000",
    "priceCurrency": "ILS",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "category": "Subscription"
  },
  "url": "https://shmul.co.il/יועץ-קידום-אתרים/",
  "image": "https://shmul.co.il/wp-content/uploads/seo-consulting-service.jpg",
  "sameAs": [
    "https://www.linkedin.com/in/shmulikdorinbaum"
  ]
}
</script>

מה מיוחד פה

• name ספציפי, ‏לא "ייעוץ SEO" כללי, ‏אלא "ייעוץ SEO חודשי, מודל ליווי שותפות". ‏מבדל מהמודלים האחרים.
• description ארוך ופירוט, ‏לא "ייעוץ SEO מקצועי". ‏פירוט בדיוק מה כלול, ‏כמה זמן, ‏ולמי מתאים. ‏זה ה-content שה-AI מצטט.
• provider כ-ProfessionalService מלא, ‏לא רק שם. ‏יש לו @id, ‏url, ‏description קצר, ‏טלפון, ‏אימייל, ‏image. ‏גוגל מקבל איתות מלא על מי שמספק את השירות.
• serviceType כסיווג, ‏"SEO Consulting" באנגלית. ‏זה ה-string שגוגל וה-AI engines משתמשים בו לסיווג ב-categories הגלובליים.
• audience כ-BusinessAudience, ‏subtype של Audience. ‏הוא מסמן שהקהל הוא עסקים ולא צרכנים פרטיים. ‏ה-AI לוקח את זה לשקלול שאילתות B2B.
• brand כ-Brand, ‏הברנד האישי. ‏לפעמים זה אותו שם כמו provider, ‏לפעמים שונה (לסוכנות עם שם מסחרי).
• slogan, ‏הסלוגן שלי. ‏זה ה-string שגוגל יכול להציג ב-Knowledge Panel.
• offers עם תוקף, ‏priceValidUntil מעדכן שהמחיר נכון, ‏availability=InStock אומר שמקבלים לקוחות.

⚖️ דוגמה מלאה, ‏שירות משפטי

שירות משפטי הוא דוגמה לתחום שבו ה-provider הוא LegalService (subtype של LocalBusiness) אבל ה-Service מתאר את השירות הספציפי. ‏יש כאן רגישות לחוק לשכת עורכי הדין, ‏אז ה-description חייב להיות מאוזן. ‏אסור "מומחה" או "מתמחה" בשיווק, ‏ולא לפרסם הבטחת תוצאות.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example-law.co.il/divorce-mediation/#service",
  "name": "גישור גירושין",
  "description": "שירות גישור גירושין למשפחות, ‏המאפשר הסכם הוגן לשני הצדדים ללא הליך משפטי ארוך. ‏כולל פגישות עם שני הצדדים, ‏ניסוח הסכם, ‏והגשתו לבית המשפט",
  "provider": {
    "@type": "LegalService",
    "@id": "https://example-law.co.il/#firm",
    "name": "משרד עורכי דין כהן ושות'",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "שדרות רוטשילד 56",
      "addressLocality": "תל אביב",
      "addressRegion": "תל אביב",
      "postalCode": "6577890",
      "addressCountry": "IL"
    },
    "telephone": "+972-3-5234567"
  },
  "serviceType": "Family Law Mediation",
  "areaServed": [
    {
      "@type": "AdministrativeArea",
      "name": "מחוז תל אביב"
    },
    {
      "@type": "AdministrativeArea",
      "name": "מחוז מרכז"
    }
  ],
  "audience": {
    "@type": "Audience",
    "audienceType": "זוגות המבקשים להתגרש בהליך גישור"
  },
  "offers": {
    "@type": "Offer",
    "name": "חבילת גישור גירושין מלאה",
    "description": "5 פגישות גישור + ניסוח הסכם + הגשה לבית המשפט",
    "price": "15000",
    "priceCurrency": "ILS",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock"
  },
  "url": "https://example-law.co.il/divorce-mediation/"
}
</script>

מה מיוחד פה

• provider = LegalService, ‏ולא Service. ‏ה-LegalService הוא subtype של LocalBusiness שמתאים למשרדי עו"ד.
• name נטרלי, ‏"גישור גירושין" ולא "גישור גירושין המוצלח ביותר" או "גישור גירושין על ידי מומחה". ‏ניסוח שעומד בחוק לשכת עו"ד.
• description פעולתי, ‏מתאר מה כלול בשירות בלי הבטחה. ‏"המאפשר הסכם הוגן" ולא "מבטיח הסכם הוגן".
• serviceType באנגלית כסיווג, ‏"Family Law Mediation" כסיווג ה-AI engines.
• 2 areaServed, ‏המשרד בתל אביב אבל משרת גם את המרכז. ‏שני AdministrativeArea entities.
• Offer ספציפית עם description, ‏מה כלול ב-15,000 שקל. ‏ה-description ב-Offer חוסך אי-הבנות.
• אין aggregateRating, ‏חוק לשכת עו"ד מגביל קידום ויראלי, ‏עדיף להימנע מ-reviews שיווקיים.

אותו pattern לרופאי שיניים, ‏שירותי ספא, ‏מטפלים

הסכמה הזאת היא תבנית שמתאימה לכל עסק שירות מקצועי עם רגולציה. ‏רופאי שיניים שמטמיעים Service על "השתלת שיניים", ‏יש להם הסתדרות לרפואת שיניים שאוסרת על הבטחות תוצאה. ‏מטפלי נפש שמטמיעים Service על "טיפול CBT", ‏יש להם משרד הבריאות שמגביל ניסוחים שיווקיים. ‏גם להם, ‏הניסוח חייב להיות תיאורי ולא הבטחתי. ‏שמרו את שיווק ה-"הטוב ביותר" ל-meta description של העמוד (שגוגל מציג אבל לא קולט כסיגנל schema), ‏ואת ה-Service schema תעצבו עובדתית בלבד.

🔧 דוגמה מלאה, ‏שירותי תיקון בית (עם דוגמת קוד)

שירותי תיקון בית הם דוגמה ל-Service עם areaServed רחב (service area business). ‏השיפוצניק לא מקבל לקוחות במשרד שלו, ‏הוא מגיע לבית הלקוח. ‏הוא משרת אזור גיאוגרפי, ‏ועליו לסמן זאת בסכמה כדי שגוגל יציע אותו בחיפושים לוקאליים.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example-handyman.co.il/ac-repair/#service",
  "name": "תיקון מזגנים בבית",
  "description": "שירות תיקון מזגנים ביתי כולל אבחון תקלה, ‏תיקון, ‏החלפת חלקים, ‏וניקוי. ‏זמינות באותו היום באזור גוש דן ובסביבותיו",
  "provider": {
    "@type": "HVACBusiness",
    "@id": "https://example-handyman.co.il/#business",
    "name": "מזגנים אקספרס",
    "telephone": "+972-50-1234567",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "רחוב התעשייה 12",
      "addressLocality": "רמת גן",
      "addressRegion": "תל אביב",
      "postalCode": "5252188",
      "addressCountry": "IL"
    }
  },
  "serviceType": "Air Conditioning Repair",
  "areaServed": [
    {
      "@type": "GeoCircle",
      "geoMidpoint": {
        "@type": "GeoCoordinates",
        "latitude": 32.073283,
        "longitude": 34.798328
      },
      "geoRadius": "25000"
    },
    {
      "@type": "City",
      "name": "תל אביב"
    },
    {
      "@type": "City",
      "name": "רמת גן"
    },
    {
      "@type": "City",
      "name": "גבעתיים"
    },
    {
      "@type": "City",
      "name": "בני ברק"
    },
    {
      "@type": "City",
      "name": "חולון"
    }
  ],
  "audience": {
    "@type": "PeopleAudience",
    "audienceType": "בעלי בתים ודירות"
  },
  "offers": {
    "@type": "Offer",
    "name": "קריאת שירות + אבחון תקלה",
    "price": "250",
    "priceCurrency": "ILS",
    "description": "קריאת שירות כוללת אבחון. ‏מחיר התיקון נקבע לפי התקלה ומאושר על ידי הלקוח לפני הביצוע",
    "availability": "https://schema.org/InStock"
  },
  "url": "https://example-handyman.co.il/ac-repair/",
  "hoursAvailable": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Friday",
      "opens": "08:00",
      "closes": "14:00"
    }
  ]
}
</script>

מה מיוחד פה

• provider = HVACBusiness, ‏subtype ספציפי של HomeAndConstructionBusiness. ‏לא LocalBusiness כללי.
• areaServed כ-array של 6 entities, ‏אחד GeoCircle (רדיוס 25 ק"מ סביב נקודה) + 5 ערים ספציפיות. ‏הכפילות מסייעת ל-AI להבין שאזור השירות כולל את הערים האלה ספציפית.
• GeoCircle עם radius במטרים, ‏25000 = 25 ק"מ. ‏מציין את הרדיוס הגיאוגרפי שהעסק נותן בו שירות.
• hoursAvailable, ‏property של Service (לא Offer). ‏מתי השירות זמין. ‏לפי שעות הפעילות.
• Offer עם description מאוזן, ‏מציין שזה רק קריאת שירות + אבחון, ‏מחיר התיקון נפרד. ‏שקיפות.
• PeopleAudience, ‏לא BusinessAudience, ‏כי הקהל הוא צרכנים פרטיים (בעלי בתים).

📚 hasOfferCatalog לעסק עם כמה שירותים (עם דוגמת קוד)

אם יש לכם עסק שמציע יותר משירות אחד (וזה רוב עסקי השירות), ‏יש דרך אלגנטית להציג את כל השירותים בסכמה אחת, ‏דרך property בשם hasOfferCatalog. ‏זה מאפשר לקבץ את כל ה-Offers שלכם ב-OfferCatalog אחד, ‏ולציין אילו services מוצעים בכל offer.

למה zh עדיף על Service entities נפרדים

אפשר היה ליצור 5 Service entities נפרדים ב-@graph אחד. ‏זה עובד, ‏אבל מצריך 5 חזרות של provider, ‏areaServed, ‏וכו'. ‏hasOfferCatalog מאפשר להגדיר את ה-provider פעם אחת (ברמת LocalBusiness או Service ראשי), ‏ואז לפרט את כל ה-offers/services בקטלוג אחד.

דוגמת קוד, ‏יועץ SEO עם 4 מודלי ייעוץ

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://shmul.co.il/#consultant",
  "name": "שמוליק דורינבאום, יועץ SEO",
  "url": "https://shmul.co.il/יועץ-קידום-אתרים/",
  "telephone": "+972-54-7126629",
  "areaServed": {
    "@type": "Country",
    "name": "Israel"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "מודלי ייעוץ SEO",
    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "ייעוץ SEO חד-פעמי",
          "description": "סשן ייעוץ ממוקד של 2 שעות, אבחון מהיר וכיוון אסטרטגי",
          "serviceType": "One-Time SEO Consultation"
        },
        "price": "1500",
        "priceCurrency": "ILS"
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "ייעוץ SEO חודשי",
          "description": "מנוי חודשי קבוע, סשן 90 דקות + מעקב שבועי + ייעוץ בוואטסאפ",
          "serviceType": "Monthly SEO Retainer"
        },
        "price": "5000",
        "priceCurrency": "ILS"
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "ייעוץ פרויקט",
          "description": "ליווי פרויקט ספציפי (מיגרציה, השקה, rebrand) עד סיום",
          "serviceType": "SEO Project Consulting"
        },
        "priceSpecification": {
          "@type": "PriceSpecification",
          "minPrice": "15000",
          "maxPrice": "100000",
          "priceCurrency": "ILS"
        }
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "Audit + Handoff",
          "description": "audit מקיף עם דוח מפורט והעברה לצוות הפנימי, ללא מחויבות חודשית",
          "serviceType": "SEO Audit and Handoff"
        },
        "price": "8500",
        "priceCurrency": "ILS"
      }
    ]
  }
}
</script>

מה מיוחד פה

• 4 Offers בקטלוג אחד, ‏כל אחד מהם עם Service ספציפי בתוך itemOffered. ‏מאפשר לגוגל להבין את כל מודלי הייעוץ במכה אחת.
• priceSpecification במקום price במודל ה-"פרויקט". ‏המחיר משתנה לפי היקף, ‏אז יש טווח מ-15,000 עד 100,000 שקל. ‏שקיפות מבלי לפרסם מספר מומצא.
• provider לא חוזר בכל Offer, ‏כי הוא מוגדר ברמת ProfessionalService העליון. ‏כל ה-Offers יורשים אותו אוטומטית.
• serviceType ב-Service פנימי, ‏סיווג ספציפי לכל מודל. ‏"One-Time SEO Consultation" שונה מ-"Monthly SEO Retainer" וכו'.

🔗 Service + LocalBusiness combo ב-@graph (עם דוגמת קוד)

זה ה-pattern המתקדם ביותר, ‏שילוב Service ו-LocalBusiness ב-@graph אחד עם references דו-כיווניות דרך @id. ‏כך גוגל מבין שהעסק שלכם הוא X, ‏שהוא מציע 3 services, ‏ושכל service מסופק על ידי אותו עסק. ‏זה מקסים את הפוטנציאל של Knowledge Graph.

המבנה הקונספטואלי

1. LocalBusiness/ProfessionalService entity ראשי עם @id ייחודי
2. Service entities (אחד או יותר) עם provider שמצביע ל-@id של LocalBusiness
3. BreadcrumbList ו-Person (אם רלוונטי) באותו @graph
4. כל אחד עם @id ייחודי, ‏מקושר זה לזה דרך references

דוגמת קוד מלאה, ‏ProfessionalService + 2 Services + Person + BreadcrumbList

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "ProfessionalService",
      "@id": "https://shmul.co.il/#consultant",
      "name": "שמוליק דורינבאום",
      "url": "https://shmul.co.il/",
      "telephone": "+972-54-7126629",
      "email": "shmulik@shmul.co.il",
      "areaServed": {
        "@type": "Country",
        "name": "Israel"
      },
      "founder": {"@id": "https://shmul.co.il/#shmulik"},
      "makesOffer": [
        {"@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-monthly"},
        {"@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-audit"}
      ]
    },
    {
      "@type": "Person",
      "@id": "https://shmul.co.il/#shmulik",
      "name": "שמוליק דורינבאום",
      "jobTitle": "יועץ SEO",
      "url": "https://shmul.co.il/אודות/",
      "sameAs": [
        "https://www.linkedin.com/in/shmulikdorinbaum"
      ]
    },
    {
      "@type": "Service",
      "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-monthly",
      "name": "ייעוץ SEO חודשי",
      "description": "מודל ליווי שותפות חודשי",
      "provider": {"@id": "https://shmul.co.il/#consultant"},
      "serviceType": "SEO Consulting",
      "areaServed": {"@type": "Country", "name": "Israel"},
      "offers": {
        "@type": "Offer",
        "price": "5000",
        "priceCurrency": "ILS"
      }
    },
    {
      "@type": "Service",
      "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#service-audit",
      "name": "Audit SEO + Handoff",
      "description": "audit חד-פעמי + העברה לצוות",
      "provider": {"@id": "https://shmul.co.il/#consultant"},
      "serviceType": "SEO Audit",
      "areaServed": {"@type": "Country", "name": "Israel"},
      "offers": {
        "@type": "Offer",
        "price": "8500",
        "priceCurrency": "ILS"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://shmul.co.il/יועץ-קידום-אתרים/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "בית",
          "item": "https://shmul.co.il/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "יועץ SEO",
          "item": "https://shmul.co.il/יועץ-קידום-אתרים/"
        }
      ]
    }
  ]
}
</script>

מה מיוחד פה

• makesOffer ב-ProfessionalService, ‏property שמצביע על ה-Service entities שהעסק מציע. ‏היפוך של provider, ‏וקישור דו-כיווני.
• founder ב-ProfessionalService מצביע ל-Person, ‏לקשר את העסק לאדם שמאחוריו. ‏חיוני ל-E-E-A-T.
• provider בכל Service מצביע חזרה ל-@id של ProfessionalService, ‏סוגר את המעגל.
• BreadcrumbList גם ב-@graph, ‏כדי שגוגל יבין את ההיררכיה הניווטית של העמוד.

למה לא לפרק לכמה scripts נפרדים

אפשרות חלופית, ‏להטמיע 5 scripts JSON-LD נפרדים בעמוד אחד, אחד לכל entity. ‏גוגל מקבל גם את זה, אבל לא מצליח לקשר בין הישויות (אין לו @id משותף ב-context אחד). ‏התוצאה, ‏הוא רואה את ProfessionalService, ‏רואה את ה-Services, ‏אבל לא מבין שהן קשורות. ‏ה-@graph אחד עם references פותר את זה לחלוטין. ‏זה גם מנקה את ה-HTML (script אחד במקום 5), ‏וזה גם מקל על תחזוקה (כל ה-schema במקום אחד).

🎁 Service vs Product לשירותים דיגיטליים

זה אחד הדילמות הכי שכיחות אצל יוצרי מוצרים דיגיטליים. ‏יש לי קורס אונליין, ‏האם זה Service או Product? ‏יש לי SaaS, ‏האם זה Service או Product? ‏יש לי e-book, ‏האם זה Service או Product? ‏התשובה תלויה בקריטריון, ‏אבל יש כללי אצבע.

Service כשמדובר ב-

• פעולה שמבוצעת על ידי בן אדם או צוות (ייעוץ, ‏טיפול, ‏ניהול קמפיין)
• גישה לאורך זמן עם תמיכה (subscription מתמשך)
• מודל שירות מוגדר עם דרישות אספקה
• SaaS עם תמיכה אנושית בולטת

Product כשמדובר ב-

• קובץ דיגיטלי שמורד פעם אחת (e-book, ‏template, ‏plugin)
• מוצר עם SKU או גרסה מוגדרת
• פריט קונקרטי שניתן לסקור, ‏לדרג, ‏ולמכור (כמו פיזית)
• תוכנה שמוכרת בלי תלות בתמיכה אנושית מתמשכת

SoftwareApplication, ‏החריג השלישי

לתוכנות יש subtype ייעודי, ‏SoftwareApplication (subtype של CreativeWork). ‏הוא משולב גם עם Service וגם עם Product. ‏השתמשו בו לפלאגינים, ‏אפליקציות מובייל, ‏SaaS, ‏או כל תוכנה שניתנת להתקנה.

טבלת ההחלטה

דוגמה, ‏קורס אונליין עם Service + Course

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": ["Service", "Course"],
  "name": "קורס SEO מתקדם",
  "description": "קורס אונליין עם 40 שעות וידאו, מטלות, ותמיכה אישית בוואטסאפ",
  "provider": {
    "@type": "ProfessionalService",
    "name": "שמוליק דורינבאום"
  },
  "serviceType": "Online SEO Course with Mentorship",
  "courseMode": "Online",
  "educationalLevel": "Advanced",
  "offers": {
    "@type": "Offer",
    "price": "2500",
    "priceCurrency": "ILS"
  }
}
</script>

הקריטריון המכריע, ‏הזמן והתמיכה האנושית

אם אתם בספק, שאלו את עצמכם, האם הקנייה היא רגע בודד או תהליך לאורך זמן? קנייה של e-book = רגע בודד (משלמים, מורידים, נגמר). קנייה של ייעוץ = תהליך לאורך זמן (משלמים, מקבלים סשנים, מעקב). הראשון Product, השני Service. גם, האם יש מעורבות אנושית? תוכנת SaaS עם Customer Success Manager שמתקשר אליכם פעם בחודש = Service. תוכנת SaaS שאתם משתמשים בה לבד = Product או SoftwareApplication. ‏השילוב של זמן + מעורבות אנושית הוא ההבדל המרכזי, ולא רק שאלה של פורמט הקובץ.

🔍 אימות + Rich Results Test

אחרי שהטמעתם את ה-Service schema, ‏צריך לאמת. ‏שלא כמו LocalBusiness או Recipe, ‏ל-Service אין rich result ייעודי שגוגל מציג ב-SERP בצורה ויזואלית בולטת. ‏זה לא אומר שהסכמה לא עובדת, ‏זה אומר שהפלטפורמה לאימות שונה.

איפה Service מופיע בפועל

• Knowledge Panel, ‏כשמישהו מחפש את שם העסק, ‏גוגל מציג panel עם מידע. Service schema תורם לשדות כמו "Services offered" וקטגוריות.
• AI Overviews, ‏Google AI Overviews משתמש בסכמה לציטוטים. Service מפורט עם serviceType + areaServed מקבל יותר ציטוטים מ-LocalBusiness בלבד.
• ChatGPT / Perplexity, ‏סורקים את הסכמה ומחזירים תשובות מפורטות יותר על השירות שלכם.
• Local Pack לעיתים, ‏במקרים מסוימים גוגל מציג Service-specific information ב-Local Pack (לרוב לעסקי שירות עם areaServed ספציפי).

Rich Results Test, ‏מה לחפש

פתחו את search.google.com/test/rich-results והדביקו את ה-URL של העמוד עם Service schema. ‏לפי גוגל:

1. בודקים שאין errors

   שגיאות יפסיקו את הסכמה לחלוטין. ‏שגיאות נפוצות, ‏חוסר ב-required property (name), ‏או type לא תקף.

2. בודקים warnings

   אזהרות אומרות שהסכמה תקפה אבל חסרים properties recommended. ‏תקנו את כולם.

3. בודקים אם eligible for rich results

   Service לא יהיה eligible ל-rich result ייעודי (זה צפוי). ‏אבל הסכמה צריכה להיקלט נכון.

4. בודקים את ה-rendered preview

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

Schema Validator

פתחו את validator.schema.org והדביקו את ה-URL או את הקוד. ‏זה הכלי של schema.org עצמה, ‏בודק תאימות מלאה ל-spec. ‏הוא מציג גם warnings על properties שלא מוכרים, ‏וזה עוזר לזהות שגיאות הקלדה.

Search Console

אחרי שגוגל סורק את העמוד, ‏היכנסו ל-Search Console > Enhancements. ‏אם יש לכם schema תקין, ‏גוגל יזהה אותו ויראה אותו תחת "Detected Schemas". ‏Service לא תופיע בקטגוריה ייעודית כמו Product, ‏אבל תופיע ב-"All".

הציפיה הריאליסטית, ‏אל תחפשו כוכבים

תקשיבו, רוב המקדמים מאוכזבים מ-Service schema כי הם מצפים לראות תוצאות ויזואליות מיידיות ב-SERP. גוגל לא מציג כוכבים, badges, ‏או מחירים גלויים ל-Service כמו שהוא מציג ל-Product או Recipe. ה-Service schema הוא בעיקר סיגנל ל-AI engines וגם לסיכומי Knowledge Panel הפנימיים. ‏ההשפעה היא ארוכת טווח (חודשים), ‏לא מיידית (שבועות). ‏אל תחפשו את הוואו הוויזואלי, חפשו את העלייה בציטוטים ובתעבורה מ-AI Overviews ומ-Knowledge Panel queries. ‏שם נמצא ה-ROI האמיתי.

🚫 הטעויות הקלאסיות (Service לבד, ‏areaServed ריק, ‏Offer בלי currency)

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

טעות 1, ‏Service בלי provider

הטעות הכי שכיחה. ‏מקדמים מוסיפים @type: Service עם name + description בלבד. ‏גוגל מקבל את הסכמה אבל לא יודע מי מספק את השירות. ‏זה כמו מודעה בלי שם המודיע. ‏תמיד תוסיפו provider, ‏גם אם הוא רק שם בסיסי.

טעות 2, ‏השמטת serviceType

serviceType הוא ה-string שגוגל מסווג לפיו לקטגוריות. ‏בלעדיו השירות שלכם "שייך" לקטגוריה גנרית. ‏השתמשו ב-strings תיאוריים באנגלית כמו "SEO Consulting", ‏"Dental Cleaning", ‏"Home Repair". ‏לא בעברית, ‏שגוגל מסווג גלובלית באנגלית.

טעות 3, ‏areaServed ריק או "Worldwide"

אם תכתבו areaServed: "Worldwide" זה אומר לגוגל "כל מקום", ‏ובפועל אומר "אף מקום ספציפי". ‏גוגל לא ידע לתת לכם עדיפות באף שאילתה לוקאלית. ‏תמיד תפרטו את האזור הגיאוגרפי שאתם משרתים בפועל, ‏גם אם זה כל המדינה ("IL" או Country).

טעות 4, ‏Offer בלי priceCurrency

price בלי priceCurrency הוא "5000" בלי שגוגל יודע אם זה דולרים, ‏שקלים, ‏או יורו. ‏גוגל מתעלם מ-Offer שלא תקין. ‏תמיד תוסיפו "priceCurrency": "ILS" (או הקוד הנכון). ‏אם המחיר משתנה, ‏אל תרשמו price מומצא, ‏השתמשו ב-priceSpecification עם טווח.

טעות 5, ‏שכפול של LocalBusiness כ-Service בלי קישור

חלק מטמיעים LocalBusiness ובנפרד Service, ‏בלי לקשר ביניהם ב-@graph. ‏שתי הסכמות מתקיימות במקביל אבל לא קשורות. ‏זה מבזבז את הפוטנציאל. ‏חייבים @id בשני ה-entities + reference דרך provider מ-Service ל-@id של LocalBusiness.

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

• name כללי כמו "השירותים שלי" במקום שם ספציפי לשירות
• description קצר מ-20 מילים (גוגל מתעלם)
• provider כ-string במקום object
• שכפול של אותו serviceType לשני services שונים
• hasOfferCatalog ריק (בלי itemListElement)
• שימוש ב-@type: Service כשהשירות הוא בעצם Product (קורס מוקלט בלי תמיכה)
• שימוש ב-Organization כ-provider לעסק עם נוכחות פיזית (חייב LocalBusiness או subtype)
• areaServed כ-string "Israel" במקום Country object (פחות מועדף, גוגל מקבל אבל לא אופטימלי)
• price בעברית עם פסיק ("5,000") במקום מספר נטו ("5000")
• השמטה של url ב-Service (גוגל לא יודע איפה לקרוא עוד)

📋 workflow הטמעה ב-10 שלבים + תחזוקה חודשית

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

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

1. זיהוי שכבת ה-LocalBusiness/ProfessionalService

   בדקו שיש לכם LocalBusiness/ProfessionalService entity מוגדר באתר. ‏אם לא, ‏הטמיעו אותו לפי המדריך השלם ל-LocalBusiness. ‏זה ה-provider של ה-Services.

2. זיהוי השירותים שאתם מציעים

   רשמו את כל השירותים. ‏לא רק "כללי", ‏אלא ספציפיים. ‏יועץ SEO = "ייעוץ חד-פעמי", "חודשי", "פרויקט", "Audit". ‏4 Services נפרדים, ‏לא אחד.

3. החלטה, ‏Service entities נפרדים או hasOfferCatalog

   1-2 שירותים = entities נפרדים. ‏3+ שירותים = hasOfferCatalog. ‏פחות שכפול קוד, ‏יותר נוח לתחזק.

4. הגדרת serviceType לכל שירות

   string באנגלית, ‏סיווג גלובלי. ‏"SEO Consulting", ‏"Dental Surgery", ‏"Tax Preparation". ‏הסיווגים האלה הם איך גוגל מקבץ אתכם בקטגוריות.

5. הגדרת areaServed

   אזור גיאוגרפי ספציפי. ‏Country, ‏City, ‏AdministrativeArea, ‏או GeoCircle. ‏לעסקי שירות עם רדיוס פיזי, ‏השתמשו ב-GeoCircle. ‏לכל אחרים, ‏Country או City.

6. הגדרת Offer לכל שירות

   price + priceCurrency + availability. ‏אם המחיר משתנה, ‏priceSpecification עם טווח. ‏אל תכתבו מספר מומצא.

7. הוספת description מפורט

   50-150 מילים לכל שירות. ‏מה כלול, ‏מה לא, ‏למי מתאים. ‏זה ה-content שה-AI מצטט.

8. שילוב ב-@graph עם provider references

   כל Service עם provider שמצביע ל-@id של LocalBusiness. ‏ב-LocalBusiness אפשר גם makesOffer שמצביע חזרה. ‏קישור דו-כיווני.

9. אימות ב-Rich Results Test + Schema Validator

   הריצו את ה-URL בשני הכלים. ‏0 errors. ‏תיקון כל warning. ‏בדקו ש-Service מופיע ב-rendered preview.

10. Request Indexing ב-Search Console

    URL Inspection, ‏Request Indexing. ‏גוגל יקלוט את הסכמה תוך 24-48 שעות. ‏בדקו ב-Enhancements ב-Search Console שהוא זוהה.

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

• בדיקת הסכמה ב-Rich Results Test, ‏עדיין תקין?
• השוואה עם הצעת השירות בעמוד עצמו, ‏עדיין תואם? (אם שיניתם מחיר באתר ולא בסכמה, ‏זה inconsistency)
• וודאו ש-areaServed עדיין מדויק (לא הרחבתם או צמצמתם אזור שירות)
• אם הוספתם שירות חדש לעסק, ‏הוספת Service entity חדש או הוספה ל-hasOfferCatalog
• בדיקת priceValidUntil ב-Offers, ‏עדיין בתוקף?
• בדיקת availability, ‏עדיין InStock? (אם מפסיקים לתת שירות, ‏עדכן ל-Discontinued)
• בדיקת Search Console > Enhancements, ‏אם יש שגיאות חדשות שצצו
• איסוף נתונים, ‏האם עליתם בציטוטי AI לשאילתות הקטגוריה שלכם?
• אחת לרבעון, ‏בדיקה אם schema.org פירסם properties חדשים ל-Service
• אחת לרבעון, ‏בדיקת תחרות, ‏האם מתחרים שיפרו את הסכמה שלהם?

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