JobPosting Schema, מדריך לאתרי קריירה ו-HR

💼 מה זה JobPosting schema, ולמה זה התנאי הבסיסי ל-Google for Jobs

תקשיבו, אני אפתח עם הסיפור שאני שומע פעם בחודש. מנהל HR מתקשר, אומר "שמוליק, פרסמנו 80 משרות באתר הקריירה שלנו, ‏אבל הן לא מופיעות ב-Google for Jobs. ‏המתחרים שלנו כן. ‏למה?". ‏אני נכנס לאתר, בודק View Source על משרה אחת. ‏אין JobPosting schema בכלל. ‏או שיש, אבל חסר חצי מה-properties. ‏נחשו למה גוגל לא מציג להם rich result, ‏לא מוסיף אותן לפילטר "jobs" ב-SERP, ‏ולא מעלה אותן ב-Google for Jobs (engine החיפוש הייעודי של גוגל למשרות)? ‏כי JobPosting schema זה תנאי בסיסי, לא bonus. ‏בלי הסכמה הזאת, המשרות שלכם פשוט לא קיימות לגוגל בקטגוריית jobs.

JobPosting הוא Schema.org type שמתאר משרה בודדת. ‏לא את החברה (זה Organization), ‏לא את אתר הקריירה (זה WebSite), ‏אלא משרה ספציפית עם title, ‏description, ‏datePosted, ‏hiringOrganization, ‏ו-jobLocation. ‏גוגל משתמש בסכמה הזאת כדי להבין שמדובר במשרה אמיתית, ‏לחלץ ממנה את כל הפרטים המובנים (תפקיד, ‏מקום, ‏שכר, ‏סוג העסקה), ‏ולהציג אותה ב-Google for Jobs, ‏הרוב הגדול של ה-job seekers בישראל היום מתחילים שם, ‏לא ב-LinkedIn, ‏לא ב-AllJobs, ‏לא ב-Drushim.

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

‏Google for Jobs הושק ב-2017 כתגובה לשליטה של LinkedIn ו-Indeed בשוק המשרות הדיגיטליות. ‏גוגל הבינה שאם היא לא תיכנס לשוק הזה, ‏היא תאבד את הקשר עם job seekers (פלח מאוד רווחי ל-AdSense בעבר). ‏הפתרון, ‏לא לבנות פלטפורמת משרות משלה, ‏אלא ל-aggregate משרות מכל אתרי הקריירה בעולם דרך JobPosting schema. ‏זה win-win, ‏גוגל מקבלת תוכן בלי לתחזק אותו, ‏אתרי קריירה מקבלים תנועה אורגנית גדולה ב-CTR גבוה מאוד (כ-2-3x מתוצאות חיפוש רגילות, ‏לפי דיווחים בענף).

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

15 פרקים שמתחילים מהבסיס (required vs recommended properties), עוברים על ה-edge cases הכי מסוכנים (validThrough שמורידה אתכם אחרי 30 יום, ‏remote jobs שדורשים applicantLocationRequirements מיוחד, ‏salary disclosure שבישראל היא נושא רגיש), ‏מציגים 7 דוגמאות JSON-LD מלאות לסוגי משרות שונים, ‏ומסיימים ב-monthly audit checklist שמונע מהמשרות שלכם להיעלם. ‏אם תקראו עד הסוף ותטמיעו את הקוד הנכון, ‏אתם תהיו בקצה הקטן של אתרי קריירה בארץ עם schema מלא, ‏מה שיתן לכם יתרון תחרותי אמיתי מול הצוותים הענקיים של LinkedIn ו-Indeed.

אגב, השם שמוליק דורינבאום מאחורי המקלדת כאן, 20 שנה בעולם ה-SEO. ‏טיפלתי בעשרות אתרי קריירה ופלטפורמות HR שעוברות מ-bulk listings סטטיים ל-JobPosting schema תקין. ‏הדבר הראשון שאני מציג בכל מקרה כזה הוא ההבדל בין ה-30 משרות שכן מופיעות ב-Google for Jobs לבין ה-200 שלא, ‏זה משחק את כל המשחק. ‏אם אחרי המאמר אתם תקועים בהטמעה, ‏יש לכם איך לדבר איתי ישירות.

✅ Required properties, ‏title + description + datePosted + hiringOrganization + jobLocation (עם דוגמת קוד)

אם תזכרו רק 5 properties מהמאמר הזה, ‏שאלה יהיו, title, description, datePosted, hiringOrganization, jobLocation. ‏אלה ה-required של JobPosting לפי הדרישות של גוגל ל-Google for Jobs. ‏בלעדיהם, ‏ה-rich result לא יופיע, ‏המשרה לא תיכלל ב-Google for Jobs engine, ‏ו-Search Console יציג errors מתחת ל-Enhancements > Job postings. ‏תקשיבו, ‏רוב המקדמים שאני בודק חסרים לפחות אחד מהחמישה, ‏בדרך כלל hiringOrganization מובנה או datePosted בפורמט הלא נכון.

title

שם המשרה. ‏לא שם המחלקה, ‏לא שם הצוות, ‏השם של תפקיד הספציפי. ‏לדוגמה "מפתח Front-End React", ‏"מנהל שיווק B2B", ‏"יועץ SEO בכיר". ‏גוגל מציג את ה-title הזה בכותרת ה-card ב-Google for Jobs, ‏אז הוא צריך להיות מדויק וקצר (עד 80 תווים). ‏אסור לכלול שם החברה, ‏מיקום, ‏סוג העסקה, ‏או דחיפות ("דחוף!"). ‏אלה שדות נפרדים. ‏אם תוסיפו אותם ל-title, ‏גוגל יחתוך או יתעלם.

description

תיאור המשרה ב-HTML. ‏גוגל מציג את זה כשמתרחבים על ה-card ב-Google for Jobs. ‏צריך להיות עשיר, ‏לפחות 200 מילים, ‏לכלול qualifications, ‏responsibilities, ‏ו-benefits. ‏מותר וצריך לכלול HTML tags כמו <p>, <ul>, <strong>. ‏אסור לכלול קישורים פעילים (גוגל יסיר אותם), ‏תמונות (irrelevant), ‏או iframes. ‏ה-description הוא הנכס היחיד שמשפיע על דירוג של המשרה מול משרות דומות, ‏השקיעו בו.

datePosted

התאריך שבו המשרה פורסמה לראשונה, ‏בפורמט ISO 8601 (YYYY-MM-DD). ‏לדוגמה "2026-05-30". ‏לא לעדכן אותו כל יום "כדי להיראות טריים", ‏זה אנטי-pattern. ‏גוגל סופר את הזמן מ-datePosted לצורך deindex, ‏אז אם תעדכנו אותו, ‏גוגל יחשוב שהמשרה חדשה ויפסיק להציג אותה אחרי 30 יום מהעדכון. ‏הכוונה ההפוכה ממה שאתם רוצים. ‏השאירו את datePosted כפי שהוא, ‏השתמשו ב-validThrough כדי לציין מתי המשרה פגה.

hiringOrganization

