02 · Four failure modes
What actually goes wrong on recruitment sites.
The ATS sync drops under load
The integration is the first thing to go and the last thing anyone checks, because the site looks healthy.
FixWhat fixes it: getting bot and attack traffic off the server before it reaches the resource ceiling, and monitoring the integration itself rather than just site uptime. An uptime monitor pinging your homepage will report 100% availability throughout this entire failure.
Candidates cannot submit applications
The most expensive failure in recruitment, because it is silent from your side. Candidates hit an error, assume the site is broken, and leave. You never hear about it. What reaches you is a small fraction of what happened, reported second-hand through consultants.
The usual cause is caching. Application forms use one-time security tokens, and a cached page serves the same token to every visitor, so the form fails for real candidates while working perfectly when you test it logged in. On the client site above, this went from one or two reports every few months to six candidates over a single weekend after an infrastructure change. The fix required bypassing caching at two separate layers, one of which was not visible in the WordPress admin at all.
FixWhat fixes it: cache bypass rules on every application and registration path, at every caching layer.
Bot registrations and spam applications
Job boards are magnets for this. Open registration, open application forms and no purchase barrier, which makes them substantially more attractive to automated abuse than an ecommerce site. It arrives in waves rather than steadily, typically a burst every few weeks, and it fills your ATS with junk records that consultants then have to clear.
FixWhat fixes it: edge-level filtering before the request reaches your forms, with CAPTCHA held in reserve rather than deployed by default. CAPTCHA adds friction to a candidate journey you have spent money driving traffic to.
Nobody in the office can reach the site
The confusing one. External candidates browse the site normally. Your own staff cannot reach it, or cannot log in. This is usually not a website problem at all. It happens when an organization internal Active Directory domain shares a name with its public web domain, so office machines resolve the internal domain controllers instead of the website. It is a configuration decision made years ago, often before anyone currently in the building.
FixWhat fixes it: identifying it correctly, quickly, and escalating to the right party. The main cost is the days lost to everyone looking in the wrong place.
03 · What we do
Protect the integration, not just the site.
Integration
Treat the ATS connection as critical infrastructure
That means keeping the server off its resource ceiling, and defining sync failure as a critical incident even when the website is up.
Forms
Get application forms out of the cache
Every path where a candidate submits something, at every caching layer, verified from a logged-out session rather than from your admin account.
Traffic
Filter bots without blocking candidates or crawlers
Job listing pages depend on search visibility. Blanket bot protection catches Googlebot along with the scrapers, and on a job board that directly costs you applications.
How we approach it →Incidents
Write an incident plan that names the ATS
A generic severity scale does not help at 4pm when the site is up and the sync is down. The priority definitions have to say, explicitly, that a failed ATS connection is a critical incident.
What that looks like →Honesty
Deal with the third-party dependency openly
Some failures originate with the ATS platform or the connector plugin, not with your site. Our response time covers investigating and escalating. It cannot cover their fix time, and we put that in writing rather than discovering it together during an outage.
04 · Platforms
What we work with.
WordPress job boards integrated with major applicant tracking systems, including Bullhorn via the common WordPress connectors. Custom job board builds, membership and candidate account systems, and CV upload and application workflows.
If your recruitment site runs on WordPress and syncs with something, we can work with it. The underlying work is the same WordPress security service, scoped against a job board rather than a brochure site.
Everything here draws on our wider WordPress security work, delivered on an ongoing basis through maintenance.
Common questions
Our site is up. Why would we need this?+
Because the site is up and the business can operate are different measurements, and standard uptime monitoring only tells you the first. The failure mode that costs recruitment firms the most is one where the website reports perfect availability throughout.
Do you work with our ATS provider?+
We work alongside them. When a problem originates on their side we escalate and manage the conversation, which in practice means chasing. What we will not do is claim we can guarantee a fix time for a platform we do not control.
We already have an IT provider. Where do you fit?+
Different layer. Your IT provider handles the internal network, email, devices and directory services. We handle the public website and what it connects to. The two overlap in exactly one place, DNS, which is where the office access problem described above comes from. Having both parties able to talk to each other is what shortens that particular diagnosis from days to hours.
Can you help with GDPR and candidate data on the site?+
We can audit what your site is actually collecting, which is usually considerably more than anyone realizes: analytics, advertising pixels, session recording tools, tracking embedded through a tag manager, and third-party scripts loading on the exact pages where candidates submit CVs. We identify it, and we bring it under proper consent control. We do not draft privacy policies, that is legal drafting rather than technical work, and we will say so.
How fast can you start?+
For a site currently under attack or with applications failing, immediately. For planned work, typically one to two weeks from a signed scope.
Do you rebuild job boards or only support them?+
Both, though they are separate conversations. If the site is fundamentally sound and the problems are infrastructure, fix the infrastructure.
