Website security
Hacked WordPress website: what to do first.
A hacked website does not always look hacked. Visitors may see nothing unusual while Google sees spam pages or the server struggles under load. This guide covers how to recognise it, what to do before you delete anything, how to clean the site and what to do in Search Console.
Signs
What a hack can look like.
01
Spam visible only to Google
Search results show pages or titles you never wrote, while the same address looks normal in your browser. This is called cloaking: the site shows Googlebot different content than it shows people.
02
Unexplained server load
The server is slow or the host warns about resource use, and traffic does not explain it. Hidden scripts, including crypto miners, can use the server’s processor around the clock.
03
Unknown users and files
An administrator nobody recognises, PHP files you did not add, or recently changed core files.
04
Warnings from outside
A message in Search Console, a browser warning, or a notice or suspension from your host.
To check what Google sees, search for site:yourdomain.com, go through several pages of results and put suspicious addresses into the URL Inspection tool in Search Console. A normal page in your own browser proves nothing in this kind of hack.
Before cleaning
Do not start by deleting.
- Make a separate copy of the files and the database as they are now. You will need it to find the way in, and if the cleaning breaks something.
- Write down when you noticed the problem and what you saw.
- Tell your host. They may see logs you cannot, and other sites on the same account may be affected.
- Do not restore an old backup until you know the entry point is closed, or the same hole stays open. The backup may also already contain the infection.
Cleaning
Remove the code and close the way in.
01
Access
Change the passwords for hosting, FTP or SFTP, the database and all WordPress users, switch on two-factor login where you can, and regenerate the secret keys in wp-config.php so that everyone is logged out. Remove users you do not recognise.
02
WordPress, themes and plugins
Replace WordPress core with a clean copy of the same version, and reinstall themes and plugins from their official source. Remove what you do not use, then update everything.
03
Where to look
Check .htaccess first, then index.php, wp-load.php, functions.php, header.php and footer.php, files outside the standard installation, recently changed files and unusually large ones.
04
What suspicious code looks like
Long blocks of unreadable text next to base64_decode, eval, gzinflate, rot13 or strrev. Not every use is malicious, and malicious code can also look ordinary, so compare with the original files rather than relying on a search alone.
Finding the cause matters as much as removing the code. If the entry point stays open, the same infection usually returns. The steps follow Google’s guide to the cloaked keywords hack and the WordPress FAQ on hacked sites.
After the cleaning: Search Console.
- Open the Security Issues report. If it lists a problem, fix everything it names and then request a review there.
- Run the spam addresses through URL Inspection again. “Not found” is a good sign that they are gone; a 404 in your own browser is not enough, because the hack may show it only to you.
- Check robots.txt and the sitemap, and make sure the attacker did not add another Search Console owner.
- Removing addresses with the Removals tool only hides them for a while. It does not clean the site, so it comes after the cleaning, if at all.
Spam addresses can stay in the results for a while after the cleaning. We do not promise a date, because that part is up to Google.
From our work
Four cases, four lessons.
01
Pharmacy spam only Google could see
On one website, Google listed Viagra spam pages while visitors saw nothing unusual. The cause was an outdated plugin with injected base64 code. After removing it, we took the remaining steps through Search Console to bring the site back to normal.
02
A crypto miner on the server
Another website was infected with a crypto miner that put a huge load on the server. Here the symptom was the load, not the content.
03
Nulled plugins
A fourth website used nulled plugins, paid plugins distributed without a licence, and was infected with several kinds of spyware. We deleted the infected plugins, cleaned the files and the server, and later replaced those plugins with custom-built solutions.
04
No backups at all
The third case was not a hack: a server disk permanently lost all its data, and the website had no backups. We rebuilt it from archive.org, Google’s cache and other sources. It worked, but it is far more work than restoring a backup, and a backup is what we recommend.
Prevention
What makes the next time less likely and less costly.
- Do not install nulled plugins or themes. Update the rest on a schedule, and remove the ones you do not use. Our maintenance checklist covers the checks before and after updates.
- Keep backups away from the server and test a restore. Our guide to testing a backup restore shows how.
- Use a separate account for each person, the lowest role that does the job and two-factor login.
- Watch server load and Search Console, so that you notice a change before your customers do.
Checklist
Short version.
- Did you make a copy of the current state before changing anything?
- Did you check site:yourdomain.com and URL Inspection, not just your own browser?
- Have all passwords changed, and are all users known?
- Are core, themes and plugins replaced with clean copies and updated?
- Have you found how the attacker got in?
- Did you request a review if the Security Issues report lists a problem?
- Do you have a tested backup away from the server?
Our free check looks only from the outside, so it cannot confirm that a website is clean. It can show what is publicly exposed.
Think your website has been hacked?
Tell us what you noticed and when. Do not send passwords by email. See also our website security service.