Woman outside a shop examining a damaged glass door

You open your site one morning and something is off. Maybe Google is showing a red warning, “this site may be hacked.” Maybe a customer calls to say they were sent off to some strange page. Or maybe you simply can’t get into the admin anymore.

The first feeling is panic. Understandable, but unnecessary. The vast majority of hacked sites recover fully. Speed matters, but the order matters more: contain the damage first, preserve the evidence, then clean the site properly.

This guide walks through that order calmly, for you as a business owner rather than a developer. What you do first, what you can do yourself, when to call someone, and what you actually have to report in Sweden.

The first hour: contain, don’t destroy

The first mistake people make is to start deleting files in a panic. Don’t. You risk destroying evidence, breaking the site, and still leaving behind whatever let the attacker in.

Do this instead, top to bottom:

  1. Put the site in maintenance mode or take it offline. This protects your visitors from malicious code and stops Google from repeatedly reading the hacked version. Use a maintenance plugin or ask your host for help.
  2. Take a copy of the site exactly as it is, infected and all. It sounds backwards, but that copy is your evidence and your way back if something goes wrong during cleanup.
  3. Contact your host. Ask for a scan, for the server logs (they often show how the attacker got in), and for the account to be isolated so nothing spreads to other sites.

And one rule worth framing: be wary of unsolicited messages from strangers claiming they spotted the hack and can fix it for a fee, and never pay them. That isn’t what help looks like.

Is the site actually hacked?

Sometimes it’s an ordinary fault, not a break-in. Here’s how to recognise a real hack:

  • Google or the browser warns visitors.
  • The site redirects to a foreign page, often only for logged-out visitors or those arriving from Google.
  • There are new admin accounts you didn’t create.
  • Strange text, pharma ads, or pop-ups appear.
  • There are unexpected .php files in the uploads folder.

A simple trick for telling a fault from a hack: an ordinary technical fault usually behaves consistently. A hack often behaves differently depending on the visitor, the device, the referrer, or whether someone is logged in. So test in an incognito window or from your phone. If two or more of the signs above match, treat it as a break-in.

Lock the attacker out

Before you clean up, you have to change the locks, or whoever got in will simply come back.

Change all passwords: WordPress admin, your host’s control panel, SFTP or SSH, the database, and the email accounts tied to password resets. One caution on the database password: only change it if you or your host can update wp-config.php at the same time, or the site will go down.

Then have someone rotate the security keys, the so-called “salts,” in the wp-config.php file. That invalidates every active login at once, so the attacker is kicked out too and forced to log in again. The step is part of WordPress’s own checklist for hacked sites, and it’s one of the most important.

The fork: restore a clean backup, or clean in place

Now you face a fork, and which path you take depends on whether you have a usable backup.

If you have a clean backup from before the break-in, that’s the easiest route. Often it’s a restore in a few clicks. But two things still hold: the copy must be from before the site was hacked, and you still have to change every password and update everything afterwards. Otherwise you just reopen the same hole.

If you have no clean backup, the site has to be cleaned in place. That means replacing WordPress core files, plugins, and theme with fresh versions from official sources, and removing the malicious code. The most-missed step here is the database. That’s where many hacks hide, and a cleanup that only touches the files often leaves the problem behind. The usual hiding places are the uploads folder, the .htaccess file, scheduled tasks, unknown admin users, and entries in the database such as settings and redirects.

Why hacked sites get hacked again

This is worth understanding, because it’s the most common reason people think they’re done and then find themselves back in the same spot a few days later.

A single scan or a “fix it with one click” plugin removes what you can see, but rarely the way in. What’s left is usually a backdoor, a hidden entrance the attacker put in place. It can sit in the database, or even at server level, entirely outside WordPress. The site can look clean for a day and then light up again.

So: scan with two different tools, ideally one server-side scan from your host and one security scan, rather than trusting only a plugin running inside the compromised site. Compare the results, and scan again after 24 hours. If the site keeps getting infected over and over, it’s a sign the original way in was never closed, and that’s the moment to bring in help.

Do it yourself, or call a pro?

You can get a long way on your own. But there’s a clear line for when you should hand it over.

This you can safely do yourself:

  • Put the site in maintenance mode
  • Take a backup
  • Change all passwords
  • Run scanners
  • Remove obviously fake admin accounts
  • Restore a clean backup if you have one
  • Request a review from Google