החברה שמגייסת. ‏Object של Organization עם name (חובה), ‏ועם url ו-logo (מומלצים). ‏לדוגמה {"@type": "Organization", "name": "חברת ABC", "sameAs": "https://abc.co.il/", "logo": "https://abc.co.il/logo.png"}. ‏ה-name חייב להיות זהה בדיוק לשם המוצג של החברה ב-Google Business Profile של החברה ובכל אתר הקריירה. ‏ה-inconsistency כאן גורר penalty.

jobLocation

היכן המשרה. ‏Object של Place עם address (PostalAddress object). ‏אם המשרה היא במשרד פיזי, ‏זה streetAddress + addressLocality + addressRegion + postalCode + addressCountry. ‏אם המשרה היא remote, ‏יש לזה טיפול מיוחד (פרק 5 צולל לעומק). ‏גוגל מציג את ה-location ב-card של ה-Job search כסיגנל ראשי לסינון לפי אזור.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "מפתח Front-End React",
  "description": "<p>חברת ABC מחפשת מפתח Front-End לצוות מוצר חדש. ‏אחריות, פיתוח רכיבים ב-React, אינטגרציה עם APIs, ‏שיתוף פעולה עם מעצבים</p><ul><li>3+ שנות ניסיון ב-React</li><li>ידע ב-TypeScript</li><li>ניסיון עם state management</li></ul>",
  "datePosted": "2026-05-30",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "חברת ABC",
    "sameAs": "https://abc.co.il/",
    "logo": "https://abc.co.il/logo.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "רחוב הברזל 32",
      "addressLocality": "תל אביב",
      "addressRegion": "תל אביב",
      "postalCode": "6971042",
      "addressCountry": "IL"
    }
  }
}
</script>

הוספת @id ו-url

‏שני properties שאינם required אבל הם best practice. ‏@id ייחודי שמזהה את המשרה על פני כל הסכמות שלכם (חשוב במיוחד ב-bulk job sites עם 1000+ משרות). ‏url שמקשר לעמוד המשרה הספציפי. ‏הפורמט המקובל ל-@id הוא URL מלא של עמוד המשרה + hash, ‏לדוגמה https://careers.example.co.il/job-12345#posting. ‏זה מבטיח ייחודיות גם כשיש לכם כמה גרסאות של אותה משרה (לדוגמה, ‏עברית + אנגלית).

💎 Recommended properties, ‏validThrough + baseSalary + employmentType + identifier (עם דוגמת קוד)

‏הגענו ל-recommended properties, ‏אבל אל תתבלבלו, ‏ה-"recommended" של גוגל ב-JobPosting זה לא באמת אופציונלי. ‏בלי validThrough, ‏המשרה נעלמת אוטומטית מ-Google for Jobs אחרי 30 יום (פרק 4 צולל לזה). ‏בלי baseSalary, ‏היא לא תופיע בפילטר "שכר" של Google for Jobs, ‏וגוגל מורידה לה בדירוג (יש דיווחים מ-Google Search Liaison שהאלגוריתם מתעדף משרות עם שכר גלוי). ‏בלי employmentType, ‏היא לא תופיע בפילטר "סוג עבודה". ‏הסיכום, ‏ה-"recommended" כאן זה ה-real required לפרודקציה.

validThrough

‏התאריך שבו המשרה פגה, ‏בפורמט ISO 8601 עם זמן. ‏לדוגמה "2026-07-30T23:59:59+03:00" (כולל timezone של ישראל, ‏+03:00 בקיץ או +02:00 בחורף). ‏אם תשמיטו, ‏גוגל יסיר את המשרה אוטומטית מ-Google for Jobs אחרי 30 יום מ-datePosted. ‏זאת מדיניות aggressive שלה. ‏הוסיפו validThrough תמיד, ‏גם אם המשרה פגה רק עוד שנה. ‏זה הביטוח שלכם.

baseSalary

‏שכר בסיס, ‏Object של MonetaryAmount עם currency, ‏value (QuantitativeValue עם minValue/maxValue/unitText). ‏גוגל מציגה את זה ב-card של Google for Jobs ובפילטרים. ‏אם השכר טווחי (לדוגמה 15,000 עד 20,000 שח חודשי), ‏השתמשו ב-minValue + maxValue. ‏אם נקודתי, ‏השתמשו ב-value. ‏ה-unitText תמיד "MONTH" (חודשי), ‏"YEAR" (שנתי), ‏"HOUR" (שעתי), ‏וכו'. ‏בישראל זה נושא רגיש כי רוב המעסיקים לא חושפים שכר, ‏פרק 6 צולל לזה.

employmentType

‏סוג העסקה. ‏מחרוזת קבועה מבין הערכים, ‏FULL_TIME, ‏PART_TIME, ‏CONTRACTOR, ‏TEMPORARY, ‏INTERN, ‏VOLUNTEER, ‏PER_DIEM, ‏OTHER. ‏לפעמים array של כמה. ‏לדוגמה "employmentType": ["FULL_TIME", "CONTRACTOR"] אומר שאתם פתוחים גם לעובד מלא וגם לפרילנס. ‏גוגל מציגה את זה כפילטר.

identifier

‏מזהה ייחודי של המשרה אצלכם. ‏Object של PropertyValue עם name (שם השדה, ‏לדוגמה "Job ID") ו-value (המספר/קוד). ‏זה מאפשר לגוגל לזהות שהמשרה זהה גם אם ה-URL משתנה, ‏או אם אתם מפרסמים את המשרה גם ב-Indeed/LinkedIn. ‏לדוגמה {"@type": "PropertyValue", "name": "חברת ABC", "value": "FE-2026-042"}.

applicantLocationRequirements (למשרות remote)

‏לא רלוונטי לכל משרה, ‏רק לכאלה שהן remote. ‏מגדיר מאיזה אזורים אתם מקבלים מועמדים. ‏צריך לבוא יחד עם jobLocationType = "TELECOMMUTE". ‏פרק 5 על remote jobs צולל לזה לעומק.

qualifications, responsibilities, skills, educationRequirements, experienceRequirements

‏5 שדות text שמתארים את דרישות התפקיד. ‏גוגל לא תמיד מציג אותם ב-rich result, ‏אבל הם מסייעים ל-matching של job seekers. ‏גם AI engines כמו ChatGPT משתמשים בהם כדי להמליץ על משרות לפי קורות חיים. ‏השקיעו בהם, ‏הם זולים והם משפיעים על relevance score.

דוגמת קוד מלאה עם recommended

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "מפתח Front-End React",
  "description": "<p>חברת ABC מחפשת מפתח Front-End לצוות מוצר חדש</p>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "חברת ABC",
    "value": "FE-2026-042"
  },
  "datePosted": "2026-05-30",
  "validThrough": "2026-07-30T23:59:59+03:00",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "חברת ABC",
    "sameAs": "https://abc.co.il/",
    "logo": "https://abc.co.il/logo.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "רחוב הברזל 32",
      "addressLocality": "תל אביב",
      "addressRegion": "תל אביב",
      "postalCode": "6971042",
      "addressCountry": "IL"
    }
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "ILS",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 18000,
      "maxValue": 26000,
      "unitText": "MONTH"
    }
  },
  "qualifications": "3+ שנות ניסיון ב-React, ידע ב-TypeScript",
  "responsibilities": "פיתוח רכיבי UI, ‏אינטגרציה עם REST APIs, ‏code review",
  "skills": "React, TypeScript, Redux, ‏Git, ‏Jest",
  "educationRequirements": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "תואר ראשון במדעי המחשב או ניסיון מקביל"
  },
  "experienceRequirements": {
    "@type": "OccupationalExperienceRequirements",
    "monthsOfExperience": 36
  }
}
</script>

