From Your ATS Into AI Search

Eight ATS, different ways in

Every applicant tracking system exports jobs differently. Some have a documented REST API. Some only publish an XML feed built for job boards. Some push webhooks. Some offer nothing beyond a career page. Building one clean pipeline on top of that variance was the core of the project.

The hardest parts we tackled:

• Different connection types, one data model: REST APIs, feeds, webhooks and career page crawling deliver different fields, different HTML quality and different update semantics. We normalise all of them into a single job record before anything else happens, so the enrichment pipeline never has to know where a job came from.
• Keeping the ATS in control: Recruiters work in their own system and should keep working there. A position closed in the ATS has to disappear from distribution within minutes, without anyone opening NextPlace. Polling intervals, webhook handling and crawl scheduling are tuned per connection type to make that hold.
• Writing for machines without writing worse for humans: Raw ATS text is inconsistent. Marketing copy, formatting leftovers, missing salary data, locations written five different ways. The pipeline has to produce something a language model can quote accurately while staying true to what the employer actually wrote.
• Proving that any of it works: AI visibility is hard to measure. There is no ranking position to screenshot. So we built access logging that separates machine traffic from human traffic per job, down to which crawler read which position and when.

Visibility in AI search, with no extra work for recruiters

The promise had to stay simple. Connect your ATS once, change nothing about how your team works, and your jobs become readable for the systems candidates now ask.

That put two requirements at the centre of the architecture. Setup had to be a one-time job measured in minutes. Everything after that had to run without a human in the loop.

Each position passes through the same pipeline. It gets cleaned and structured, enriched with schema.org JobPosting metadata covering salary, location and working model, and extended with generated questions and answers that mirror what candidates actually ask. The result is published on pages built to be read by machines, alongside agent-readable endpoints and explicit crawler handling, so answer engines get the facts in a form they can quote instead of guessing from rendered HTML.

We built NextPlace on Laravel with Inertia and Vue.js, the same foundation we use for large web applications. Server-side rendering carries more weight here than anywhere else, because a crawler that has to execute JavaScript is a crawler that will not see the job. Tailwind carries the UI, and sync and enrichment run through Laravel's queue system, so imports never block the interface.