My website was fine yesterday
It worked yesterday and now it does not. Something quietly changed. Here is how to find what and put it back.
01 / What probably happened
Something changed even if you did not touch it
When a site is fine yesterday and broken today, the cause is almost always a small change somewhere in the stack: an automatic plugin update, an SSL renewal that did not complete, a DNS record overwritten by a provider, a PHP version bump on the host, or a third-party script that went down. The site itself is rarely the problem. Something it depends on changed, and it broke.
The fastest way to find the cause is to ask 'what is different about today compared to yesterday'. Hosting control panels, plugin update histories and DNS provider logs all answer this question in different places. We know where to look.
Resist the urge to start clicking 'reset' on things. The site is broken, but it is not gone. Random fixes usually make things harder to recover from. Diagnose first, act second.
02 / How to find what changed
The diagnostic checklist
Six places to look. The answer is almost always in one of them.
Ask the 'what changed' question
Did anyone update a plugin, change a theme, edit a page, switch hosting plans, change DNS, renew the domain, change the email setup, or install something new? Whatever changed yesterday is the prime suspect.
Check for automatic updates
Even if nobody touched the site, automatic updates may have applied themselves overnight. WordPress core, plugins and PHP versions update silently and break things silently. The hosting control panel usually shows recent automatic actions.
Look at the server logs
The error log tells you, in plain text, what failed and when. Most small business owners never look at it. We do, and the answer is normally on line one or line two.
Roll back to a recent backup
If a good backup exists from before the breakage, restoring it is usually faster than diagnosing the cause. We restore to a sandbox first to confirm it works, then promote it to live without losing today's enquiries.
Rule out the obvious external causes
An expired SSL certificate, a DNS change, a hosting outage, a Cloudflare incident, a payment provider change. Sometimes the site is fine and the thing in front of it broke.
Test the change in isolation
Once we suspect a specific update or edit, we revert just that thing in a copy of the site. If the site comes back, we know exactly what to fix permanently. No more guessing.
03 / How we handle it
Our diagnosis sequence
Triage
We ask one question: 'what was the last thing that changed?' Then we cross-reference the timing with hosting logs, automatic update history and DNS changes to nail the cause within the first hour.
Stabilise
If we have a known-good backup from before the breakage, we restore it to a staging copy and switch it over so the site is back online while we figure out the proper fix.
Fix
We do the real repair on the broken thing, whether that is a downgraded plugin, a corrected configuration file, a reverted theme or a rewritten template. Then we test that the original problem is actually gone.
Prevent
We add automatic snapshots before every update, monitoring that catches the next breakage in minutes, and a process where nothing changes silently. Next time, you hear from us before you notice.
FAQ
Common questions
Nobody touched the site. How can it have just broken?
Things break by themselves all the time: automatic plugin updates, expiring SSL certificates, hosting maintenance, PHP version bumps, DNS changes from upstream providers, third-party scripts going down. Sites are connected to so many moving parts that something quietly changing is the rule, not the exception.
Can you find out what broke without my logins?
Often yes for the diagnosis. We can tell from outside whether it is a DNS issue, a certificate issue, a server error or an application error. We only need access if you want us to actually do the repair.
Should I just restore yesterday's backup?
If you have a good backup from before the breakage and you have not taken important enquiries today that need preserving, yes, that is usually the fastest path. We can also restore to a copy first to confirm it actually works before swapping it over.
What if there are no backups?
Then we have to fix the live site in place, carefully. The first thing we do is take a snapshot of what is there now (so we cannot make it worse), then we start working backwards through the most likely causes.
How long does this kind of fix usually take?
Once the cause is identified, most fixes are under an hour. Identifying the cause is the variable bit. If the change history is clean, it can be ten minutes. If you have no logging at all, it can take half a day. Either way, the site is up on a holding page while we work.
How do I stop this happening every few months?
Stop relying on automatic updates running blind. On a managed plan we test updates in staging first, snapshot before applying, and roll back the moment something complains. The site does not 'just stop working' because we are watching it.
Want a site where nothing changes silently?
Managed hosting, supervised updates, snapshots before every change and real monitoring. From £79/month, this stops being a thing that happens to you.