Listen to this post: How to Detect If Your Website Has Been Hacked (and What to Do Next)
You open your website like you always do. Maybe you’re checking a new post, a product page, or last night’s orders. But something feels wrong. A page you don’t remember is there, the site is sluggish, or a customer emails to say they saw a pop-up warning.
A hacked website rarely starts with fireworks. It’s more like finding a window ajar in a house you swear you locked. The sooner you act, the less damage spreads to your visitors, your search rankings, and your revenue.
This guide gives you a calm, practical plan: quick hack checks you can do in 10 to 15 minutes, what to do in the first hour, how to clean up without destroying evidence, and how to reduce the odds of it happening again.
Fast warning signs your website has been hacked (what to check first)
You don’t need to be a developer to spot most hack symptoms. The goal here isn’t to “prove” it in one minute, it’s to notice patterns. One odd thing can be a bug or a bad plugin update. Several odd things at once is your cue to act.
Start with these quick checks:
- Load your homepage and a few key pages (pricing, contact, checkout) in a private or incognito window.
- Check your site on mobile data, not just your Wi-Fi.
- Run a quick search on Google for
site:yourdomain.comand scan the results. - Look at your CMS admin area for new users, new pages, and recent changes.
A simple way to organise what you see is to separate “front of house” signs from “behind the scenes” signs.
| What you notice | Why it matters |
|---|---|
| Weird redirects or pop-ups | Often a sign of injected code or malicious scripts |
| New pages you didn’t publish | Can indicate spam page generation for SEO abuse |
| Site suddenly slow or timing out | Can mean malware is using server resources |
| Unknown admin users or logins | Strong signal your access has been compromised |
| Browser security warnings | Can lead to traffic loss and blocked visitors |
Recent UK security reporting (as of January 2026) keeps pointing to the same theme: stolen logins and phishing are still a common starting point, and small businesses get hit because attackers know they’re busy, not because they’re “important”.
Visitor-facing red flags: redirects, pop-ups, strange pages, and spam links
These are the signs your visitors tend to notice first, and they’re often the ones that cause immediate harm.
Unexpected redirects are a classic. A visitor clicks your link and lands on a gambling site, a fake “download” page, or a scammy survey. Sometimes it only happens once every few visits, which makes it harder to catch.
Pop-ups that don’t match your brand are another giveaway. If you’ve never run ads but your site suddenly shows “Congratulations, you’ve won” banners, treat it as hostile until proven otherwise.
Watch for new pages you didn’t create, especially if they look like thin content stuffed with keywords (medicine, crypto, adult terms, payday loans). Hackers often generate hundreds of these to hijack your domain’s trust.
Also look for spam links inside real pages. A common trick is adding hidden links in the footer, inside old blog posts, or behind CSS so you can’t easily see them, but search engines can.
A practical tip that catches a lot of malware: test in incognito and on mobile. Some infections show clean pages to logged-in admins, but a poisoned version to regular visitors. Others target only mobile traffic to avoid being spotted in office checks.
If you want a quick, structured list of symptoms to compare against, the UK National Cyber Security Centre’s incident guidance is a solid reference point, especially the section on how to identify what’s happening.
Hidden clues: sudden slowdowns, unfamiliar scripts, mixed content warnings, and odd admin activity
Many hacks are quiet on purpose. The site still “works”, it just works for the attacker too.
Sudden slowdowns matter when they’re new and persistent. If your site was fine last week and now every page feels heavy, malware could be using your server to send spam, mine crypto, or run automated attacks elsewhere.
CPU spikes (your server working unusually hard) can show up as random timeouts, 500 errors, or hosting alerts about resource usage.
Unfamiliar scripts are a big one. A script is a small piece of code (often JavaScript) that loads features like chat widgets or analytics. Attackers inject their own scripts to skim card data, redirect users, or load pop-ups. If you spot new third-party code you didn’t add, assume risk until verified.
Mixed content warnings can be a clue too. Mixed content means parts of your page load over HTTPS (secure) and parts over HTTP (not secure). Sometimes it’s harmless (an old image link), but attackers also use insecure requests to sneak in malicious code.
Then there’s the admin side:
- Unknown admin users you didn’t create.
- Password reset emails you didn’t request.
- Unusual logins at odd times or from unexpected locations.
- New plugins, themes, or integrations you don’t recognise.
Treat access changes as a priority. If someone can log in as admin, they can re-infect the site even after you “clean” it.
What to do next when you suspect a hack (the first hour checklist)
The first hour is about three things: protect visitors, stop the spread, and keep enough evidence to fix the root cause. Move fast, but don’t panic-click your way into a worse mess.
A helpful mindset is “contain first, clean second”. If your site is actively harming users, getting it stable matters more than diagnosing every detail.
Contain the damage: take the site offline safely, protect users, and alert your host
If visitors might be exposed to malware, scams, or payment skimmers, limit contact until you know what’s going on.
- Switch to maintenance mode if you can. A proper maintenance response should return a 503 status (it tells search engines it’s temporary).
- Pause risky features: disable new user sign-ups, turn off forms, and pause checkout if you run e-commerce.
- Disable non-essential plugins (or modules) that handle scripts, ads, pop-ups, or file uploads. Don’t uninstall everything blindly, you might wipe clues you need later.
- Contact your hosting provider and keep the message factual: when you noticed it, what symptoms you saw (redirects, new admin users, warnings), what platform you use (WordPress, Magento, custom), and what changed recently.
If you operate in the UK and you suspect personal data exposure (accounts, emails, addresses, payment details), start a simple incident log straight away: time, what you saw, what actions you took, and who you contacted. This helps if you later need to assess reporting duties and customer communications.
For additional recovery context, you can compare approaches in guides like How to Diagnose and Fix a Hacked Website, but keep your first hour focused on stopping harm.
Secure access right away: change passwords, enable MFA, and lock down accounts
Once the bleeding is contained, lock the doors. Assume the attacker has at least one password or session token.
Work through access points in this order:
- Email inboxes linked to the domain (your admin email, support inbox, billing email). If attackers control email, they can reset everything else.
- Hosting control panel (cPanel, Plesk, cloud dashboard).
- CMS admin accounts (including editors with high permissions).
- SFTP/FTP and database access (anything that can change files or data).
- API keys and integrations (payment gateways, marketing tools, shipping apps, tag managers).
Use unique passwords and turn on multi-factor authentication (MFA) wherever possible (a second step like an app code). Password changes don’t help much if the attacker still has a logged-in session, so log out all devices and revoke sessions if your platform supports it.
Then do a quick permission sweep:
- Remove unknown admin accounts.
- Reduce roles to the minimum needed (an editor doesn’t need admin).
- Revoke access for old contractors and agencies you no longer use.
If you’re working with a team, don’t share one “admin” login. Shared logins make it almost impossible to trace what happened.
How to confirm, clean, and recover your hacked website without making it worse
This part is where people often trip. They delete the wrong thing, overwrite evidence, or restore a backup that was already infected.
A safer workflow is: back up, identify changes, clean or restore, then verify.
Make safe backups and find the entry point (plugins, weak passwords, server issues)
Before you remove anything, take two types of backups:
- A snapshot of the current state (even if infected). This preserves evidence and can help a specialist see what changed.
- The last known clean backup, if you have one, ideally from before the first signs appeared.
Then look for the entry point. Common ones include:
Outdated software: old CMS versions, plugins, themes, or server components.
Weak or reused passwords: especially if someone used the same password on email and the CMS.
Compromised plugins or add-ons: sometimes a plugin is abandoned, sometimes it’s a fake copy from an unofficial source.
File upload weaknesses: contact forms, image uploaders, and “free” file managers are frequent targets.
Practical checks you can do without deep server skills:
- Review the CMS “updates” page and note anything overdue.
- Check for plugins installed recently that nobody remembers choosing.
- Look for a spike in changed files (many hosts show “modified” timestamps).
- Scan for unfamiliar scheduled tasks (a scheduled task is an automated job that runs at set times, attackers use them for re-infection).
Keep notes as you go. Write down each change you make, even small ones. If the hack returns, those notes shorten the second round.
Clean up, re-launch, and request de-listing fixes (Search Console and warnings)
There are two main recovery paths. Which one you choose depends on how confident you are in your backups and how messy the infection is.
Path A: Restore from a verified clean backup
- Restore files and database from a point you trust.
- Update the CMS and extensions immediately after restoring.
- Change all passwords again (restoring doesn’t fix stolen logins).
Path B: Reinstall clean core software
- Install fresh core files (for example, a fresh WordPress core) from the official source.
- Copy over only clean content (uploads, posts, products) after scanning.
- Rebuild configs carefully and avoid reintroducing unknown files.
Either way, don’t stop at “it looks fine now”. Many hacks leave a backdoor, a hidden method to get back in. That’s why a scan matters, and why checking users, cron jobs, and file integrity matters.
After cleaning, check your site reputation signals:
- Browser warnings in Chrome or other browsers.
- Hosting provider malware flags.
- Google Search Console security issues (if you use it).
If search engines flagged your site, you’ll usually need to request a review after you’ve fixed it. For a practical view of the steps involved, this guide on what to do if your website is hacked is a useful comparison point.
Before you take the site fully live, run a short “go-live” test:
- Forms submit and arrive in your inbox.
- Logins work for real users (not just admins).
- Payments work (test mode if possible).
- No surprise redirects on desktop and mobile.
- Final malware scan comes back clean.
Then re-check again after 24 to 48 hours. Some infections are timed to reappear.
Stop it happening again: simple security habits that cut risk fast
Security can feel like a hobby you don’t have time for, until the day you do. The aim isn’t perfection, it’s reducing easy wins for attackers and shrinking recovery time.
January 2026 reporting still shows phishing as a common trigger for breaches, and repeat incidents aren’t rare. That means your routine matters as much as your tools.
Set up a basic security stack: updates, backups, firewall, and monitoring
A basic stack for most small sites looks like this:
Updates: turn on automatic updates where it’s safe, and schedule a weekly check for anything that can’t auto-update.
Daily off-site backups: store backups away from the same server (so an attacker can’t wipe them too). Test restores, not just backup creation.
Web application firewall (WAF): a WAF filters bad traffic before it hits your site. It can block common attacks and rate-limit brute force logins.
Malware scanning: scans can spot known bad patterns and file changes.
Uptime and page-change alerts: you want to know fast if your homepage changes or your site goes down.
Also, limit what you install. Fewer plugins and add-ons means fewer doors to watch. Remove anything unused, even if it seems harmless.
For a step-by-step prevention view from another angle, see Essential recovery tips after a hacked website, then adapt the ideas to your own setup.
Tighten access: least privilege, safer logins, and a simple monthly audit
Access control is often where hacks begin and where they return.
Least privilege means each person only gets the access they need. A writer shouldn’t be able to install plugins. A support agent shouldn’t be able to edit payment settings.
Make these changes stick:
- Put MFA on every admin account, plus hosting and email.
- Use separate admin accounts, never shared ones.
- If your platform allows it, restrict admin logins by location, IP address, or VPN.
A simple monthly audit keeps you honest:
- Review users and remove old accounts.
- Update plugins and themes.
- Check basic logs for odd login patterns.
- Test a backup restore to a staging site.
- Scan pages for strange outbound links.
These habits are boring. That’s why they work.
Conclusion
A hacked website can feel personal, like someone scrawled on your shop window. The fix is calmer than it first seems: spot the signs early, contain the damage fast, clean up in a controlled way, then build a routine that makes re-infection harder.
Run the quick checks today (incognito, mobile, admin users, and strange pages). Set up backups you’ve tested and turn on MFA across email, hosting, and your CMS. If you handle customer data or payments, get a security professional involved sooner rather than later. The goal isn’t to feel safe, it’s to be ready.


