When they call me, the problem is already eight months old

The phone calls almost all start the same way: the website isn't working anymore.

Sometimes it's literally true: the page won't open. More often it's something less dramatic and more annoying: requests sent through forms no longer arrive via email, a section has broken on mobile, the browser shows a security warning, a page that was bringing in inquiries has disappeared from search results. The question that comes is always the same: what happened today?

Almost always the answer is that nothing happened today. It happened months ago, one piece at a time, and no one was watching.

A website doesn't break, it degrades

A website is not a finished object. It's a collection of parts built by different people, and those parts continue to evolve on their own even when the site remains identical. The software that runs it releases new versions. The add-ons that manage forms, catalogs, translations, and the cookie banner get updated, or abandoned by those who wrote them. The server changes configuration. Browsers change rules, and things that worked for years stop appearing without anyone touching anything.

Then there's everything that simply expires. The certificate that secures the connection, and from one day to the next the site becomes a full-screen red warning for everyone. The domain, when the renewal notice arrives at an address that no longer exists.

The site, meanwhile, always looks the same. The symptoms, to be honest, are almost always there: warnings in the dashboard, errors logged by the server, rejected messages, certificates expiring with weeks of advance notice. Only they appear where no one ever looks, in panels that are never opened and in inboxes that are never read. The degradation isn't silent: it's unheard. Until it becomes a failure, and then everyone hears it.

Then one part stops talking to another, or worse, continues talking to it while misunderstanding: the form thanks you for the request and the request reaches no one. And on an ordinary day the site presents all at once everything that hasn't been done.

Website emails are where this happens most often and is least visible. Messages that a site generates stop arriving on their own with some regularity: they end up in spam, they're rejected by major email providers because they lack authenticity checks, which have become stricter in recent years, or they remain saved in the archive while the notification doesn't send. No one notices, because the symptom of a request that doesn't arrive is silence, and silence looks very much like a period with few requests.

Eight months of archived reports

The title of this article is not a figure of speech.

Some time ago a medical clinic contacted me: appointment requests coming from the site had become much fewer than before. Not zero, fewer. That's also why no alarm had been triggered.

The site was working. The page opened, the form filled out, and for some people the request went through without problems. For others, no: the submit button produced nothing.

The difference between the two groups was a choice made thirty seconds earlier, on the cookie banner. The form relied on an external check that verifies there's a person on the other end and not an automated program. That check had ended up among the profiling tools, and therefore was blocked for those who denied consent. Without it the form couldn't complete the submission. In practice, anyone who refused cookies couldn't book an appointment.

No one at the facility could notice by testing: those who work there had accepted consent months earlier, and for them the form always worked.

The reports, however, were there, and had been going on for eight months, since the new cookie banner had been activated. Someone calling to say they had written and received no response. Someone trying again from their phone. Each report, taken alone, seemed like an isolated case: someone who had the wrong address, someone who hadn't pressed the right button. They were archived one at a time, until there were too many to archive anymore.

The fix was quick: putting that check back in the right category, which in that case required a manually written setting, because the banner panel didn't allow changing the classification. But the point isn't the fix. It's that for months a healthcare facility lost appointment requests without knowing it was losing them, and that the symptom had existed all along, in the form of people who were saying so.

Three answers that seem like maintenance and aren't

When I ask a company who takes care of the site, three answers come back more than others. None of the three answers the question.

"We have hosting." Hosting is the house where the site lives. The provider is responsible for the house: that it stays standing, that it's reachable, that the wiring doesn't catch fire. What you've put inside, no. Something automatic exists, and it's a good thing: the software that runs the site automatically installs the most urgent security fixes, some components update themselves, several providers maintain monitoring that flags vulnerable parts. These are things to keep enabled. But they cover a narrow band: they don't touch what was custom-written for you, nor the paid components with expired licenses, nor those that no one maintains anymore. And above all, no automation watches the site afterward: the update that runs on its own at three in the morning and breaks the contact form is a classic. The point isn't who presses the button, it's who checks the result.

