Reviews Schema לעסקים מקומיים, Review + AggregateRating המדריך השלם

⭐ Review מול AggregateRating, ההבדל שכל מקדם חייב להפנים

תקשיבו. ‏אני אפתח עם השיחה הכי שכיחה שיש לי בשטח. בעל עסק מתקשר אליי, "שמוליק, יש לי 47 ביקורות ב-Google Business Profile, איך אני מקבל כוכבים זהובים ב-SERP?". אני שואל, "אתה רוצה Review או AggregateRating?". הוא נדהם, "מה זה משנה, אני סתם רוצה את הכוכבים". וזה בדיוק הרגע שאני עוצר ומסביר את ההבדל, כי בלי להבין את שני המנגנונים, הוא יבנה schema לא נכון ויפסיד את הכוכבים בעצמו.

Review הוא schema של ביקורת בודדת, אדם אחד שכתב טקסט אחד עם ציון אחד על העסק שלכם. הוא מייצג entity של ביקורת אחת ספציפית, עם author, datePublished, reviewBody, ו-reviewRating. שימוש לדוגמה, אם יש לכם עמוד ביקורות באתר ואתם רוצים שכל ביקורת תופיע כ-structured data נפרדת. גוגל יודע לקלוט את הביקורת הזאת ולהציג אותה במקרים מסוימים ב-rich results.

AggregateRating הוא schema של סיכום, ציון ממוצע אחד שמייצג את כל הביקורות יחד. הוא לא מייצג ביקורת ספציפית, אלא את הציון המצרפי. דוגמה, "4.7 כוכבים מתוך 5, על בסיס 127 ביקורות". זה מה שמופיע ככוכבים זהובים ב-SERP וב-Local Pack. רוב בעלי העסקים רוצים את זה, אבל לא מבינים שזה דורש מקור אמין לציון, לא סתם מספר שאתם רושמים.

מתי להשתמש בכל אחד

• Review בלבד, כשיש לכם ביקורת אחת או כמה שאתם רוצים להציג כ-entities נפרדות (למשל בעמוד "ביקורות" באתר). גוגל יציג Review בודד ב-rich results רק במצבים מסוימים, רוב הזמן הוא יישמר ב-Knowledge Graph.
• AggregateRating בלבד, כשיש לכם הרבה ביקורות (5+) ואתם רוצים את הציון הממוצע עם כוכבים זהובים ב-SERP. דורש שהביקורות יהיו גלויות באתר ושייאספו ב-first-party.
• שניהם יחד, השיטה המומלצת. AggregateRating לציון הכללי, ומערך של Review entities לפרטי הביקורות הבודדות. גוגל מקבל את שני הסיגנלים, רואה consistency, ומגיב הכי טוב.

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

15 פרקים שמתחילים מה-distinction הזה, עוברים לכללים המחמירים של גוגל (פרק 2-3), נכנסים לעומק של ה-properties (פרק 4-5), מציגים שילוב נכון עם LocalBusiness ועם subtypes (פרק 6), ועוברים לדוגמאות קוד JSON-LD מלאות לעסקים ישראליים אמיתיים (פרק 7-9). אחר כך נכסה את היחס בין reviews ב-GBP לבין schema באתר (פרק 10), workflow איסוף (פרק 11), AI engines (פרק 12), הקונטקסט הישראלי (פרק 13), והטעויות הקלאסיות + audit חודשי (פרק 14-15).

אגב, השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO. אני אישית טיפלתי באתרים שאיבדו את כל ה-rich snippets שלהם בגלל schema לא תקין של reviews, וגם באתרים שעלו דרמטית ב-CTR אחרי שהטמיעו את זה כמו שצריך. ההבדל הוא לא טכני, הוא תהליכי. אם אחרי המאמר אתם תקועים, יש לכם איך לדבר איתי ישירות.

🔒 הקריטריון הקריטי של גוגל, FIRST-PARTY בלבד

אם תזכרו רק דבר אחד מהמאמר הזה, שזה יהיה. גוגל מקבל aggregateRating רק מ-first-party data, כלומר רק מביקורות שנאספו ישירות על ידי העסק, מוצגות על האתר של העסק, ולא נמשכו מצד שלישי. זאת מדיניות מפורשת מ-2019, וגוגל אוכף אותה באגרסיביות.

מה זה first-party

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

מה זה third-party (ואסור להציג)

• ביקורות מ-Google Business Profile, אתם לא יכולים להעתיק את הציון של GBP ל-schema באתר שלכם. גוגל יודע איפה הביקורת הוקלדה, ויודע אם אתם משכפלים נתוני third-party.
• ביקורות מ-Yelp, TripAdvisor, Facebook, אותו דבר. אסור לקחת מהם ולהציג כ-aggregateRating על האתר שלכם.
• ביקורות מ-Trustpilot, Tripadvisor, Booking, גם הם third-party. ‏הם יכולים להציג ביקורות באתר שלהם, אבל אתם לא יכולים להציג את הציון שלהם כ-schema שלכם.
• widgets שמושכים reviews מ-GBP, אם אתם משתמשים ב-widget שמושך את הביקורות מ-GBP ומציג אותן באתר, זה עדיין third-party. הביקורת נכתבה ב-GBP, רק מוצגת אצלכם.

