Job-Board Monitoring for Recruiting: Turn a Posting Into an Outreach Queue, Not a Copy of a Noticeboard

A job posting is evidence that one organisation was searching for someone on one date. It is not outreach. A useful recruiting monitor converts every posting into a single task with a named owner, a decision deadline and a recorded outcome, and merges repeat postings of the same role into that one task.

Why a copy of the job board is not a recruiting pipeline

A system that mirrors what has already been published creates a second interface to the same information. After a fortnight nobody opens it, because it never says what to do now or who is supposed to do it.

The difference is not the amount of information, it is its shape. A row on a board is a description of a state. A task is a closed question: do we approach this organisation, who approaches them, and by when is an answer due. When that conversion is skipped, the data stays correct and stops being useful, which is the hardest failure to notice because nothing breaks.

The working rule: every item that enters leaves in exactly one of two ways, as an open outreach task or as a closure with a stored reason. An item with neither is noise you paid to collect.

What does a job posting record actually contain?

Google's documentation for job posting structured data lists title, description, datePosted, hiringOrganization and jobLocation as required properties. Among the recommended ones are employmentType, baseSalary, identifier and validThrough, and the last of those is required when a posting has an expiration date. A site that marks up its jobs properly hands you those fields ready-made, with no free-text parsing.

One field changes how you build. For anonymous hiring - a staffing agency recruiting on behalf of an employer who is not named - the documentation instructs publishers to set hiringOrganization.name to the value confidential. So there is a documented, legitimate state in which the employer's name simply is not in the record, and your process has to handle it deliberately rather than treat it as a parsing bug.

What the record does not contain matters just as much:

• Who actually makes the decision, and which recruiter owns the role.
• Whether budget for the role was approved, or whether this is a market test.
• How many candidates are already in process, and at what stage.
• Whether the role was filled yesterday. The documentation tells publishers to remove a filled posting, but that is a convention, not enforcement.
• Whether the same role is running on two other channels at the same time.

What happens to a posting the moment it lands

1. Normalise the fields: hiring organisation, a canonical job title, city, posting date and expiry if present. Keep the original text alongside them, unchanged.
2. Compute a merge key from three parts: hiring organisation, normalised title and location. A posting that lands on an existing key joins the existing task and increments its repeat counter.
3. Assign one owner and a decision deadline. Without an owner the queue is addressed to "everyone", which means nobody.
4. Show the decision maker the minimum that supports a five-second answer: the organisation, the role, the posting date, the repeat count and the reason the item was selected.
5. Record the outcome as a closed value: approach opened, rejected with a reason, or deferred to a date. An outcome that lives in someone's head is not an outcome.

The step people skip sits between the second and the third: a check against the records you already hold. If the hiring organisation is already a client, a former client, or an approach declined two months ago, the item is not a new task but an update to an existing record, and its owner is whoever already runs that relationship. A cold approach to an organisation mid-negotiation with you is the most expensive damage a system like this can do, and one cross-reference prevents it.

Posting fields against what they actually prove

That table doubles as the expectations document for the recruiting team. A manager who has read the right-hand column stops asking the system for a certainty it does not have.

How do you tell the same role from a new one?

Three kinds of repetition, each needing different handling:

• The same role on two channels at once, the company site and an external board. The merge key catches this when the title normalisation is good.
• A weekly repost of the same role to push it back to the top of a list. Here the repeat counter is the useful signal, not the individual item.
• An agency posting for an anonymous employer alongside a direct posting by that same employer. No key merges those automatically, so it is a human ruling, recorded once and kept.

A role that reappears three times in a month is stronger information than one posted once, because it suggests the search has not closed. A process that merges without counting throws away exactly that signal.

What you measure to know the queue is alive

• Median time from ingesting a posting to the first decision on it.
• Number of tasks that expired without a decision, broken down by owner.
• Share of approaches that produced a conversation, broken down by the source of the posting.
• Item counts per source per run, so a source that stopped returning anything is visible.
• Number of wrong merges corrected by hand, as the quality measure for normalisation.
• How many of the roles you approached had already been filled at the moment of contact. That is the real freshness metric.

The ownership-and-deadline principle is the same one set out in lead follow-up ownership and response times, the reasons a source reader breaks silently are covered in why scrapers break and what maintenance includes, and the Israeli source landscape itself is in scraping Israeli job boards.

Sources

• Google Search Central - job posting structured data
• Schema.org - JobPosting