"We have backups." Having a backup is different from knowing how to go back. Someone needs to know which copy to take, that the copy is intact, and what gets lost by restoring it. You need to know where they are, because copies kept on the same server and same account as the site disappear along with everything else, and how far back you can go: fifteen or thirty days seem like a lot, until you discover the problem started four months earlier and all available copies already carry it inside. An archive of copies that no one has ever tried to reopen is a fire extinguisher that no one has ever checked, with the added problem that for the extinguisher the check is mandatory and for the backup it's not: you find out if it works only at the worst moment.

"The site is new: we redid it two years ago." Two years is a long time. And what starts from zero is only the count of what was redone: the domain, hosting, email accounts, external service accounts, old documents still downloadable, and old page addresses carry the previous age with them. A freshly redone site is not a reason to skip checks: it's the moment when the count restarts, not when the risk disappears.

The day it breaks

When I take over a site built by others, the first thing I ask isn't who developed it. It's this: if tomorrow morning it stops working, who responds? Often the question has no answer. Whoever built it closed the relationship at delivery, the person who had the passwords no longer works at the company, the current provider handles something else. The site exists, but it belongs to no one.

On the day of the failure the bill really comes due, because to the damage is added the time lost figuring out where to start.

Whoever intervenes must first discover where the site is located and who has the credentials. Then if a backup exists and from when. Then what has been installed over the years and by whom, if anyone has touched it recently and why. These are hours of reconstruction that no one had planned for, on a site that meanwhile is down.

And they almost always end with an unpleasant diagnosis. Getting it back up is possible, and with some work you can even reconstruct what was modified. What you can't establish is what was read or copied, and since when: no trace of that remains. And that's why you also can't say with certainty which backup copy is still clean, because if access was open for months, so are the copies.

The difference between a maintained site and an abandoned site isn't noticed on normal days. You see it exactly here: not in the fact that the failure doesn't happen, but in the fact that someone immediately knows where to look and how to go back.

When what ages isn't the technology

If what's inside the site has consequences outside the site, the problem changes nature.

A medical clinic has forms that collect appointment requests. These aren't just any data: if the form asks for the service or reason for the visit, you're collecting health information about people, which has stricter rules than a normal commercial contact. Who receives those requests today? Are they still the right addresses, or does the inbox of someone who retired last year continue to receive them without anyone reading them? That inbox, by the way, isn't just poor service: it's a company access that no one closed, for correspondence concerning someone's health. And has what the cookie banner blocks or allows through been reviewed recently? The map, video, chat, and pixels added in the last two years—did they end up in the right category, or do they load anyway before the person has chosen?

A training organization publishes calendars, announcements, and downloadable documents on the site. Can those documents actually be read, or are they photographs of a sheet of paper, where there's nothing to search, nothing to enlarge, and nothing a screen reader can pronounce? They were at delivery; then others were uploaded, by other people, without anyone checking.

A manufacturing company publishes technical sheets and certifications, and often they're the first thing a new customer looks at to decide if the supplier is reliable. Are they updated to the latest revision? And is the one from three years ago still downloadable? When an updated document is uploaded, almost always the previous file isn't replaced: it's placed alongside. It remains at its address, continues to appear in search results, and is still the link contained in emails and quotes from back then.

In all three cases, what ages silently isn't the site's appearance: it's the correctness of what's inside it. And this type of degradation isn't flagged by any automatic warning. A person going to look finds it.

The five questions

If you manage the site yourself or if it landed in your hands without you choosing it, these are the questions to ask whoever decides in the company. You don't need technical skills to ask them. They serve to understand if someone knows how to answer, and each ends with the same implicit request: show me.

1. In whose name are the domain and hosting registered, who has access today to the site and connected services (analytics, email, payments, consent manager), and what happens if that person doesn't respond?
2. When was the last check performed, what did it include, and where is it documented? Can we also see the previous one?
3. If tomorrow the site stops working, who do we call, how far back can we go, and when was the last time a restore was actually tested?
4. Is there a written list of what's installed on the site, what was custom-built for us, and who maintains it today? Can we see it?
5. What data does the site collect, beyond form data: who receives it, where does it remain, for how long, and who responds if someone asks to delete it?

Write them on a sheet of paper, bring them to the next meeting, and mark how many boxes remain empty.
If all the answers are there, the site is in good hands and this article wasn't needed.
If they're missing, it doesn't mean there's a problem today. It means that if there were, you wouldn't know.

This topic is also discussed in a six-minute conversation, generated with AI from this article.