Job listings have their own structured-data type, JobPosting, and getting it right puts your jobs into rich search results, which for a job board is oxygen. This post is the schema as the plugin renders it, the Search Console complaint that improved it, and the moment I refused to fill two fields, because the fabrication temptation in schema work deserves plain words.
Every job page prints a JobPosting block built from the post’s real meta:
$loc = jab_split_location(get_post_meta($id, '_jab_location', true)); // 'City, ST'
$schema = array(
'@context' => 'https://schema.org',
'@type' => 'JobPosting',
'title' => get_the_title($id),
'datePosted' => get_the_date('c', $id),
'validThrough' => get_post_meta($id, '_jab_close_date', true),
'employmentType' => get_post_meta($id, '_jab_jobtype', true),
'hiringOrganization' => array(
'@type' => 'Organization',
'name' => get_post_meta($id, '_jab_department', true),
),
'jobLocation' => array(
'@type' => 'Place',
'address' => array(
'@type' => 'PostalAddress',
'addressLocality' => $loc['city'],
'addressRegion' => $loc['state'],
'addressCountry' => 'US',
),
),
'baseSalary' => jab_salary_schema($id), // value + unitText from real pay data
);
The Search Console complaint that taught me most was about location, my first version put the whole City, State string into addressLocality, and Google wanted the parts separated, locality and region as their own properties. The fix is the jab_split_location helper, break City, ST on the comma into addressLocality and addressRegion, a small parser that moved the jobs from warnings to valid. Salary needed similar care, the earlier pay-period work, mapping the source’s PA, PH, PD, PW, BW, PM codes to real frequencies, feeds unitText here, so an hourly wage never masquerades as an annual salary in search results.
And the refusal, Search Console also suggested streetAddress and postalCode. USAJOBS does not provide them, federal postings are city-level, and the temptation is obvious, invent a plausible zip, silence the suggestion. The answer is no, twice over, schema describes reality and a fabricated address in a job posting is a lie told to machines about someone’s potential workplace, and these are suggestions, not requirements, valid schema with honest gaps outranks complete schema with invented facts everywhere it matters. The fields stay blank, and the jobs stay true.
A few things people ask me about this
Why does Search Console warn about my job locations? Composite strings in one property. Split City, State into addressLocality and addressRegion, warnings clear when the parts live in their own fields.
Must I fill every field Search Console suggests? No. Required properties matter, suggestions are optional enrichment. Fill them only from real data, and leave honest gaps where your source has none.
Next
Schema tells search what jobs are, but a board also has to prove its jobs are alive, expired listings and undiscovered pages kill trust and traffic alike. Freshness and the sitemap are the next post.