LocalBusiness Schema, מדריך עומק לכל סוג עסק

🏪 מה זה LocalBusiness schema, ולמה זה לא Organization

תקשיבו. אני אפתח עם הסיפור שאני שומע פעם בשבוע. בעל עסק מתקשר, "שמוליק, יש לי schema באתר, רואה את זה ב-View Source". אני בודק את האתר. הוא הטמיע @type: Organization בעמוד הבית של חנות הפיצה שלו ברמת גן. נחשו למה גוגל לא מציג לו rich results, ולמה Google Business Profile לא מקבל את הסיגנלים האלה? כי Organization זה לא LocalBusiness. נקודה.

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

למה זה משנה לגוגל

גוגל משתמש ב-LocalBusiness schema כ-"מקור אמת שני" אחרי Google Business Profile. כשיש סתירה בין מה ש-GBP אומר לבין מה שהאתר אומר, גוגל מצמצם אמון בעסק. כשיש עקביות, גוגל מעלה אותו ב-Local Pack וב-Maps. ה-schema הוא הגשר בין מה שאתם אומרים על עצמכם ב-GBP, לבין מה שאתם אומרים על עצמכם באתר. שניהם חייבים להגיד אותו דבר, באותו פורמט.

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

15 פרקים שמתחילים מהבסיס (איך לבחור subtype נכון, מה זה PostalAddress, איך כותבים OpeningHours שגוגל באמת מבינה), ועוברים לדוגמאות קוד JSON-LD מלאות לעסקים ישראליים, ‏שילוב עם @graph, multi-location, וטעויות נפוצות. אם תקראו עד הסוף ותטמיעו את הקוד הנכון לעסק שלכם, אתם תהיו בשטח הקטן של 10% מהעסקים בישראל עם schema תקין. רוב המקדמים בארץ עדיין מטמיעים LocalBusiness גנרי או Organization שגוי, אז זה advantage אמיתי.

אגב, השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO. אני אישית טיפלתי במאות אתרי לקוחות בכל הסוגים, ממסעדות בתל אביב ועד משרדי עו"ד בחיפה. בכל פעם, ההבדל בין dominant Local Pack לבין שקיפות מוחלטת התחיל מבחירת ה-subtype הנכון של LocalBusiness. אם אחרי המאמר אתם תקועים בהטמעה, יש לכם איך לדבר איתי ישירות.

🌳 100+ ה-subtypes, ‏מבנה ההיררכיה (עם דוגמאות)

זה החלק שמפיל הכי הרבה מקדמים. הם פותחים schema.org, רואים את הדף של LocalBusiness, ואומרים "אוקיי, אני אשתמש ב-LocalBusiness". אבל זה כמו ללכת לחנות בגדים ולבחור "בגד" במקום "חולצה". יש 100+ subtypes ספציפיים שכל אחד מהם יורש את ה-properties של LocalBusiness ומוסיף משלו. הבחירה הנכונה מאפשרת לגוגל להבין בדיוק מה אתם עושים, ולספק לכם rich results ייעודיים. נחשו למה רוב המקדמים בארץ עדיין משתמשים ב-LocalBusiness כללי? כי הם לא טרחו לקרוא את schema.org. אל תהיו הם.

ה-subtypes הראשיים

ההיררכיה היא LocalBusiness > sub > sub-sub. הנה הענפים המרכזיים שתפגשו בשטח, עם תת-הטיפוסים החשובים בכל אחד:

1. AutomotiveBusiness

   עסקים בתחום הרכב. תת-טיפוסים: AutoBodyShop (פחחות), AutoDealer (סוכנות רכב), AutoPartsStore (חלפים), AutoRental (השכרה), AutoRepair (מוסך), AutoWash (שטיפת רכב), GasStation (תחנת דלק), MotorcycleDealer, MotorcycleRepair.

2. MedicalBusiness

   שירותי בריאות. תת-טיפוסים: CommunityHealth, Dentist, Dermatology, Hospital, Optician, Pharmacy, Physiotherapy, Psychiatric, VeterinaryCare. כל subtype רפואי מוסיף את medicalSpecialty.

3. FoodEstablishment

   אכילה ושתייה. תת-טיפוסים: Bakery, BarOrPub, Brewery, CafeOrCoffeeShop, FastFoodRestaurant, IceCreamShop, Restaurant, Winery. כולם יורשים את servesCuisine ו-menu.

4. HealthAndBeautyBusiness

   טיפוח. תת-טיפוסים: BeautySalon, DaySpa, HairSalon, HealthClub, NailSalon, TattooParlor.

5. HomeAndConstructionBusiness

   שיפוצים ובית. תת-טיפוסים: Electrician, GeneralContractor, HVACBusiness (מיזוג), HousePainter, Locksmith, MovingCompany, Plumber, RoofingContractor.

6. LegalService, FinancialService, ProfessionalService

   שירותים מקצועיים. עו"ד = LegalService, רואה חשבון = AccountingService (subtype של FinancialService), יועץ עסקי = ProfessionalService. בנק = BankOrCreditUnion (גם תת של FinancialService).

7. LodgingBusiness

   שינה. Hotel, Motel, Hostel, BedAndBreakfast, Resort, Campground.

8. SportsActivityLocation

   ספורט ופנאי. BowlingAlley, GolfCourse, Gym, SkiResort, StadiumOrArena, TennisComplex.

9. Store

   חנויות קמעונאיות. BookStore, ClothingStore, ComputerStore, ConvenienceStore, FurnitureStore, GardenStore, JewelryStore, ToyStore, ShoeStore, WholesaleStore.