⏰ validThrough הקריטי, ‏למה גוגל מוחקת את המשרה אחרי 30 יום (וזה לא באג)

‏זה החלק שמורט הכי הרבה לקוחות HR. ‏הם פרסמו 100 משרות, ‏הן הופיעו ב-Google for Jobs לכמה שבועות, ‏ואז נעלמו. ‏מה קרה? ‏זה לא באג, ‏זאת מדיניות מכוונת של גוגל. ‏היא מסירה אוטומטית כל JobPosting שלא הוגדר לו validThrough, ‏אחרי 30 יום מ-datePosted. ‏בלי אזהרה, ‏בלי הודעה ב-Search Console. ‏פשוט נעלמות. ‏תקשיבו, ‏זה אחד הדברים הכי מתסכלים ב-Google for Jobs, ‏ויחד עם זה, ‏הוא קל לפתרון אם יודעים עליו.

למה גוגל עושה את זה

‏גוגל רוצה ש-Google for Jobs יציג רק משרות פעילות. ‏job seeker שמגיע למשרה שכבר מולאה ומגיש מועמדות מקבל חוויית משתמש גרועה, ‏וזה פוגע באמון בכל הפלטפורמה. ‏לכן גוגל הניחה את הסף, ‏אם המעסיק לא טרח להגדיר תאריך תפוגה, ‏היא מנחשת שהמשרה כנראה כבר לא רלוונטית אחרי 30 יום ומסיר אותה. ‏זה logical, ‏אבל הוא מענישה את מי שלא יודעים על המדיניות.

איך מטמיעים נכון

‏הוסיפו validThrough לכל משרה. ‏הפורמט הוא ISO 8601 datetime עם timezone. ‏לדוגמה "2026-08-30T23:59:59+03:00". ‏הזמן הסופי של היום (23:59:59) חשוב כי אחרת המשרה תיעלם בחצות של אותו יום ולא בסוף היום. ‏ה-timezone +03:00 הוא של ישראל בשעון קיץ (אפריל-אוקטובר), ‏+02:00 בשעון חורף (נובמבר-מרץ).

כמה זמן validThrough נכון

‏תלוי בעסק. ‏המקובל הוא 60-90 יום מ-datePosted. ‏פחות מ-30 יום זה מבזבז את ה-eligibility (המשרה לא תספיק להופיע מספיק זמן ב-Google for Jobs). ‏יותר משנה זה suspicious (גוגל אוהבת freshness). ‏60-90 יום זה ה-sweet spot.

מה לעשות אם המשרה ממולאת מוקדם

‏שינו את validThrough לתאריך שבו המשרה מולאה. ‏אל תסירו את ה-schema לחלוטין, ‏זה גורם ל-redirect chain בעייתי. ‏אל תעדכנו את datePosted להיום (זה שינוי משמעותי שגוגל ירשום אותו). ‏פשוט עדכנו validThrough להיום, ‏המשרה תיעלם תוך 24 שעות מ-Google for Jobs.

אופציה מתקדמת, ‏jobImmediateStart

‏property בשם jobImmediateStart (boolean) אומר לגוגל שהמשרה מתחילה מיד. ‏גוגל מתעדף משרות עם jobImmediateStart=true בדירוג. ‏לא חובה, ‏אבל אם המשרה באמת מיידית, ‏הוסיפו אותה.

איך לעקוב אחרי deindex

‏ב-Search Console, ‏Enhancements > Job postings, ‏יש דוח שמציג כל ה-job postings שגוגל זיהתה. ‏אם משרה נעלמת, ‏היא תופיע כ-"Removed". ‏בדקו פעם בשבוע. ‏הסיבות הנפוצות לדיאינדקס, ‏(1) validThrough חסר ועברו 30 יום, ‏(2) המשרה הוסרה מהאתר וגוגל מצאה 404, ‏(3) ה-schema נשבר בעדכון אחרון של הקוד, ‏(4) המשרה מסומנת כ-duplicate של משרה אחרת באתר.

🌍 Remote jobs, ‏jobLocationType TELECOMMUTE ו-applicantLocationRequirements (עם דוגמת קוד)

‏משרות remote הן edge case מסובך ב-JobPosting schema. ‏בעבר היו אנשי HR שמילאו את jobLocation עם הכתובת של המשרד הראשי, ‏גם אם המשרה היא 100% remote. ‏זה גרם לבלבול אצל job seekers ("למה המשרה הזאת ברחובות אם היא remote?") וגם אצל גוגל ("איך זה משרה ברחובות אם המעסיק מקבל מועמדים מכל הארץ?"). ‏הפתרון של גוגל, ‏property חדש בשם jobLocationType עם הערך "TELECOMMUTE", ‏בשילוב עם applicantLocationRequirements שמגדיר מאיזה אזורים מתקבלים מועמדים.

הסכמה למשרה 100% remote

‏עבור משרה שהיא לחלוטין remote, ‏אסור לכלול jobLocation (זה ייגרום ל-validation error כשגם jobLocationType="TELECOMMUTE"). ‏במקום, ‏הוסיפו רק jobLocationType ו-applicantLocationRequirements. ‏לדוגמה, ‏משרה שמקבלת מועמדים מכל ישראל,

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "מפתח Full-Stack remote",
  "description": "<p>חברת stratup israely מחפשת מפתח Full-Stack שיעבוד מהבית או מ-co-working space. ‏הצוות מבוזר ברחבי הארץ, ‏ישיבות שבועיות ב-Zoom</p>",
  "datePosted": "2026-05-30",
  "validThrough": "2026-07-30T23:59:59+03:00",
  "employmentType": "FULL_TIME",
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": {
    "@type": "Country",
    "name": "Israel"
  },
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Startup ABC",
    "sameAs": "https://startup-abc.co.il/"
  }
}
</script>

הסכמה למשרה hybrid (remote + ימים במשרד)

‏כאן צריך גם jobLocation וגם jobLocationType="TELECOMMUTE" וגם applicantLocationRequirements. ‏גוגל יבין שהמשרה היא בעיקרה remote אבל יש דרישה להגעה פיזית מדי פעם, ‏אז המיקום הפיזי רלוונטי כדי לסנן מועמדים שגרים רחוק מדי.

{
  "@type": "JobPosting",
  "title": "מנהל מוצר Hybrid",
  "jobLocationType": "TELECOMMUTE",
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "תל אביב",
      "addressRegion": "תל אביב",
      "addressCountry": "IL"
    }
  },
  "applicantLocationRequirements": {
    "@type": "AdministrativeArea",
    "name": "מרכז ושפלת החוף"
  }
}

multiple countries

‏אם המשרה מקבלת מועמדים מכמה מדינות, ‏השתמשו ב-array של Country objects:

"applicantLocationRequirements": [
  {"@type": "Country", "name": "Israel"},
  {"@type": "Country", "name": "United States"},
  {"@type": "Country", "name": "Germany"}
]

הטעות הקלאסית, ‏jobLocation עם המשרד הראשי במשרה 100% remote

