A recruitment website needs a job search that matches on more than the exact job title, job pages complete enough to decide from, an application that finishes on a phone in two minutes, valid JobPosting markup so your roles reach Google's jobs results, a live two-way link to your ATS, and a content system your team can use without booking developer time. That is the working list. Vendor feature pages run to forty items because a long list closes deals, and a good portion of what sits on them will be switched off for the life of the site.
We have delivered 350+ recruitment projects since the business went recruitment-only over fifteen years ago. The pattern holds across almost all of them. The features that move applications and enquiries are few and unglamorous, and they are rarely the ones being sold hardest.
A recruitment website has two jobs
Candidates apply. Clients enquire. Every feature either serves one of those or it is decoration you are paying to host.
That sounds obvious until you put a feature list next to it. Count how many items on the list you were sent map to either job. On most vendor pages it is under half.
Candidate side: the features that move applications
Job search that finds jobs
The single most expensive failure on a recruitment website is a search that returns nothing. A candidate types "warehouse", gets zero results, and leaves. They do not try "warehouse operative", and they do not browse your other forty roles.
Two things cause it. The search matches the job title only and ignores the description, so "warehouse" never finds "Warehouse Operative (Nights)". And the location filter is keyed to a named town rather than a radius, so Pudsey returns nothing while Leeds returns everything.
What to insist on: full-text matching across title and description, location by radius with a distance the candidate can widen, filters that work with a thumb, and a fallback on every empty result offering nearby roles or a job alert. Never a dead end.
Job pages built to decide from
A title, a salary band and three lines pasted from the client brief is not enough for anybody to decide with. They leave to research, and mostly they do not come back.
A job page that converts covers what the work involves day to day, what the pay actually is, whether it is remote, hybrid or on site, what happens after they apply, and how long the process runs. That last one gets forgotten most often and candidates ask about it most.
This is a content feature as much as a technical one. The template has to have somewhere to put it, and somebody has to write it.
An application built for a phone
Every field costs you applications. An account, a password, a covering letter, availability, right-to-work questions and three referees, all before a human has spoken to them.
Ask for a name, contact details, a CV and the role. Your consultants can ask the rest on the call. If your ATS forces a long form, put a short one on the website and pass what you capture into the system, rather than sending candidates into the ATS interface.
We wrote about this in more detail in how to get more candidates from your website, including how to measure the drop-out before you change anything.
Speed and mobile, which are the same feature
Most candidates look for work on a phone, outside working hours, on mobile data, often mid-shift. A site that takes six seconds to load on 4G has lost people before the job search has rendered.
Speed is a consequence of how the site is built, and it cannot be added afterwards. A platform that loads three trackers, a chat widget, a slider and a cookie banner before the job list appears will be slow no matter what the sales page says. Test the vendor's existing client sites on your own phone, away from the office wifi, before you sign anything.
Getting your jobs in front of candidates
JobPosting structured data
Google surfaces roles directly in search results, and it takes them from JobPosting markup on your job pages. Get it right and your jobs appear where candidates are already looking. Get it wrong, or leave expired roles live, and the whole feed suffers.
This is not optional and it is not advanced. It is documented publicly by Google in its job posting structured data guidance. Ask any vendor to show you a live client job page passing the Rich Results Test. Plenty cannot.
Multiposting and job board distribution
Posting a role once and having it reach your website, the aggregators and the boards you pay for is a genuine time saving for a small team. Most agencies run this through their ATS or a distribution tool rather than the website, so the question to ask is which system owns it and whether the website is a source or a destination in that flow.
Job alerts
Worth having, easy to get wrong. An alert people can set in one field converts. An alert that requires an account, a sector, a salary band and a confirmation email will collect a handful of signups in a year.
Client side: the features that produce enquiries
Candidate features get all the attention, and then agencies wonder why the website produces no business development.
Case studies with numbers in them. Not logos. What the client needed, what you did, what changed, and over what period. A client-side visitor is looking for evidence you have solved their problem before, and a wall of logos is not evidence.
Sector and service pages that are pages, not menu items. If you place in engineering, there should be a page about placing in engineering, written properly, ranking for what those hiring managers search.
An enquiry path that is not the contact form. A hiring manager at 9pm is not filling in "How can we help?". Give them something worth their email address, or a way to book time directly.
Publishing without a developer. If putting a case study live means raising a ticket and waiting a week, no case study will ever go live. This is the feature that quietly determines whether the site improves after launch or decays.
Tracking that tells you which pages produce enquiries. Most recruitment sites cannot answer that question. Analytics with conversions configured properly is the cheapest feature on this list and the one most often skipped.
The integration question, and where it catches people
"ATS integration" on a feature list can mean two very different things.
One direction only: jobs flow from the ATS to the website. Almost everyone offers this.
Both directions: jobs flow out, and applications flow back into the ATS as records with the CV attached. This is the one that saves your team hours a week, and it is the one that involves the ATS vendor's API and sometimes their fees.
Ask which one you are being sold, ask which specific systems have been done before, and ask to speak to a client running that exact combination. "We integrate with all major ATS systems" is not an answer.
Features you will be sold and probably will not use
None of these are bad. They are just expensive to build, easy to demo and rarely used, and they turn up on nearly every feature list.
Candidate accounts and portals. They add a barrier at the moment somebody is willing to apply. Worth it in high-volume sectors where the same people apply repeatedly. Not worth it for most agencies.
Per-client microsites. Genuinely valuable if you run large contracts with named clients who want their own careers presence. Dead weight if you do not, and they are often the reason a build overruns.
On-site salary survey tools. Excellent lead magnets when someone owns the data and refreshes it. Embarrassing when the numbers are three years old and the page is still live.
Chatbots. A chatbot that answers "where is my application" is useful. One that opens with "Hi! Can I help you find a job?" over a page the candidate is already reading is a cost with a negative return.
CV parsing on the website. Attractive in a demo, fragile in practice, and it duplicates something the ATS already does properly.
Video on every page. One good video of your team explaining how you work will outperform a video header on every service page, and it costs a fraction as much to maintain.
The test for all of them is the same. Who on your team will own this in month four, and what will it change if nobody does?
How to test a feature list before you sign
Take whatever list you have been sent and put five questions against it.
- Which of these serve applications, and which serve enquiries? Anything that does neither is a cost.
- Show me this live on a client site. Not in a demo environment.
- Who edits this after launch, and does that person work here or there?
- What does this cost to keep running, including licences and any per-integration fee?
- What happens to it if the vendor relationship ends?
Question five is the one nobody asks. A feature that only works while you keep paying a specific platform is a rental. That matters more than any single item on the list.
What this means for the build
Pick the six features that serve your two jobs, get them properly right, and treat everything else as optional.
An agency with a fast site, a search that works, honest job pages, a two-minute application and valid job markup will out-perform one with forty features and a slow homepage. Every time, and it is not close.
If you are working out what your build should include and what it should cost, we set out both on our approach to recruitment website design and what a recruitment website costs.