10. TravelAgency, ChildCare, EmploymentAgency, RealEstateAgent

    שירותים ספציפיים אחרים, כל אחד subtype ישיר של LocalBusiness, בלי תת-קטגוריות נוספות.

איך בוחרים

הכלל פשוט, תלכו לעומק הכי אפשרי. אם אתם מסעדה ספציפית, אל תבחרו FoodEstablishment, תבחרו Restaurant. אם אתם רופא שיניים, אל תבחרו MedicalBusiness, תבחרו Dentist. אם אין subtype ספציפי לעסק שלכם (לדוגמה, ייעוץ עסקי לא-קלאסי), השתמשו ב-ProfessionalService או LocalBusiness ישיר. רק כמוצא אחרון.

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

חוץ מגוגל, גם ChatGPT, Perplexity, ו-AI Overviews משתמשים ב-schema כדי להבין מה העסק עושה. כש-AI engine מקבל שאלה "איזה רופא שיניים טוב בירושלים", הוא לא רק קורא טקסט, הוא קורא structured data. עסק עם @type: Dentist ספציפי מקבל יותר סיכוי להופיע בתשובה מאשר עסק עם LocalBusiness כללי. ה-subtype הוא הסיגנל שאתם נמצאים בקטגוריה הנכונה.

✅ Required properties, ‏name + address + telephone (עם דוגמת קוד)

אם תזכרו רק שלושה דברים מהמאמר הזה, שיהיו אלה, name, address, telephone. אלה ה-required properties של LocalBusiness לפי גוגל (לא לפי schema.org, ששם רק name חובה, אבל אנחנו עובדים לפי גוגל, לא לפי schema.org). בלעדיהם, ה-rich results לא יופיעו, ‏גוגל לא יחשיב את ה-schema, ו-Search Console יראה אזהרות מתחת ל-Enhancements > LocalBusiness.

name

השם המסחרי המלא של העסק. בדיוק כפי שהוא רשום ב-Google Business Profile. לא קיצורים, לא ניקוד מיותר, לא תוספות ("רחוב X" או "סניף ראשי"). פשוט השם. אם ב-GBP אתם "מסעדת רומא", אז ב-schema אתם "מסעדת רומא". אם תוסיפו "בע"מ" או "סניף תל אביב" רק במקום אחד, יש לכם inconsistency.

address

כתובת מובנית של PostalAddress (פרק 4 צולל לעומק). אסור להגיש מחרוזת אחת של "דיזנגוף 142, תל אביב". חייב להיות object מובנה עם streetAddress, addressLocality, addressRegion, postalCode, addressCountry. גוגל יכול לפענח גם מחרוזת אחת, אבל הוא יתעלם ממנה כשהוא בוחר eligible ל-rich results.

telephone

מספר טלפון בפורמט בינלאומי E.164, בדיוק כמו ב-GBP. דוגמה, +972-3-5551234. עם המקף או בלי, גוגל מתעלם מהמקף, אבל חייבת להיות קידומת בינלאומית (+972). מספר ישראלי בפורמט מקומי ("03-5551234" או "0501234567") נפסל. זה אחד הדברים הראשונים שגוגל בודק.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "קפה דיזנגוף 142",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "דיזנגוף 142",
    "addressLocality": "תל אביב",
    "addressRegion": "תל אביב",
    "postalCode": "6433201",
    "addressCountry": "IL"
  },
  "telephone": "+972-3-5551234"
}
</script>

זה ה-schema המינימלי שיעבור validation ויחזיר eligible for rich results ב-Schema Validator. אבל זה לא יקבל אותם, כדי לקבל rich results בפועל, צריך לפחות openingHours, image, ו-priceRange. נצלול לזה בפרקים הבאים.

הוספת @id ו-url

שני properties שאינם required אבל הם best practice. @id ייחודי שמזהה את העסק על פני כל ה-schemas שלכם (חשוב במיוחד ב-@graph). url שמקשר לעמוד הבית של העסק (או לעמוד הסניף הספציפי, ב-multi-location). הפורמט המקובל ל-@id הוא URL מלא של העמוד + hash, לדוגמה https://example.co.il/#business. זה מבטיח ייחודיות גם כשיש לכם כמה entities באתר אחד.

📍 PostalAddress structure, ‏איך לבנות כתובת מסודרת ב-IL

הנה איפה רוב המקדמים נופלים. PostalAddress לא קשה, אבל יש בו דקויות שגוגל מקפיד עליהן בישראל, בעיקר בגלל הפורמט העברי המעורבב והעובדה שיש addressRegion שלא תמיד ברור איך לתרגם לישראלי. תקשיבו, רוב המקדמים פותחים schema.org רואים "streetAddress" ומדביקים "דיזנגוף 142, תל אביב". זאת טעות, וזה ההבדל בין rich results לבין כלום.

השדות

1. streetAddress

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

2. addressLocality

   שם העיר. "תל אביב", "ירושלים", "חיפה", "באר שבע". אסור לקצר ל-"ת"א", גוגל מצפה לשם המלא. אם בעיר יש שני שמות (לדוגמה "בית שמש"), השתמשו בשם הרשמי כפי שהוא ב-GBP.

3. addressRegion

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

4. postalCode

   המיקוד הישראלי בן 7 ספרות (לא 5 כמו לפני 2013). אם אתם בעמוד הוצאת תעודות, חפשו שם. בלי מקף בין הספרות. הפורמט הוא רצף של 7 ספרות, לדוגמה "6433201".

5. addressCountry

   הכי חשוב לישראל. תמיד "IL" כקוד ISO 3166-1 alpha-2. לא "Israel", לא "ישראל", לא "IS". רק "IL". זה אחד מהשדות שגוגל בודק first, אם הוא לא תקין, ה-schema נפסל לחלוטין.

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

