Recruitment agency websites: job boards, CVs and client vacancies

Short answer: A recruitment agency website serves two very different visitors: candidates looking for a job, and employers looking to fill one. Feed the job board from your applicant tracking system (ATS) or recruitment CRM so jobs never go stale, give every job its own page on your domain, and make applying with a CV take under a minute on a phone. Then give clients their own path with sector pages, proof and a short vacancy form.

Two audiences, one site map

Home
Candidates
- Job search (feed from ATS/CRM), with one page per job
- Send your CV / register
- Job alerts
- Candidate advice
Employers
- Sectors and roles you recruit for
- How we work (process, timelines, terms in outline)
- Submit a vacancy
- Case studies and testimonials (real, with permission)
About / Team (consultants by sector, with direct contact)
Contact

The homepage splits the two paths immediately: a job search box for candidates, and "Hiring? Tell us about your vacancy" for clients. Trying to talk to both in one paragraph usually reaches neither.

Candidate side: features that matter

A job board fed from the ATS

Retyping jobs onto the website is how boards fill up with roles that closed weeks ago. Most recruitment systems publish jobs to your website in some way. JobAdder's help centre, as one example, lists four routes, each needing a different amount of developer work:

Route	What it is	Trade-off
Hosted careers page	A standard template with your logo and colours, linked from your site	Fastest, little customisation, lives on the vendor's web address
JavaScript widget	Code embedded on your page that displays your jobs	Quick, some layout control; check how search engines see the jobs
XML job feed	A file of job data sent to your site by FTP or HTTP post	Developer builds the board and search; full design control
API	Your developer reads jobs and posts applications directly	Most control and most work

JobAdder notes its hosted careers page updates every 15 minutes when jobs are added, edited or expired. Whatever system you use, ask the same question: when a consultant closes a job, how soon does it vanish from the website?

For search visibility, a feed or API that creates a real page per job on your own domain is usually stronger than a hosted page elsewhere or a widget that only renders in the browser.

Job pages candidates can act on

Each job page should show the title, location (or remote/hybrid), salary or rate where the client allows it, contract type, a proper description, the consultant's name and direct contact, and one obvious "Apply" button. Similar jobs at the bottom help candidates who aren't quite right for this one.

Applying and CV upload

Most candidates will apply on a phone. Keep the form to name, email, phone, CV upload and an optional note. Accept PDF and Word files, and let people upload from cloud storage as well as the device. Applications should land in the ATS against the right job, not in a shared inbox.

Add a general "Send us your CV" route for people who don't see the right job yet, tagged by sector so the right consultant sees it.

Job alerts

Let candidates subscribe to alerts by sector, location and keyword. It brings people back without them checking the site daily.

Client side: features that matter

Sector pages with real substance

One page per sector you genuinely recruit in, with the roles you typically fill, the consultants who cover it and, where you can, real placements described with permission. Generic "we recruit for all industries" pages give employers nothing to judge you on.

A vacancy form that saves a call

Ask for company, contact details, job title, location, salary range, start date, permanent or temporary, and a field to attach a job description. Send it straight to the relevant sector lead and confirm on screen who will call and when.

How you work

A plain description of your process: briefing call, shortlist timeline, interview arrangement, offer and follow-up. Describe your terms in outline and offer the full terms on request.

Job posting markup, briefly

Google's job posting documentation explains how structured data can make jobs eligible for its job search experience. A few points recruiters often miss, as of November 2026:

Required properties include datePosted, a full description, hiringOrganization, jobLocation and title.
If you're hiring on behalf of an unnamed client, Google says to use "confidential" as the hiring organisation's name.
Jobs that are no longer open must be expired: set validThrough in the past, remove the page (404 or 410), or remove the markup. Google warns that failing to expire jobs promptly may lead to a manual action.
Google recommends its Indexing API for job posting URLs because it prompts a faster crawl; the API can only be used for pages with JobPosting (or livestream) markup.

If your ATS feed creates the job pages, ask whether it outputs this markup and handles expiry automatically. That one question often decides between two otherwise similar systems.

FAQ

Should the job board be on our domain or the ATS provider's?

On your own domain where possible. Candidates stay on your site, and search engines credit your website for the job pages.

Can candidates apply without uploading a CV?

Offer it as an option. Some candidates apply from a phone without their CV to hand; a short profile now and a CV later keeps them in your pipeline.

How do we stop the board showing filled jobs?

Use a live feed or API from your ATS rather than manual posting, and check how often it syncs. Then make sure closed jobs are expired in their markup as well as hidden from the list.

Do we need separate sites for candidates and clients?

No. One site with two clearly separated paths is easier to maintain and builds one stronger domain.

If your job board still relies on someone copying roles across by hand, tell us which ATS or CRM you use and we'll outline the cleanest feed.