מה זה אומר בפועל

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

וכן, GBP זה מצוין אבל בנפרד

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

ראיתי לקוחות שאיבדו 60% מהקליקים אחרי שגוגל הסירה להם את ה-rich snippet בגלל הפרת המדיניות הזאת. זה לא משחק, זה הלכה למעשה. אם תרצו לקרוא יותר על הקשר עם Google Business Profile, יש פרק שלם על זה. גם NAP consistency רלוונטי כאן, כי הביקורות הן עוד ערוץ של אות consistency.

💥 ה-crackdown של 2019, מתי גוגל אמרה "מספיק" ל-fake reviews

בספטמבר 2019, גוגל פרסמה עדכון מדיניות ל-rich results של reviews. עד אז, היה אפשר להציג aggregateRating כמעט בכל סוג של schema, כולל Organization וטיפוסים שאינם LocalBusiness. אתרים השתמשו בזה אגרסיבית, רובם בלי לקפיד על אמיתות, ובכך "ניפחו" את עצמם בכוכבים שלא הגיעו להם.

מה בדיוק השתנה ב-2019

• צמצום הטיפוסים שמותר להם להציג aggregateRating, רק LocalBusiness (וכל ה-subtypes), Product, Recipe, Book, Course, Event, Game, MediaObject, Movie, MusicPlaylist, MusicRecording, Organization (במגבלות), SoftwareApplication. כל השאר, אסור.
• self-serving reviews אסורים, ביקורות שמוצגות על העמוד של העסק עצמו, שנאספו על ידי העסק עצמו, אסורות במצב הזה.
• חובת first-party, הביקורות חייבות להיאסף ולהיות מוצגות ישירות על האתר, לא נמשכות מ-third-party.
• חובת visibility, הביקורות חייבות להיות גלויות לגולשים על העמוד, לא מוסתרות או רק ב-schema.

מה זה אומר על self-serving reviews

הנקודה הזאת מבלבלת. "self-serving" משמע ביקורת שנאספה על ידי העסק עצמו על העסק עצמו, ומוצגת בעמוד של העסק עצמו. גוגל מגדירה את זה כ-"unhelpful" כי יש בו אינטרס מובנה לבעל העסק להציג רק ביקורות חיוביות.

הרקע, למה גוגל הגיעה למסקנה הזאת

בשנים שלפני 2019, אינטרנט היה מוצף ב-fake reviews. אתרים פברקו ביקורות, או הזמינו אותן בכמויות מ-fiver וכאלה. גוגל ראתה שמשתמשים מאבדים אמון ב-rich snippets, וכל המערכת איבדה שווי. הם החליטו לסגור את הצ'יט בצורה דרסטית, ועכשיו רק עסקים שבאמת אוספים ביקורות ממשיים מקבלים את הכוכבים.

איך הם תופסים אתכם

גוגל יש לה כמה שכבות של זיהוי. ה-algorithm סורק את העמוד ובודק consistency בין ה-schema לבין מה שמופיע בפועל. אם schema אומר "reviewCount: 245" אבל בעמוד יש רק 3 ביקורות גלויות, זה red flag. אם reviewer names נראים מפוברקים ("John 1", "John 2", "User1"), זה red flag. אם כל הביקורות מתאריך אחד, זה red flag. גוגל לא מסביר בדיוק איך, אבל מי שמנסה לרמות, גוגל מוצא אותו.

מה התוצאות של הפרה

1. הסרת rich snippets

   הכוכבים נעלמים מ-SERP. ה-schema נשאר, אבל גוגל מתעלם ממנו לצורך rich results.

2. הזהרה ב-Search Console

   אם זה נורא, תקבלו manual action. בדרך כלל זה רק "silent removal".

3. השפעה רחבה

   במקרים חמורים, פגיעה בכל ה-organic visibility של האתר, לא רק ב-reviews.

בקיצור, ב-2019 הצ'יט נסגר. עכשיו צריך לעבוד אמיתית, לאסוף ביקורות אמיתיות, להציג אותן בגלוי, ולקבל את הכוכבים בצורה הגונה. אם אתם רוצים לעצב מערכת איסוף נכונה, פרק 11 מכסה את ה-workflow השלם.

✅ Required properties של Review, מה חובה ומה מומלץ (עם דוגמת קוד)

אם אתם מטמיעים Review schema, יש 4 properties שחייבים להיות בפנים. בלעדיהם, גוגל פוסל את הסכמה לחלוטין. עוד 2-3 properties מומלצים מאוד אבל לא חובה. בואו נעבור עליהם.

ה-4 ה-required

• author, מי כתב את הביקורת. חייב להיות Person או Organization, לא מחרוזת. דוגמה, "author": {"@type": "Person", "name": "דנה לוי"}.
• datePublished, מתי הביקורת פורסמה. פורמט ISO 8601, לדוגמה "2026-04-15". בלי השדה הזה גוגל מתעלם מה-Review.
• reviewRating, ציון הביקורת. אובייקט של Rating עם ratingValue, bestRating, worstRating. נצלול בפרק הבא.
• itemReviewed, על מה הביקורת. חייב להיות Schema entity, כמו LocalBusiness, Restaurant, Product, או כל subtype. הכי חשוב בעיני גוגל, כי בלעדיו אין הקשר.

