Job Expiration & validThrough for Loxo Listings

Every job page the plugin renders carries a validThrough date in its JobPosting structured data. That date tells Google when the opening stops being current. Get it wrong and Google either drops the listing early or keeps showing a role you filled months ago — and neither is visible from your site, because the date lives in the page source, not on the page.

This page explains where that date comes from, how to change it for one job, and what expiry does not do.

What expiration actually controls

Expiration feeds exactly one thing: the validThrough property in the JSON-LD JobPosting schema on the single job page.

It does not control visibility. An expired job stays published, stays in the jobs directory, keeps its URL, and still accepts applications. Nothing in the plugin filters listings by expiry date. This is the most common misunderstanding on this page, so it is worth stating plainly: the expiration date is an SEO signal, not a switch.

What does take a job off your site is its status in Loxo. When a sync sees a status other than Active or Open, the WordPress post is moved to pending and disappears from the front end. See Synchronizing Jobs.

Where the date comes from

Two sources, in this order:

The job’s own expiry date. If the job has one stored, it is used as-is. It gets there either from Loxo — the plugin copies Loxo’s published end date on every sync — or from you, by setting it in the admin Jobs list.
Publication date + Default job validity. Only used when the job has no expiry date of its own.

Default job validity (in days) lives under Loxo Jobs → Settings → SEO Settings (see Plugin Settings). It falls back to 180 days whenever the field is empty or not a number, so a fresh install behaves as 180 days even before you touch it.

The precedence matters more than it looks. Raising Default job validity changes nothing for any job that already carries a date from Loxo — the setting is only ever consulted for jobs that have none. If your Loxo records all have a published end date, this field is effectively inert.

Setting a date for one job

Go to Loxo Jobs in the admin.
Find the Expires column at the right of the job list.
Click the Change button next to the date to open the date picker. The date itself is read-only — the button is the way in.
Pick a date. It saves immediately, over the REST API; there is no separate save button.

The picker will not offer a date earlier than the job’s publication date. Because the save goes through the REST API it needs a user who can manage options — and it reports nothing back either way, so the date in the field is not by itself proof that the save landed. Reload the page to confirm.

One thing to know about that column: it is never blank. When a job has no stored expiry, the column shows the calculated fallback instead — publication date plus Default job validity. A date in the column therefore does not prove the job has a date of its own.

A hand-set date survives future syncs as long as Loxo has no published end date for that job. If Loxo does have one, the next sync overwrites your date with Loxo’s.

How this relates to Auto-Extend Expiry

Auto-Extend Expiry is a free add-on that keeps every eligible job’s expiry inside a rolling window — by default 90 days ahead — so validThrough never drifts into the past on jobs you are still hiring for.

Once it is enabled it owns the date, but it only rewrites dates that fall outside its window. A stored date closer than the renew threshold — 14 days by default — or further out than the interval of 90 days is reset to today plus the interval. A date between those two bounds is left alone, so a hand-set date 30 days out survives, until time carries it into the renew window and the next check moves it.

What it does do on every sync, whether or not the date changes, is discard the published end date arriving from Loxo and write the value it owns instead. So while the add-on is enabled, Loxo’s date no longer reaches the job. If you need one job left out of this entirely, the add-on has a per-job Do not auto-extend checkbox.

Troubleshooting

Symptom	Cause	Fix
Raised Default job validity, `validThrough` unchanged	The job already has its own expiry date from Loxo, so the setting is never consulted	Change the published end date in Loxo, set the date in the Expires column, or use Auto-Extend Expiry
Date set in the Expires column reverts after a sync	Loxo supplies a published end date for that job and the sync copies it over yours	Clear or correct the date in Loxo itself — that is the source of truth
Date set by hand keeps moving on its own	Auto-Extend Expiry is enabled and your date falls outside its window — under 14 days away, or more than 90 days out	Tick Do not auto-extend on that job, or turn the add-on off. A date between those bounds is left where you put it
Expired job still listed on the site	Expected — expiry only feeds schema	Change the job’s status in Loxo and re-sync
Clicking the Expires field does nothing	The field is read-only by design	Use the Change button beside it
Picked a new date, it reverts on reload	The REST save failed silently — usually a capability or security-plugin block	Sign in as an administrator and check the browser console for a rejected request to `loxo/v1/job-expiration`

FAQ

Does an expired job get deleted or hidden?

No. Nothing happens on your site at all. The date passes, validThrough becomes a past date, and Google stops treating the listing as current. The page itself is untouched.

Can I clear a job’s expiry date so it falls back to the default?

Not from the Expires column — the date picker can only set a date, not empty one. Clearing it means removing the job’s date_expires post meta directly, for example with WP-CLI.

What date format does the schema use?

YYYY-MM-DD, in UTC, whichever source the date came from.

Job Expiration