"address": {
  "@type": "PostalAddress",
  "streetAddress": "רחוב הרצל 89",
  "addressLocality": "ירושלים",
  "addressRegion": "ירושלים",
  "postalCode": "9418901",
  "addressCountry": "IL"
}

מה אם יש קומה או דירה

הוסיפו לתוך streetAddress, לדוגמה "דיזנגוף 142, קומה 3, משרד 7". אין שדה נפרד ב-PostalAddress לקומה. תפסיקו לחפש.

מה אם אתם בקיבוץ או יישוב קהילתי

אין שם רחוב? streetAddress = שם המקום + מספר הבית, לדוגמה "קיבוץ אילון, בית 47". addressLocality = שם הקיבוץ עצמו או שם היישוב המוניציפלי. addressRegion = מחוז. גוגל קולט את זה לפי שילוב geo coordinates שתוסיפו (פרק 6). הוא יודע שיש דברים שאי אפשר לפענח רק מהכתובת.

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

הכתובת ב-schema חייבת להיות זהה למילה אחרונה עם הכתובת ב-Google Business Profile, ב-NAP citations בכל הספריות (B144, Walla Yellow, Easy וכו'), ובפוטר של האתר. כל וריאציה ("רחוב" מול "רח'", "ת"א" מול "תל אביב") נחשבת inconsistency וחותכת ב-Local Pack. המדריך המלא ל-NAP consistency מתעמק בזה. הכלל הזהב, תבחרו פורמט אחד של הכתובת ותדבקו בו בכל המקומות. אל תכתבו "רחוב" במקום אחד ו-"רח'" במקום אחר.

⏰ OpeningHours, ‏הפורמט שגוגל באמת מבינה (עם דוגמת קוד)

OpeningHours זה אחד התחומים שגוגל שינה את הדעה לגביו. בעבר התקבל הפורמט הקצר openingHours: "Mo-Fr 09:00-18:00" כמחרוזת. היום זה עדיין עובד אבל פחות מומלץ. הפורמט המודרני הוא openingHoursSpecification עם array של OpeningHoursSpecification objects. למה השינוי? כי הפורמט החדש מאפשר דקויות שהפורמט הישן לא ידע לתאר, ימים שונים עם שעות שונות, תקופות חגים, סגירה זמנית, וכל מה שעסק אמיתי באמת צריך להגדיר.

הפורמט הישן (עדיין עובד)

"openingHours": [
  "Mo-Fr 09:00-18:00",
  "Sa 10:00-14:00"
]

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

הפורמט המומלץ (openingHoursSpecification)

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "https://schema.org/Sunday",
      "https://schema.org/Monday",
      "https://schema.org/Tuesday",
      "https://schema.org/Wednesday",
      "https://schema.org/Thursday"
    ],
    "opens": "09:00",
    "closes": "18:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": "https://schema.org/Friday",
    "opens": "09:00",
    "closes": "14:00"
  }
]

הדקויות הישראליות

בישראל יש כמה דקויות שגורמות לבלגן:

• שבוע ישראלי שונה מהמערבי, ‏יום ראשון (Sunday) הוא יום עבודה רגיל אצלנו, ולא חלק מהסוף שבוע. תוודאו ש-Sunday נמצא ב-array של ימי פעילות אם העסק שלכם פתוח אז.
• שישי קצר, ‏רוב העסקים סוגרים מוקדם בשישי. הוסיפו בלוק נפרד לשישי עם השעות הנכונות.
• שבת סגור, ‏אם העסק סגור בשבת, אל תכללו את Saturday ב-array. אל תוסיפו opens: "00:00" כמובן.
• חגים יהודיים, ‏אפשר להוסיף validFrom ו-validThrough לבלוקים מיוחדים. לדוגמה, לסגירה בפסח, הוסיפו בלוק עם validFrom="2026-04-12" ו-validThrough="2026-04-19" ועם opens=closes=00:00.

פורמט מלא לעסק ישראלי טיפוסי (פתוח א"ה, שישי עד 14, שבת סגור)

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday"],
    "opens": "08:30",
    "closes": "18:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": "Friday",
    "opens": "08:30",
    "closes": "14:00"
  }
]

פורמט שעות, 24h או 12h?

תמיד 24h. גוגל לא קולט AM/PM. "opens": "09:00" ולא "9:00 AM". פורמט HH:MM עם אפס מוביל אם צריך. "opens": "08:30" עובד, "opens": "8:30" יעיף warning, ו-"opens": "8:30 AM" יפיל validation. תמיד 24h, אפס מוביל לשעות חד-ספרתיות, מסך עם נקודתיים. זה קל לזכור אבל קל גם להחמיץ אם מעתיקים מתבנית ישנה.

🗺 Geo coordinates, ‏latitude/longitude כ-GeoCoordinates (עם קוד)

geo coordinates זה ה-bonus הגדול של LocalBusiness schema. הוא משחזר לגוגל את המיקום המדויק שלכם, מעבר למה שהוא יכול לפענח מהכתובת. במיוחד חשוב בקיבוצים, יישובים חדשים, בתי עסק בקניון (שמספר הרחוב לא ייחודי), או כל מצב שכתובת לבדה לא מספיק מדויקת. רוב המקדמים מדלגים על השדה הזה כי "זה לא חובה". זה טעות. הוספת geo coordinates שמתאימות לכתובת מחזקת את האות, ובעיקר מבטלת כל אי-ודאות של גוגל לגבי המיקום הפיזי שלכם. במיוחד באזורים שמקבלים שינויי ניווט תכופים (התחדשות עירונית, רחובות שעוברים שמות), ה-geo coordinates מקבעות את המיקום גם אם שם הרחוב משתנה.