ה-properties המומלצים

• reviewBody, טקסט הביקורת. לא חובה טכנית, אבל בלעדיו הסכמה לא משמעותית. ‏גוגל לפעמים מציג חלק מהטקסט ב-rich snippet.
• publisher, מי פרסם את הביקורת באתר. בדרך כלל זה אתם (Organization), עוזר לגוגל להבין שזה first-party.
• name, כותרת לביקורת. אם הביקורת ארוכה ויש לה headline, שווה לכלול.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "Restaurant",
    "name": "מסעדת הים",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "דיזנגוף 142",
      "addressLocality": "תל אביב",
      "addressCountry": "IL"
    }
  },
  "author": {
    "@type": "Person",
    "name": "דנה לוי"
  },
  "datePublished": "2026-04-15",
  "reviewBody": "אוכל מעולה, השירות אדיב. הזמנו את הסלמון הצרוב והוא היה מושלם",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "5",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

וה-AggregateRating, מה חובה שם

ל-AggregateRating הכללים שונים. החובה היא, ratingValue (הציון הממוצע), ו-אחד מהשניים, ratingCount (כמה ביקורות בסך הכל) או reviewCount (כמה ביקורות עם טקסט). מומלץ לכלול גם bestRating ו-worstRating כדי להיות מפורש.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "מסעדת הים",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "127",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

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

itemReviewed הוא הקישור בין הביקורת לבין הישות שעליה היא נכתבה. בלעדיו, גוגל לא יודע על מה הביקורת. בעבר היה אפשר להעמיד Review בלי itemReviewed (גוגל היה מסיק מההקשר), אבל היום זה דרישה מפורשת.

אל תעמידו את itemReviewed כ-string או כ-URL. הוא חייב להיות אובייקט schema מלא (לפחות @type ו-name). אחרת גוגל מתעלם. עוד דוגמאות יותר מורכבות בפרקים 7-9.

⭐ reviewRating, ה-Rating type בעומק (ratingValue, bestRating, worstRating)

ה-reviewRating הוא ה-property שמייצג את הציון של הביקורת. נראה פשוט, אבל יש בו הרבה דקויות שגוגל מקפיד עליהן. ‏בלי הבנת ה-Rating type, אתם תהיו עם ביקורות ש"אמורות לעבוד" אבל לא יוצגו.

המבנה הבסיסי

"reviewRating": {
  "@type": "Rating",
  "ratingValue": "5",
  "bestRating": "5",
  "worstRating": "1"
}

השדות בפירוט

• ratingValue, הציון של הביקורת. מספר או מחרוזת של מספר. דוגמה, "5" או "4.5" או 5 (כמספר). יכול להיות עשרוני.
• bestRating, הציון המקסימלי האפשרי בסולם שלכם. אם אתם משתמשים בסולם 1-5, זה "5". אם בסולם 1-10, זה "10". אם בסולם 1-100, זה "100".
• worstRating, הציון המינימלי האפשרי. בדרך כלל "1", אבל לפעמים "0".

למה bestRating ו-worstRating חשובים

גוגל לא יודע אוטומטית באיזה סולם אתם משתמשים. אם תרשמו ratingValue: 4 בלי bestRating, גוגל יניח 5 כברירת מחדל. אבל אם הסולם שלכם 1-10, הציון 4 הוא בעצם נמוך, וגוגל יציג אותו לא נכון.

סולם לא סטנדרטי

"reviewRating": {
  "@type": "Rating",
  "ratingValue": "8",
  "bestRating": "10",
  "worstRating": "1"
}

כאן הסולם הוא 1-10, והציון 8 משקף 80% מהמקסימום. גוגל יציג זאת בהתאם (4 כוכבים מתוך 5 בייצוג ויזואלי, כי 80% = 4/5).

מספרים עשרוניים

גוגל מקבל מספרים עשרוניים. ratingValue: "4.7" או ratingValue: 4.7 שניהם תקפים. אל תעגלו ל-5, השאירו את הדיוק. גוגל מציג כוכבים חצויים אם צריך.

הטעות הנפוצה, ratingValue גבוה מ-bestRating

// ‏זה לא תקין
"reviewRating": {
  "@type": "Rating",
  "ratingValue": "6",
  "bestRating": "5"
}

גוגל פוסל. אם הציון 6 והמקסימום 5, הסכמה לא הגיונית. תקנו אחד מהשניים.

מה הכי משכנע ב-SERP

1. סולם 1-5

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

2. ציון 4.5-4.9

   הטווח שמעורר אמון. ציון 5.0 נראה חשוד ("כולם מושלם?"). ציון 4.2 נראה בינוני. הטווח 4.5-4.9 הוא הנקודה המתוקה.

3. הרבה ביקורות

   reviewCount: 127 משכנע יותר מ-reviewCount: 7. כמות = אמון. גם בלי לקרוא, גולשים רואים שהיו הרבה תגובות.

קשר ל-reviewedItem (inverse property)