‏אני רואה את זה לפחות פעם בשבועיים. ‏חברה ישראלית מפרסמת משרה 100% remote, ‏וב-jobLocation היא ממלא את הכתובת של המשרד הראשי כי "זאת הכתובת של החברה". ‏job seeker מחו"ל מסתכל ב-Google for Jobs, ‏רואה "רחובות, ישראל", ‏ולא מגיש מועמדות כי הוא חושב שמדובר במשרה במשרד פיזי בישראל. ‏זה פספוס של מועמדים טובים. ‏הגדרה נכונה של jobLocationType+applicantLocationRequirements פותרת את הבעיה.

💰 baseSalary disclosure, ‏הדיון על שקיפות שכר וההשפעה על Google

‏זה אחד הנושאים הכי שנויים במחלוקת ב-JobPosting schema. ‏גוגל ברורה, ‏היא מתעדפת משרות עם baseSalary גלוי. ‏ארה"ב חוקקה חוקים בכמה מדינות (NY, CA, CO) שמחייבים פרסום שכר במשרות. ‏האיחוד האירופאי הולך לכיוון דומה. ‏ישראל, ‏לא. ‏רוב המעסיקים הישראלים לא חושפים שכר. ‏הסיבות, ‏"אסטרטגיה", ‏"הימנעות מתחרות פנימית", ‏"גמישות במשא ומתן". ‏הסיבות הללו מתחשבות, ‏אבל הן באות במחיר של דירוג נמוך יותר ב-Google for Jobs.

למה גוגל מעדיפה משרות עם שכר גלוי

‏גוגל ל-Google for Jobs מצהירה במפורש בתיעוד, ‏"השכר הוא הפילטר הראשון של job seekers". ‏משרות עם שכר גלוי מקבלות יותר קליקים, ‏זמן ארוך יותר על העמוד, ‏ופחות נטישות. ‏האלגוריתם של Google for Jobs לומד את זה ומתעדף משרות עם שכר. ‏לפי דיווחים מ-Search Engine Journal ו-Search Engine Land, ‏אתרי קריירה שעברו לפרסם שכר ראו עלייה של 15-25% ב-impressions ב-Google for Jobs תוך חודשיים.

איך לגלות שכר ב-baseSalary

‏אם המעסיק אישר לחשוף שכר, ‏הסכמה היא פשוטה. ‏MonetaryAmount עם currency=ILS, ‏ו-value שהוא QuantitativeValue. ‏אם השכר נקודתי, ‏השתמשו ב-value. ‏אם טווחי, ‏ב-minValue ו-maxValue.

"baseSalary": {
  "@type": "MonetaryAmount",
  "currency": "ILS",
  "value": {
    "@type": "QuantitativeValue",
    "minValue": 22000,
    "maxValue": 32000,
    "unitText": "MONTH"
  }
}

unitText, ‏האפשרויות

• HOUR, ‏שכר שעתי (מקובל ב-freelance, ‏ייעוץ, ‏מורים פרטיים)
• DAY, ‏שכר יומי (מקובל ב-day-rate consultants)
• WEEK, ‏שכר שבועי (נדיר בישראל)
• MONTH, ‏שכר חודשי (הרגיל למשרות שכירים בישראל)
• YEAR, ‏שכר שנתי (מקובל ב-tech ובמשרות בכירות)

מה לעשות אם המעסיק לא רוצה לגלות שכר

‏יש שלוש אופציות, ‏(1) ‏לוותר על baseSalary לחלוטין. ‏המשרה תופיע ב-Google for Jobs אבל בלי שכר, ‏ותקבל פחות clicks. ‏(2) ‏לפרסם טווח רחב מאוד (לדוגמה minValue=10000 maxValue=50000). ‏זה לא נותן ערך אמיתי ל-job seeker אבל מאפשר eligibility מלא. ‏לא מומלץ, ‏גוגל יכולה לזהות את זה כ-misleading. ‏(3) ‏לפרסם טווח ריאלי אבל רחב יותר ממה שהמעסיק רצה. ‏לדוגמה אם הוא רוצה לשלם 18-22 אלף, ‏פרסמו 16-25 אלף. ‏זה ה-compromise המעשי שאני ממליץ עליו אצל לקוחות.

🇮🇱 ההקשר הישראלי, ‏איך לטפל בחשיפת שכר בעברית

‏ישראל היא מקרה מיוחד בעולם המשרות. ‏רוב המעסיקים לא חושפים שכר, ‏לא בגלל חוק (אין חוק שאוסר), ‏אלא בגלל מנהג מקומי. ‏המנהג הזה מקבע את עצמו, ‏כי כל מעסיק חושב "אם אני אגלה, ‏המתחרים יידעו מה אני משלם". ‏זה classic prisoner's dilemma. ‏כולם היו מרוויחים אם היו מגלים, ‏אבל אף אחד לא רוצה להיות הראשון. ‏הסיכום, ‏כ-80-90% מהמשרות בישראל אין להן שכר מפורסם. ‏זה עובד נגדכם ב-Google for Jobs כי גוגל מתעדפת משרות עם שכר.

השוק הישראלי משתנה

‏השנים האחרונות יש שינוי. ‏חברות tech בינלאומיות שמגייסות בישראל (Microsoft Israel, ‏Google Israel, ‏Meta Israel, ‏Apple Israel) מתחילות לפרסם שכר כי זאת מדיניות גלובלית שלהן. ‏זה יוצר לחץ על חברות ישראליות מקומיות לעשות את אותו דבר. ‏אתרים כמו AllJobs ו-JobMaster עוד לא דורשים שכר חובה, ‏אבל זה רק שאלת זמן. ‏אם אתם אתר קריירה גדול, ‏שקלו להפוך את שדה השכר ל-soft requirement, ‏אופציונלי אבל מעודד אקטיבית.

הניסוח של שכר בעברית בתוך description

‏אם המעסיק לא רוצה לפרסם baseSalary structured אבל מסכים לציין שכר ב-description, ‏הוסיפו אותו ב-HTML של description. ‏זה לא יופיע בפילטר השכר של Google for Jobs (שאוסף רק מ-baseSalary), ‏אבל זה ייחשף ל-job seekers שלוחצים על המשרה. ‏ניסוחים מקובלים בעברית, ‏"שכר תחילי 18,000 ש\"ח", ‏"טווח שכר 22-30 אלף ש\"ח ברוטו", ‏"שכר תואם תכנון".

שכר באלפי שקלים, ‏הטעות הנפוצה

