Every client arrives with a problem they can name. The site is slow. They are not sure they are compliant. The developer who built it left, and nobody knows how anything works.
Those are the easy ones. The expensive problem is the one nobody has named yet.
Between what a team believes is true about its website and what is actually true, there is a gap. We call it the assumption gap: the distance between the state of a system as its owners describe it and the state of the system as it exists. It does not show up in a ticket queue, a status page, or a scope of work, because every one of those is written from the assumptions.
It shows up when someone asks the right question. Here is what that looked like on a real engagement.
A real example. A publishing client came to us because their email was bouncing. They had used the same business email provider for decades, so that provider was where everyone looked.
Our first question was simpler: which servers actually send your mail?
Not that provider. Outbound mail for both of their domains relayed through a different company's platform, and an email marketing service and a transactional mail service were sending on their behalf too. The SPF record did not authorize the relay. The relay signed DKIM with its own domain instead of the client's. DMARC failed, and Microsoft was rejecting their mail outright.
Nothing was wrong with the provider they were watching. The problem lived in the one nobody knew they were using. That is the assumption gap: the team was not wrong about their email provider. They were wrong about which systems their email depended on.
What they believed vs. what was sending
What "Website Maintenance" Actually Covers
"Website maintenance" sounds comprehensive. Read the contract.
The typical line says something like "ongoing maintenance and support of your web property." In practice that usually means uptime monitoring, plugin and core updates, and a support queue.
What it usually does not mean:
- Security hardening
- Access reviews
- Backup restore testing
- Performance work
- DNS and domain hygiene
- Certificate and email authentication checks
- Compliance validation (cookie consent, accessibility, privacy disclosures)
This is not a knock on whoever wrote the contract. They deliver what they promised. The problem is that the space between what is in scope and what the site actually needs belongs to nobody, and unowned space is where breaches, data leaks, and failed audits start.
Our maintenance does not leave that space unowned. Every item on that list is part of how we maintain a site, because a website that is up but unaudited is not being maintained. It is being watched.
Five Questions That Find the Gap
These are the questions that most reliably get silence on a first call. Each one takes minutes to answer if the answer is good, and days if it is not.
1. Who has admin access to your domain registrar and your DNS provider, and do they all still work with you?
The registrar controls who owns the domain. DNS controls where it points and where your email goes. They are often two different accounts with two different user lists, and whoever holds either one can take your site offline or redirect it with one change. If the honest answer is "I would have to check," that is the answer.
A good answer: a named list for each, reviewed in the last quarter, with company-owned accounts at both.
2. When did you last restore from a backup, and did it work?
A backup that is configured and a backup that has been restored are two different things. Backups fail silently: storage fills, credentials expire, a plugin update breaks the job. You find out the day you need one.
A good answer: a date, and a note of how long the restore took.
3. What happens if your developer is unreachable for two weeks?
If one person holds every password, every deploy step, and every piece of context, your website does not have a maintenance plan. It has a single point of failure with a name.
The same goes for licenses, and we have been on the wrong side of this one. A client's site ran a premium WordPress plugin licensed through our own agency subscription. When that subscription lapsed, the plugin kept running but could no longer be updated, and the first task was working out whose key the site was actually using. It was ours.
A good answer: credentials and license keys in a shared vault the company controls, and written deploy and recovery steps someone else has followed at least once.
4. What is every plugin, embed, and script on your site actually doing on each page load?
Small additions get treated as small. They are not always small.
A B2B software company's blog started throwing 504 errors. The logs were full of timezone warnings, which turned out to be harmless debug output that sent the first investigation in the wrong direction. The real cause was the newsletter signup form in the sidebar. It called the marketing platform's API live on every page render. Under traffic bursts, with the shared rate limit contended, pages waited up to 30 seconds for that form, blew past the 15-second hosting timeout, and failed. A signup box was taking down blog pages.
How a signup form took down the blog
A good answer: an inventory of every plugin and third-party script, with an owner and a reason for each.
5. When did a person last look at your hosting account, rather than an automated report about it?
Dashboards report what they were configured to report. They do not report the staging site nobody took down, the old FTP account, or the server running a PHP version that stopped getting security fixes.
On one client's documentation site, the WordPress REST API was publicly listing the site's user accounts: usernames anyone could collect and try passwords against. The site was up, and up is all an uptime dashboard measures.
A good answer: a person, a date, and a short list of what they checked.
If any one of these gets a shrug instead of an answer, you have found part of your assumption gap.
Four Patterns Behind the Gaps
The gaps are not random. Across engagements they cluster into four patterns.
Access rot. Accounts and permissions outlive the reasons they were granted. People leave, contractors finish, and their access stays, because removing it is nobody's job. Every stale account is a password someone else might already have.
The check: export every user list (CMS, hosting, registrar, DNS, analytics, forms) and ask of each name, "Would we grant this today?"
Unwritten rules. The site works because a few people know things nobody wrote down. A step you always do after another step. A setting you never touch. A "we will come back to that" that nobody came back to. The system runs, until someone new makes a reasonable change without knowing the rule.
On one site's CMS, creating a redirect did not remove the old URL from the sitemap. That only happened if an editor also unpublished the old page or marked it noindex by hand. Nothing enforced the pairing, nothing warned when it was skipped, and it was not written down anywhere. So redirected URLs kept going out in the sitemap, pointing search engines at addresses that only bounced them somewhere else.
The check: can someone rebuild the production environment, and run a normal week of publishing, from documentation alone? If not, the documentation is the project.
Silent failures. Backups that stopped running months ago. A certificate that expired overnight. A contact form that has been dropping submissions for a week. Nothing alerts, so nothing is wrong, until a customer tells you.
For another client, the bot protection in front of the site was blocking Google's ad crawler, and Google Ads was rejecting the landing page URLs. The site was up. The firewall was doing exactly what it was told. The ads were not getting approved. In the scans behind our robots.txt research, two sites returned HTTP 403 for robots.txt itself, and one had 106 URLs in its sitemap that its own robots.txt told crawlers not to read. None of it threw an error.
The check: for every automated job, confirm something alerts a person when it fails, and test that alert once.
Shadow IT. Marketing needed a landing page builder. Sales needed a CRM integration. Someone added a chat widget. Each one made sense at the time, and each one now loads code on your site, collects data, and sits outside whatever security and privacy review you have.
We see this every time we set up cookie consent. Before a consent banner can do its job, every third-party script on the site has to be found and put in a category: embeds, tag manager containers, API loaders, analytics. A consent tool can only block what it knows about, so the inventory is the real work, and it is rarely short.
The check: list every third-party script your pages load, and match each one to a contract and a privacy disclosure.
None of this is negligence. It is what a website looks like when the business around it is busy growing instead of auditing itself. It is also exactly what an attacker, an auditor, or a plaintiff's attorney looks for first.
How We Work
Every engagement starts with discovery: of the stack, and of what the team believes about it. The gaps sit wherever that belief has not been checked.
For each gap we find, we do three things:
- Name it. What it is, where it lives, what it exposes.
- Size the risk. What happens if it fails, and how likely that is.
- Help you decide. Fix it, monitor it, or accept it.
Accepting a risk is a legitimate decision when you make it on purpose. Accepting it because nobody told you it existed is not a decision.
Sometimes the check finds nothing, and that is still worth writing down. A membership association asked us whether anyone with their email domain could automatically get member access to their gated content. We checked the live configuration. The platform supported domain-wide access, but their group was set to a single exact address, so the answer was no. The deliverable was that answer and the exact settings path, so the next person could verify it without starting over.
What you get is a working website and a written record: which questions were asked, what the answers were, and what you decided to do about each one.
Common Questions
What does a website maintenance plan usually include?
Most plans cover uptime monitoring, software updates, and a support channel. Fewer include access reviews, backup restore tests, security hardening, or compliance checks. Read the scope for those specific items, and assume anything not written down is not included.
How often should we test restoring a backup?
We recommend at least once a quarter, and after any change to hosting, backup tooling, or site architecture. A restore test should end with a working copy of the site and a record of how long it took.
How do we find out who has access to our website?
Pull the user list from every system the site depends on: the CMS, the hosting account, the domain registrar and DNS provider, analytics, and any form or email tools. Compare each name against current staff and active vendors. Remove anyone you would not grant access to today.
Start With the Five Questions
Take the five questions above to your next team meeting. If every answer comes back specific (a name, a date, a list), you are in good shape. If they come back as silence, that silence is your first list of things to fix.
The problems you know about get fixed. The ones nobody asked about get discovered, and the only choice you get is who discovers them first.
If the answers raise more questions than they settle, talk to us. We will ask the rest.