ב-schema.org יש concept של inverse properties. כל property יש לו (לפעמים) inverse שמתקשר חזרה. reviewRating הוא ה-property של Review שמצביע על Rating. ה-inverse הוא reviewed ב-Rating שמצביע על Review. בפועל, גוגל לא דורש שתשתמשו ב-inverse, אבל זה signal חזק ל-knowledge graph.

בדוגמאות בפרקים 7-9, נראה איך לבנות structure נכון, כולל קישור בין Review לבין ה-LocalBusiness דרך itemReviewed.

🏪 שילוב עם LocalBusiness, איך AggregateRating נכנס פנימה (עם קוד)

עד עכשיו דיברנו על Review ועל AggregateRating כ-standalone. עכשיו נראה איך משלבים אותם בתוך LocalBusiness או באחד מה-subtypes שלו. זה ההטמעה הנפוצה והחשובה ביותר.

שני אופנים לשילוב

1. aggregateRating בתוך LocalBusiness

   הפשוט. שמים את ה-aggregateRating כ-property של ה-LocalBusiness. גוגל מבין שהציון הזה מתייחס לעסק.

2. review array בתוך LocalBusiness

   מערך של Review entities בתוך ה-LocalBusiness. כל review עם פרטיו, וה-itemReviewed לא נדרש (גוגל מסיק מהמיקום).

דוגמה מלאה, LocalBusiness + aggregateRating + reviews

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.co.il/#business",
  "name": "חנות האופניים של דני",
  "image": "https://example.co.il/images/store.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "אבן גבירול 78",
    "addressLocality": "תל אביב",
    "addressRegion": "תל אביב",
    "postalCode": "6420315",
    "addressCountry": "IL"
  },
  "telephone": "+972-3-5234567",
  "priceRange": "₪₪",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "89",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "רון כהן"
      },
      "datePublished": "2026-04-20",
      "reviewBody": "שירות מצוין, דני יודע בדיוק על מה מדובר. רכשתי אופני הרים והוא התאים אותי לדגם המדויק שאני צריך",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "מיכל לוי"
      },
      "datePublished": "2026-04-12",
      "reviewBody": "הגעתי לתיקון פנצ'ר. תוך 15 דקות הייתי בחוץ, מחיר הוגן. ממליצה",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

שימו לב למה שקורה כאן

• ה-LocalBusiness מכיל גם aggregateRating (הסיכום) וגם review (מערך של ביקורות בודדות).
• הביקורות הבודדות לא חייבות itemReviewed, כי הן בתוך הקונטקסט של ה-LocalBusiness.
• ה-aggregateRating צריך להתאים לציון הממוצע של הביקורות. אם הביקורות בעמוד הן בעיקר 5, ה-ratingValue צריך להיות גבוה (4.5-5).
• reviewCount: 89 אומר שיש 89 ביקורות בסך הכל, גם אלה שלא מוצגות ב-schema. גוגל לא דורש שכל 89 יהיו בקוד, רק שיהיו גלויות באתר.

שילוב עם subtypes

בדיוק אותו pattern עובד עם Restaurant, Dentist, LegalService, ושאר ה-subtypes. הכל יורש מ-LocalBusiness, אז כל subtype יכול לקבל aggregateRating ו-review. נראה דוגמאות ספציפיות בפרקים הבאים.

שילוב עם @graph

במאמרים בעלי schema מורכב, רצוי להשתמש ב-@graph. במקרה הזה, מציגים את ה-LocalBusiness, ה-Review entities, וה-Person entities של ה-authors בנפרד, ומקשרים ביניהם דרך @id. מתעמקים בזה ב-המדריך ל-LocalBusiness Schema.

🍝 דוגמה מלאה, מסעדה בתל אביב עם 47 ביקורות

בואו נראה דוגמה מלאה ועמוקה למסעדה ישראלית טיפוסית. השילוב הזה כולל את כל ה-properties שגוגל אוהב, כולל aggregateRating, review array של 3 ביקורות לדוגמה, וכל ה-recommended properties של Restaurant.

<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/front.jpg",
    "https://pasta-roma-tlv.co.il/images/inside.jpg"
  ],
  "description": "מסעדה איטלקית בלב תל אביב, פסטה הכי טובה בעיר",
  "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"
    }
  ],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "47",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "דנה שטרן"
      },
      "datePublished": "2026-05-02",
      "reviewBody": "הגעתי עם החברה למסעדה ויצאנו מאוהבות. הקרבונרה הייתה הכי טובה שאכלתי בארץ. השירות אדיב והצוות זוכר אותנו בפעם הבאה",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "יוסי כהן"
      },
      "datePublished": "2026-04-28",
      "reviewBody": "אטמוספירה נעימה, יין טוב, מנת הראש ענקית. החצרון של המסעדה מקסים בערב",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "מיכל זילברמן"
      },
      "datePublished": "2026-04-19",
      "reviewBody": "אוכל טעים אבל המקום קצת רועש בשעות שיא. אם אתם מחפשים שקט, להזמין מוקדם",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

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

