נתונים מובנים לעורכי דין

נתונים מובנים לעורכי דין הם סימון בקוד של האתר, בדרך כלל בפורמט JSON־LD, שמתאר לגוגל את המשרד ואת העמודים שלו לפי אוצר המילים של schema.org. הם חלק קטן וטכני מקידום אתרים לעורכי דין, שנעשה פעם אחת כמו שצריך ואז מתוחזק. המדריך הזה עוסק בשאלות שמשרד צריך להחליט עליהן: איזה סוג לבחור, אילו שדות למלא ומה מותר לכתוב בהם לפי כללי הלשכה, איפה כל סימון יושב באתר, ואיך בודקים שהוא עובד.

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

מה נתונים מובנים עושים, ומה הם לא עושים

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

בעמוד המבוא שלה גוגל מביאה מקרי בוחן. Rotten Tomatoes מדדה שיעור הקלקה גבוה ב־25% בעמודים עם סימון, ו־Nestlé מדדה שיעור הקלקה גבוה ב־82% בעמודים שהופיעו כתוצאה מועשרת. אלה אתרי מדיה ומתכונים, שבהם יש תצוגות מועשרות בולטות כמו כוכבים, תמונות וזמני הכנה. למשרד עורכי דין רשימת התצוגות האפשריות קצרה בהרבה, כפי שמראה הטבלה בפרק הבא, ולכן המספרים האלה לא מתורגמים אליו.

שלושה משפטים מהתיעוד של גוגל קובעים את הציפיות:

• אין הבטחה. גוגל כותבת שהיא לא מבטיחה שהנתונים המובנים יופיעו בתוצאות, גם כשהסימון תקין לפי Rich Results Test. האלגוריתם מחליט לפי משתנים רבים, בהם היסטוריית החיפוש, המיקום וסוג המכשיר.
• העונש הוא על התצוגה. פעולה ידנית על נתונים מובנים מוציאה את העמוד מהזכאות לתוצאה מועשרת. לפי גוגל היא לא משפיעה על הדירוג של העמוד בחיפוש הרגיל.
• אין סימון מיוחד ל־AI. בעמוד על תכונות AI בחיפוש גוגל כותבת שאין צורך בנתונים מובנים מיוחדים של schema.org כדי להופיע ב־AI Overviews או במצב AI, ושהסימון הקיים צריך להתאים לטקסט הגלוי בעמוד.

מה נשאר אחרי כל ההסתייגויות? זיהוי. במאגר הנהלת בתי המשפט, לפי topdin, יש 42,062 עורכי דין עם כתובת משרד ידועה, ב־864 יישובים. זה ממוצע של כ־49 עורכי דין ליישוב (42,062 ÷ 864), ובערים הגדולות הרבה יותר, חלקם עם שמות משפחה דומים ותחומים זהים. סימון שאומר במפורש ״זה השם, זו הכתובת, זה הטלפון, זה הלוגו, ואלה הפרופילים ברשתות״ מקטין את הסיכוי שגוגל תחבר את הפרטים של המשרד למשרד אחר, או תציג שעות ישנות. זה לא מביא פניות בעצמו, אבל הוא מונע איבוד של פניות שכבר מגיעות.

מה גוגל מציגה היום ממה שמשרד יכול לסמן

בשלוש השנים האחרונות גוגל צמצמה כמה מהתצוגות המועשרות שמשרדים נהגו לסמן בשבילן. ספקים שמוכרים ״סכמה״ כשירות נפרד מסתמכים לפעמים על מצב שכבר לא קיים. הטבלה מסכמת את המצב לפי התיעוד ויומן השינויים של גוגל, כפי שנבדקו ב־25 באוקטובר 2026.

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

LegalService, Attorney או LocalBusiness, איזה סוג לבחור

ב־schema.org הסוגים בנויים כעץ. LegalService יושב מתחת ל־LocalBusiness, שיושב מתחת ל־Organization. ההגדרה שלו היא עסק שנותן שירותים, ייעוץ וייצוג משפטיים, למשל משרד עורכי דין. מתחתיו יש שני סוגים צרים יותר, Attorney ו־Notary.

הבחירה הזאת מבלבלת כי Attorney נשמע כמו הסוג הנכון. בעמוד של Attorney ב־schema.org כתוב שהסוג מיושן, ושהסוג LegalService כוללני יותר ופחות דו משמעי. אותו דבר כתוב על ProfessionalService, שהיה פעם הסוג הכללי לשירותים מקצועיים, וגם הוא מסומן כמיושן כי התבלבלו בינו לבין Service. לפי נתוני השימוש ש־schema.org מציג, מבוססי האינדקס של גוגל באוגוסט 2026, גם LegalService וגם Attorney נמצאים בטווח של 10,000 עד 100,000 דומיינים. כלומר, הרבה אתרים עדיין משתמשים בסוג הישן.

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

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