Call someone experienced when:

  • Customers’ personal or payment data may have leaked
  • Several sites on the same account are affected (the problem is often at server level then)
  • The site keeps getting reinfected
  • You’d need to edit core files or the database and aren’t comfortable with it
  • Every hour of downtime is costing real money

The first 72 hours: recover and report

Here’s something most Swedish guides skip. A hack isn’t just a technical cleanup. If it’s a webshop or a site with a contact form, it can also be something you have to report. This table puts both tracks together.

Time windowSave the siteReport and notify
Hour 0–1: containMaintenance mode, take a copy of the infected state, contact your host–
Hour 1–4: secureChange all passwords, rotate the salts in wp-config.php, check for fake adminsCould customer personal data be affected? Then the GDPR clock starts ticking
Hour 4–24: assessConfirm with two scans, choose backup or cleanupFile a police report for data intrusion (save evidence first). Call CERT-SE for advice if you like
Hour 24–72: clean and notifyCarry out the cleanup, reinstall from official sources, clean the database, harden the siteRequest a review from Google, complete any report to the data protection authority

A few words on the Swedish tracks:

Police report. A break-in on your site is dataintrång (data intrusion) under the Swedish Criminal Code (chapter 4, section 9 c), a crime in itself. Save evidence first, screenshots, files, server logs, and any suspicious accounts or redirects, because logs get harder to retrieve as time passes. Then report it to the police by calling 114 14 or visiting a police station.

CERT-SE is Sweden’s national support for IT incidents, reachable around the clock on 010-382 80 00 or [email protected]. Even if you have no legal duty to report, you can call and ask for advice.

GDPR and IMY. If personal data may have been accessed, altered, lost, or exposed, assess whether the breach creates a risk for the people affected. If it does, report it to the Swedish data protection authority (IMY) within 72 hours of becoming aware of it. If the risk is high, the affected customers may need to be informed too. We cover that part in more detail in a separate article.

NIS2 and Sweden’s Cybersecurity Act. You’ve probably seen the headlines about new reporting requirements. Some businesses now have stricter duties under Sweden’s Cybersecurity Act, in force since January 2026. But for an ordinary small-business website this generally does not apply. It applies to medium-sized and large organisations in 18 designated sectors, such as healthcare, energy, transport, finance and digital infrastructure. If your business is in one of those sectors, go through the Swedish National Cyber Security Centre’s overview of who is covered (in Swedish). The guidance used to sit with Myndigheten för civilt försvar (MCF).

Google’s warning. The red “may be hacked” flag in the search results doesn’t disappear on its own once the site is clean. You have to request a review through Google Search Console, under Security Issues. Describe what happened and what you fixed. According to Google’s own guidance, the review takes a few days for a site that had malware, and up to several weeks if it was hacked to show spam.

What it costs and how long it takes

Less than you’d think if you have a backup, more if you don’t.

With a clean, recent backup, a restore can be done in under an hour. Without a backup, where the site has to be cleaned file by file and the database gone through, it takes anywhere from a few hours to a couple of days depending on how deeply the code embedded itself.

What an agency charges for a cleanup varies a lot, and there are no independent price statistics to go by. The price almost always comes down to the same two things: whether there’s a clean backup, and how long the intrusion went unnoticed.

The cheapest way to handle a hack is to avoid it

Almost every hack has the same root cause, and it isn’t sophisticated attackers. It’s outdated software. Patchstack reported 11,334 new vulnerabilities in the WordPress ecosystem in 2025, with 91 percent of them in plugins. For the most heavily exploited holes, the median time from disclosure to the first attack was five hours. How to reduce that risk is covered in our guide to WordPress security for business owners.

That means the real difference isn’t in how skilfully you clean up after a hack, it’s in whether the site is kept updated before one happens. Tested backups, prompt updates, and a regular check now and then mean a hack either never occurs, or can be solved with a single restore.

That’s exactly what a maintenance plan does. It means tested backups, regular updates, and someone keeping an eye on the site, so a small issue gets caught before it becomes an emergency, all for a predictable monthly cost.

If it’s happening to you right now

Work through the table above row by row, and call your host before you delete anything. If you need help with the cleanup, we take over from there: we go through the files and database, close the way in, and request the review from Google once the site is clean.

If it hasn’t happened to you, the cheapest protection is a backup that can actually be restored. Automatic backups are part of our maintenance.


Last updated: October 2026. Advice, prices, and rules change over time, so check current figures where needed.