• שלוש ביקורות עם ציונים מעורבים, שתי 5 ואחת 4. זה משקף mix טבעי. אם כולן היו 5, גוגל היה חושד.
• טקסטים אמיתיים ומפורטים, לא generic. הביקורת השלישית אפילו כוללת ביקורת קונסטרוקטיבית ("רועש בשעות שיא"). זה signal של אותנטיות.
• תאריכים מפוזרים, לא כולן באותו יום. גוגל בודק את זה.
• aggregateRating מתאים, 4.7 הוא ממוצע הגיוני של ביקורות 4-5.
• reviewCount: 47, אומר שיש 47 בסך הכל, רק 3 מוצגות ב-schema. גוגל יבדוק שיש 47 גלויות באתר (בעמוד או בעמוד "ביקורות" נפרד).

איפה להציג את הביקורות בעמוד

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

🦷 דוגמה מלאה, רופא שיניים בירושלים (YMYL, רגיש לרגולציה)

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

<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.jpg",
  "description": "קליניקה לרפואת שיניים כללית ושיקומית בירושלים",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "רחוב הרצל 89, קומה 3",
    "addressLocality": "ירושלים",
    "addressRegion": "ירושלים",
    "postalCode": "9418901",
    "addressCountry": "IL"
  },
  "telephone": "+972-2-6234567",
  "medicalSpecialty": "Dentistry",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "63",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "שרה אברהמי"
      },
      "datePublished": "2026-05-10",
      "reviewBody": "ד\"ר כהן הסביר לי בסבלנות את כל אפשרויות הטיפול. הסביר את העלויות מראש, בלי הפתעות. הצוות בקליניקה נחמד ומקצועי",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "רון בן עמי"
      },
      "datePublished": "2026-04-22",
      "reviewBody": "עברתי בקליניקה הזאת השתלת שיניים. התהליך לקח כמה חודשים, ד\"ר כהן ליווה אותי כל הדרך והתוצאה מצוינת",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "דליה גוטמן"
      },
      "datePublished": "2026-04-08",
      "reviewBody": "קיבלתי טיפול שורש. הכאב היה מינימלי, ההסבר היה ברור. ממתינה ארוכה לתור, אבל שווה את זה",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

מה מיוחד פה

• @type: Dentist, subtype ספציפי. לא MedicalBusiness כללי.
• medicalSpecialty: Dentistry, signal מקצועי לגוגל.
• description מאוזן, בלי "הטוב ביותר", בלי "מומחה מספר אחת", בלי הבטחות. תיאור עובדתי.
• reviews שמתארים תהליך טיפול, לא רק "שירות טוב". משקף ניסיון אמיתי של לקוחות.
• הביקורת ה-3, כוללת ביקורת קונסטרוקטיבית ("המתנה ארוכה לתור"). זה מותר ורצוי, מוסיף אמינות.
• אין השוואות לרופאים אחרים, לא "הכי טוב בירושלים", לא "יותר טוב מ-X". זה אסור ברגולציה.

איך לאסוף ביקורות במציאות רפואית

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

לקריאה רחבה על YMYL ועל איך לבנות תוכן רפואי כדי שגוגל יאמין בו, יש פרק שלם ב-המדריך השלם ל-SEO לרופאי שיניים.

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

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

<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",
    "addressLocality": "חיפה",
    "addressRegion": "חיפה",
    "postalCode": "3464124",
    "addressCountry": "IL"
  },
  "telephone": "+972-4-8123456",
  "email": "info@levi-law-haifa.co.il",
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "חיפה והקריות"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "34",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "אסתר ברקוביץ"
      },
      "datePublished": "2026-05-01",
      "reviewBody": "קיבלתי טיפול בהסכם ממון. עו\"ד לוי הסביר לי כל סעיף בסבלנות והתאים את ההסכם לצרכים האישיים שלי",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "דוד שמש"
      },
      "datePublished": "2026-04-15",
      "reviewBody": "ייעוץ ראשוני מעמיק. עו\"ד לוי לקח את הזמן להבין את המצב לפני שייעץ. שקיפות מלאה בעלויות",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

מה מיוחד פה

• @type: LegalService, subtype משפטי ייעודי.
• description בלי "מומחה", חוק לשכת עוה"ד אוסר על שימוש בתואר "מומחה" או "מתמחה" בשיווק. כתבנו "עוסק בדיני".
• הביקורות מתארות תהליך עבודה, לא "זכינו בכל המקרים". זה אסור.
• הביקורות מתארות איכות שירות, לא תוצאות בתיקים ספציפיים. גם זה אסור ברגולציה.
• areaServed, property חשוב לעו"ד שמשרת אזור רחב יותר ממיקום המשרד.

איך לאסוף ביקורות של עו"ד

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

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

🏢 GBP reviews מול site schema, איך הם משלימים זה את זה

אחת השאלות הנפוצות שאני מקבל. "שמוליק, יש לי 200 ביקורות ב-Google Business Profile, מה הקשר שלהן ל-schema באתר שלי?". התשובה היא, אין קשר ישיר. הן שני ערוצים נפרדים, וצריך להבין כל אחד בנפרד.

שני ערוצים, שני תפקידים

למה גוגל מפרידה ביניהם

