Nobody edited your website last month. It changed anyway.
The server it runs on took updates. The version of PHP behind it moved a release. Your host adjusted a caching rule. A certificate renewed itself. A browser shipped an update that handles one of your scripts a little differently than the version before it did.
None of that appears in any content history, because none of it happened to your content. It happened underneath your content.
That gap is where most website problems actually come from. Not from a bad build. From a good build sitting still while everything around it moves.
A Website Is a System,
Not a Document
Most people picture a website the way they picture a brochure. Designed once, printed, finished. The comparison is comfortable, and it is wrong in one specific way.
A brochure in a drawer is identical a year later. A website is not a file sitting still. It is a program running on a machine you do not own, talking to browsers you do not control, under standards that get revised on somebody else's schedule. Every one of those layers has its own release calendar. Your site inherits all of them.
What Actually Drifts
In practice, the things that change without anyone deciding to change them fall into four groups.
Platform behavior. Hosting companies update PHP versions, adjust caching, change default headers, and modify how files get served. These are usually improvements. They are still changes, and a site written against last year's behavior does not always survive them intact.
File state. Deployment tools have defaults, and the defaults are not always right. Some upload methods create files with permissions the server will then refuse to execute, which produces a blank error page and nothing at all in the error log. Working files get left behind after a fix. None of this is visible from the front of the site.
Standards. Accessibility guidance gets revised. Security headers that did not exist when a site launched become the expected baseline three years later. Search engines change what they reward, and what they quietly stop counting.
Inheritance. Sites that came from a previous platform or a previous developer carry things forward. Old administrative login pages, unused plugins, files that announce which version of what you are running. They sit there quietly until something scanning the internet finds them, and something is always scanning.
None of these are mistakes in the ordinary sense. They are entropy. A system left alone does not stay the way you left it. It drifts.
Why Most Sites Get Checked
Only After Something Breaks
Here is the uncomfortable arithmetic of this industry.
Checking one site properly, file by file, against a written standard, takes real hours. Checking thirty of them takes a week that no client is paying for. So most shops do the rational commercial thing and check when something breaks.
That model has an obvious flaw. By the time a problem announces itself, it has already been a problem for a while. A page throwing an error is the good case, because at least you find out. The expensive case is the quiet one: a contact form that stopped delivering mail six weeks ago, a page that slid out of accessibility conformance after a revision, an old file exposing something it should not.
Nobody reports those. You just stop hearing from people, and you never learn why.
Judgment Was Never the Bottleneck
Knowing what to look for has never been the hard part. Any competent developer can tell you that program files should not be left writable by the world, that backup copies do not belong in a public folder, that every form field needs a label, and that security headers should be set.
The hard part was volume. Opening every file on every site, comparing each one against a standard, and writing down what does not match is thousands of small, exacting, extremely boring comparisons. That is precisely the category of work that does not get done, in any industry, ever.
This is where the current generation of AI development tooling changes the math, and it is worth being specific about how.
Tools like Claude Code do not supply the judgment. The standard still has to be written by somebody who knows what correct looks like, and every finding still has to be evaluated by a person, because these tools state wrong things with the same confidence they state right ones. What the tooling removes is the volume constraint. An audit that used to be a week of tedium becomes an afternoon.
Once the cost of checking drops far enough, checking stops being a project you schedule and starts being something that simply runs.
That is the whole shift. Not smarter analysis. Cheaper repetition. Cheap repetition is what turns a good intention into an actual practice.
An Audit Needs Something
to Audit Against
A finding only means something relative to a rule. "This looks fine to me" is not an audit. It is an opinion.
So the first piece of this is a written standard. Ours covers four things: how a site is laid out on the server, how shared pieces like headers and footers are built, how design values are defined, and how a deployment is verified before it counts as finished.
That last one carries the most weight. Every deployment now sets file permissions, checks the syntax of every file it touches, scans the whole site for files the server would refuse to run, and confirms the affected page still returns a healthy response. If any of that fails, the deployment fails loudly instead of finishing quietly and leaving a page broken until a customer happens to find it.
The point is not vigilance. Vigilance fails, because people get tired and busy and distracted. The point is that correctness gets enforced by the process rather than remembered by a person.
The Cycle, in Four Steps
- A written standard that defines what correct means, so findings get measured against something instead of against a mood.
- Verification on every deployment, with no option to skip it on a day when you are in a hurry.
- A periodic sweep across every site, checked against that same standard.
- Findings written down, sorted by severity, and scheduled. Not fixed in a panic, and not quietly forgotten.
The fourth step matters more than it sounds. Most findings are not emergencies, and treating them as emergencies is how maintenance turns into chaos. A working list with severities attached is what lets a small shop look after a lot of sites without anything falling through the floor.
What This Means for Your Site
If we host and maintain your site, this is what you are actually paying for. Not disk space. A site that gets checked on a schedule against a written standard, with a record of what was found and what was done about it.
If your site lives somewhere else, the questions worth asking whoever looks after it are short ones:
- When was my site last checked, as opposed to last edited?
- What was it checked against?
- Can I see what was found?
If the answer to any of those is a pause, that itself is useful information. It does not mean something is wrong. It means nobody currently knows.
Not knowing is fine, right up until the moment it is not.
Wilson Digital Strategy builds, hosts, and maintains websites for small businesses, nonprofits, and municipalities across New Hampshire and beyond. If you are not sure when your site was last looked at properly, I am glad to run a review and send you a plain-language summary of what is solid, what is drifting, and what is worth doing something about. It costs nothing, it applies whether or not we built the site, and there is no jargon in the report.