השדות שכדאי למלא, ומה כללי הלשכה אומרים עליהם

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

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

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

דוגמת JSON־LD למשרד עם סניף אחד

הקוד הבא הוא דוגמה למשרד בדוי. כל הפרטים בו, מהשם ועד הטלפון והקואורדינטות, הם דוגמה ולא משרד אמיתי. הוא מכניס את השדות מהטבלה לפי ההמלצות של גוגל לעסק מקומי. את הקוד שמים בתוך תג script מסוג application/ld+json בעמוד שהוא מתאר, בדרך כלל עמוד הבית או עמוד יצירת הקשר.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://www.example.com/#office",
  "name": "משרד לוי ושות׳",
  "alternateName": "Levi Law Office",
  "telephone": "+972-4-000-0000",
  "email": "[email protected]",
  "address": { "@type": "PostalAddress",
    "streetAddress": "רחוב הדוגמה 10, קומה 3",
    "addressLocality": "חיפה",
    "postalCode": "3100000",
    "addressCountry": "IL" },
  "geo": { "@type": "GeoCoordinates", "latitude": 32.81234, "longitude": 34.99876 },
  "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday"],
    "opens": "09:00:00", "closes": "18:00:00" }],
  "knowsAbout": ["דיני משפחה", "גירושין", "ירושות וצוואות"],
  "knowsLanguage": ["he", "en", "ru"],
  "areaServed": ["חיפה", "הקריות", "טירת כרמל"],
  "logo": "https://www.example.com/images/logo.png",
  "sameAs": ["https://www.facebook.com/example", "https://www.linkedin.com/company/example"],
  "url": "https://www.example.com/"
}

כמה דברים שכדאי לשים לב אליהם בקוד:

1. ‏@id. מזהה קבוע שמאפשר לסימונים אחרים באתר, כמו המאמרים, להפנות לאותו משרד בלי לחזור על כל הפרטים. גוגל ממליצה להשתמש ב־@id כשרוצים לקשר בין פריטים.
2. הטלפון. עם קידומת המדינה, כמו שגוגל מבקשת, ואותו מספר שמופיע בפרופיל העסק ובכותרת האתר.
3. השעות. בפורמט של שעות, דקות ושניות. אם המשרד סגור בשישי, פשוט לא כוללים אותו. שעות שונות לימים שונים נכתבות כמה אובייקטים במערך.
4. הקואורדינטות. חמש ספרות אחרי הנקודה, המינימום של גוגל. את המספרים לוקחים מנעץ במפות על הכניסה לבניין.
5. תחומים ושפות. השדות knowsAbout ו־knowsLanguage קיימים ב־schema.org, אבל לא מופיעים ברשימת השדות שגוגל תומכת בהם לעסק מקומי. הם לא יזיקו, ואנחנו לא מבטיחים שגוגל משתמשת בהם.
6. אין דירוג ואין מחיר. בכוונה, מהסיבות שבפרק הקודם.

עמוד הבית ומשרד עם כמה סניפים

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

{
  "@context": "https://schema.org",
  "@graph": [{ "@type": "WebSite",
    "@id": "https://www.example.com/#website",
    "name": "לוי ושות׳", "alternateName": ["Levi Law", "משרד לוי"],
    "url": "https://www.example.com/" },
  { "@type": "Organization",
    "@id": "https://www.example.com/#org",
    "name": "לוי ושות׳", "legalName": "לוי ושות׳, עורכי דין",
    "logo": "https://www.example.com/images/logo.png",
    "url": "https://www.example.com/" }]
}

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

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": "לוי ושות׳ תל אביב", "telephone": "+972-3-000-0000",
  "address": { "@type": "PostalAddress", "streetAddress": "רחוב הדוגמה 20",
    "addressLocality": "תל אביב", "postalCode": "6100000", "addressCountry": "IL" },
  "parentOrganization": { "@id": "https://www.example.com/#org" },
  "url": "https://www.example.com/סניפים/תל-אביב/"
}

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