המבנה

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 32.083333,
  "longitude": 34.783333
}

זהו. שתי שדות, שני מספרים עשרוניים. בלי מעלות, בלי קו רוחב/אורך באותיות.

איך מקבלים את הקואורדינטות

1. פתחו Google Maps
2. חפשו את הכתובת המדויקת של העסק
3. לחצו עם קליק ימני על הסיכה במפה
4. השורה הראשונה בתפריט שנפתח היא ה-latitude,longitude. לחצו כדי להעתיק
5. הדביקו ב-schema

דוגמה, חנות אופניים בתל אביב

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 32.072143,
  "longitude": 34.778890
}

כמה ספרות אחרי הנקודה

6 ספרות מספיקות לדיוק של כ-10 ס"מ. 4 ספרות = דיוק של כ-10 מטר. אל תעגלו ל-2 ספרות, זה דיוק של 1 ק"מ וזה מטריד את גוגל. השאירו 5-6 ספרות.

שילוב עם hasMap

property נוסף שגוגל אוהב, hasMap עם URL ישיר ל-Google Maps של העסק:

"hasMap": "https://maps.google.com/?cid=12345678901234567890"

ה-cid (Customer ID) של העסק נמצא ב-URL של Google Business Profile. זה ה-signal הכי חזק לגוגל שהעסק שלכם ב-schema הוא בדיוק העסק ב-GBP. אם אין לכם את ה-cid, אפשר להשתמש ב-URL הרגיל של Maps, אבל cid עדיף.

איך לחלץ את ה-cid

פתחו את Google Business Profile של העסק שלכם. ב-URL של הפרופיל יש פרמטר ?placeid= או דרך ה-API. אם זה מורכב, יש כלים חינמיים ("Google Maps CID Finder") שיעשו את זה. שווה את 5 הדקות. ‏ה-cid הוא בעצם המפתח שמקשר בין ה-schema באתר לבין ה-listing הספציפי של העסק ב-GBP. בלעדיו, גוגל צריך להסיק את הקישור לבד דרך תאימות NAP. עם cid, האות מיידי וחד-משמעי.

🎯 Subtype בחירה, ‏איך להחליט בין LocalBusiness ל-Restaurant/Dentist/וכו'

הכלל הברור, תמיד תבחרו את ה-subtype הספציפי ביותר שמתאים לעסק שלכם. למה? כי כל subtype יורש את ה-properties של LocalBusiness ומוסיף משלו. שימוש בטיפוס הספציפי = יותר properties = יותר rich results = יותר אינפורמציה לגוגל. שימוש בטיפוס הכללי = פחות מידע = פחות יתרון. תקשיבו, זה כל כך פשוט שזה כואב לראות כמה מקדמים מפספסים את זה.

דוגמאות מעולם המסעדנות

• FoodEstablishment (כללי), כל סוג של עסק שמגיש אוכל. ירש מ-LocalBusiness, מוסיף servesCuisine, menu, acceptsReservations.
• Restaurant (ספציפי יותר), מסעדה לאכילה במקום. ירש מ-FoodEstablishment, מוסיף את כל ה-properties שלו.
• FastFoodRestaurant (הכי ספציפי), מסעדת מזון מהיר. ירש מ-Restaurant.

אם אתם בורגר רנץ', תבחרו FastFoodRestaurant. אם אתם בית קפה, תבחרו CafeOrCoffeeShop. אם אתם מסעדה ים תיכונית, תבחרו Restaurant. אל תסתפקו ב-FoodEstablishment אם יש שם ספציפי יותר.

דוגמאות מעולם הרפואה

• MedicalBusiness (כללי), כל עסק רפואי
• Dentist (ספציפי), קליניקת שיניים. ירש את כל ה-properties הרפואיים ומוסיף את עצמו כסוג ייחודי
• Physiotherapy, פיזיותרפיסט
• Optician, אופטומטריסט
• Pharmacy, בית מרקחת

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

השתמשו ב-array של @type. דוגמה, סלון יופי שגם נותן טיפול ספא:

"@type": ["BeautySalon", "DaySpa"]

גוגל מכבד את שני הסוגים, ויכול להציג rich results שמתאימים לשניהם. שימוש מתון, אל תוסיפו 5 סוגים סתם כי "זה לא מזיק". כל סוג שמוסיף = השער של תחזוקה.

מה אם אין subtype שמתאים

השתמשו ב-LocalBusiness ישירות, או ב-ProfessionalService אם זה שירות מקצועי. הימנעו מ-Organization (זה לא local) או מ-@type שגוי.

בסוף, ‏בחירת ה-subtype היא ההחלטה הראשונה והכי חשובה ב-LocalBusiness schema. אל תתפשרו עליה. 5 דקות של מחקר בהתחלה חוסכות חודשים של schema לא-אופטימלי שלא מציג rich results. אגב, אחת לתקופה גוגל גם מוסיפים subtypes חדשים. אם פתחתם את העסק בקטגוריה שלא הייתה קיימת ב-schema.org לפני שנתיים, ייתכן שכבר יש subtype חדש שמתאים לכם. אחת לחצי שנה כדאי לבדוק.

🍝 דוגמת קוד מלאה, ‏מסעדה בתל אביב

