Skip to content

Security

Website hacked - what to do in the first hour

17 sierpnia 2026 5 min czytania Dariusz Niemczak

Website hacked - what to do in the first hour

Short answer: close the door first, clean up afterwards. In the first hour three things matter: make a full copy of the "after the break-in" state (it is both evidence and your starting point), change the passwords and log out every session, and only then start cleaning. Simply restoring last week's backup achieves nothing - if the hole is still open, the site will be taken over again, usually within a day.

How to tell it is a break-in

  • the site redirects to an unfamiliar address, sometimes only on a phone or only from Google results,
  • unfamiliar pages appear in search results (pharmaceuticals, casinos, Chinese characters) - check by typing site:yourdomain.pl into Google,
  • the browser shows a red warning screen, and Search Console has a "Security issues" section,
  • spam is going out from your domain and your mail starts landing in other people's junk folders,
  • the panel contains a new administrator account you never created,
  • your host has suspended the account or sent a notice about malicious files,
  • the site has suddenly slowed down for no reason (somebody is using your server for their own work).

One symptom is enough to take it seriously. Several at once is certainty.

The first hour - step by step

  1. Do not delete anything in a panic. A deleted file is a deleted trace; without it you cannot establish how somebody got in - and that is the only piece of information that protects you from a repeat.
  2. Make a full copy: files plus database. Exactly as it is now, infection included. It is your evidence and your safety net against a botched clean-up.
  3. Change passwords in this order: hosting panel → FTP/SFTP → database → every administrator account on the site. The site password alone is not enough if the intruder has file access.
  4. Log out every session and review the list of administrator accounts. Delete accounts you did not create - but write down their names and creation dates first.
  5. If the site is serving malicious code - switch on maintenance mode or take it down temporarily. An hour of downtime is cheaper than a week on Google's blocklist.
  6. Update the core and the plugins, especially after the 2026 vulnerabilities. I set them out in a separate article: in July two holes in WordPress itself gave remote code execution without logging in, on a clean installation.
  7. Tell your host. A good provider has access logs that show the entry - and can often point to the hour and the vulnerable file.

If at any step you feel this is out of your depth, write to me and touch nothing else. The worst clean-up is one that began with deleting half the files.

What not to do

  • Do not restore a backup and consider the matter closed. A backup reverses the effect, not the cause. If they came in through a vulnerable plugin, that plugin is in the backup too.
  • Do not change only the WordPress password. If the intruder has the files or the database, they are back in five minutes.
  • Do not ignore your email. The same login-password pair is often used on the mailbox too. Check the forwarding rules - a planted redirect is a classic that can sit there for months.
  • Do not delete the hosting account or the site to "start from scratch" before making a copy. Along with the infection you will throw out your content and your search rankings.
  • Do not leave it until the weekend. Google can flag a site as dangerous within hours, and removing that flag takes longer than earning it.

Where such break-ins usually come from

In practice it is almost always one of four routes:

  • an outdated plugin or theme - in 2025, 91 per cent of all vulnerabilities in the WordPress ecosystem were in plugins, and the median time from disclosure to first attack is five hours,
  • a weak or reused administrator password,
  • an outdated core,
  • a neighbour on the same server - on cheap shared hosting an infection can cross from one account to another.

None of these requires anyone to take a special interest in you. Bots scan the whole internet and take whatever is open.

What clean-up looks like with me

  1. Diagnosis - exactly what is infected and how they got in (logs, file modification dates, accounts).
  2. Closing the entry route - that is the actual repair; the rest is cosmetics.
  3. Cleaning - removing injected code, foreign accounts, scheduled tasks and redirects.
  4. Rebuilding trust - requesting a review in Search Console, verifying mail and domain reputation.
  5. Hardening - updates, two-factor login, backups kept off the server, fewer plugins.

Pricing is individual, because the extent of an infection varies, but the diagnosis is free and afterwards you know where you stand. If cleaning makes no sense (as happens with sites abandoned for years), I will say so plainly and quote the alternative.

How not to end up back here

Updates on a weekly rhythm, not an annual one. Fewer plugins. Backups that live elsewhere and that somebody has actually tested. Two-factor login. And an awareness that a company website is not furniture - it is a device plugged into the mains, and it needs servicing.

If you would rather not have to remember this, hand it to somebody who remembers professionally. And if you are thinking about changing technology so there is nothing to update - that is exactly how a NEO site works: no plugin layer, with fixes applied once for every client at the same time.

Frequently asked questions

Can a site be recovered without a backup? Usually yes - an infection rarely deletes content, more often it adds its own code. Harder and slower, but possible.

How long does a clean-up take? A simple infection: a few hours. A site with several thousand files and an old theme: a day or two, because everything has to be reviewed.

Will I get my Google rankings back? Usually yes, if you act quickly. The longer the site serves foreign content, the more there is to make up afterwards.

Shouldn't my host be watching for this? Your host watches the server, not your plugins. A firewall can deflect some attacks, but holes in code you installed yourself are on your side.

Write to me

Have the same problem?

Tell me in two sentences what is going on. I answer personally - and I say plainly whether it can be fixed, or whether another route works out cheaper.

Write to me