Recruitment & Job Automation for a traceable recruitment operations workflow.

It authenticates with a token generated in the site's admin area and writes through an authenticated API endpoint. Nothing is scraped or injected from the browser, and the token can be revoked at any time without redeploying the site. Keeping the importer on the desktop means fetching, parsing and model calls never run on the web host, so import batches cannot slow down the live site.

Because sources present the same information completely differently. A government portal, a scanned newspaper advertisement and an employer career page differ in where the closing date sits, how the pay scale is written, what counts as the description and whether a location is stated at all. A single universal parser produces malformed listings, which is exactly what gets a job board penalised. A per-source profile defines those rules once and stays isolated, so adding a new source cannot break existing ones.

Yes, and that is deliberate. The importer runs against your own OpenAI or Anthropic key so model spend sits on your account where you can see it, cap it per run and audit it. It also means you can change provider or model without waiting on a code change, and you are never billed through a reseller margin on tokens.

Matching happens in two stages. First on the source's own identifier, which catches re-imports of the same listing. Then on a normalised composite of job title, hiring organisation, location and closing date, which catches the same vacancy collected from two different sources. A match updates the existing page rather than creating a second one, so the site keeps a single canonical listing per vacancy.

Expired vacancies are refused at import and never published. Listings that expire after publication are transitioned so the page no longer presents an open vacancy with active markup. This is not optional housekeeping: Google's guidelines require expired postings to be removed, return 404 or 410, have their JobPosting markup removed, or carry a validThrough date in the past, and failing to act can result in a manual action against the site.

JobPosting JSON-LD with the five properties Google requires — title, description, datePosted, hiringOrganization and jobLocation — plus validThrough taken from the real closing date, employmentType, and baseSalary where the source actually states one. directApply is set to reflect whether the application genuinely completes on the page. Every value in the markup also appears visibly on the page, because markup describing content a visitor cannot see breaches the structured data policies.

Yes. Each imported listing creates or matches terms for hiring organisation, location, category, employment type and pay scale, and each of those gets its own archive page with a listing count. Those archives are usually where the searchable volume is — people search for jobs in a city or at a department far more often than for one specific vacancy — so they are treated as landing pages rather than as a by-product.

Every listing keeps the employer's official application URL or documented method and links to it clearly. The site's role is to make the vacancy findable and understandable, not to intercept the application. That is also what keeps directApply honest in the markup and what stops applicants reaching a dead end on a listing they found through search.

Yes. jobflowpk.com and hiringportalusa.com both run on WordPress because an editorial team maintains them, and the importer writes over the REST API. The pipeline itself is platform-independent — it needs an authenticated write endpoint and a content model, which a Next.js application with its own database provides equally well. Next.js is usually the better choice at higher volumes or where archive page speed and rendering control matter more than a familiar admin.

It is if the pages are thin or near-identical. Google's scaled content abuse policy targets pages generated at volume that add nothing for the reader — a title and an outbound link is exactly that. A complete listing with eligibility, positions, requirements, documents, closing date and the official application route is genuinely useful to someone searching for that vacancy. The gates matter here as much as the writing: no expired listings, no duplicates, and nothing published while incomplete.

Two components. Model usage scales with how many listings are written and how long each description is, and is visible directly on your own provider account. Hosting depends on the platform and traffic rather than the importer, since the heavy work happens on the desktop. The variable that moves cost most is import frequency, so run cadence and per-run caps are set deliberately rather than left open.

That source's extraction profile stops matching and its imports fail rather than publishing garbage — failing closed is the intended behaviour. The profile is then updated to the new layout, which is normally a small change confined to that one source. This is the main recurring maintenance cost of the system and should be budgeted rather than treated as a defect.