Website for recruiters: what it costs once vacancies come from your ATS

en 2026-09-20 6 min read

A recruitment website is step 03 at EUR 1.500 to 3.500 when vacancies are typed in by hand, and step 04 at EUR 3.500 to 7.500 as soon as they arrive from somewhere else. That single difference, whether a vacancy is written on your site or pulled from the system your consultants already work in, moves the project a whole step.

The reason is not the front end. Both look like a website with a list of jobs on it. The difference is that in one a vacancy is a page, and in the other it is a record arriving from a system we do not control.

A vacancy is data, not a page

Write one out and the point makes itself. A vacancy carries:

• job title
• location
• contract type, permanent, temporary or interim
• hours
• salary range
• sector or discipline
• your internal reference
• publication date
• closing date
• the consultant who owns it
• the application route
• the description itself

Twelve fields, and only the last one is prose. The other eleven are what a candidate filters on, what a search engine reads, and what decides whether the vacancy is still visible. A page has none of that structure. A record has all of it, which is why a recruitment site is a small database with a website on top.

It also changes hands constantly, created, edited, put on hold, filled and archived by consultants with no interest in a CMS. If your vacancies already live in an applicant tracking system, that system is the truth and the website must never be a second place to type them.

Typed by hand or fed from your ATS

What the integration actually involves

"We just pull the jobs from the ATS" hides four pieces of work, and this is where a step 04 budget goes.

Reading. Your ATS exposes an API, a feed, or nothing at all. An API needs credentials and ideally a sandbox; a feed we read on a schedule. If it is neither, that conversation belongs before the quote, because it changes the answer.

Mapping. Their field names are not your field names. Contract types come back as codes, locations as free text with three spellings of the same city, salary as two numbers, a string or nothing. Turning that into clean, filterable data is the unglamorous middle of the project, and what makes the filters work.

Syncing. New vacancies appear, existing ones change, filled ones vanish. The site has to handle all three without a person watching, and behave when the ATS is unreachable instead of showing an empty jobs page.

Writing back. An application submitted on the site should land in the ATS attached to the right vacancy, with the CV file, so the consultant sees it where they already look, rather than in a second inbox.

We build these in Next.js, which keeps the sync, the filtering and the structured data straightforward: Next.js development in Amsterdam covers the stack, design and engineering covers how the data model gets decided alongside the design.

Search engines read the fields, not the page

A vacancy page can carry JobPosting structured data, which is what allows a listing into Google's job results. It uses fields you already have: title, description, hiring organisation, location, employment type, posting date and a valid-through date. Two things matter more than the markup: the closing date has to be honest, and a filled vacancy has to come down or return a proper gone response. A list of roles that no longer exist loses candidates and search engines at the same speed.

The other search work is the pages that are not vacancies: sector and location pages, and pages about the roles you place. Those are what ongoing SEO growth at EUR 500 to 800 per month builds. The SEO foundation comes first, EUR 450 to 750 as a one-off: console and analytics, indexation, technical hygiene, titles, internal links and a plan for the following 3 to 6 months.

The application form is the whole funnel

Everything else is preamble. The form should take a CV as a file rather than demanding a retyped work history, say plainly what happens to the data, carry a consent checkbox you can stand behind, resist spam without a puzzle that loses real candidates, and confirm that the application arrived. On a phone, held in one hand.

Where step 05 starts

If employers will buy postings and you need billing, moderation and an admin view, you are commissioning a product rather than a website. That is step 05, from EUR 7.500, quoted after discovery. Payments belong at step 04 and above, never below.

Process and timeline

Step 03 runs 3 to 6 weeks, step 04 runs 6 to 12 weeks, and the extra time is integration rather than design.

1. Scoping, including which ATS you use and what it can give us. A fixed quote follows the scope, never precedes it.
2. Access: API credentials or the feed URL, in writing.
3. The data model first: fields, filters and URLs, agreed before anything is designed.
4. Design, on real vacancies pulled from your system rather than invented ones.
5. Build, sync, application flow and structured data, then launch with analytics and search console connected.

The part that waits on you is step two: getting API access out of an ATS vendor is the item to start the day you decide to go ahead.

When to spend less

If you place a small number of senior roles and none are advertised publicly, you do not need a jobs section at all. A search firm's site is a credibility document: who you are, what you place, who to call. That is step 02 at EUR 900 to 1.500 or step 03 at EUR 1.500 to 3.500, with nothing to keep in sync.

If your ATS already publishes a hosted careers page, point at it and spend nothing. The styling is limited, the URLs are not yours, and listings drawn by someone else's script do little for your site in search, but it works. Buy the integration when your vacancies are a reason people come to the site.

And if the choice is between the feed and a redesign, take the feed: a handsome site with a stale job list is worse than a plain one with an accurate list.

Questions recruiters ask

Our ATS has an embeddable jobs widget. Why not use that?

You can, and at step 03 it is a reasonable shortcut. The trade-offs are real: the listings sit in an iframe or are drawn by a script, so they are not pages on your domain, you cannot style or filter them your way, and the structured data belongs to the vendor. The step 04 integration makes those vacancies part of your site.

What if our ATS has no API?

Then we say so before you spend anything. Some systems publish a feed without a documented API, some enable access on request, and some offer neither, in which case the honest options are a CMS at step 03 with vacancies typed on the site, or a change of system. Scoping answers that.

Who owns the site and the candidate data?

You own the code, the repository and the database. Candidate data is yours and stays in systems you control. Hosting is agreed per project, decided with you rather than assumed.

If you know which ATS you use, one conversation places you on a step. Every price is on the packages page, and telling us what you place and where the vacancies live gets you a fixed quote against a written scope.