Candidates ask ChatGPT now. So we built NextPlace.

Most of what we build belongs to someone else. A client has a problem, we design and ship the thing that solves it, and our name sits quietly in the footer.

NextPlace is ours.

We built it because the same gap kept showing up between a job ad and the person it was written for, and nobody was closing it.

The gap nobody was closing

The job market is familiar ground for us. timebite is our own platform for students, where employers build branding profiles that get matched to people by what they study. Mechanical engineering students see technical employers. Law students see law firms.

Same problem, seen from the other end. Getting the right opening in front of the right person at the moment they are open to it.

We also watched how people started looking for work.

They stopped typing keywords into a search box. They started describing a situation to a language model. "I am a nurse in Innsbruck, I want to move to day shifts, what is out there." The answer comes back as a paragraph with a handful of concrete suggestions in it.

For an employer, that is either a channel or a blind spot. There is very little in between.

What an answer engine actually sees

Here is the part that surprises people.

Most job ads are effectively invisible to the systems answering those questions.

A typical career page is a JavaScript application. The listings load after the page does, the filters live in session state, and the job text often sits three clicks deep behind a widget that the applicant tracking system renders. A crawler that has to execute JavaScript and click through a filter to reach content is a crawler that gives up.

What gets read instead is the shell. A page title, a cookie banner, a promise that there are exciting opportunities.

Job boards solved this for Google fifteen years ago. Those optimisations assume a person who types keywords, scans ten blue links and clicks one. An answer engine works on different terms. It reads, it extracts facts, and it needs those facts unambiguous enough to repeat in a sentence without getting them wrong.

A salary buried as a range in a PDF does not survive that. A city written five different ways across five postings does not survive it either.

The six channels we publish into behave differently from each other too. Some crawl ahead of time and answer from an index. Some fetch a page live in the middle of a conversation. Some do both depending on how the question is phrased. A setup that only satisfies one of them covers a fraction of the traffic and looks like success on a dashboard.

Getting the jobs out of the ATS

The first problem was structural.

Recruiters work in an applicant tracking system, and they should keep working there. Any product that asks a recruiting team to maintain a second home for their jobs has already lost. So the requirement was simple. Connect once, then never think about it again.

Every ATS hands its jobs over differently. Some have a documented REST API. Some publish a feed that was built for job boards. Some push webhooks when a record changes. And some offer nothing at all beyond a career page.

We built a path for each of those, and every path ends in the same normalised job record. Nothing downstream ever learns where a job came from. That is what turns adding the next system into an integration task instead of a rebuild.

The career page fallback is the one that keeps us honest. An API tells you when a field is missing. A career page just renders differently one morning because someone changed a template, and the parser has to notice that something is off rather than confidently importing nonsense.

Closing a position in the ATS removes it from distribution within minutes. Nobody opens NextPlace to make that happen.

Preparing a job for a machine to read

Once a job is inside, it runs through the same pipeline every time.

It gets cleaned and structured, because raw ATS output is inconsistent in exactly the ways that break extraction. Marketing language, formatting leftovers, missing fields, a location spelled differently than it was last week.

It gets enriched with schema.org JobPosting metadata. Salary, location, working model, employment type, each stated in a form that leaves no room for interpretation.

And it gets extended with generated questions and answers, built around what candidates actually want to know about a role. This is the part that changed our thinking most. An answer engine is looking for a passage it can quote. Handing it one works better than hoping it assembles a decent summary on its own.

One rule sits above all of it. The pipeline never invents a fact the employer did not state. A generated answer that sounds helpful and turns out to be wrong costs a candidate an application and an employer their credibility, and it would be our fault. So the model works with what the posting contains, and where a posting says nothing, the output says nothing.

The result is published on pages built to be read by machines, with server-side rendering, agent-readable endpoints and explicit crawler handling.

Proving that any of it works

This turned out to be harder than the pipeline.

AI visibility has no ranking position to screenshot. There is no console that tells you where you place. A customer paying for visibility deserves more than an assurance that it is probably working.

So we built access logging that separates machine traffic from human traffic, per job. Every month a customer sees which system read which position and when. ChatGPT's crawler on the nursing role in Innsbruck, on the fourth, at eleven in the morning.

It is unglamorous data. It is also the only honest answer to the question of whether the thing does what it claims.

Where it stands today

NextPlace is in its pilot phase. The first customers are connected, their jobs sync out of their own systems without anyone changing a workflow, and the crawlers are reading them.

The stack is the one we reach for when reliability matters more than novelty. Laravel with Inertia and Vue, the same foundation under the large web applications we build for clients. Server-side rendering carries more weight here than anywhere else we have used it, for reasons that should be obvious by now.

Why we are telling you this

Building our own product changes how we work on yours.

We had to make the calls a client normally makes. What ships first, what waits, what is worth the complexity, what gets cut when the date holds and the scope does not. We ate every consequence of those decisions ourselves, which is a useful thing to have done before advising someone else on theirs.

If your jobs live in an ATS and you want to know whether anything out there can actually see them, NextPlace is live. The case study goes deeper into the technical side.

And if you are working on a product that needs the same treatment, we would like to hear about it. Pick a slot for a discovery call right here and we will find a time.

Frequently Asked Questions

Why are job ads invisible to ChatGPT and other AI search engines?

Most career pages are JavaScript applications. The listings load after the page does, the filters live in session state, and the job text often sits several clicks deep behind a widget rendered by the applicant tracking system. A crawler that has to execute JavaScript and click through a filter to reach the content usually gives up, so what gets read is the page shell rather than the job.

Which applicant tracking systems does NextPlace connect to?

eRecruiter, Personio, rexx, SmartRecruiters, softgarden, onlyfy, Sage and Infoniqa. Systems without a usable interface are covered by reading the career page directly, so a missing API is not a reason to stay out.

Does our recruiting team have to change how they work?

No. Recruiters keep working in their applicant tracking system, which stays the single source of truth. NextPlace connects once and syncs on its own after that. Closing a position in the ATS removes it from distribution within minutes, without anyone opening NextPlace.

Where do the jobs actually appear?

Across ChatGPT, Claude, Copilot, Gemini, Grok and Perplexity. Google visibility stays intact, because the pages are server-side rendered and carry schema.org JobPosting metadata that classic search engines read as well.

How do you measure whether AI systems really read our jobs?

Access logging separates machine traffic from human traffic for each individual position. Every month you see which system read which job and when. There is no ranking position to screenshot in AI search, so this log is the honest answer to the question.

What does the AI pipeline do with a job ad?

It cleans and structures the raw text, adds schema.org JobPosting metadata for salary, location, working model and employment type, and generates questions and answers around what candidates want to know about the role. The pipeline never invents a fact the employer did not state.