מאמרים, פירורי לחם ושאלות נפוצות

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

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "מזונות ילדים אחרי גירושין, מה קובע את הסכום",
  "datePublished": "2026-09-01T09:00:00+03:00", "dateModified": "2026-10-20T12:00:00+03:00",
  "author": { "@type": "Person", "name": "שם עורך הדין",
    "url": "https://www.example.com/צוות/שם-עורך-הדין/" },
  "publisher": { "@id": "https://www.example.com/#org" },
  "image": "https://www.example.com/images/mezonot.jpg"
}

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

שאלות נפוצות. כאן השינוי הגדול. באוגוסט 2023 גוגל הודיעה שהתוצאות המועשרות של שאלות נפוצות יוצגו רק לאתרי ממשלה ובריאות מוכרים וסמכותיים. ב־8 במאי 2026 היא הוסיפה הודעה שהתכונה לא תופיע בחיפוש החל מ־7 במאי 2026, וב־15 ביוני 2026 הסירה את התיעוד שלה. משרדים שקנו ״סכמת שאלות נפוצות״ כדי לתפוס יותר מקום בעמוד התוצאות לא מקבלים יותר את התצוגה הזאת. ב־2023 גוגל כתבה שסימון שלא נעשה בו שימוש לא גורם בעיות בחיפוש, ולכן אין דחיפות להסיר אותו. ההחלטה מה לעשות איתו היא שאלה של תחזוקה, לא של דירוג.

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

איפה כל סימון יושב באתר של משרד

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

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

בדיקה ב־Rich Results Test, צעד אחר צעד

גוגל ממליצה להתחיל ב־Rich Results Test, כדי לראות אילו תוצאות מועשרות אפשר להפיק מהעמוד, ולהשתמש ב־Schema Markup Validator לבדיקה כללית של כל סימון schema.org, בלי ההנחיות הייחודיות לגוגל. ההבדל חשוב למשרד. Rich Results Test מציג רק סוגים שיש להם תכונה בגוגל, ולכן שדות כמו knowsAbout לא ייבדקו בו. זה הסדר שאנחנו עובדים בו:

1. בודקים את עמוד הבית לפי כתובת. מכניסים את הכתובת המלאה ב־Rich Results Test. הכלי ניגש לעמוד כמו גוגל, תחת השם Google-InspectionTool, ובודק כברירת מחדל כמו טלפון חכם. עמוד שחסום ב־robots.txt או מסומן ב־noindex לא ייבדק.
2. קוראים את השורה העליונה. הכלי מחזיר אחד מכמה מצבים, למשל פריטים תקינים, פריטים תקינים עם אזהרות, פריטים לא תקינים, או שגיאת תחביר. שגיאה קריטית מתקנים לפני כל דבר אחר. לפי ההנחיות הכלליות של גוגל, פריט שחסר בו שדה חובה לא זכאי לתוצאה מועשרת, וכל שדה מומלץ שמוסיפים משפר את איכות התוצאה.
3. סופרים כמה פעמים המשרד מופיע. אם הכלי מראה שני ארגונים או שני עסקים מקומיים באותו עמוד, יש כפילות, בדרך כלל מתוסף ומהתבנית.
4. מריצים את אותה כתובת ב־Schema Markup Validator. כאן רואים את כל השדות, כולל השפות והתחומים, ושגיאות בשמות של שדות.
5. בודקים עמוד סניף, עמוד תחום ומאמר אחד. סימון נוצר בדרך כלל מתבנית, ולכן עמוד אחד מכל סוג מייצג את כולם.
6. משווים לפרופיל העסק. שם, כתובת, טלפון ושעות, תו אחר תו. סימון תקין שאומר ״פתוח עד 19:00״ כשהפרופיל אומר 18:00 הוא סימון שגוי.
7. בודקים ב־Search Console אחרי הסריקה. בכלי בדיקת כתובות רואים איך גוגל רואה את העמוד, ובדוחות הנתונים המובנים, כולל הדוח על נתונים שלא ניתן לנתח, רואים שגיאות בכל האתר.

שתי הערות טכניות מהעזרה של הכלי. אפשר לבדוק גם קטע קוד, בלשונית Code, לפני שהוא עולה לאתר. ו־Rich Results Test מתעלם מהערות בתוך JSON־LD, אבל התקן לא מתיר אותן, ולכן מוחקים אותן לפני פרסום. עמוד שנמצא מאחורי סיסמה או על מחשב מקומי לא נגיש לכלי, ובודקים אותו כקטע קוד.

טעויות נפוצות בסימון של אתרי משרדים

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