‏רוב הישראלים אומרים "שכר 25" (כלומר 25,000 ש"ח). ‏ב-baseSalary, ‏ה-value חייב להיות במספר מלא, ‏לא בקיצור. ‏לדוגמה minValue=25000 ולא minValue=25. ‏25 בקיצור ייפורש על ידי גוגל כ-25 ש"ח, ‏וזה ייצור curiosity-killing פילטור ("משרה ב-25 ש"ח לחודש? ‏מי תגיש מועמדות?"). ‏ולעיתים גוגל יתעלם לגמרי מהסכמה כי הערך נראה לא ריאלי.

מטבע, ‏ILS תמיד

‏עבור משרות בישראל, ‏currency תמיד "ILS" (Israeli New Shekel, ‏קוד ISO 4217). ‏לעולם לא "NIS" (קיצור לא רשמי), ‏לא "שקל", ‏לא "₪". ‏גם אם השכר מצוין בדולר (לדוגמה ייעוץ לחברה אמריקאית), ‏ופרילנס ישראלי, ‏השתמשו ב-USD. ‏גוגל ימיר אוטומטית ב-Google for Jobs לפי שער ההמרה הנוכחי לטובת job seekers ב-IL.

📋 Employment types, ‏FULL_TIME / PART_TIME / CONTRACTOR / TEMPORARY / INTERN

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

FULL_TIME

‏משרה מלאה, ‏המקובל בישראל הוא 42-45 שעות שבועיות. ‏לרוב משרות שכירים בענף ה-tech, ‏ההייטק, ‏הפיננסים, ‏וכמעט כל "משרה ממשלתית" יש סיווג FULL_TIME. ‏אם המשרה היא 100% (משרה מלאה לפי הגדרת השעות של המעסיק), ‏זה FULL_TIME גם אם בפועל מספר השעות שונה ממקום למקום.

PART_TIME

‏משרה חלקית, ‏לרוב 50-80% משרה. ‏מקובל בעבודות סטודנטים, ‏עבודות נוספות, ‏הוראה חלקית. ‏אם השעות גמישות לחלוטין, ‏שקלו CONTRACTOR במקום.

CONTRACTOR

‏פרילנסר, ‏עוסק מורשה/פטור, ‏חברה ניהול. ‏לא שכיר, ‏עובד נגד חשבונית. ‏מקובל ב-tech freelance, ‏ייעוץ, ‏עיצוב, ‏תוכן. ‏אם המעסיק מקבל גם שכירים וגם פרילנסרים, ‏השתמשו ב-array (["FULL_TIME", "CONTRACTOR"]).

TEMPORARY

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

INTERN

‏סטאז'/התמחות. ‏לרוב סטודנטים בשנות לימודי לתואר ראשון או שני, ‏או בוגרים שעוד לא נכנסו לשוק העבודה הראשי. ‏בישראל זה מקובל בעיקר ב-tech ("intern at Google"), ‏ובמקצועות שדורשים התמחות חובה (רפואה, ‏עריכת דין, ‏ראיית חשבון). ‏שכר מקובל הוא 70-80% מהמשרה המלאה המקבילה.

VOLUNTEER

‏מתנדבים. ‏ללא תשלום. ‏מקובל בעמותות, ‏ארגונים חברתיים, ‏ופרויקטים קהילתיים. ‏גוגל מציג את זה בנפרד ב-Google for Jobs (יש פילטר "Volunteer").

PER_DIEM

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

OTHER

‏כל מה שלא נכנס בקטגוריות אחרות. ‏שימוש נדיר, ‏רק כאשר באמת אין התאמה.

שילובים

// משרה מלאה רגילה
"employmentType": "FULL_TIME"

// משרה שיכולה להיות גם שכיר וגם פרילנס
"employmentType": ["FULL_TIME", "CONTRACTOR"]

// משרה חלקית או התמחות
"employmentType": ["PART_TIME", "INTERN"]

🏢 דוגמת קוד מלאה, ‏משרת office מלאה ב-tech

‏הנה דוגמה מלאה למשרת office ב-tech ישראלי. ‏כוללת את כל ה-properties שגוגל אוהב, ‏כולל baseSalary מפורסם, ‏identifier, ‏jobBenefits שמוצגים ב-Google for Jobs כ-feature. ‏תקשיבו, ‏זאת הגישה ה-best in class. ‏רוב המשרות בארץ עדיין עם schema חלקי. ‏תיתנו למשרות שלכם schema מלא, ‏ותתחילו לראות אותן מופיעות גבוה ב-Google for Jobs מעל למשרות של מתחרים גדולים יותר.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Senior Backend Developer",
  "description": "<p>חברת StreamFlow מחפשת Senior Backend Developer לצוות platform שמטפל ב-2M requests ביום. ‏הצוות בנוי מ-8 מהנדסים, ‏עובדים ב-Hybrid (3 ימים במשרד, 2 מהבית). ‏הטכנולוגיה, ‏Node.js + PostgreSQL + Redis + Kubernetes.</p><h3>מה תעשו</h3><ul><li>פיתוח micro-services ב-Node.js</li><li>תכנון schemas ב-PostgreSQL ו-optimization של queries</li><li>Code review של חברי הצוות</li><li>Mentorship לחברים junior</li><li>Participation ב-on-call rotation (פעם בחודש)</li></ul><h3>מה אנחנו מחפשים</h3><ul><li>5+ שנות ניסיון בפיתוח backend ב-Node.js</li><li>ניסיון מעמיק ב-PostgreSQL (queries מורכבים, optimization, indices)</li><li>ניסיון ב-distributed systems</li><li>ידע ב-Kubernetes ו-Docker</li><li>יכולת mentorship מוכחת</li></ul>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "StreamFlow",
    "value": "BE-SENIOR-2026-007"
  },
  "datePosted": "2026-05-30",
  "validThrough": "2026-08-30T23:59:59+03:00",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "StreamFlow Technologies",
    "sameAs": "https://streamflow.co.il/",
    "logo": "https://streamflow.co.il/logo-square.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "רחוב יגאל אלון 94",
      "addressLocality": "תל אביב",
      "addressRegion": "תל אביב",
      "postalCode": "6789139",
      "addressCountry": "IL"
    }
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "ILS",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 35000,
      "maxValue": 48000,
      "unitText": "MONTH"
    }
  },
  "qualifications": "5+ שנות ניסיון ב-Node.js, ‏PostgreSQL, ‏ניסיון ב-distributed systems",
  "responsibilities": "פיתוח micro-services, ‏code review, ‏mentorship",
  "skills": "Node.js, PostgreSQL, Redis, Kubernetes, Docker, distributed systems",
  "educationRequirements": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "תואר ראשון במדעי המחשב או ניסיון מקביל"
  },
  "experienceRequirements": {
    "@type": "OccupationalExperienceRequirements",
    "monthsOfExperience": 60
  },
  "jobBenefits": "קרן השתלמות, ‏ביטוח בריאות פרטי, ‏סופי שבוע ארוכים, ‏meal allowance",
  "workHours": "Sunday to Thursday, ‏09:00-18:00, ‏Friday 09:00-13:00",
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": {
    "@type": "AdministrativeArea",
    "name": "מרכז ושפלת החוף"
  }
}
</script>

מה מיוחד פה

• description עשיר עם HTML, ‏headings (h3), ‏unordered lists (ul/li). ‏גוגל מרנדר את זה ב-Google for Jobs כשמתרחבים על ה-card.
• identifier ייחודי, ‏BE-SENIOR-2026-007 שמאפשר tracking של המשרה גם בין אתרים שונים (LinkedIn, ‏Indeed) שמשתמשים באותו identifier.
• jobLocationType="TELECOMMUTE" עם jobLocation שמלא, ‏המשרה היא hybrid, ‏3 ימים במשרד 2 מהבית. ‏גוגל יבין שהמיקום הפיזי רלוונטי אבל המשרה תופיע גם בפילטר "Remote".
• applicantLocationRequirements="מרכז ושפלת החוף", ‏אנחנו מקבלים מועמדים רק מאזור המרכז כי הם יצטרכו להגיע למשרד 3 ימים בשבוע. ‏מסנן אוטומטי לאנשים מהצפון או הדרום.
• baseSalary טווח רחב, ‏35-48 אלף. ‏זה מאפשר flexibility במשא ומתן ועוזר ל-job seekers להבין שהמשרה ריאלית לטווח רחב של ניסיון.
• workHours כתוב במחרוזת חופשית, ‏גוגל לא מציג את זה רגיל ב-Google for Jobs, ‏אבל זה assists ל-AI engines (ChatGPT, ‏Perplexity) שיכולים להציג את זה ב-summary של המשרה.