גוגל רוצה למנוע מצב שבו ביקורות נספרות פעמיים. אם הציון שלכם ב-GBP הוא 4.7 בגלל 200 ביקורות שם, ואז אתם שמים את אותו ציון ב-schema באתר, גוגל יראה את אותה מציאות פעמיים. זה לא הוגן ולא מועיל למשתמש. ההפרדה הופכת את שני הערוצים למשלימים.

במה הם משלימים

• GBP Reviews עוזרות ל-Local Pack, כשמישהו מחפש "מסעדה בתל אביב", גוגל מציג את ה-Local Pack עם ציון GBP.
• Site Schema עוזר ל-organic SERP, כשמישהו מחפש "פסטה רומא תל אביב" (חיפוש ספציפי), גוגל מציג את האתר עם כוכבים זהובים אם יש לכם schema תקין.
• שניהם משפיעים על האמון, גולש שרואה ציון גבוה ב-GBP, ואז ציון גבוה גם באתר, מקבל אישור כפול.

תוכנות שמושכות מ-GBP, האם זה תקין

יש widgets כמו "Google Reviews Widget" שמושכים את הביקורות מ-GBP ומציגים אותן באתר. זה מותר לתצוגה, אבל אסור להמיר ל-schema. כלומר, אם אתם מציגים ביקורות מ-GBP ב-widget, הן יוצגו כ-HTML רגיל, בלי לעטוף ב-Review schema. גוגל יודע שזה third-party.

אם תרצו להמיר ב-schema, חייבים לאסוף את הביקורות בעצמכם, באמצעות טופס באתר או אימייל ישיר. זה first-party, וזה מותר.

חשוב לזכור על הקשר עם NAP

הביקורות הן עוד אות של consistency. אם השם, הכתובת, והטלפון שלכם ב-GBP זהים לאלה ב-schema באתר, גוגל מקבל אישור נוסף שזה אותו עסק. אם יש פערים, גוגל מתבלבל. למידע נוסף על זה, ראו NAP consistency מדריך ו-Google Business Profile.

🔄 Workflow איסוף ביקורות, מהבקשה ועד ה-schema

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

שלב 1, זיהוי טריגרים לבקשה

מתי לבקש ביקורת? אחרי שהלקוח קיבל את השירות, וכשהוא במצב חיובי. דוגמאות:

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

שלב 2, ערוץ הבקשה

אימייל אוטומטי הוא הסטנדרט. אבל יש גם SMS, WhatsApp, או טופס שמופיע באתר אחרי שלקוח גילש בעמוד "תודה". הכל תלוי בלקוח שלכם.

שלב 3, הטופס

הטופס באתר חייב להיות פשוט. שדות מומלצים:

• שם (חובה)
• אימייל (חובה, לאימות)
• ציון (סולם 1-5, חובה)
• טקסט ביקורת (חובה, אבל עם דוגמה כדי לעזור ללקוח)
• תמונה (אופציונלי)

שלב 4, מודרציה

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

שלב 5, פרסום באתר

הביקורת חייבת להיות גלויה באתר, לא רק ב-schema. סקציית "מה אומרים הלקוחות" בעמוד הבית או בעמוד שירותים, או עמוד ייעודי "ביקורות" שמרכז את כולן.

שלב 6, עדכון ה-schema

כאן יש שתי גישות:

1. Dynamic schema

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

2. Manual update

   אחת לחודש, מעדכנים את ה-schema ידנית עם ה-reviewCount החדש וה-ratingValue החדש. מתאים לאתרים קטנים בלי backend.

שלב 7, מעקב

אחת לחודש, בדקו ב-Search Console את ה-rich results. אם גוגל מציג את הכוכבים, ה-schema עובד. אם לא, יש בעיה. בדקו את ה-Rich Results Test לזיהוי מהיר.

שלב 8, תגובה לביקורות

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

הקצב המומלץ

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

ההבדל בין כמות לאיכות

100 ביקורות עם ציון ממוצע 4.7 שווה הרבה יותר מ-1000 ביקורות עם ציון ממוצע 3.5. כמות לבדה לא מספיקה. אם ה-quality יורד, עדיף לא להציג בכלל.

🤖 AI engines + Review schema, איך ChatGPT ו-Perplexity מציגים reviews

בעולם החיפוש החדש, AI engines (ChatGPT, Gemini, Perplexity, AI Overviews) משתמשים ב-Review schema במשקל אפילו גבוה יותר מגוגל המסורתי. הסיבה, AI engines רוצים נתונים מובנים שמהם הם יכולים לצטט, ו-reviews מובנים הם זהב לתשובות שלהם.

איך AI engine קוראים reviews

כשמישהו שואל את ChatGPT "איזה מסעדה איטלקית טובה בתל אביב", המנוע סורק אתרים שעולים בתוצאות גוגל לקוורי הזה. בכל אתר, הוא קורא את ה-structured data. עסק עם aggregateRating מלא + reviews מפורטות = יותר סיכוי להופיע בתשובה של ChatGPT.

היתרון של AI engines על SERP

