Website Hacked? What to Do First, in the Right Order

A customer says your site "came up with a warning". Or Google emails you. Or you search your own business and find pages you never wrote, selling things you have never sold. You open the site and it looks completely normal, which is somehow worse, because now you cannot even see the thing everybody else can. The next hour matters, and the two moves that feel most obvious, deleting the strange page and restoring last night's backup, can leave whoever got in still holding the door. Google's own guidance is direct about it: fix the security issue that allowed the infection, or the site is likely to be reinfected.

The first useful thing is knowing that you may not be able to reproduce it, and that this proves nothing.

Google's Security issues report can identify hacked content, malware, unwanted software and social engineering, and it gives you a category, a detection date and sample addresses. Those samples can be incomplete, so the ones you can see are not necessarily all of them.

Browser warnings can also vary by context, which is why a home page that looks perfectly fine to you can be showing a warning to somebody else. A clean-looking site is not evidence of a clean site.

There are also several genuinely different incidents wearing one word. Spam pages injected to sell something have different implications from a compromised form, a membership area or a checkout. The first is a search and reputation problem. The second raises a question about information, and that question has its own rules.

What matters most in the first hour is not which one you have. It is not destroying the evidence that would tell you.

Ten minutes here changes the entire rest of the job, and it is the step people skip because it feels like doing nothing.

Screenshot the warning, wherever it appeared: the search result, the browser page, the email. Save the exact addresses affected, and the date and time you first saw it. Save what the customer told you, in their words.

Check Search Console and save what the Security issues report says, including the category and the sample addresses. Save any alerts from your platform or host.

Then write down, from memory and from your records, who has access to what. Everybody with an administrator account. Every agency or contractor, current and former. Every integration or plugin with credentials. That list is usually where the answer lives, and it is much harder to reconstruct after you have started resetting things.

Do not delete the strange pages yet. Do not restore a backup yet. Both destroy the trail, and the trail is what tells you whether it can happen again on Thursday.

The order below puts closing the route before cleaning, which is the opposite of instinct and the reason it works.

Contain the public harm. For a hosted brochure site that usually means putting the site into a maintenance state rather than anything dramatic. The corporate advice about taking equipment offline at the switch is written for an organisation with servers and forensics, and it does not describe somebody with a hosted site and a customer waiting.

Establish the scope. Which pages, which files, which accounts, and whether anything that handles customer information was touched. That last one changes what kind of incident this is.

Close the entry route. Reset the credentials for every account on that list, not just the obvious one. Update or remove whatever was out of date. Check for administrator accounts nobody created. If the route cannot be established, that is itself a finding and it changes how much you rebuild rather than clean.

Then clean. Remove the injected content and files, working from a known-good reference rather than by eye.

Restore carefully if you restore at all. A backup taken after the compromise is not a recovery point, and guidance on this is consistent: assess the integrity of backup data before restoring it. Work backwards to one that predates the earliest sign.

Ask Google for a review once the site is genuinely clean, through Search Console.

Rotate everything again afterwards, and check that the accounts list matches reality rather than history.

One thing not to do, specifically: Google says it does not recommend using its Removals tool to block the whole site as a way of taking it offline after a hack. The tool can temporarily hide hacker-created addresses, which is a different and narrower job.

The waiting is the part that makes owners panic and start changing things again, so it helps to know which delays are normal.

Google says a malware review takes a few days. A hacked-spam review may take up to several weeks. After a review is approved, warnings clear within a few days, with a possible extra day for systems to update.

That gap between "we fixed it" and "the internet agrees" is real, and it is not a sign the fix failed. What you can do during it is make sure the site stays clean, because a review that finds the problem still present resets the clock.

Everything before the review has no published duration, and that is honest rather than evasive: it depends on the platform, how much was changed, whether a known-good backup exists, how many accounts need rotating, and whether customer information is involved.

This is the failure mode worth understanding properly, because it is the difference between one bad week and four of them.

Deleting the visible pages removes the symptom. If the way in is still open, whoever used it puts the pages back, often within days, and now the site has a second Google review on its record.

The common routes are unglamorous. Reused or weak credentials on an administrator account. An out-of-date extension or plugin with a known flaw. An old account belonging to somebody who left. A contractor's access that outlived the contract. A compromised backup that reinstalls the problem the moment it is restored.

That last one deserves emphasis because it looks like the responsible move. Restoring the most recent backup is exactly what a careful person does, and if the compromise happened before that backup was taken, it restores the compromise along with everything else.

So, the discipline is: establish the route, close it, then clean. When the route genuinely cannot be established, the honest answer is to rebuild the site from known-good sources rather than to clean and hope, and anybody helping you should say so plainly rather than quoting for a clean.

There is no market rate for this, and any range presented as one is invented. One published example is worth seeing purely as a shape: a US WordPress malware cleanup service listing $250 per hour with a two-hour minimum, captured in 2026. That is one company's advertised price rather than a benchmark or a quote.