• הסוג Attorney או ProfessionalService. שניהם מסומנים ב־schema.org כמיושנים. מחליפים ל־LegalService.
• מילות מפתח בשם. ״עורך דין גירושין בחיפה, משרד לוי״ בשדה name. השם בקוד הוא השם האמיתי של המשרד.
• פרטים שלא תואמים לפרופיל. טלפון ישן, שעות של לפני המעבר, כתובת של המשרד הקודם. בדרך כלל אחרי מעבר דירה או אתר, ולכן זה סעיף קבוע ברשימה של העברת אתר עורך דין.
• כוכבים מסומנים בקוד. aggregateRating על המשרד עצמו. גוגל לא תציג אותם, ושמות לקוחות בביקורות דורשים הסכמה בכתב לפי כלל 3(ט).
• מחיר בשדה priceRange. ערך כמו ״₪₪₪״ שמולא בהגדרות התוסף, שבהן יש שדה טווח מחירים. מוחקים.
• שלושה סניפים בעסק מקומי אחד. שלוש כתובות במערך בעמוד הבית במקום עסק מקומי לכל סניף בעמוד שלו.
• סימון כפול. התבנית מוציאה Organization, התוסף מוציא Organization נוסף עם שם אחר, ועוד תוסף מוסיף LocalBusiness. גוגל מקבלת שלושה תיאורים סותרים.
• סימון של תוכן שלא מופיע בעמוד. שאלות ותשובות בקוד שלא כתובות בעמוד, או שעות שלא מופיעות בשום מקום גלוי. גוגל אוסרת לסמן תוכן שלא גלוי לקוראים.
• קואורדינטות לא מדויקות. שתי ספרות אחרי הנקודה, שמצביעות על אמצע העיר. גוגל דורשת לפחות חמש.
• לוגו קטן או שקוף. לוגו לבן על רקע שקוף נראה כמו ריבוע ריק על הרקע הלבן של גוגל. המינימום הוא 112 על 112 פיקסלים.
• הערות בקוד. שורות הערה שנשארו מהמפתח בתוך ה־JSON־LD.

כמה זה עולה, ומה זה שווה

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

בתעריף לדוגמה של ₪250 לשעה למפתח, זה 6 × ₪250 = ₪1,500 פעם אחת. מה מקבלים מול זה? לא תוצאה מועשרת חדשה, כפי שראינו. הערך הוא בפניות שלא הולכות לאיבוד בגלל שעות שגויות, טלפון ישן או בלבול עם משרד אחר. כדי לתת לזה סדר גודל, בקטגוריה המשפטית במדד של BoostIt לפרסום בגוגל בישראל, העלות החציונית לפנייה ממודעה היא ₪108. אם הסימון המתוקן מונע אובדן של פנייה אחת בחודש, הוא שווה בערך ₪108 × 12 = ₪1,296 בשנה במונחי מחיר של מודעות. זו הערכה גסה שמניחה פנייה אחת, לא מדידה. אבל היא מראה שהעבודה מחזירה את עצמה בתוך כשנה וחודשיים, ושלא כדאי לשלם עליה כעל שירות חודשי.

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

תוספים, בוני אתרים ומה לשאול את מי שבנה את האתר

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

• Yoast SEO. לפי תיעוד המפתחים שלו, כל עמוד מוציא סימון של ארגון, אתר ועמוד, בגרף אחד שבו הפריטים מקושרים ב־@id. במאמרים נוסף Article, ובעמוד עם בלוק שאלות נפוצות נוסף FAQPage. התיעוד של התוסף הבסיסי לא מזכיר עסק מקומי.
• Rank Math. במדריך ה־Local SEO שלו אפשר לבחור סוג עסק מקומי לעמוד הבית ולעמודי אודות ויצירת קשר. התוסף כותב בעצמו שהסוג Attorney מיושן והוחלף ב־LegalService. ההגדרה הזאת לא מסומנת כחלק מהגרסה בתשלום, אבל ריבוי מיקומים כן.

כל תוסף כזה הוא נקודת התחלה, לא בדיקה. השאלות ששואלים את מי שבנה או מתחזק את האתר:

1. איזה סוג המשרד מסומן בו היום, ומאיפה הסימון מגיע, מהתבנית, מתוסף או מקוד ידני?
2. כמה תיאורים של המשרד יש בעמוד הבית, ואם יש יותר מאחד, למה?
3. האם לכל סניף יש עמוד עם סימון משלו?
4. האם מישהו מעדכן את השעות והטלפון בקוד כשהם משתנים בפרופיל העסק?
5. האם יש בקוד דירוג, ביקורות או מחיר?

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

נתונים מובנים, פרופיל העסק ותשובות AI

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