• ב-SERP רגיל, כדי לקבל את הכוכבים, צריך לעמוד בכל הכללים המחמירים של גוגל. אם משהו לא תקין, אין כוכבים.
• ב-AI Overviews, גם אם גוגל לא מציג כוכבים, ה-AI עדיין קורא את הסכמה ויכול לצטט ממנה.
• ב-ChatGPT/Perplexity, אין דרישה למחירים ספציפיים. כל אתר עם schema תקין נחשב.

מה AI engine מציג

במקום כוכבים, AI engine מצטט. דוגמה לתשובה אופיינית:

"לפי האתר של פסטה רומא, המסעדה מקבלת 4.7 כוכבים מתוך 5 על בסיס 47 ביקורות. ביקורת אחת מ-2026-05-02 מציינת שהקרבונרה היא הטובה ביותר בארץ, וביקורת אחרת מ-2026-04-19 מציינת שהאטמוספירה רועשת בשעות שיא."

שימו לב, ה-AI לא רק נותן את הציון, הוא מצטט ביקורות ספציפיות. זה אומר שהאיכות והטקסט של כל review מתחילים לחשוב.

מה AI engine מתעלם ממנו

• Reviews בלי טקסט (רק ציון) - לא משמש לציטוט
• Reviews שכולן כמעט זהות בלשון - מזוהות כ-spam
• Reviews מלפני שנתיים+ - נחשבים פחות רלוונטיים
• Reviews שלא תואמות לציון - אם הציון 5 והטקסט שלילי, ה-AI מבולבל

קישור ל-llms.txt

גוגל ו-AI engines מעריכים את הסכמה כשהיא מלווה בקובץ llms.txt באתר (סטנדרט חדש שמתפתח). הקובץ מסביר ל-AI engines איזה content באתר אמין ומה ניתן לצטט. אם יש לכם reviews schema, שווה לציין את זה ב-llms.txt.

הקשר ל-E-E-A-T

Reviews הם signal עוצמתי של E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). הם מעידים על Experience אמיתי של לקוחות, ועוצמתם של כמותם מעידה על Trustworthiness של העסק.

למידע נוסף על איך לבנות תוכן ל-AI engines, ראו המדריך המלא ל-GEO.

🇮🇱 הקונטקסט הישראלי, B144, Bezeq, ומה לא ניתן להעביר

בישראל יש כמה ייחודיות שמשפיעות על איך לעבוד עם Review schema. הנה הדברים שצריך לדעת.

אתגר 1, Google Reviews בעברית עדיין מוגבל

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

אתגר 2, B144 reviews לא ניתן להעביר ל-schema

B144 הוא הספרייה העסקית של בזק, והוא מקבל ביקורות. אבל אם יש לכם 200 ביקורות ב-B144, אסור לכם להעתיק אותן ל-schema באתר שלכם. אותו כלל first-party חל כאן בדיוק כמו על GBP. ה-B144 הוא third-party, וביקורות שם שייכות ל-B144.

אתגר 3, ספריות עסקיות ישראליות נוספות

• Walla Yellow, ספרייה שמקבלת ביקורות. third-party.
• Easy, ספרייה לעסקים. third-party.
• Zap, ספרייה למוצרים. third-party.
• Trustpilot Israel, יותר אוניברסלי, מקבל reviews. third-party מבחינת אתר עצמאי, אבל יש להם widget שבא במצב first-party כי מטמיע ישירות באתר.

הכלל פשוט, כל ביקורת שלא נאספה ישירות על האתר שלכם, היא third-party ואסור להעתיק ל-schema.

אתגר 4, איסוף ביקורות בעברית

שפת העברית מקשה על איסוף ביקורות אוטומטיות. רוב מערכות ה-CRM לא תומכות בעברית RTL מלאה. כשאתם בוחרים tool, וודאו שהוא תומך בעברית, RTL, ושהביקורת נשמרת בצורה תקינה ב-DB.

אתגר 5, רגולציה מקצועית

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

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

הזדמנות, פחות תחרות

בגלל שרוב העסקים הישראליים עדיין לא מטמיעים Review schema תקין, אם אתם כן, אתם תהיו ב-10% המובילים. ראיתי לקוחות שעלו מקום אחד או שניים ב-SERP רק בגלל reviews schema. בעולם פחות מתחרה, זה advantage אמיתי.

למידע נוסף על שירותים מקומיים בישראל, ראו קידום אתרים לוקאלי ו-citations building בישראל.

🚫 10 הטעויות הקלאסיות (וכל אחת מסירה את הכוכבים)

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

טעות 1, ratingValue בלי count

הטעות הכי שכיחה. שמים ratingValue: 4.7 בלי reviewCount או ratingCount. גוגל פוסל מיד. תמיד תכללו את ה-count.

טעות 2, fake reviews שמומצאות

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

טעות 3, reviews שלא גלויות באתר

הסכמה אומרת "reviewCount: 100", אבל בעמוד יש רק 3 ביקורות גלויות. גוגל בודק, גוגל מסיר. תמיד גלוי = שיהיה ב-schema.

טעות 4, copy-paste מ-GBP

לקיחת הציון מ-GBP ושימוש בו ב-schema באתר. הפרת מדיניות מפורשת. אסור.

טעות 5, copy-paste מ-Trustpilot/Yelpאותה טעות, מקור אחר. third-party = אסור.