הנה דוגמה מלאה לסוג העסק הראשון, מסעדה איטלקית בתל אביב. כוללת כל ה-properties שגוגל אוהב, כולל servesCuisine, menu, acceptsReservations שמיוחדים ל-Restaurant. תקשיבו, רוב המסעדות בישראל היום עם schema של LocalBusiness כללי. תיתנו להן schema של Restaurant עם כל ה-properties הספציפיים, ותקבלו rich results שהן לא יודעות שקיימים בכלל. כפתור "View Menu" ב-SERP, כפתור "Reserve", הצגת servesCuisine מתחת לשם המסעדה. כל אלה דורשים את ה-subtype Restaurant ולא LocalBusiness.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://pasta-roma-tlv.co.il/#restaurant",
  "name": "פסטה רומא",
  "image": [
    "https://pasta-roma-tlv.co.il/images/restaurant-front.jpg",
    "https://pasta-roma-tlv.co.il/images/dining-room.jpg",
    "https://pasta-roma-tlv.co.il/images/pasta-carbonara.jpg"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "בוגרשוב 23",
    "addressLocality": "תל אביב",
    "addressRegion": "תל אביב",
    "postalCode": "6346924",
    "addressCountry": "IL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 32.080123,
    "longitude": 34.772456
  },
  "telephone": "+972-3-5234567",
  "url": "https://pasta-roma-tlv.co.il/",
  "servesCuisine": ["איטלקית", "ים תיכונית"],
  "menu": "https://pasta-roma-tlv.co.il/menu/",
  "acceptsReservations": true,
  "priceRange": "₪₪",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "12:00",
      "closes": "23:30"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Friday",
      "opens": "12:00",
      "closes": "15:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "19:30",
      "closes": "23:30"
    }
  ],
  "paymentAccepted": ["Cash", "Credit Card", "Debit Card"],
  "currenciesAccepted": "ILS",
  "hasMap": "https://maps.google.com/?cid=15234567890123456789",
  "sameAs": [
    "https://www.facebook.com/pastaromatlv",
    "https://www.instagram.com/pasta_roma_tlv"
  ]
}
</script>

מה מיוחד פה

• servesCuisine, array של סוגי מטבח. גוגל מציג ב-rich results וב-Local Pack.
• menu, URL לדף התפריט באתר. גוגל יכול להציג כפתור "View Menu" ב-results.
• acceptsReservations: true, גוגל יציג כפתור "Reserve" אם משולב עם reservation service.
• priceRange: "₪₪", סולם 1-4 סמלי מטבע. "₪" זול, "₪₪₪₪" יקר.
• שבת פתוח בערב, ‏בלוק נפרד עם שעות שונות. גוגל מציג בדיוק במפה לפי השעות הללו.
• currenciesAccepted: "ILS", ‏קוד ISO לשקל. חשוב לתיירים שמחפשים מסעדות.

🦷 דוגמת קוד מלאה, ‏קליניקת שיניים בירושלים

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://clinic-cohen-jlm.co.il/#dentist",
  "name": "קליניקת שיניים ד\"ר כהן",
  "image": "https://clinic-cohen-jlm.co.il/images/clinic-front.jpg",
  "description": "קליניקה לרפואת שיניים כללית ושיקומית בירושלים, בהובלת ד\"ר כהן, מומחה בעל ותק של 15 שנים",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "רחוב הרצל 89, קומה 3",
    "addressLocality": "ירושלים",
    "addressRegion": "ירושלים",
    "postalCode": "9418901",
    "addressCountry": "IL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 31.776812,
    "longitude": 35.224732
  },
  "telephone": "+972-2-6234567",
  "url": "https://clinic-cohen-jlm.co.il/",
  "medicalSpecialty": "Dentistry",
  "availableService": [
    {
      "@type": "MedicalProcedure",
      "name": "רפואת שיניים שיקומית"
    },
    {
      "@type": "MedicalProcedure",
      "name": "השתלות שיניים"
    },
    {
      "@type": "MedicalProcedure",
      "name": "יישור שיניים"
    }
  ],
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday", "Monday", "Wednesday"],
      "opens": "08:30",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Thursday"],
      "opens": "08:30",
      "closes": "15:00"
    }
  ],
  "priceRange": "₪₪₪",
  "paymentAccepted": ["Cash", "Credit Card", "Bank Transfer"],
  "currenciesAccepted": "ILS",
  "hasMap": "https://maps.google.com/?cid=12345098765432109876",
  "sameAs": [
    "https://www.facebook.com/clinic-cohen-jlm"
  ]
}
</script>

מה מיוחד פה

• @type: Dentist, ‏subtype ספציפי במקום MedicalBusiness כללי. גוגל מקבל איתות שזו קליניקת שיניים ולא בית חולים.
• medicalSpecialty, ‏שדה ייחודי ל-Dentist שמציין את ה-specialty. "Dentistry" הוא הערך הכללי. ל-specialties ייעודיים אפשר "Orthodontics" (יישור), "Endodontics" (טיפול שורש), "Oral Surgery" (כירורגיה).
• availableService, ‏array של MedicalProcedure objects. שירותים ספציפיים שהקליניקה מציעה. גוגל יכול להציג זאת כ-services panel.
• description מאוזן, ‏בלי "הטוב ביותר" או "מומחה מספר אחת". "בהובלת ד"ר כהן, מומחה" + ציון ותק. נכון, נכון לרגולציה, נכון לגוגל.
• אין aggregateRating בדוגמה הזאת, ‏רק מוסיפים אם יש לכם רייטינגים אמיתיים מאומתים. פרק מלא על reviews schema.

לפרספקטיבה רחבה יותר

ראו את המדריך השלם ל-SEO לרופאי שיניים, שמכסה את כל ההיבטים של קידום קליניקה, כולל ה-schema בהקשר רחב יותר של קידום YMYL.

