The careers page problem HR gets blamed for but doesn't control

Most people leaders can recite their time to hire, their cost per hire and their offer acceptance rate without looking anything up. Far fewer could tell you how many candidates clicked "apply" and never reached the end of the form.

The answer tends to be uncomfortable. Recruitment data provider Appcast has put the drop-off rate for candidates who start an application and never submit it at roughly 92 per cent, a figure reported by the Society for Human Resource Management. Some of that is healthy self-selection, people deciding partway through that the role isn't for them. A meaningful share of it is not. It's candidates who wanted the job, started the process, and hit something that didn't work.

When that happens, the conversation almost always turns to the application form. Too many fields. Too many screener questions. Indeed's own research has found that applications carrying 20 screener questions lose around 40 per cent of candidates. All true, all worth fixing, and all firmly within HR's control.

The part of the funnel HR doesn't own

What's rarely discussed is everything sitting underneath the form. The careers page, the job listing, the file upload, the confirmation screen. All of it runs on infrastructure that HR almost never chooses, rarely gets consulted about and often couldn't name if asked.

That matters more than it sounds. The moment someone in finance or operations sits down to pick a business hosting plan, they're making a decision about how your careers site behaves for the next three years. They're deciding how much traffic it can absorb before it slows down, how quickly pages load for someone on a phone in regional Australia, and how gracefully a large file upload is handled. Nobody frames it that way at the time. It's usually treated as a line item, weighed on cost and renewed without much thought.

Then a recruitment campaign goes out, and the consequences land on the people team.

What actually goes wrong

The failures here are rarely dramatic. A careers site doesn't usually crash outright. It degrades in ways that look like candidate disinterest.

A page takes six seconds to load instead of one, and a proportion of visitors leave before it renders. A resume upload times out on a mobile connection, and the candidate doesn't try a second time. A job ad gets shared widely on LinkedIn, traffic spikes to ten times normal, and the site slows to a crawl during precisely the window when interest peaked. A form submission fails silently, the candidate assumes it went through, and nobody follows up because nothing was recorded.

None of these show up in an ATS report. The candidate simply never appears. From the inside, it reads as a weak response to a well-written ad.

The mobile picture sharpens this further. Most job seekers now search and apply on phones, often on mobile data rather than a stable connection. A site that performs adequately on an office desktop can be genuinely unusable on a train. The gap between how HR tests the careers page and how candidates experience it is wide, and it's widening.

Why volume hiring makes it acute

Organisations that hire steadily and in small numbers may never notice any of this. The load is low, the traffic is flat, and the infrastructure copes.

The problems surface at the peaks. Graduate intake. Retail and hospitality recruitment before Christmas. A restructure that opens 40 roles at once. An employer brand campaign that lands. These are the moments when a careers site needs to hold up, and they're the moments when a shared, entry-level hosting arrangement is most likely to buckle.

They're also the moments with the highest stakes. Peak hiring windows are short, competitive and expensive to run. Losing a portion of your applicant pool to a slow server during a two-week graduate campaign isn't a technical inconvenience. It's a hiring outcome, and it will be measured as one.

The questions worth asking

People leaders don't need to become infrastructure specialists. They do need to ask a handful of questions of whoever manages the organisation's web presence, ideally before the next hiring peak rather than during it.

How does the careers page perform on a mobile connection? Not on the office wifi. Test it on a phone, on mobile data, at a realistic time of day.

What happens if traffic increases tenfold overnight? Someone should be able to answer this. If nobody can, that's the finding.

Are application submissions and file uploads monitored? A failed submission that nobody logs is a candidate who has vanished from the process without anyone knowing.

Where does the careers page sit relative to everything else? If it shares resources with a busy corporate site or an e-commerce store, a spike elsewhere in the business can degrade the hiring experience.

When is the hosting arrangement next up for review? This is the one that matters most, because it's the point where HR can actually influence the outcome.

Getting into the room

The broader issue is a structural one. Web infrastructure is usually procured by IT, finance or marketing, evaluated against their requirements, and renewed on a cycle nobody outside those functions tracks. HR inherits the result.

Changing that doesn't require a policy or a new committee. It requires the people function to raise its hand at renewal time with a specific, evidenced request: here is our hiring volume, here are our peak periods, here is what candidates experience on mobile today, and here is what we need the careers site to do.

That's a conversation most people teams have never had. It's also one of the few remaining places in the hiring funnel where a modest amount of attention produces a measurable return, because every candidate recovered from a technical drop-off is a candidate you've already paid to attract.

The applications you never received are still costing you. They're just not showing up in the report.

Want to see more stories from trusted news sources?
Make HR Leader a preferred news source on Google.