A phone call on a Thursday evening: "Szymon, something's going on. The site froze, and now it's showing text I've never seen before."

Panic in that situation is natural, and it's the worst possible advisor. If you know the order to do things in, the site can be back to normal within hours — and, more importantly, it stops harming your visitors and your position in search.

I've been working with businesses for over ten years and I've seen more injected code than I'd care to. Here is exactly what to do in the first minutes after you find out, and in the days that follow.

Before you start

A compromise almost never means the end of a business. It means a few hours of unpleasant work. Hundreds of thousands of sites are taken over every year, and the large majority come back.

Take a breath and sit down. You're about to make decisions where rushing costs more than waiting.

Step 1: Confirm It's Really a Hack (3-5 minutes)

Sometimes it looks like a hack, but it's a bug, hosting problem, or something completely different.

What to do:

  1. Open the site in incognito/private browser window (to avoid cache)
  2. Check if problem shows on all devices (computer, phone)
  3. Check hosting access logs (if you have access to panel)
  4. Ask someone else to look at the site (might be local issue, might be your computer)

Signs that it's really a hack:

  • Site shows foreign content (ads, political posts, crypto scam, anything not yours)
  • Site is completely changed
  • Google alerts you that site contains malware (check: Google Search Console)
  • Messages from customers "What happened to your site?"
  • Unexpected emails from your host or your backup system

If you confirm it's a hack—move to step 2.

Step 2: Close Access—Right Now, Immediately (5 minutes)

Every minute an infected site stays reachable is a risk to your visitors — and a signal to Google that the site is unsafe. The second one takes weeks to undo.

Do this now:

  1. Disable database access or shut down the site completely. If you have hosting panel access (cPanel, Plesk), disable the site. If it's WordPress, change the .htaccess file and put 403 Forbidden on the entire site. If you can't — go to step 3.
  2. If you can't shut down the entire site — at least disable the admin panel (/wp-admin for WordPress). Add a rule to .htaccess that blocks access to the wp-admin directory for everyone (Order allow,deny / Deny from all).
  3. If possible, change all passwords. Password to hosting panel, password to FTP, password to WordPress, password to email connected to the site. Everything.

Why now? Because whoever got in most likely holds one of your passwords. While they do, they can keep coming back — and they can leave themselves a way in that survives the removal of the malicious code itself.

Step 3: Contact Your Hosting Provider (10-15 minutes)

Call. Don't email. Phone. Immediately.