What actually moves the number is scope, and it is worth knowing so you can read a quote properly. Whether public harm has to be contained immediately. Whether a known-good backup exists. Whether the entry route can be established at all. Whether the site has custom code, a shop or member accounts. How many accounts and integrations need credentials rotated. Whether personal information may be exposed, which brings its own work. And how much validation is needed afterwards.

Ask any quote to separate investigation, cleanup, closing the route, and post-recovery checks. A quote that covers only the cleanup is quoting for the visible half, which is the half that comes back.

A useful amount of this needs no technical skill and makes everything afterwards faster.

Capture the evidence, as above. Write the access list. Find your backup dates. Check whether Search Console shows a security issue and save what it says. Confirm who holds the domain registration and the hosting account, because you will need both and now is a bad time to discover you do not have them.

Change your own passwords on the domain, hosting and platform accounts, using a unique password on each, and turn on multi-factor authentication where it is available. That is safe, useful, and reduces the chance of the route staying open through you.

Where to stop is narrower than usual and the reason is specific. Do not delete files or database entries by eye, because you can remove something the site needs and you destroy the evidence at the same time. Do not restore a backup until somebody has established which restore points predate the problem. Do not hand anybody the only administrator account, and do not share a password to let a contractor work. And do not tell customers anything about their information until you know what is actually true, because a correction afterwards is worse than a slightly later first message.

If access itself is the problem, because a former provider holds the accounts, that is a different job and it is covered in what to do when your web designer disappears.

A hacked website does not by itself establish that a data breach occurred, and treating the two as the same thing leads people into announcements they did not need to make and away from ones they did.

The question is whether sensitive personal information was actually acquired, and whether the information is of the kind the statute covers. Those are questions of fact and of law, which means this is a moment for qualified counsel rather than for an article, an insurer's checklist or a forum thread.

Where it does apply, Section 521.053 of the Texas Business and Commerce Code requires disclosure without unreasonable delay and no later than the 30th day after determining that the breach occurred, subject to the statute's own exceptions and to any law enforcement delay. Where at least 250 Texas residents are involved, the Attorney General must be notified electronically as soon as practicable and within the same 30 days, and the Attorney General's reporting page states the same threshold. The report has to cover the nature and circumstances, the number of Texas residents affected, the measures taken and intended, and whether law enforcement is investigating.

The practical consequence for the first hour is simply this: the date you determined a breach occurred matters, so write down when you knew what. That is another reason the capture step comes first.

Most of what makes a recovery painful is decided months earlier, and none of it is expensive.

Keep backups you have actually tested restoring, kept somewhere the site cannot reach, with enough history that a restore point predating a slow compromise still exists. A backup nobody has ever restored is a hope rather than a plan.

Keep the access list current, and treat it as a real document. Remove people when they leave. Remove contractors when the job ends. Give each person their own login rather than sharing one, so an account can be closed without changing everybody's password.

Keep the platform and its extensions updated, and remove the ones you stopped using, because an unused plugin is still running code.

Keep multi-factor authentication on the accounts that matter: domain, hosting, platform, email.

And know, before anything happens, who to call and what you would need to give them. Ten minutes writing that down is the cheapest insurance available here.

Can a hacked website be recovered?

Usually, yes. The part that decides whether it stays recovered is whether the entry route is found and closed, rather than how thoroughly the visible damage is removed.

My site looks fine to me. Is the warning wrong?

Probably not. Browser warnings can vary by context, and Google's sample list of affected addresses can be incomplete, so a clean-looking home page tells you very little.

Should I just restore a backup?

Only once you know which restore points predate the problem. A backup taken after the compromise is not a recovery point, and restoring it reinstalls the issue while erasing the evidence.

How long until the warning goes away?

After a successful review, warnings clear within a few days plus up to a day for systems to update. Getting to that point takes a few days for a malware review and up to several weeks for a hacked-spam review.

Do I have to tell my customers?

It depends on whether personal information was actually acquired and whether it is the kind the law covers. Where Texas notification applies, it runs to the 30th day after you determine a breach occurred, and at 250 Texas residents the Attorney General must be notified too. That is a question for a lawyer, not for a checklist.

How do I stop it happening again?

Close the route rather than the symptom, then keep tested backups, a current access list, updated software, and multi-factor authentication on the accounts that matter.

The instinct in the first hour is to make the visible problem disappear, and that instinct is what turns one incident into three. Capture what you can see, work out how they got in, close that, then clean, then ask for the review.

The waiting afterwards is real and normal. A few days for a malware review, potentially several weeks for hacked spam, then a few days for warnings to clear. Nothing about that gap means the fix failed.

If you are in the middle of this now, Arlington Website Designer works with businesses around Arlington, TX and the first thing we would ask for is the warning, the affected addresses and your access list rather than your card details. Send those through the contact page and you will get back what kind of incident it looks like, whether the route is findable, and whether this is a clean or a rebuild.