What to do when a client breaks their own website

It's 4:40pm on a Thursday. The message says something like "I think I've done something to the website" or, more often, "the website has gone weird". There's a screenshot, taken at an angle, on a phone.

Here's how to handle the next hour, and then the conversation that matters more.

First, lower the temperature

The client is embarrassed. Embarrassment makes people vague, and vague is the enemy of a fast fix. So the first reply is short, calm, and asks nothing accusatory:

No problem, I'll take a look now. Quick question so I can find it fast — roughly what time were you last in there, and what were you changing?

You're not asking what they did wrong. You're asking for a timestamp and a page. Those two things cut the search space enormously, and framing it as "so I can find it fast" gets you an honest answer instead of a defensive one.

Never open with "what did you do?". You'll get "nothing", and you'll waste twenty minutes.

Then triage, in this order

Is it down, or is it wrong? Completely different problems. Down means you're looking at hosting, DNS, certificates or a failed deployment. Wrong means content. Check the site yourself before you believe the screenshot — it's surprisingly often a caching artefact, a browser extension, or a page they were previewing rather than the live site.

Is it public? A broken draft is not an emergency. A broken homepage is. Decide which one you're in before you cancel your evening.

What changed most recently? Whatever your platform, go to the history — version history, revisions, deployment log, git. Recency is nearly always the culprit. If your platform records who changed what and when, this step takes a minute; if it doesn't, this is the moment you notice.

Restore, don't repair. If there's a previous good version, put it back first and understand it afterwards. Debugging on a live client site while the client watches is how a ten-minute problem becomes ninety. In Contentive that's restoring the document's previous version, or rolling back the deployment — the site is right again while you work out what happened.

Confirm with them, not to them. "It's back — can you check the page you were on?" They need to see it, not be told.

Then find out what actually happened

Once it's fixed, spend ten minutes on the cause, because the same thing will happen again to a different client otherwise.

The patterns repeat. Pasted from Word and brought the formatting with it. Uploaded a portrait photo into a landscape slot. Added a ninth job to an eight-slot careers grid. Deleted a page that something else linked to. Published a half-finished draft by clicking the obvious button. Changed a setting while looking for a different setting.

Notice what's common to all of those: the tool allowed it. None of them are carelessness. Every one is a person doing a reasonable thing in a tool that offered them a second, unreasonable thing at the same moment.

The conversation, a week later

Not the same day. On the day, the client feels bad and anything you say lands as blame, however you phrase it. Wait until it's cooled.

Then it's one message, and it's about the system rather than the person:

That thing last week wasn't your fault — the editor let you do something it shouldn't have. I'd like to change it so it can't happen again. Two options: I can restrict what's editable on that section, or we can rebuild the page so the layout isn't something anyone can change by accident. The second is a couple of hours.

You've done three things: removed the blame, named a cause, and put a price on a fix. That's a far better conversation than an apology, and clients almost always take one of the options.

Then make it not happen again

The prevention work sorts into three tiers.

Restrict. Narrow what the client can reach to the tasks they actually do. Most editing tools allow some version of this. It's a fence — imperfect, but it helps.

Record. Make sure every change is attributed and reversible. Version history on documents, a deployment log with rollback, and somewhere to see who did what. This doesn't prevent anything; it turns a two-hour investigation into a two-minute one.

Remove. Build so the mistake isn't available. If the client's editor is generated from a content model that has five rows in the price list, there is no sixth row to add. If they can't set a type size, they can't set the wrong one. This is the only tier that actually ends the category, and it's the one Contentive is designed around.

The thing worth remembering

A client breaking their site isn't a client problem. It's a design problem, and it's yours — you chose the tool and you handed it over.

Fix it fast, don't make them feel stupid, and then change the system so the same afternoon doesn't happen again in March.