🏠 דוגמת קוד מלאה, ‏משרת remote 100%

‏הנה דוגמה למשרה שהיא 100% remote, ‏ללא דרישה להגיע למשרד בכלל. ‏שימו לב, ‏אין jobLocation בכלל, ‏רק jobLocationType="TELECOMMUTE" + applicantLocationRequirements. ‏זה ההבדל המהותי מהדוגמה הקודמת. ‏המשרה מקבלת מועמדים מכל ישראל ומחו"ל.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Frontend Engineer (Fully Remote)",
  "description": "<p>חברת NotionLike מחפשת Frontend Engineer לעבודה remote 100%. ‏הצוות מבוזר ב-5 מדינות, ‏ישיבות שבועיות ב-Zoom, ‏async communication ב-Slack. ‏אין דרישה לימי משרד, ‏אין דרישה ל-timezone ספציפי, ‏עובדים גמיש.</p><h3>מה תעשו</h3><ul><li>פיתוח רכיבי UI מורכבים ב-React + TypeScript</li><li>עבודה צמודה עם designers</li><li>optimization של performance לאלפי משתמשים בו זמנית</li><li>כתיבת unit + integration tests</li></ul><h3>מה אנחנו מחפשים</h3><ul><li>3+ שנות ניסיון ב-React</li><li>TypeScript proficiency</li><li>ניסיון בעבודה async ב-distributed team</li><li>יכולת self-management גבוהה</li><li>אנגלית רהוטה (השפה של הצוות)</li></ul>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "NotionLike",
    "value": "FE-REMOTE-2026-013"
  },
  "datePosted": "2026-05-30",
  "validThrough": "2026-08-30T23:59:59+00:00",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "NotionLike",
    "sameAs": "https://notionlike.com/",
    "logo": "https://notionlike.com/logo.png"
  },
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": [
    {"@type": "Country", "name": "Israel"},
    {"@type": "Country", "name": "United States"},
    {"@type": "Country", "name": "Germany"},
    {"@type": "Country", "name": "United Kingdom"},
    {"@type": "Country", "name": "Portugal"}
  ],
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 90000,
      "maxValue": 130000,
      "unitText": "YEAR"
    }
  },
  "qualifications": "3+ years React, ‏TypeScript proficiency, ‏async work experience",
  "responsibilities": "Build complex UI components, ‏work with designers, ‏optimize performance",
  "skills": "React, TypeScript, CSS-in-JS, Jest, ‏async communication",
  "experienceRequirements": {
    "@type": "OccupationalExperienceRequirements",
    "monthsOfExperience": 36
  },
  "jobBenefits": "Unlimited vacation, ‏home office stipend, ‏health insurance allowance, ‏ESOP"
}
</script>

מה מיוחד פה

• אין jobLocation בכלל, ‏כי המשרה היא 100% remote. ‏אם הייתי מוסיף jobLocation עם כתובת של משרד כלשהו, ‏גוגל היה מבלבל job seekers ומציג את המיקום הפיזי. ‏העדפה ברורה, ‏השמטה.
• applicantLocationRequirements כ-array של 5 מדינות, ‏המעסיק מוכן לקבל מועמדים מ-IL, ‏US, ‏DE, ‏GB, ‏PT. ‏גוגל יציג את המשרה ל-job seekers מהארצות הללו ב-Google for Jobs.
• currency="USD" ו-unitText="YEAR", ‏המעסיק שותל שכר בדולר שנתי (פורמט סטנדרטי ב-tech בינלאומי). ‏גוגל ימיר את זה לשקלים אוטומטית לפי שער ההמרה הנוכחי כשמציג ל-job seeker בישראל.
• validThrough עם timezone UTC (+00:00), ‏כי המעסיק לא בישראל, ‏ולא רוצה להתחייב ל-timezone ספציפי. ‏UTC הוא ה-default המקובל ב-tech בינלאומי.
• jobBenefits כולל "Unlimited vacation" ו-"ESOP", ‏benefits שנפוצים בחברות tech בינלאומיות. ‏גוגל לא תמיד מציגה אותם ב-card, ‏אבל הם מעלים את ה-CTR כשהם מופיעים.

💼 דוגמת קוד מלאה, ‏משרת freelance / CONTRACTOR

‏משרות freelance הן edge case מעניין. ‏הן לא משרות שכירים, ‏אז הרבה מ-properties הרגילות לא רלוונטיות. ‏אין שעות עבודה קבועות, ‏אין benefits שכירים, ‏אין דרישת הגעה למשרד. ‏עם זאת, ‏גוגל מציגה אותן ב-Google for Jobs באותו פילטר עם CONTRACTOR. ‏הנה דוגמה למשרה freelance של מעצב UX לפרויקט של 3 חודשים.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "מעצב UX לפרויקט redesign (3 חודשים)",
  "description": "<p>חברת FintechIL מחפשת מעצב UX לפרויקט redesign של הדשבורד הראשי שלה. ‏פרויקט מוגדר, ‏3 חודשים, ‏אפשרות הארכה לפרויקטים נוספים. ‏עובדים מול PM ו-Frontend lead. ‏העבודה רובה async עם sync calls פעמיים בשבוע.</p><h3>מה תעשו</h3><ul><li>Discovery research עם משתמשים קיימים (3 שבועות)</li><li>Wireframes ו-prototypes ב-Figma (4 שבועות)</li><li>High-fidelity designs (3 שבועות)</li><li>Handoff ל-frontend ו-QA support (2 שבועות)</li></ul>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "FintechIL",
    "value": "UX-CONTRACT-Q2-2026"
  },
  "datePosted": "2026-05-30",
  "validThrough": "2026-06-30T23:59:59+03:00",
  "employmentType": "CONTRACTOR",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "FintechIL",
    "sameAs": "https://fintechil.co.il/"
  },
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": {
    "@type": "Country",
    "name": "Israel"
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "ILS",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 400,
      "maxValue": 550,
      "unitText": "HOUR"
    }
  },
  "qualifications": "5+ שנות ניסיון UX/UI, ‏ניסיון מוכח עם פרויקטים פיננסיים, ‏Figma proficiency",
  "responsibilities": "Discovery research, ‏wireframes, ‏prototypes, ‏high-fidelity designs, ‏handoff",
  "skills": "Figma, ‏user research, ‏wireframing, ‏prototyping, ‏design systems, ‏fintech UX",
  "experienceRequirements": {
    "@type": "OccupationalExperienceRequirements",
    "monthsOfExperience": 60
  },
  "workHours": "Flexible, ‏estimated 80-100 hours/month for 3 months"
}
</script>

