Why many salary pages underperform

How SwiftSchema helps

How it works

What is EstimatedSalary structured data?

EstimatedSalary pairs Occupation with a MonetaryAmountDistribution to express currency, unit (YEAR/HOUR/MONTH), and percentile values for salary estimates.

Essential elements

1. Occupation
   — includes
   name
   , optional
   description
   ,
   occupationLocation
   .
2. estimatedSalary
   — a
   MonetaryAmountDistribution
   with
   currency
   ,
   unitText
   , and percentiles (
   median
   ,
   percentile10/25/75/90
   ).
3. occupationLocation
   — Place or AdministrativeArea (city, state, country) explaining where the salary applies.
4. mainEntityOfPage
   — link to the canonical occupation page.
5. identifier
   /
   sameAs
   — include job codes (SOC, ONET) or external references.
6. datePublished
   /
   dateModified
   — optional; note when the salary estimate was last updated.
7. provider
   — optional; mention the data source (job board, internal survey).
8. description
   — explain methodology or scope.
9. inLanguage
   — add locale if you publish region-specific pages in multiple languages.

Content prep checklist

• Gather median and percentile data for each occupation (source: surveys, job board data).
• Decide on the geographic scope (country, state, city) and note it on the page.
• Specify whether salaries include benefits, bonuses, or base pay only.
• Provide context on methodology (“Based on 5,000 job postings from 2024”).
• Include disclaimers about variability and data freshness.
• Link to job postings, employer profiles, or related occupations for additional context.

Implementation workflow

1. Create or update the occupation page with the salary info, methodology, and location context.
2. Generate Occupation JSON‑LD with
   name
   ,
   description
   ,
   occupationLocation
   , and
   estimatedSalary
   .
3. Fill in MonetaryAmountDistribution with
   currency
   ,
   unitText
   ,
   median
   , and other percentiles.
4. Add metadata such as
   identifier
   ,
   sameAs
   ,
   provider
   , and
   mainEntityOfPage
   .
5. Embed the schema once per occupation page.
6. Validate using Rich Results Test; pay attention to warnings about missing median or invalid unitText.
7. Monitor Search Console for job/occupation enhancements if available.
8. Update cadence: refresh salary values and
   dateModified
   on a regular schedule (e.g., quarterly).

Location and currency considerations

• Use ISO currency codes (USD, EUR) and match the displayed currency.
• For multi-country pages, consider separate pages per region to avoid mixing currencies/rates.
• When listing multiple cities on one page, provide separate Occupation entries or clearly note differences in the content.
• Mention data sources when referencing aggregated platforms (e.g., “Based on SwiftSchema job postings”).
• If displaying different ranges by seniority (Junior/Mid/Senior), either create separate Occupation entries or make the ranges explicit in content; avoid mixing unrelated levels in one distribution.

Complementing JobPosting and Employer data

• Link to JobPosting schema for relevant listings; highlight salary ranges from real job postings when available.
• Pair with EmployerAggregateRating to provide employer reputation context.
• Use breadcrumbs and internal links so occupation pages feed traffic to related job listings or training courses.

Troubleshooting checklist

• Missing median: include
  median
  value; if unavailable, reconsider publishing.
• Wrong units: ensure
  unitText
  is uppercase (YEAR, HOUR, MONTH).
• Ambiguous region: add
  occupationLocation
  with Place/AdministrativeArea.
• Stale data: update
  dateModified
  and salary values regularly (quarterly recommended).
• Insufficient data: if sample size is small, mention it in the description to avoid misleading readers.
• Scale confusion: ensure currency and units match what’s shown on-page; don’t mix base pay with total compensation unless stated.

Common Errors & Fixes

• Missing median: include at least the median; add other percentiles when possible.
• Wrong units: use
  unitText
  in uppercase (YEAR/HOUR/MONTH).
• Ambiguous region: add
  occupationLocation
  to avoid misleading global values.
• Missing currency: always set
  currency
  on the MonetaryAmountDistribution.
• Hidden data: only include schema if the salary values are visible to users on the page.

On-page parity checklist

• Occupation name and description match on-page text.
• Salary figures and percentiles in schema match what’s displayed; currency and units are consistent.
• Region/location shown on-page matches
  occupationLocation
  .
• Methodology/source and last updated date on-page align with
  provider
  /
  dateModified
  .
• If multiple levels/regions are shown, schema reflects the same breakdown or separate entries.

Validation and QA

• Run Rich Results Test/Schema Validator after updates.
• Spot-check percentiles for numeric values and correct units/currency.
• Confirm
  mainEntityOfPage
  points to the canonical occupation URL.
• Review quarterly to refresh
  dateModified
  and values; keep a changelog of data sources.

Methodology and sourcing notes

• Document sample size, time window, and filters (e.g., “Based on 8,200 postings from Jan–Dec 2024; excludes internships”).
• Clarify whether values are base salary, base + bonus, or total compensation.
• If you blend datasets (e.g., internal + third-party), explain the weighting in on-page copy.
• Provide links to data dictionaries or SOC/ESCO codes when relevant to disambiguate the occupation.

Handling multiple segments

• If publishing salaries by seniority, location, or industry, create distinct Occupation entries per segment or clearly label each distribution on-page.
• Avoid mixing currencies in one distribution; split into region-specific blocks and schema.
• When ranges are narrow or volatile, add a confidence note (“Range reflects limited sample size”) to avoid misleading readers.

Automation and governance

• Drive both the UI and JSON‑LD from the same data source to prevent drift.
• Add automated checks to confirm currency/unit consistency and numeric types before deploy.
• Track when sources change (new vendors, new survey methods) and refresh
  dateModified
  + on-page notes simultaneously.

Localization and accessibility

• Use
  inLanguage
  on Occupation entries for localized pages and translate units/descriptions accordingly.
• Provide alt text for charts or salary tables; consider plain-text summaries for screen readers.
• If pages are country-specific, note labor market context (taxes, benefits norms) in the content.