⚖️ דוגמת קוד מלאה, ‏משרד עו"ד בחיפה

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://levi-law-haifa.co.il/#firm",
  "name": "משרד עורכי דין לוי ושות'",
  "image": "https://levi-law-haifa.co.il/images/office.jpg",
  "description": "משרד עורכי דין בחיפה, עוסק בדיני משפחה, צוואות וירושות, ונדל\"ן. ‏מספק ייעוץ ראשוני ללא תשלום",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "שדרות הנשיא 124, קומה 5",
    "addressLocality": "חיפה",
    "addressRegion": "חיפה",
    "postalCode": "3464124",
    "addressCountry": "IL"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 32.812345,
    "longitude": 34.987654
  },
  "telephone": "+972-4-8123456",
  "url": "https://levi-law-haifa.co.il/",
  "email": "info@levi-law-haifa.co.il",
  "areaServed": [
    {
      "@type": "AdministrativeArea",
      "name": "חיפה והקריות"
    },
    {
      "@type": "AdministrativeArea",
      "name": "כל מחוז חיפה והצפון"
    }
  ],
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:30",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Friday",
      "opens": "08:30",
      "closes": "13:00"
    }
  ],
  "priceRange": "₪₪₪",
  "paymentAccepted": ["Cash", "Credit Card", "Bank Transfer"],
  "currenciesAccepted": "ILS",
  "hasMap": "https://maps.google.com/?cid=98765432109876543210",
  "sameAs": [
    "https://www.linkedin.com/company/levi-law-haifa"
  ]
}
</script>

מה מיוחד פה

• @type: LegalService, ‏subtype ייעודי. גוגל מבין שזה משרד עו"ד.
• areaServed, ‏property חשוב ל-service-area businesses. משרד עו"ד יכול לתת שירות לאזור גיאוגרפי רחב יותר ממקום המשרד. AdministrativeArea רך, אפשר לציין "חיפה והקריות" או "כל מחוז חיפה".
• email, ‏שדה לא חובה אבל מומלץ. גוגל יכול להציג כפתור "שלח אימייל" ב-rich results.
• description בלי "מומחה", ‏חוק לשכת עו"ד אוסר על שימוש בתואר "מומחה" או "מתמחה" בשיווק. כתבתי "עוסק בדיני" שזה תיאור פעולה ולא תואר.
• "ייעוץ ראשוני ללא תשלום", ‏מותר לציין, חשוב להמרה ב-CTR.

הוספת prices לשירותים

אם רוצים להוסיף שירותים ספציפיים עם מחירים:

"makesOffer": [
  {
    "@type": "Offer",
    "name": "ייעוץ ראשוני",
    "price": "0",
    "priceCurrency": "ILS"
  },
  {
    "@type": "Offer",
    "name": "הסכם ממון",
    "price": "3500",
    "priceCurrency": "ILS"
  }
]

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

🌐 שילוב עם @graph, ‏Person + BreadcrumbList + FAQPage באותו script

עד כה הצגתי schemas פשוטים, entity יחיד בכל script. בפועל, עמוד עסק טיפוסי צריך 4-7 entities שונים, וכולם משולבים ב-@graph אחד. זה הפתרון המודרני שגוגל מעדיף. רוב המקדמים עדיין מטמיעים כל schema ב-script נפרד, וזה עובד טכנית, אבל גוגל לא רואה את הקשרים בין הישויות. כשמדובר ב-LocalBusiness עם Person בעלים, ‏BreadcrumbList, ‏FAQPage, ‏ולפעמים גם reviews, החיבור ביניהם דרך @id הוא הדבר שמעצים את ה-Knowledge Graph של גוגל לגביכם.

מה זה @graph

במקום לרשום 5 scripts נפרדים בעמוד, אנחנו רושמים script אחד עם array של entities תחת property בשם @graph. כל entity מקבל @id ייחודי, ויכול להצביע על אחר דרך {"@id": "..."}. זה יוצר graph של ישויות מקושרות.

דוגמת קוד מלאה לקליניקת רופא, ‏עם Person, BreadcrumbList, ו-FAQPage

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Dentist",
      "@id": "https://clinic-cohen-jlm.co.il/#dentist",
      "name": "קליניקת שיניים ד\"ר כהן",
      "telephone": "+972-2-6234567",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "רחוב הרצל 89, קומה 3",
        "addressLocality": "ירושלים",
        "addressRegion": "ירושלים",
        "postalCode": "9418901",
        "addressCountry": "IL"
      },
      "employee": {"@id": "https://clinic-cohen-jlm.co.il/#dr-cohen"}
    },
    {
      "@type": "Person",
      "@id": "https://clinic-cohen-jlm.co.il/#dr-cohen",
      "name": "ד\"ר ישראל כהן",
      "jobTitle": "רופא שיניים",
      "alumniOf": "האוניברסיטה העברית בירושלים",
      "worksFor": {"@id": "https://clinic-cohen-jlm.co.il/#dentist"}
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://clinic-cohen-jlm.co.il/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "דף הבית",
          "item": "https://clinic-cohen-jlm.co.il/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "השירותים שלנו",
          "item": "https://clinic-cohen-jlm.co.il/services/"
        }
      ]
    },
    {
      "@type": "FAQPage",
      "@id": "https://clinic-cohen-jlm.co.il/#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "האם הקליניקה עובדת עם קופות חולים?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "כן, הקליניקה מסונפת לכלל הקופות בהסדר ישיר"
          }
        }
      ]
    }
  ]
}
</script>

הקסם של @id

שימו לב ל-employee ב-Dentist שמצביע ל-Person, ול-worksFor ב-Person שמצביע חזרה ל-Dentist. שתי ה-references דו-כיווניות יוצרות graph מקושר. גוגל יכול עכשיו לזהות את ד"ר כהן כאדם שעובד בקליניקה, ולקשר את שניהם ב-Knowledge Graph שלו. ‏זה signal חזק ל-E-E-A-T.