מה מיוחד פה

• employmentType="CONTRACTOR", ‏זה freelance, ‏לא שכיר. ‏גוגל יציג את המשרה בפילטר "Contract" של Google for Jobs ולא בפילטר "Full-time". ‏זה חשוב כי שני ה-job seeker pools שונים.
• unitText="HOUR", ‏שכר שעתי במקום חודשי. ‏מקובל ב-freelance. ‏גוגל ימיר את זה לחישוב חודשי (לפי 168 שעות) כשמציג בפילטר השכר.
• validThrough קצר (30 יום בלבד), ‏כי הפרויקט עצמו קצר ויש דחיפות. ‏אין סיבה לתת לפרסום לחיות 90 יום אם הפרויקט מתחיל בעוד שבועיים.
• workHours כ-"Flexible", ‏לא שעות קבועות. ‏המעסיק רק מציין כמה שעות בחודש בערך. ‏מקובל ב-freelance.
• jobLocationType="TELECOMMUTE" + applicantLocationRequirements=Israel, ‏המשרה remote, ‏אבל רק לישראלים (אולי בגלל דרישות חשבונית/מע"מ).
• בלי benefits, ‏freelance לא מקבל benefits שכירים (קרן השתלמות, ‏ביטוח בריאות, ‏חופשה). ‏השמטה היא הגישה הנכונה, ‏לא להמציא benefits שלא קיימים.

🔍 Validation עם Rich Results Test ו-Google for Jobs requirements

‏אחרי שתטמיעו את ה-schema, ‏חובה להריץ validation. ‏גוגל מציע 2 כלים, ‏Rich Results Test (search.google.com/test/rich-results) ו-Schema Validator (validator.schema.org). ‏שניהם חינמיים, ‏שניהם מקבלים URL או קוד מודבק. ‏ההבדל ביניהם, ‏Rich Results Test בודק eligibility ל-rich results של גוגל ספציפית, ‏Schema Validator בודק תאימות תחבירית של ה-schema בלי קשר לגוגל.

השלבים לתפעול Rich Results Test

1. פתחו search.google.com/test/rich-results

   ‏הכניסו את ה-URL של עמוד המשרה, או בחרו "Code" וה-deduce את הסכמה ידנית.

2. חכו ל-test לסיים

   ‏לוקח 10-30 שניות. ‏גוגל מוריד את העמוד, ‏מפענח את הסכמה, ‏ובודק אותה מול הדרישות.

3. בדקו את התוצאה

   ‏"Eligible for Job posting rich results" = מעולה, ‏המשרה תופיע ב-Google for Jobs. ‏"Not eligible" = יש שגיאות חמורות. ‏"Eligible with warnings" = תופיע אבל לא optimal.

4. תקנו warnings

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

השגיאות הנפוצות ב-Rich Results Test

• Missing field 'validThrough', ‏הוספתם datePosted אבל לא validThrough. ‏warning בלבד, ‏אבל אחרי 30 יום תיעלם המשרה.
• Invalid value for 'datePosted', ‏פורמט לא נכון. ‏חייב להיות ISO 8601 (YYYY-MM-DD).
• Invalid currency code, ‏השתמשתם ב-"שח" או "NIS" במקום "ILS". ‏גוגל לא מקבל.
• Missing 'value' for baseSalary, ‏הוספתם MonetaryAmount בלי QuantitativeValue. ‏צריך value או minValue+maxValue.
• jobLocation should not be present when jobLocationType is TELECOMMUTE without applicantLocationRequirements, ‏סתירה לוגית. ‏אם 100% remote, ‏השמיטו jobLocation.
• employmentType value not recognized, ‏השתמשתם בערך לא תקני (לדוגמה "משרה מלאה" או "full time" בקטנות).
• Description shorter than 50 characters, ‏description קצר מדי. ‏גוגל רוצה לפחות 200 מילים בפועל, ‏אבל זורק warning כבר ב-50 תווים.

בדיקה ב-Search Console

‏אחרי שה-schema הוטמע ו-validated, ‏ב-Google Search Console יש דוח ייעודי, ‏Enhancements > Job postings. ‏הוא מציג, ‏(1) ‏כמה משרות גוגל זיהתה, ‏(2) ‏כמה מהן eligible ל-rich results, ‏(3) ‏כמה errors יש, ‏(4) ‏אילו URLs ספציפיים בעייתיים. ‏בדקו את הדוח הזה אחת לשבוע. ‏אם יש errors חדשים אחרי הטמעה, ‏זה כנראה שינוי בקוד שלכם שבר את ה-schema.

📊 Indeed/LinkedIn vs your-site, ‏אפשר לדרג על אותה משרה בשני המקומות

‏אחד הדברים שמפתיע אנשי HR, ‏אפשר לדרג על אותה משרה גם ב-Indeed/LinkedIn וגם באתר הקריירה שלכם. ‏גוגל לא מעניש על duplication בין אתרים, ‏הוא רק מציג את הגרסה הטובה ביותר ב-Google for Jobs. ‏אם שתי הגרסאות (LinkedIn ו-שלכם) טובות, ‏גוגל יציג את שתיהן (לפעמים אחת בלבד, ‏אבל עם קישור ל-"Apply on more sites"). ‏זה אומר שיש לכם הזדמנות לתפוס את ה-job seeker גם דרך LinkedIn וגם דרך האתר שלכם, ‏מה ש-doubles את ה-exposure.

למה זה עובד אחרת מ-duplicate content רגיל

‏ב-SEO רגיל, ‏duplicate content בין שני אתרים הוא בעיה. ‏גוגל מסירה אחד מהם או מבזרת את ה-authority. ‏ב-JobPosting, ‏זה לא ככה. ‏גוגל מבין שזה נורמלי שאותה משרה תופיע ב-3-4 אתרים שונים (LinkedIn, ‏Indeed, ‏אתר החברה, ‏job board ייעודי). ‏זה לא duplicate, ‏זה syndication. ‏גוגל יציג את כולם, ‏ויאפשר ל-job seeker לבחור איפה להגיש מועמדות.

איך גוגל מחליטה איזו גרסה להציג ראשונה

‏גוגל יש לה אלגוריתם מורכב, ‏אבל הסיגנלים הראשיים, ‏(1) ‏איכות ה-schema (כמה properties יש, ‏האם הם מלאים, ‏האם validThrough תקין), ‏(2) ‏authority של הדומיין (אתר חברה גדולה ידורג גבוה ממיני job board), ‏(3) ‏freshness (משרה שפורסמה אתמול עדיפה על משרה שפורסמה לפני חודשיים, ‏גם אם זאת אותה משרה), ‏(4) ‏completeness (משרה עם baseSalary + benefits + skills מלאים מנצחת משרה עם רק title + description), ‏(5) ‏clicks היסטוריים (משרות שנקראות יותר בעבר עולות גבוה).

למה לפרסם גם באתר שלכם וגם ב-LinkedIn

• השליטה במידע, ‏ב-LinkedIn יש מגבלות פורמט, ‏מספר תווים, ‏ועיצוב. ‏באתר שלכם אתם שולטים ב-100%.
• ה-CTA יותר חזק, ‏ב-LinkedIn job seekers נשארים ב-LinkedIn ולא מבקרים באתר שלכם. ‏באתר שלכם הם רואים גם משרות אחרות, ‏גם תוכן על החברה, ‏גם blogposts. ‏זה משפיע על brand awareness.
• ה-applicant data שלכם, ‏ב-LinkedIn applicants עוברים דרך LinkedIn ויש להם פחות שליטה על ה-data שלכם. ‏באתר שלכם אתם אוספים את ה-data ישירות (ATS שלכם).
• SEO לטווח ארוך, ‏גם אם משרה מסוימת ממולאת, ‏העמוד שלכם נשאר ויכול לדרג על keywords ארוכי-זנב ("מפתח Backend ב-StreamFlow", ‏"קריירה ב-StreamFlow").

איך להבטיח שגוגל מציגה את שתיהן

‏הקפידו על schema זהה במידת האפשר בין שני האתרים. ‏אם ה-identifier זהה (אותו FE-2026-042 גם ב-LinkedIn וגם אצלכם), ‏גוגל יבין שזאת אותה משרה ויציג את שתי הגרסאות בקרוסלה. ‏אם identifier שונה, ‏גוגל יחשוב שזאת 2 משרות נפרדות ויציג אותן כאילו הן 2 משרות.

🚫 הטעויות הנפוצות (missing validThrough, ‏baseSalary בלי currency, ‏identifier חסר)

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

טעות 1, ‏missing validThrough

‏הכי שכיחה. ‏המקדם הטמיע את הסכמה עם datePosted אבל שכח את validThrough. ‏המשרה מופיעה ב-Google for Jobs לחודש, ‏ואז נעלמת. ‏אנשי HR לא מבינים מה קרה. ‏הם חושבים שזה באג של גוגל. ‏זה לא, ‏זאת מדיניות. ‏הוסיפו validThrough תמיד, ‏גם אם זה +90 יום מהיום.

טעות 2, ‏baseSalary בלי currency

‏המקדם הוסיף baseSalary עם value אבל שכח את currency. ‏גוגל מתעלם מה-schema לחלוטין (לא רק מה-salary), ‏ולא מציג eligibility ל-rich results. ‏currency חייב להיות ISO 4217, ‏ILS למשרות בישראל, ‏USD לבינלאומיות. ‏לעולם לא "שח".

טעות 3, ‏identifier חסר

‏המקדם לא הוסיף identifier. ‏זה לא error חמור (המשרה עדיין eligible), ‏אבל זה מונע tracking יעיל. ‏גוגל לא יודע לקשר את המשרה לגרסה אחרת שלה ב-LinkedIn/Indeed, ‏ולכן יציג אותן כ-2 משרות נפרדות במקום כקרוסלה אחת.

טעות 4, ‏datePosted בפורמט DD/MM/YYYY

‏מפתח ישראלי כותב את התאריך בפורמט "30/05/2026" כי זה הפורמט בעברית. ‏גוגל לא קולט. ‏ISO 8601 בלבד, ‏"2026-05-30".

טעות 5, ‏employmentType בעברית או בקטנות

‏"משרה מלאה" או "full_time" בקטנות. ‏גוגל מתעלם. ‏חייב להיות FULL_TIME עם underscore ובאותיות גדולות.

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

• jobLocation עם המשרד הראשי במשרה 100% remote
• jobLocationType="TELECOMMUTE" בלי applicantLocationRequirements
• currency code לא תקני ("NIS" במקום "ILS")
• description קצר מדי (פחות מ-200 מילים)
• description עם קישורים פעילים (גוגל מסירה אותם)
• hiringOrganization name לא תואם לשם החברה ב-GBP
• שכפול JobPosting schema באותו עמוד (גוגל סופר רק אחת)
• תאריכים בפורמט מקומי במקום ISO 8601
• baseSalary בלי unitText (MONTH/HOUR/YEAR)
• baseSalary value=25 במקום value=25000 (קיצור ל-25 אלף)

📅 Monthly audit checklist + bulk job site implementation

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

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

1. זיהוי ה-CMS/ATS שלכם

   ‏WordPress + WP Job Manager? ‏Drupal? ‏Greenhouse? ‏Workday? ‏Bullhorn? ‏בנייה מותאמת? ‏ה-CMS משפיע על איך מטמיעים.

2. יצירת template של JSON-LD

   ‏הגדירו template שאוסף מ-DB את כל ה-fields ופולט JSON-LD תקין. ‏השתמשו ב-helper libraries (jsonld-php, json-ld.js) כדי להבטיח escape תקין של תווי עברית.

3. הזרקה ל-<head> של כל עמוד משרה

   ‏ה-schema צריך להיות בתוך <script type="application/ld+json"> בתוך <head>. ‏לא ב-body, ‏לא ב-footer.

4. הגדרת default values

   ‏לכל field שאופציונלי, ‏הגדירו default ב-CMS. ‏לדוגמה employmentType="FULL_TIME" אם המפרסם לא בחר, ‏currency="ILS" תמיד.

5. הוספת validation בהגשה

   ‏בטופס יצירת משרה, ‏ולידציה ב-frontend ו-backend על השדות הקריטיים (title, ‏datePosted, ‏validThrough). ‏אל תאפשרו לפרסם משרה בלי validThrough.

6. בדיקה ב-Rich Results Test

   ‏לפני go-live, ‏בדקו 5-10 משרות לדוגמה ב-RRT. ‏וודאו 0 errors.

7. הוספת sitemap-jobs.xml

   ‏sitemap נפרד שמכיל רק URLs של משרות. ‏זה עוזר לגוגל לסרוק אותן מהר יותר.

8. הגשה ל-Search Console

   ‏הוסיפו את ה-sitemap-jobs.xml ל-GSC. ‏גוגל יתחיל לסרוק.

9. monitoring ב-GSC

   ‏אחרי 7-14 יום, ‏בדקו ב-Enhancements > Job postings. ‏שתי המשרות אמורות להופיע כ-Valid.

10. אוטומציה של validThrough

    ‏אם משרה ממולאת, ‏ה-ATS שלכם צריך לעדכן validThrough אוטומטית להיום. ‏אל תסמכו על אנשי HR לעשות את זה ידנית.

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

• בדיקת Search Console > Enhancements > Job postings, ‏ספירת errors
• בדיקת כמה משרות חדשות נוספו, ‏וכמה נמחקו
• בדיקה ידנית של 5 משרות אקראיות ב-Rich Results Test
• השוואה עם Google for Jobs בפועל, ‏חיפוש 3 משרות שלכם בגוגל, ‏וודאו שהן מופיעות
• בדיקת validThrough, ‏האם יש משרות שתפוגנה בקרוב? ‏אם כן, ‏האם הן עוד פעילות?
• בדיקת clicks ב-GSC ל-jobs queries, ‏האם ה-traffic עולה או יורד?
• סקר על משרות שנמחקו, ‏מהאתר ומ-Google for Jobs, ‏ניהול inventory
• בדיקה שאין JobPosting schema על עמודים שאינם משרות (לדוגמה עמוד קטגוריות)
• בדיקת שינויים בקוד שעלולים לשבור את ה-schema (אחרי כל deploy)
• בדיקת changelog של schema.org, ‏האם יש properties חדשים שכדאי להוסיף?

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