טעות 6, מבנה Review בלי itemReviewed

Review entity בלי itemReviewed = Review בלי הקשר. גוגל מתעלם.

טעות 7, ratingValue שלא תואם ל-bestRating

ratingValue: 6 עם bestRating: 5 = הסכמה לא הגיונית. גוגל פוסל.

טעות 8, datePublished בפורמט לא תקין

גוגל מצפה ל-ISO 8601 (2026-04-15). פורמטים אחרים ("15 באפריל 2026") לא יתפסו. תמיד פורמט מספרי.

טעות 9, author כמחרוזת במקום אובייקט

// לא תקין
"author": "דנה לוי"

// תקין
"author": {
  "@type": "Person",
  "name": "דנה לוי"
}

טעות 10, כל הביקורות 5 כוכבים

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

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

• שכחה של bestRating ו-worstRating (גוגל מניח 5 ו-1, אבל עדיף מפורש)
• reviewBody עם HTML טאגים (גוגל לא מקבל, רק plain text)
• הבאת @type Review בלי שהוא בתוך LocalBusiness או Product
• aggregateRating בתוך Organization כללי (לא נתמך)
• ביקורות לא מתורגמות (אם האתר עברית והביקורת באנגלית, זה אנומליה)
• סולם לא עקבי (חלק 1-5, חלק 1-10)
• חזרה על אותו author עם תאריכים שונים (חשוד)
• aggregateRating בתוך Article (לא תקין למאמרים, רק לעסקים ומוצרים)
• ביקורות שלא תואמות לשם הביקורת ("ביקרתי במסעדה" כשזה לא מסעדה)
• שימוש ב-RatingValue במקום ratingValue (case sensitive!)

איך לבדוק שהסכמה תקינה

הריצו את העמוד ב-Rich Results Test של גוגל (search.google.com/test/rich-results). אם הוא מציג "Eligible for review snippet", הסכמה בסדר. אם יש errors, תתקנו. אם יש רק warnings, עדיין שווה לתקן.

📅 Audit חודשי של reviews, ה-checklist המלא

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

שלב 1, validation טכני

• הריצו את העמוד הראשי ב-Rich Results Test. תקין?
• הריצו את עמודי השירותים העיקריים (3-5 מהם). תקינים?
• בדקו ב-Search Console את ה-Enhancements > Review snippets. יש שגיאות חדשות?
• בדקו ב-Coverage report אם יש דפים שהוסרו בגלל schema לא תקין

שלב 2, validation תוכני

• ה-reviewCount ב-schema תואם למספר הביקורות הגלויות בעמוד?
• ה-ratingValue הוא הממוצע הנכון של הציונים בעמוד?
• תאריכי הביקורות עדכניים? (לא ביקורות בלבד מלפני שנה+)
• שמות ה-authors מגוונים? (לא 5 "John" בשורה)
• הטקסטים מגוונים? (לא חזרות של אותה לשון)

שלב 3, validation מדיניות

• הסכמה לא כוללת ביקורות מ-GBP או third-party?
• אין הפרת רגולציה (במשפט, ברפואה)?
• הטקסט של כל ביקורת הוא original ו-authentic?
• יש mix טבעי של ציונים? (לא הכל 5)
• aggregateRating הוא בעסק או במוצר, לא ב-Article או Organization?

שלב 4, איסוף חודשי

• כמה ביקורות חדשות נאספו החודש?
• היו לקוחות שלא הגיבו על הבקשה? אולי לשלוח reminder?
• יש חודש שלם בלי ביקורות חדשות? אולי הזרם נעצר?
• הטופס באתר עובד? בדקו ידנית

שלב 5, תגובה לביקורות

• הגבתם לכל ביקורת חדשה החודש?
• הגבתם לביקורות שליליות במיוחד? (חשוב!)
• התגובות שלכם מקצועיות ולא הגנתיות?
• אם יש ביקורת שמפרה את התנאים שלכם (קללות, ספאם), פנו אליה ובקשו הסרה

שלב 6, מעקב KPIs

• CTR ב-Search Console עלה או ירד החודש?
• מיקום ממוצע ב-SERP לקוורי המותג שלכם?
• מספר ה-Impressions של דפים עם reviews schema?
• השוואה לחודש קודם, יש שיפור?

שלב 7, אופטימיזציה

• איזה reviewBody טקסטים מצוטטים על ידי AI? (חיפוש בגוגל/ChatGPT)
• איזה review טכניקות הביאו הכי הרבה לקוחות?
• האם כדאי לשנות את הטופס איסוף כדי לקבל reviews יותר מפורטות?
• האם כדאי להוסיף תמונות לביקורות (אם עוד לא)?
• האם כדאי להוסיף תרגום לעברית/אנגלית?

שלב 8, תוכנית לחודש הבא

• יעד לאיסוף, כמה reviews חדשות החודש הבא?
• שיפורים טכניים, יש בעיה ב-schema שצריך לתקן?
• שיפורים תוכניים, סקציית reviews בעמוד צריכה refresh?
• שיתופי פעולה, יש לקוחות פוטנציאליים שצריך לבקש מהם reviews?

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