קישור לפרקים אחרים

ל-BreadcrumbList schema מדריך משלו, ול-FAQ schema פרק מיוחד גם כן. ב-LocalBusiness, רוב הזמן תרצו לשלב את 3 ה-entities הללו לפחות.

⭐ reviews ו-aggregateRating, ‏מה גוגל מציגה ומה לא

aggregateRating ו-review הם properties שמופיעים ב-rich results כ-כוכבים זהובים, וזה הדבר הכי משפיע על CTR. עסק עם 4.7★ ב-Local Pack מקבל 30% יותר קליקים מעסק בלי כוכבים, אומרים מחקרים. אבל יש לזה כללים מחמירים, וגוגל מענישה על fake reviews. בעבר היו עסקים שהוסיפו aggregateRating מפוברק כדי לקבל כוכבים, וגוגל פתח manual action שגרר מחיקה מהאינדקס. ‏היום זה אסור באכיפה חזקה, ‏תהיו זהירים.

הכללים של גוגל

• aggregateRating חייב להיות מבוסס על reviews אמיתיים ומאומתים, לא ערכים מומצאים
• ה-reviews צריכים להיות גלויים באתר במקום שגוגל יכול לקרוא
• אל תוסיפו aggregateRating בעמוד עסק שלם רק כי "רוב הלקוחות אוהבים". זה false advertising
• חייבים ratingCount או reviewCount. גוגל לא יציג את הכוכבים בלי לדעת כמה reviews יש
• הסולם bestRating ו-worstRating חייב להיות עקבי (לרוב 1-5)

דוגמת קוד

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.7",
  "reviewCount": "127",
  "bestRating": "5",
  "worstRating": "1"
},
"review": [
  {
    "@type": "Review",
    "author": {
      "@type": "Person",
      "name": "דנה לוי"
    },
    "datePublished": "2026-04-15",
    "reviewBody": "שירות מקצועי, צוות אדיב. ‏ממליצה בחום",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5",
      "bestRating": "5",
      "worstRating": "1"
    }
  }
]

מה גוגל מציגה ומה לא

גוגל מציגה את הכוכבים ב-Local Pack וב-rich results רק אם:

1. ה-reviews גלויים באתר

   צריך שגוגל יוכל לראות את ה-reviews בעמוד (לא רק ב-schema). אחרת היא מתעלמת.

2. יש מספר מינימלי

   סף לא רשמי הוא 5 reviews. פחות מזה, גוגל לרוב לא תציג.

3. ה-reviews לא נראים מפוברקים

   אם כולם 5 כוכבים מתאריכים סמוכים, גוגל יחשוד. עדיף mix טבעי עם רוב 4-5 וכמה 3-4.

4. הכוכבים מציעים בשל הקטגוריה

   גוגל לא מציגה כוכבים ל-organization כללי, רק ל-LocalBusiness ול-Product. עוד סיבה להשתמש ב-subtype הנכון.

קישור פנימי

למדריך מלא על reviews schema, ראו את aggregate rating ו-reviews schema. שם נצלול לעומק לכללי גוגל ולעבירות הנפוצות. בקיצור, רק reviews אמיתיים, גלויים באתר, בכמות מינימלית של 5+, ועם mix טבעי של ציונים. כל זיוף = סיכון אמיתי של מחיקה מהאינדקס.

🏬 Multi-location, ‏איך לטפל בעסק עם 5 סניפים

עסק עם כמה סניפים מבלבל הרבה מקדמים. האם schema אחד לכל הסניפים? schema נפרד לכל אחד? משולב? התשובה תלויה במבנה האתר. תקשיבו, אני אקח עמדה ברורה, multi-location דורש מבנה אתר עם עמוד נפרד לכל סניף, ו-schema נפרד לכל אחד. כל קיצור דרך אחר פוגע ב-Local Pack. נקודה.

תרחיש 1, אתר עם עמוד נפרד לכל סניף

זה המודל המומלץ. כל סניף מקבל URL ייעודי (לדוגמה /sniff/tlv, /sniff/jlm, /sniff/haifa), וכל עמוד מקבל schema של LocalBusiness עם נתוני הסניף הספציפי. אין conflict, אין confusion, וגוגל יכול לדרג כל סניף בנפרד באזור הגיאוגרפי שלו.

<!-- ב-/sniff/tlv/ -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.co.il/sniff/tlv/#restaurant",
  "name": "מסעדה X, סניף תל אביב",
  "branchOf": {"@id": "https://example.co.il/#parent-org"},
  "address": {...},
  "geo": {...},
  "telephone": "+972-3-..."
}
</script>

תרחיש 2, אתר עם עמוד אחד שמרכז את כל הסניפים

פחות מומלץ אבל קיים. דף אחד עם רשימת כל הסניפים. במקרה הזה, השתמשו ב-ItemList שמכיל מספר LocalBusiness entities:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "Restaurant",
      "name": "מסעדה X, סניף תל אביב",
      "address": {...}
    },
    {
      "@type": "Restaurant",
      "name": "מסעדה X, סניף ירושלים",
      "address": {...}
    }
  ]
}
</script>

הוספת Organization כ-parent

אם יש לכם מותג רב-סניפים, כדאי להוסיף Organization נפרד שמייצג את הברנד עצמו (לא סניף ספציפי), ולקשר כל LocalBusiness אליו דרך branchOf:

{
  "@type": "Organization",
  "@id": "https://example.co.il/#parent-org",
  "name": "מסעדות X",
  "url": "https://example.co.il/"
},
{
  "@type": "Restaurant",
  "branchOf": {"@id": "https://example.co.il/#parent-org"},
  ...
}