בתשובות של AI, גוגל אומרת במפורש שאין סימון מיוחד שצריך להוסיף, ושהסימון הקיים צריך להתאים לטקסט הגלוי. מה שכן משפיע הוא שהעמוד נגיש לסריקה, כתוב בטקסט ועונה על השאלה. ההסבר המלא נמצא במדריך על AI Overviews. ההחלטה אילו סורקי AI מורשים לקרוא את האתר בכלל היא קובץ אחר לגמרי, robots.txt, ומוסברת במדריך על בוטים של AI באתר. העבודה על הנוכחות בתשובות עצמן היא חלק מנראות בבינה מלאכותית למשרדים.

תוכנית ל־90 יום

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

ימים 1 עד 14, מצב קיים.

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

ימים 15 עד 30, תיקון.

1. משאירים מקור אחד לסימון של המשרד, ומכבים את השאר.
2. מחליפים את Attorney או ProfessionalService ל־LegalService.
3. מוחקים דירוג, ביקורות ומחיר מהקוד.
4. מוסיפים עסק מקומי נפרד לכל סניף בעמוד שלו, ו־WebSite עם שם האתר בעמוד הבית.
5. מוסיפים Article ו־BreadcrumbList לתבנית של המאמרים.

ימים 31 עד 60, אחרי הסריקה.

1. מבקשים סריקה מחדש של העמודים שתוקנו בכלי בדיקת הכתובות ב־Search Console.
2. בודקים את דוחות הנתונים המובנים פעם בשבועיים, ומתקנים שגיאות חדשות.
3. מחפשים את שם המשרד בגוגל ובודקים מה מופיע בחלונית, הלוגו, השעות והטלפון.

ימים 61 עד 90, שגרה.

1. מוסיפים לרשימת הבדיקה של כל עמוד חדש בדיקה אחת ב־Rich Results Test לפני פרסום.
2. קובעים שכל שינוי בפרופיל העסק, כמו שעות חג או טלפון חדש, מתעדכן באותו יום גם בקוד.
3. בודקים שוב אחרי כל עדכון של התבנית או של התוסף, כי שם נוצרות רוב הכפילויות.

איך זה נראה אצלנו

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

מקורות

• Google Search Central, נתונים מובנים לעסק מקומי (LocalBusiness), עודכן 8 בספטמבר 2026
• Google Search Central, נתונים מובנים לארגון (Organization), עודכן 8 בספטמבר 2026
• Google Search Central, נתונים מובנים לפירורי לחם (BreadcrumbList)
• Google Search Central, נתונים מובנים למאמר (Article)
• Google Search Central, הנחיות כלליות לנתונים מובנים
• Google Search Central, מבוא לנתונים מובנים בחיפוש
• Google Search Central, בדיקת נתונים מובנים (Rich Results Test ו־Schema Markup Validator)
• Search Console Help, הכלי Rich Results Test
• Google Search Central Blog, שינויים בתוצאות מועשרות של HowTo ו־FAQ (8 באוגוסט 2023, עדכון 14 בספטמבר 2023)
• Google Search Central, יומן השינויים בתיעוד (FAQ במאי וביוני 2026, פירורי לחם בינואר 2025), נבדק 25 באוקטובר 2026
• Google Search Central, הנחיות לקטעי ביקורת (Review snippet), עודכן 8 בספטמבר 2026
• Google Search Central, שם האתר בתוצאות החיפוש (WebSite)
• Google Search Central, תכונות AI ואתרים
• Schema.org, הסוג LegalService (גרסה 30.1)
• Schema.org, הסוג Attorney (מסומן כמיושן)
• Schema.org, הסוג ProfessionalService (מסומן כמיושן)
• Google Business Profile Help, איך גוגל קובעת את הדירוג המקומי
• Google, הנחיות לייצוג העסק בגוגל
• כללי לשכת עורכי הדין (פרסומת), התשס״א 2001
• topdin, אינדקס עורכי דין (מאגר הנהלת בתי המשפט 08/2025 וספר עורכי הדין 01/2023)
• BoostIt, מדד פרסום בגוגל בישראל לפי ענף
• Rank Math, מדריך Local SEO (נבדק 25 באוקטובר 2026)
• Yoast, תיעוד הסימון ש־Yoast SEO מוציא (נבדק 25 באוקטובר 2026)
• השלמה אוטומטית בגוגל, ״נתונים מובנים״, 25 באוקטובר 2026

צוות Reboost · עודכן לאחרונה ב־25.10.2026