Say:

  • Your site was hacked
  • You want to temporarily shut down the site or entire account (so hacker can't continue)
  • Can they check access logs (to find how they got in)
  • Can they restore a backup from before the hack

Hosting—if decent—has backups. That's your safety net. If you have a backup from 24 hours ago, you can restore the site to state before attack.

Questions worth asking:

  • When was the last backup made?
  • Can they identify from what IP/country the attack came?
  • Does the site have malware?
  • Can I temporarily shut down the site?

Good hosting will cooperate. Bad hosting will say "sorry, I don't see a problem"—if that happens, find new hosting, but now focus on rescue.

Step 4: Make Full Backup of Current State (if you can) (15-30 minutes)

Paradoxically—even though site is hacked, you want a backup of this state. Why? So a developer (me, or someone else) can examine it and find exactly what the hacker did. Helps in future.

How to backup hacked site:

  1. SSH to server (if you have access) and use scp command to copy all files
  2. Or log in via FTP and download all files locally
  3. Download database (phpMyAdmin → Export)

Keep this backup on safe disk. It's evidence. It's what a developer will need.

Step 5: Restore from Backup OR Clean (1-4 hours)

You have two paths here.

Path A: Restore from clean backup (preferred)

If hosting has backup from 24-48 hours ago—tell them to restore it. This is the simplest way.

Gain: site returns to normal quickly.

Risk: if backup has wrong data (e.g. you changed product prices yesterday, backup is from day before)—you lose changes. So restoring backup is always a business decision—what hurts more, that a hacker controls the site or that you lose 24 hours of data?

Path B: Manual cleaning (time-consuming, but precise)

If you don't have a backup, or prefer not to restore—you must manually find and remove malware. This is work for a developer.

Signs where to look:

  • Recently modified files (check timestamp in FTP)
  • PHP files in places where PHP shouldn't be (media folder, etc)
  • Weird files (shell.php, backdoor.php, x7x.php)—definitely a hack
  • In source code—eval(), base64_decode(), assert()—common malware hiding techniques
  • Theme files (in WordPress)—hacker modifies them

If you can't do this—time to call developer. Don't risk it. Cleaning can be difficult—if you mess something up, site becomes more broken.

In WordPress—special steps:

  1. Install plugin like Wordfence or Sucuri—they scan for malware
  2. Change all passwords (WordPress admin, database, FTP)
  3. Delete all old plugins and themes
  4. Update WordPress to latest version
  5. Remove unused plugins

Step 6: Change ALL Passwords (10 minutes)

This is the solution everyone skips. Don't skip it.

What to change:

  • WordPress admin password
  • Database password
  • FTP/SFTP password
  • Email connected to the site password
  • Hosting panel password
  • Domain password (whois contact email)

The hacker who hacked your site probably has at least one password. New passwords should be:

  • Minimum 16 characters
  • Mix of uppercase, lowercase, numbers, symbols
  • Not "qwerty123" or other common patterns
  • Stored in password manager (LastPass, 1Password)

Step 7: Notify Google (24 hours)

Once the site is clean and running again:

  1. Google Search Console → Security & Manual Actions → Security Issues. Mark the problem as fixed and request a review.
  2. Google Safe Browsing → Report form. State that the site no longer serves malware.
  3. If customers were affected — phishing sent through your site, or form data exposed — tell them. If personal data was involved, check whether you are required to notify your data protection authority; under GDPR that window is 72 hours.

Google takes time to trust the site is clean. Sometimes days. Sometimes a week. Be patient.

Step 8: Learn How It Happened (next day)

After the site is restored, analyze what happened.

Questions to ask:

  • What plugin/theme was vulnerable?
  • Were there old versions of software?
  • Were passwords weak?
  • Was backup being made regularly?
  • Were security updates regular?

If it's WordPress—check which plugins were recently updated. Hackers attack old plugins that aren't patched.

Step 9: Security for the Future (this hour if possible)

Now that the site is secure—you don't want this to happen again.

The minimum:

  1. A security plugin, if you are on WordPress: Wordfence, Sucuri, iThemes Security
  2. Regular backups — daily, weekly at worst. Stored somewhere other than the site's own server: cloud storage, S3, anything separate.
  3. Regular updates — plugins, themes, the CMS itself. On a fixed rhythm, rather than whenever you remember.
  4. Strong passwords—for every account. Password manager.
  5. Two-factor authentication—for WordPress, FTP, hosting.

If you run something more critical (e-commerce, customer data):

  • Web Application Firewall (WAF)—Cloudflare, Sucuri, Wordfence
  • Regular security audits (once a year)
  • SSL certificate (https)—should always be there
  • Dependency updates, if the site is custom-built

My Experience-Based Advice

Everyone who runs a website should be prepared for a hack. It's not if, it's when.

So:

  1. Have regular backup. Off-site. Not on same server as site. If server burns, backup burns with it.
  2. Update everything. Plugins, themes, operating system, libraries. Don't ignore updates because "the site might change". Updates contain security patches.
  3. Use strong passwords. And don't reuse passwords between services.
  4. If your site touches money — payments, card data — treat security as a line item, not an afterthought. A firewall in front of it, and audits on a schedule.
  5. If you're on WordPress — its popularity cuts both ways. It gets attacked more, but it also gets patched faster and documented better. Use the second half of that.

If you need help right now

If you're reading this mid-incident, here's what urgent help looks like. I work remotely with clients across Poland and internationally, in Polish and English. Write or call and I'll help get the site back up.

A compromise isn't the end of the world. It's an incident — one that can be fixed, and one that usually produces a single clear conclusion: the site needed looking after sooner than this.

And if you're reading this calmly, with a site that's working fine, this is the best possible moment to check your backups and your updates. That is the entire point of doing it before rather than after.