מה לגבי Google Business Profile

בכל GBP יש עמוד נפרד לכל סניף. ב-schema שלכם, ה-hasMap של כל סניף צריך להצביע על ה-cid של הסניף הספציפי. וודאו עקביות מלאה בין ה-cid של GBP, ה-schema של עמוד הסניף, ו-NAP citations של אותו סניף בספריות. המדריך המלא ל-GBP מסביר. אגב, ב-multi-location השם של כל סניף ב-schema חייב להיות זהה לשם של אותו סניף ב-GBP. אם ב-GBP יש לכם "מסעדה X, סניף תל אביב", ב-schema צריך להיות בדיוק "מסעדה X, סניף תל אביב", לא רק "מסעדה X" או "סניף תל אביב".

🚫 הטעויות הנפוצות (subtype לא ספציפי, פורמט שעות שגוי, geo לא מתאים)

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

טעות 1, שימוש ב-LocalBusiness כללי במקום subtype

זה השכיח ביותר. מקדם מוסיף @type: LocalBusiness לעמוד מסעדה במקום Restaurant. גוגל מקבל, אבל מפסיד את rich results הספציפיים למסעדות (servesCuisine, menu, acceptsReservations). תמיד לעומק.

טעות 2, telephone בפורמט מקומי

"03-5551234" או "0501234567" לא תקינים. גוגל רוצה פורמט בינלאומי E.164. "+972-3-5551234" או "+972-50-1234567". זה ההבדל בין rich results לבין כלום.

טעות 3, openingHours כמחרוזת אחת ברשימה לא מסודרת

"א'-ה' 9-18, שישי 9-14, שבת סגור" כמחרוזת אחת. גוגל לא יודע לפענח. השתמשו ב-OpeningHoursSpecification array (פרק 5).

טעות 4, geo coordinates של ה-CRM/שרת ולא של העסק

אם אתם משלבים schema אוטומטית ב-CMS, וודאו ש-latitude/longitude הם של העסק האמיתי. ראיתי אתרים שמוסיפים את הקואורדינטות של ה-data center של החברה ב-AWS. גוגל מתעלם מ-schema שלא עקבי עם הכתובת.

טעות 5, address כמחרוזת במקום PostalAddress object

"address": "דיזנגוף 142, תל אביב" לא תקין. חייב להיות object מובנה עם streetAddress, addressLocality, וכו'. גוגל מתעלם מ-string address.

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

• שכחה של addressCountry = "IL"
• שימוש ב-"Israel" במקום "IL"
• postalCode בן 5 ספרות במקום 7 (לפני 2013)
• currenciesAccepted בעברית ("שקל") במקום ISO code ("ILS")
• paymentAccepted לא תקין ("מזומן" במקום "Cash")
• כתיבת dayOfWeek בעברית ("ראשון") במקום באנגלית
• שעות בפורמט 12h עם AM/PM (גוגל לא קולט)
• שכפול שגוי של @id (חייב להיות ייחודי בכל ה-graph)
• canonical loop ב-employee/worksFor (Person A worksFor Org B, Org B employee Person C, וכו')
• aggregateRating בלי reviewCount

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

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

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

1. בחירת subtype

   פתחו schema.org/LocalBusiness, מצאו את ה-subtype הספציפי ביותר לעסק שלכם.

2. אימות עם GBP

   וודאו שהשם, הכתובת, הטלפון, ושעות הפעילות זהים ל-Google Business Profile של העסק.

3. בניית PostalAddress

   פירוק הכתובת ל-streetAddress, addressLocality, addressRegion, postalCode, addressCountry=IL. בדיקה ב-Maps.

4. חילוץ geo coordinates

   קליק ימני ב-Maps על הסיכה, העתקת latitude/longitude. 6 ספרות אחרי הנקודה.

5. בניית OpeningHoursSpecification

   array של blocks לכל קבוצת ימים עם שעות זהות. שישי וושבת בנפרד אם רלוונטי.

6. הוספת properties recommended

   image (3+ images), priceRange, paymentAccepted, currenciesAccepted, hasMap עם cid.

7. שילוב @graph

   הוספת Person (לעסק שמסונן עם דמות בולטת), BreadcrumbList, FAQPage, כולם מקושרים ב-@graph.

8. הזרקה לעמוד

   שמירת ה-script בתוך <head> של עמוד הבית, או בעמוד הסניף הספציפי ב-multi-location. אם משתמשים ב-WP, דרך תוסף SEO (Yoast/RankMath).

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

   הריצו את ה-URL בכלי הוואלידציה של גוגל. וודאו 0 errors. תיקנו warnings.

10. בקשת re-crawl ב-Search Console

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

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

• בדיקת ה-schema ב-Rich Results Test, עדיין eligible?
• השוואה עם GBP, כתובת/טלפון/שעות עדיין זהים?
• אם יש aggregateRating, ‏reviewCount עדכני? הוספת reviews חדשים?
• איסוף נתוני ה-Local Pack ב-Search Console, נשארנו או עלינו?
• אימות openingHoursSpecification בעקבות שינויי שעות לחגים
• בדיקה שאין warnings חדשים ב-Coverage report
• קישור פנימי לעמוד הסניף קיים בעמוד הבית ובעמודים רלוונטיים
• בדיקת NAP citations חיצוניות (B144, Walla Yellow, וכו') שכולם זהים
• אם הוספתם שירות חדש לעסק, ‏הוספת availableService matching ב-schema
• אחת לרבעון, ‏בדיקה אם schema.org פירסם properties חדשים לסוג הזה

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