Compromised WordPress site: emergency response guide for non-technical users

A compromised WordPress site is recognised first and foremost by its warning signs, not by suspicion. This guide is designed for those who manage a site but do not administer a server: an agency, a small e-commerce business, a freelancer. It applies regardless of the vulnerability exploited: it is not tied to a specific CVE, but to the sequence of actions to take in the first few hours.

Warning signs to look for

You don't need to be a systems administrator to notice something is wrong. The most common warning signs are:

• the browser displays a warning such as "Deceptive site ahead" or "Dangerous" when someone visits the site;
• the site redirects to another domain, often only on mobile or only when arriving from Google;
• pages or posts appear that nobody on the editorial team has written, sometimes in languages other than your own;
• you receive an email from your hosting provider flagging suspicious activity or suspending the account;
• Google Search Console sends a security issue notification.

WordPress.org's official documentation recommends as a first useful step to document the symptoms observed, with precise time and timezone, and to note what operations had been performed recently on the site (plugins installed, themes modified, widgets added): this is the basis for understanding what happened and, if needed, for anyone helping you to reconstruct the incident.

First step: isolate the site

Before investigating the cause, you need to stop the spread. Putting the site into maintenance mode or taking it temporarily offline prevents visitors from continuing to land on pages that redirect to malware or phishing, and reduces the risk that Google will re-scan the compromised site and worsen the flag. If you don't know how to enable maintenance from your control panel, this is the first thing to ask your technical support provider.

Isolate a clean backup

Don't just take the latest available backup: if the site was already compromised days ago, even the most recent snapshot might contain malicious code. You need to trace back to the date of the first documented symptom and find a backup from before that date. Before restoring anything, it's still a good idea to save a copy of the current state (even if infected): it serves as a reference for understanding what was modified and, if reporting to third parties, as evidence.

Who to ask for help

If you don't manage the server directly, you have two options: the agency or freelancer who built the site, or the technical support of your hosting provider. Many hosts offer a paid malware removal service or include it in some plans: it's worth asking before proceeding on your own, especially if the site handles payments or registered user data.

What to change after cleanup

Regardless of how the site was cleaned, after remediation all credentials must be changed, not just the WordPress administrator password:

• hosting, FTP/SFTP and control panel password;
• database password;
• passwords for all WordPress users, not just administrators;
• API keys and tokens linked to external services (payments, shipping, newsletters);
• WordPress security keys in the wp-config.php file, which invalidate sessions already open from anyone with access.

WordPress.org's official documentation explicitly recommends regenerating these keys via the official generator and overwriting them in the configuration file, precisely to force disconnection of anyone who might have remained logged in with valid sessions.

Verify and unblock Google Search Console

If the site is registered in Google Search Console, check the Security issues report, accessible from the Security & manual actions menu. If Google has detected compromised content, malware or phishing pages, the report lists the issue category and a sample of affected URLs (the list may not be complete).

Before requesting a review, the problem must be resolved on all pages of the site, not just those listed as examples: according to Search Console's official guide, resolving the issue on only some pages does not guarantee reinstatement in search results. Only then do you select Request review in the report. A reconsideration request, to be valid, must meet three conditions, also according to Google: explain the issue encountered with precision, describe the procedure followed to resolve it and document the result of the countermeasures adopted.

The review can take anywhere from several days to a few weeks, and Google sends email updates until the final decision. It's worth waiting for the outcome before submitting a new request: a repeated request on an unresolved issue prolongs the wait and may cause the site to be flagged as a repeat offender.