Hacked or infected website

A hacked or infected website is one where an attacker has injected malicious code, added rogue accounts, or planted spam content. The symptoms range from obvious (visitors redirected to a casino site) to subtle (a hidden backdoor file that does nothing visible).

If you suspect your site has been hacked, contact support right away. Cleaning an infected site is free on paid production websites under our hacked site fix guarantee.

Common signs of an infected site

New, suspicious administrator accounts. Admin users you don't recognize appear on the site.
Unexpected redirects. Visitors are sent to an external website they never intended to visit.
New pages or posts you didn't create. Often spam about online casinos, pharmaceuticals, or counterfeit goods.
Fake Cloudflare "captchas". A page pretends to be a Cloudflare human-verification check, then asks you to copy and paste a command into a terminal or the Windows Run dialog. Never do this - it runs malware on your own computer.
Unexpected Google Search Console verification. Google emails you that a new owner was verified for your site. Attackers verify ownership by uploading a google*.html file, then submit spam sitemaps or deindex your pages.
Spammy search results for your site. Searching for your site on Google returns pages or descriptions you never published.
Browser or Google warnings. Visitors see "Deceptive site ahead" or "This site may be hacked" when opening the site.

How sites get infected

Most infections come in through:

Outdated plugins or themes with known, unpatched vulnerabilities. This is by far the most common cause.
Leaked administrator passwords. The most common cause we see is an attacker logging straight into WP Admin as an administrator using a password that leaked or was reused elsewhere.
Cross-site scripting (XSS) and other application-level flaws that let an attacker act as a logged-in administrator.

How we clean an infected site

When we detect or are notified of an infection, we perform a best-effort cleanup:

Password protect the site so the infection can't spread further or reinfect while we work.
Trace the entry point. We look for recently changed files and match them against the site's access logs to find how the attacker got in.
Quarantine and rebuild. We move malicious files to a safe quarantine directory, then reinstall WordPress core and plugins from clean copies:
```
wp core download --force
wp plugin install <plugin_name> --version=<version> --force
```
Audit administrators. We list administrators straight from the database (malicious code can hide them from the normal admin list), remove rogue accounts, reset every admin password, and review application passwords:
```
wp user list --role=administrator
```
We also regenerate the salts in wp-config.php, which logs out every active session, including any the attacker still holds. See which passwords to change after an infection.
Update everything. We apply the latest core and plugin updates to close the vulnerability that was exploited.
Remove spam content. We delete any spam pages or posts the attacker published.
Notify you or your agency, along with recommendations to keep the site secure.

After any cleanup - ours or your own - run a full malware scan with Wordfence to confirm no infected files remain. Once the scan comes back clean you can remove the plugin again, or keep it installed for ongoing peace of mind.

Remove an attacker from Search Console

If Google notified you that a new owner was verified:

Delete all google*.html verification files from your webroot. They're only needed at verification time, so removing them is safe once your site is verified.
In your Search Console property, open Settings → Users and permissions and remove every user you don't recognize.
Open Settings → Ownership verification and unverify any owner or method you didn't set up.

Why restoring a backup isn't enough

Don't restore a backup as your first move. A restore doesn't delete files added after the backup was taken, so the attacker's backdoor almost always survives - and the backup itself may already be infected. Restoring before the entry point is traced also overwrites file timestamps, our main clue for finding the first infected file, and can make tracing impossible.

Backups complement a cleanup, they don't replace one. Deleting all files before restoring does guarantee infected files are removed, but it's heavy-handed and we treat it as a last resort.

Which passwords to change after an infection

An infection calls for rotating exactly two credentials - the ones an attacker may actually hold:

Administrator passwords - reset every one. A leaked or reused admin password is one of the most common ways sites get hacked in the first place.
Salts and keys - regenerate the AUTH_KEY, SECURE_AUTH_KEY, and the other salt lines in wp-config.php. This invalidates every existing login cookie, so anyone using a stolen session is logged straight out. Everyone has to log in again, including you. Over SSH it's one command:
```
wp config shuffle-salts
```

Your SFTP/SSH and Templ account passwords aren't exposed by an infection - they live outside the website - so they don't need rotating.

The database password isn't one of them

Changing the database password doesn't shut an attacker out, so we don't do it as part of a cleanup. The database is only reachable from inside the server, and anything running there can read the new password straight from wp-config.php the moment you set it. What locks an attacker out is removing the malicious code and closing the vulnerability that let it in.

Preventing future infections

Keep WordPress core, plugins, and themes updated.
Scan for known vulnerabilities in your plugins and themes.
Enable two-factor authentication on your Templ account and in WP Admin.
Use strong, unique passwords for every administrator.
Disable the built-in file editor, so a compromised login can't edit code from the dashboard, by adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php (just before the /* That's all, stop editing! Happy publishing. */ line).

For the full list of what Templ secures automatically and what to set up yourself, see security on Templ.