Here is a position that will annoy plenty of people selling website tools: when your site gets hacked, the most useful question is not how did they get in. It is whose job is it to get me back online, and can I reach that person today. Everything else is a distraction until you can answer that one.
Plenty of advice about a hacked website jumps straight to malware, plugins, and passwords. That matters, and we will get to it. But it answers the wrong question first. A small business owner staring at a defaced homepage, or a site that visitors say their browser warned them away from, does not need a lecture on attack methods. They need to know who fixes it, how quickly, and whether that help is already included or arrives as a surprise bill.
Who is actually responsible for fixing a hacked website?
This is where the honest comparison lives, and it has nothing to do with scaring you. It comes down to a structural fact that does not change with the news: different ways of putting a business online put the responsibility for recovery in very different hands.
- A DIY site builder typically hands you the tools and the templates, but the account, the content, and the cleanup are largely yours to manage. Support may exist, yet the person who has to notice something is wrong and act on it is usually you.
- A freelancer who built it and moved on may or may not answer when you call much later. The site sits on your own domain, which is good, but the knowledge of how it was assembled can leave with them.
- A social page or marketplace listing is maintained by the platform, so a break-in at the platform level is their problem to solve, not yours. The tradeoff is that the page is part of their world: the brand the visitor sees is partly theirs, and little remains under your control if the account is suspended.
- A managed, human-maintained site puts a named team on the technical side, so the question who fixes this has an answer before anything goes wrong.
Notice that none of that is about who is smartest or who writes the best code. It is about where the responsibility lands at the moment you least want to be figuring it out.
Five things to establish before you touch a hacked site
Say you run a plumbing business and your site starts showing content you never put there, or a customer tells you their browser flagged it. The instinct is to start deleting things. Resist that. Run through these five points first, because acting blind can turn a recoverable problem into a bigger one. It is a short checklist, and every item is something you can check yourself.
- Confirm the change is on your real site, not a lookalike. Scam messages sometimes point to a copycat address. Check the exact domain in your browser before you assume your own site is affected.
- Find out who has administrative access. List every account that can log in and change the site, including old ones for people who have left. Unused accounts with weak passwords can be a common way in.
- Locate your most recent clean backup, and where it lives. A backup you can actually restore from is often the difference between a quick recovery and rebuilding from memory. If you cannot say where it is, that is your first real finding.
- Identify who controls the hosting side. Malware removal often has to happen at the server, not just inside the page editor. Know whether that is you, a host's support queue, or a maintainer you can reach.
- Write down what the site must actually do. Not just how it looks: whether your contact form is still delivering its submissions, whether bookings still go through, whether payment links still work. These are the things a hack can quietly break while the homepage looks fine.
Run those five and you will know, before you change anything, whether this is a problem you can handle or one you need to hand to someone.
But isn't a big platform safer than a small team?
This is the strongest argument against everything above, and it deserves a fair answer rather than a dismissal. A large DIY platform can pour resources into security that no small team could match, and it patches its own infrastructure on a scale an individual never will. That is genuinely an advantage, and pretending otherwise would be dishonest.
Here is the answer anyway. Platform-level security protects the platform. It does not pick up the phone when your specific site has a problem that falls on your side of the line: a weak password on your account, an outdated add-on you installed, content that needs cleaning up, a form that has stopped delivering. Security on these arrangements is usually shared. The platform guards the shared foundation, and the owner is left responsible for their own corner, whether or not anyone spelled that out. A skipped security update on your side can leave a known hole open no matter how well the platform defends itself.
The tradeoff nobody names: convenience means someone holds the keys
Honesty also means naming the cost of the managed approach, because there is one. A human team that can fix your site quickly can do so precisely because it holds administrative access to it. You are trusting people with the keys to your online presence. That is a real tradeoff, and anyone who tells you otherwise is selling.
The right question is not whether someone else holds access, because on almost any arrangement someone does, even if it is a faceless support system. The question is whether you know who holds it, whether they are accountable to you, and whether reaching them means a name and a conversation rather than a ticket in a queue. A managed relationship can concentrate that access in people you can identify. A DIY setup can scatter it across accounts you have half forgotten. Neither removes the risk. They just put it in different places, and one of those places is easier to reason about when something breaks.
A hack is a maintenance question you answer before it happens
Strip away the drama and a hacked website is a maintenance problem wearing an emergency's clothes. The businesses that recover well are rarely the ones with the cleverest defenses. They tend to be the ones who could already answer who fixes this on an ordinary day, because that answer does not appear out of nowhere the moment things go wrong. Decide who is responsible for the technical side of your site while everything is calm, and a break-in becomes a task for someone else instead of a crisis that lands entirely on you.