Every Team Touches the Site. No Team Owns It.
Ask most organizations who's responsible for their WordPress site and you'll get a confident answer, followed by a caveat that quietly undoes it. Marketing will say they own it — meaning the content, the campaigns, the copy. IT will say they're involved — meaning the network it sits behind, the email that runs alongside it, maybe the SSO integration. The agency that built it will say they're available — meaning for new project work, billed separately, not for watching the thing they built.
None of those answers is wrong. That's the actual problem. Three groups each own a real piece of the site, and the piece that's left over — is the core current, are plugins patched, do backups actually restore, is anyone watching for a compromise — belongs to whichever of them notices first that no one else is doing it. Usually, no one notices until it breaks.
Why IT Doesn't Naturally Pick This Up
Internal IT teams are typically structured and staffed around internal infrastructure: the network, endpoint devices, email, internal applications. A public-facing WordPress site with its own plugin ecosystem, its own update cadence, and its own attack surface is a different discipline, even though it's technical enough to feel like "an IT thing" by default. Most IT teams don't have anyone with deep WordPress-specific expertise, and even when they do, it competes for time against internal tickets that have a more immediate, visible cost when ignored. The website's maintenance quietly loses that competition, repeatedly, until it's badly behind.
Why Marketing Can't Actually Own It Either
Marketing teams are the ones who feel the site's importance most directly — it's their lead generation, their brand, their campaigns landing on it — which is why they're often the ones who get handed informal ownership of "the website." But owning the content and owning the underlying software are different jobs. A marketing team publishing blog posts and updating landing pages has no natural reason to also be tracking CVE disclosures for the fourteen plugins running underneath those pages, or verifying that last month's backup would actually restore if it needed to.
Why the Agency Relationship Usually Doesn't Cover This
Most web design and development agencies are structured around project work: design the site, build it, launch it, invoice it, move to the next client. Some offer a maintenance retainer afterward, but "maintenance" in that context often means content updates and small requests on an as-needed basis — not a defined operational responsibility with a monitoring cadence, an update schedule, and an incident-response commitment attached to it. The agency isn't being dishonest when it says it's "available." Available for requests is a genuinely different thing from accountable for uptime, security, and the state of the site between requests.
What the Gap Actually Costs
None of this shows up as a line item until it does. A plugin vulnerability sits unpatched for months because no one owns the decision to update it, especially if an update has broken something before and everyone's now cautious about touching it without a defined process. A backup exists, technically, but no one has verified it restores cleanly, so it's a false sense of coverage rather than real coverage. When the site does go down or get compromised — and eventually, unmanaged, it will — there's no established point of contact and no rehearsed process, so what should be a contained incident turns into hours or days of scrambling to figure out who can even get into the hosting account.
The cost isn't hypothetical. It's the incident response time multiplied by however long it takes to even identify who's supposed to be responding, plus whatever revenue, leads, or reputation the outage or breach cost while that was being sorted out.
Closing the Gap Doesn't Require a New Hire
The fix isn't asking IT or marketing to informally absorb more responsibility — that's the arrangement that created the gap in the first place. It's assigning the WordPress site to a party whose actual job is operating it: applying updates on a defined schedule after validating them, monitoring for security issues continuously rather than reactively, verifying backups actually work, and having a named, rehearsed incident-response process instead of a scramble. That's a specific operational function, distinct from both internal IT and internal marketing, and it doesn't require building an internal team to get it — it's exactly what managed WordPress operations exist to provide.
The test is simple: if your site went down or got compromised at 2 a.m. tonight, could you name, right now, the person or team who would notice first, own the response, and have the authority to act — without a chain of "let me check with" in between? If the honest answer is no, the accountability gap already exists, whether or not it's ever been named out loud.
