You open your site and see pages you never created. Or your host tells you it found malicious code, and Google warns visitors that the site may be hacked. A hacked WordPress site looks frightening, but it can be fixed if you go in the right order.
This is the order recommended by the WordPress documentation and Google's help. First you lock the doors by changing the passwords and removing unknown administrators. Then you save a copy of the site, decide whether to restore a clean backup or clean by hand, update everything and ask Google to remove the warning. At the end there is a checklist and an explanation of when to write to support.
How to tell that your site is hacked
Hacking rarely shows at first glance. The WordPress documentation lists clear signs:
- the site is on a blacklist of Google, Bing or another search engine;
- the host has disabled your site;
- the site has been flagged for distributing malware;
- visitors say their antivirus reacts to the site;
- someone tells you your site is being used to attack other sites;
- there are actions on the site that you did not take, for example new users;
- the hack is visible right in the browser.
Part of it can be hidden from you. Hacked content is sometimes shown only to the search engine, and Google calls this cloaking. So type site:primer.bg into Google and look through the indexed pages. Look for pages you do not recognise, because the hacker may have added some. Also open Google Search Console. In the Security Issues section you will see what problem Google detected, together with sample URLs.
Before you touch anything, write down what you see, when you noticed it and what you changed last, for example a new plugin.
Change the passwords and remove unknown administrators
First check the computer you log in from. According to the WordPress documentation, attackers often start there, with malicious software that steals the login details for FTP and wp-admin. Run an antivirus and only then change the passwords, otherwise the new ones may reach the same person.
Change every login. The WordPress documentation lists FTP or SFTP, wp-admin, the hosting panel and MySQL.
- The cPanel password is in Password & Security. If you cannot find it, search for "Password" in the cPanel search.
- The passwords of the FTP accounts, if you have any.
- The database password.
- The passwords of all WordPress users, especially the administrators.
For the database, the easiest way is WP Toolkit, if your host has it. Open the Database tab of the site and click change next to the user name. WP Toolkit updates wp-config.php by itself.
If you plan to change it from MySQL Databases in cPanel (called Manage My Databases in newer versions), use Change Password in the Current Users table. Then you must enter the same password by hand on the DB_PASSWORD line in wp-config.php.
WordPress passwords are changed from Users, All Users. Choose the user, click Generate Password and then Update User.
Next, review the administrators. In Users, All Users, see who has the Administrator role. Write down the name and email of every unknown one and delete it, so it cannot log in again.
The same list can be taken with one command in the cPanel Terminal (in the classic view it is in the Advanced section). Terminal appears only if the host has given shell access, and the wp commands work only where WP-CLI exists. If you are missing one of the two, skip the command blocks, because most checks can also be done from WP Toolkit or from the WordPress admin.
# cPanel > Terminal
# Read-only. Replace public_html with the site folder if it is different.
cd ~/public_html
wp user list --role=administrator \
--fields=ID,user_login,user_email,user_registered
Finally, end all logged-in sessions. wp-config-sample.php from WordPress says the secret values (salts) can be changed at any time to invalidate all existing cookies. That logs out the attacker if they stayed logged in, but it logs you out too, so do it when nobody else is working on the site.
# cPanel > Terminal, in the site folder
wp config shuffle-salts
Without Terminal, take new values from api.wordpress.org/secret-key/1.1/salt/ and replace with them the eight lines AUTH_KEY, SECURE_AUTH_KEY and the rest in wp-config.php, which you open in File Manager.
Check the files and save a copy
If your host scans the files with ImunifyAV, search for "Imunify" in the cPanel search. If you cannot find it, ask your host's support whether there is a scanner. Open the list of detected files and write down the path of each one.
According to the cPanel documentation, ImunifyAV detects the malicious code, while automatic cleanup is a feature of the paid ImunifyAV+ version. So do not count on the tool to clean the site by itself. Before you delete a file from the list, open it, and if you are not sure, ask support.
Then make a copy of the site in its current state. Google advises saving the files and the database before you change anything. WordPress recommends the same for the infected state, because if the cleanup goes wrong you will at least have something to examine.
In WP Toolkit, click Back Up / Restore on the site card and then Back up. Download the file to your computer and label it as infected so you do not restore it by mistake. How to do this is described in the guide to WP Toolkit. If you have no WP Toolkit, the other ways are in the backup guide.
If your host makes automatic backups, ask its support from which dates they exist, because you will need them in the next step.
How to clean a hacked WordPress site
There are two ways. If you have a clean backup, restore it. If you do not, you clean by hand. Google describes the three cases like this:
| Which backup you have | What you do |
|---|---|
| Clean and recent | Restore it, update everything and change the passwords. |
| Clean but old | Restore it, update everything, then carry over from the infected copy only content you have checked. |
| No clean backup | Clean by hand with the steps below. |
A backup from a date after the hack began carries the infection with it. So choose a backup from before the first sign you wrote down.
The WordPress core
In WP Toolkit, click Check WordPress Integrity on the site card, then Verify Checksums. WP Toolkit compares the core files with the original WordPress checksums. If a file differs, click Reinstall WordPress Core, which does not touch the content of the site.
WP Toolkit does not check index.php, wp-config.php and the other files with data specific to the installation, so review them by hand. In current versions of WordPress, index.php is short and apart from the comments has only define( 'WP_USE_THEMES', true ); and require __DIR__ . '/wp-blog-header.php';. Anything else there was added by someone. In wp-config.php, look for code you do not recognise.
With Terminal, the same check is one command.
# cPanel > Terminal, in the site folder
# Read-only. Compares the core with the WordPress.org checksums.
wp core verify-checksums
Plugins and themes
There is a similar check for the plugins from WordPress.org.
# cPanel > Terminal, in the site folder
# Read-only. Checks the plugins from WordPress.org.
wp plugin verify-checksums --all
For paid plugins, download a clean package from the vendor's site. Delete the plugins and themes you do not use. Google stresses that a plugin must be deleted, and deactivating it is not enough. A plugin you do not remember installing is a reason for concern.
The uploads folder
wp-content/uploads holds the images and documents, so you do not expect PHP files there.
# cPanel > Terminal, in the site folder
# Read-only. Shows files that can run as PHP.
find wp-content/uploads -type f \
-iregex '.*\.\(php[0-9]*\|phtml\|phar\)$'
Open every file found before you decide. From the site folder, the command head -c 1500 PATH_TO_FILE shows the start of a file without running it. A file with only a comment is harmless, and a file with a long unreadable string is not.
# cPanel > Terminal. Deletes one file, with no way back.
rm wp-content/uploads/2026/10/SUSPICIOUS_FILE.php
The .htaccess file and encoded code
The WordPress documentation calls .htaccess one of the files most often changed in an infection. Such a file can exist in other folders of the site too.
# cPanel > Terminal, in the site folder
# Read-only. Shows all .htaccess files under the current folder.
find . -name ".htaccess" -type f
The standard WordPress block in the main folder is short. Everything outside it was added by you, by the host, by a plugin or by the attacker. Look for rules that redirect visitors elsewhere or send requests to an unknown .php file, and copy the file before you edit it.
# .htaccess in the main folder, the standard WordPress block
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Google advises looking for files with encoded code too, for example with base64_decode or eval.
# cPanel > Terminal, in the site folder
# Read-only. Shows the names of files with such code.
grep -rIl --include="*.php" \
-E "(eval|assert)[[:space:]]*\(.*(base64_decode|gzinflate|str_rot13)" \
wp-content
Some of the files found may be legitimate, so look only at the ones you do not expect in that place. If you are not sure, ask support.
Update everything and close the entrance
Cleaning does not help if the hole stays open. Google cites a study according to which a considerable share of hacked sites are hacked again on the very first day. As possible ways in, Google lists weak or reused passwords, missed updates and vulnerable plugins and themes.
Update WordPress, the themes and the plugins. The site card in WP Toolkit shows what is waiting for an update and marks plugins with known vulnerabilities with the label Vulnerable, based on data from the Patchstack and Wordfence databases. Update them or remove them.
After that, change the passwords and the secret values once more. The WordPress documentation says this explicitly, because the first change was made while the site was still infected. Also think about two-factor login for the administrators, which the documentation recommends too.
How to remove the Google warning
The Google warning does not go away by itself. It stays until the site owner takes action.
- In Google Search Console, verify that the site is yours.
- Open Users and permissions and check for an unknown user or owner. If there is one, write down their email and remove them, together with the verification token they left.
- In Security Issues, look at the sample URLs. Do not open them in an ordinary browser. Use URL Inspection or curl.
- When everything is clean on all pages, click Request Review.
- Describe what the problem was, what you did for each category and what the result is.
A review takes from a few days to a few weeks. Do not send a new request while the first one is being processed, because that may delay later ones. The pages must be reachable by Googlebot, with no blocking in robots.txt and no noindex.
When should you write to support?
Write to your host's support at once, without waiting to try everything, when:
- you cannot log in to cPanel or to the WordPress admin;
- your host has written to you about malicious code, spam or abuse;
- the infection comes back after cleaning;
- the account holds other sites and you do not know whether they are affected;
- the site sends spam or your emails bounce.
On shared hosting a hack can affect more than one site, and sites used for spam end up on email blacklists, the WordPress documentation warns. Google advises telling the host right at the start. If visitors see malicious content, ask support to take the site down temporarily, with a 503 response from outside, as Google recommends.
In your message, write the domain, what you see, when you noticed it, what you have already done and which files the scanner showed, if the host has one.
# Message to support
Hello,
I suspect that the site primer.bg is hacked.
On a phone, an unknown address opens instead of the page.
I noticed it on 7 October around 10 o'clock, after a plugin update.
I already changed the passwords for cPanel, the database and the admins.
ImunifyAV shows three files in wp-content/uploads/2026/10.
Can you check whether other sites in the account are affected?
Can you tell me from which dates automatic backups exist?
Thank you.
If you would rather not go through all of this yourself, or the infection keeps coming back, with hacked site cleanup we remove the malware and the backdoors, close the hole and ask Google to lift the warning, wherever the site is hosted. Describe what you see in the inquiry form, with the same details as in the message above.
Checklist
- I wrote down what I see, when I noticed it and what I changed recently.
- I checked my computer with an antivirus and changed the passwords for cPanel, FTP, the database and all WordPress users.
- I removed the unknown administrators and changed the secret values in wp-config.php.
- I reviewed what the host's scanner found, if there is one, and downloaded a copy of the site in its infected state to my computer.
- I restored a clean backup or cleaned the core, the plugins, uploads and .htaccess.
- I updated everything and deleted the plugins and themes I do not use.
- I changed the passwords and the secret values once more.
- I asked for a review in Search Console once everything was clean.
Frequently asked questions
How can I tell whether my WordPress site has been hacked?
The WordPress documentation lists clear signs, such as the site being on a Google or Bing blacklist, the host disabling it, visitors' antivirus reacting to it or actions on the site you did not take, like new users. Part of a hack can be hidden, because hacked content is sometimes shown only to the search engine. So type site:primer.bg into Google and look through the indexed pages, and check the Security Issues section in Google Search Console.
What should I do first if my site is hacked?
First check the computer you log in from with an antivirus, because according to WordPress attackers often start there. Then change the passwords for cPanel, FTP, the database and every WordPress user, and delete unknown administrators after writing down their name and email. Finally change the secret values (salts) in wp-config.php to log the attacker out if they are still logged in.
Should I keep a copy of the hacked site?
Yes. Google advises saving the files and the database before you change anything, and WordPress recommends the same for the infected state, so there is something to examine if the cleanup goes wrong. Download the copy to your computer and label it as infected so you do not restore it by mistake.
Which backup should I restore after a hack?
A backup from after the hack began carries the infection with it, so choose one from before the first sign you wrote down. If the backup is clean and recent, restore it, update everything and change the passwords, and if it is clean but old, carry over only checked content from the infected copy. Restoring deletes everything changed after the backup's date, including new orders and comments.
Does ImunifyAV clean the site by itself?
No. According to the cPanel documentation, ImunifyAV detects malicious code, while automatic cleanup is a feature of the paid ImunifyAV+ version. Use its list of detected files to see the path of each one, open a file before deleting it, and ask support if you are unsure.
How do I clean a hacked WordPress site without a backup?
For the core, use Check WordPress Integrity and Verify Checksums in WP Toolkit or wp core verify-checksums, and replace changed files with Reinstall WordPress Core. Plugins from WordPress.org have a similar check, paid ones should be downloaded clean from the vendor, and unused ones deleted, since deactivating is not enough. Look for PHP files in wp-content/uploads, review .htaccess for foreign redirects and search for encoded code with base64_decode or eval.
How do I remove Google's hacked site warning?
The warning does not go away by itself. In Google Search Console verify that the site is yours, check Users and permissions for unknown users, and when everything is clean click Request Review under Security Issues with a description of what you did. A review takes from a few days to a few weeks, and you should not send a new request while the first is being processed.
When should I contact my host's support about a hacked site?
At once if you cannot log in to cPanel or the WordPress admin, if your host has written to you about malicious code or spam, if the infection comes back after cleaning, if the account holds other sites or if the site sends spam. In your message, give the domain, what you see, when you noticed it, what you have done and which files the scanner showed. If visitors see malicious content, ask for the site to be taken down temporarily with a 503 response, as Google recommends.
Sources
- WordPress.org, FAQ My site was hacked
- WordPress.org, Reset your password
- WordPress core, wp-config-sample.php
- WordPress core, index.php
- WordPress core, class-wp-rewrite.php
- WP-CLI, wp user list
- WP-CLI, wp config shuffle-salts
- WP-CLI, wp core verify-checksums
- WP-CLI, wp plugin verify-checksums
- Google, How do I know if my site was hacked?
- Google, Quarantine your site
- Google, Use Search Console
- Google, Clean and maintain your site
- Google, Fix the cloaked keywords and links hack
- Google, Top ways sites get hacked by spammers
- Google, Request a review
- Google Search Console Help, Security Issues report
- Google Search Help, Report a problem with Google Search
- Plesk, WP Toolkit documentation
- cPanel documentation, ImunifyAV+ license
- cPanel documentation, Password & Security
- cPanel documentation, MySQL Databases
- cPanel documentation, Terminal in cPanel