If you searched your business name and found pages about pharmaceuticals, replica handbags, or casino offers sitting under your domain, an attacker has most likely gotten in. Finding your WordPress site hacked like this is stressful, but it is fixable. The work has a sensible order: contain the damage, preserve evidence, find everything the attacker added, clean it, close the hole they came through, and then ask Google to take another look.
This guide walks through that order in plain terms. It is written for business owners and the people who manage their sites, not for security researchers. Where Google or WordPress.org has published guidance, we point you to it so you can check the details yourself.
Is your WordPress site hacked? How to tell
Spam hacks are designed to stay out of your sight. The attacker wants search engines to see the spam, not you. Common signs include:
- A
site:yourdomain.comsearch in Google shows page titles you never wrote, often in another language. - The Search Console Pages report shows a sudden jump in indexed or discovered URLs with strange paths or query strings.
- Search Console’s Security Issues report lists a “hacked: URL injection” or “hacked: content injection” style warning.
- Visitors from Google land on a spam page or get redirected, while typing your address directly looks normal. This is called cloaking.
- New administrator accounts, unfamiliar plugins, or files with random names appear on the server.
- Your host suspends the account or emails you about outbound spam or malware.
Google’s Security Issues report help page explains what each hacked-content category means and shows sample affected URLs. Treat those samples as a starting point, not a complete list.
Step one: contain the damage before you clean
The instinct is to start deleting things right away. Resist it for an hour. Containment first keeps the attacker from coming back in while you work.
-
Take a full backup of the hacked site
Yes, back up the infected version. Copy all files and export the database. You need it to compare against later, to work out how the attacker got in, and as a fallback if a cleanup step breaks something. Label it clearly so nobody restores it by mistake.
-
Change every credential
Reset passwords for WordPress administrators, hosting control panel, SFTP/SSH, the database user, and any email accounts tied to the site. The WordPress.org “FAQ My site was hacked” article also recommends updating the secret keys in
wp-config.php, which logs out every active session, and checking your own computer for malware, since stolen logins often come from an infected local machine. -
Consider a maintenance page
If the site is actively redirecting visitors to harmful pages, putting up a temporary maintenance page protects customers while you work. Keep it short-lived; a long outage creates its own problems.
-
Tell your host
Hosts can often see access logs, flagged files, and other accounts on the same server that you cannot. On shared hosting, a neighbor account can be the source.
Step two: find everything the attacker added
Spam hacks rarely live in one file. Attackers leave several footholds so that removing one does not lock them out. Work through each of these areas.
User accounts
In Users, sort by role and look for administrators you do not recognize. Also check the wp_users table directly in the database, because some malware hides accounts from the dashboard list.
Plugins and themes
Look for plugins you did not install, including ones with generic names, and for “must-use” plugins in wp-content/mu-plugins, which do not appear in the normal plugin list. Remove nulled or pirated themes and plugins entirely; they are a frequent source of backdoors.
Core and uploads files
Compare WordPress core files against a fresh download of the same version. PHP files inside wp-content/uploads are a red flag, because that folder should normally hold media, not code.
Database content
Search the posts and options tables for spam keywords, hidden links, and injected <script> tags. Spam pages are sometimes stored as posts with unusual post types or statuses.
Scheduled tasks
Check WordPress cron events (a tool such as WP-CLI’s wp cron event list helps) and server-level cron jobs. Attackers use scheduled tasks to reinstall malware after you delete it.
Server configuration
Review .htaccess, wp-config.php, and any php.ini or .user.ini files for redirect rules or auto-prepended files that serve spam only to search engine crawlers.
Because cloaked spam is often shown only to Googlebot, use the URL Inspection tool in Search Console to view a suspicious URL the way Google fetched it. What you see in your own browser may look perfectly clean.
Step three: clean up, or restore from a known-good backup
You have two broad paths, and the right one depends on what backups you have.
| Approach | When it fits | Watch out for |
|---|---|---|
| Restore a clean backup | You have a backup from before the compromise and know roughly when it started. | Restoring brings back the same vulnerability. Update everything immediately after, and re-add any legitimate content created since the backup. |
| Rebuild from fresh files | No trustworthy backup exists, or the infection date is unclear. | Replace core, themes, and plugins with fresh copies from official sources, then carefully migrate only your media and cleaned database. |
| Clean in place | The infection is small and well understood. | Easy to miss a backdoor. Usually best done by someone experienced with WordPress malware. |
Whichever path you choose, finish by updating WordPress core, every theme, and every plugin, and deleting anything you do not actively use. An inactive plugin with a known vulnerability is still a way in.
Step four: harden the site so it does not happen again
The WordPress.org Hardening WordPress guide frames security as risk reduction rather than risk elimination, and notes that outdated software and brute-force password guessing are among the most common attack routes. Practical steps for a small business site:
- Turn on automatic updates where you can, and schedule a regular check for the rest.
- Add two-factor authentication for administrators. WordPress core does not include it, so it comes from a plugin or your identity provider, as the WordPress.org brute-force guidance explains.
- Give each person their own login with the lowest role they need. No shared “admin” account.
- Disable XML-RPC if nothing on your site uses it.
- Set sensible file permissions and disable file editing in the dashboard with
DISALLOW_FILE_EDIT. - Keep automated, off-server backups with several restore points, and test a restore at least once.
- Use a reputable host that isolates accounts and patches the server stack.
If keeping up with all of that is not realistic for your team, ongoing website maintenance is the usual answer: someone owns updates, backups, and monitoring every month instead of only after something breaks.
Step five: clear the spam out of Google
Once the site is genuinely clean, turn to search results. This is where a few common mistakes slow recovery down.
Let spam URLs return 404 or 410
The injected pages should simply stop existing. When a crawler requests one, your server should answer with a 404 (Not Found) or 410 (Gone) status. Google’s Removals tool help page lists returning 404 or 410 as a way to make removal permanent.
Do not redirect spam URLs to your homepage
It is tempting to 301 every spam URL to the homepage so “nothing is broken.” Google’s Search Console help on 404 errors warns that redirecting non-existent URLs to the homepage instead of returning a 404 can be problematic and may be treated as a soft 404. It also ties your homepage to thousands of spam addresses. A plain 404 or 410 is the cleaner signal.
Do not block spam URLs in robots.txt
If Googlebot cannot crawl a URL, it cannot see that the page is gone. Google’s removals guidance also says not to rely on robots.txt as a blocking mechanism. Leave the URLs crawlable so Google can confirm the 404s.
Use the Removals tool for the worst offenders
The Removals tool in Search Console hides URLs from results quickly, but Google’s help page says a successful request lasts only about six months. Use it for the most visible or embarrassing URLs, especially those ranking for your brand name, while the permanent 404s do the real work. For large spam sets, you can submit a prefix if all the spam shares a common path.
Request a review in Security Issues
When every issue in the Security Issues report is fixed across the site, select Request Review. Explain what was wrong, what you changed (for example, removed injected pages, deleted an unknown admin account, updated an outdated plugin), and what the outcome was. Google notes that reviews for sites hacked with spam can take up to several weeks because they may involve manual checks. Do not resubmit while a request is pending.
Resubmit your real sitemap
Submit your clean XML sitemap so Google has an accurate list of your legitimate pages. Some hacks add their own sitemap files; delete those and remove them from Search Console if they were submitted.
What recovery realistically looks like
Spam URLs drop out of the index gradually as Google recrawls them, and that can take weeks or longer on sites with many injected pages. You may keep seeing 404s for spam URLs in Search Console for months; that is expected and not harmful in itself. Rankings for your real pages may wobble during the cleanup. We cannot tell you how long your recovery will take, because it depends on how large the hack was and how often Google crawls your site, but the order of operations above gives Google the clearest possible signals.
Keep a short incident log: when you noticed the hack, what you found, what you changed, and when you requested review. It helps if the problem returns, and it is useful for your host or insurer.
If you want a second set of eyes on the cleanup or the Search Console side, our technical SEO services and SEO audits cover indexing problems like this, and our WordPress development team can rebuild from clean files when that is the safer route.
Frequently asked questions
Can a security plugin clean the hack for me?
Scanners are helpful for finding known malware signatures, but they can miss custom backdoors, database injections, and scheduled tasks. Use a scanner as one tool, then verify manually or with someone experienced.
Should I delete the spam URLs one by one in Search Console?
No. Fix the site so those URLs return 404 or 410. Use the Removals tool only for a handful of highly visible URLs or a shared prefix, since temporary removals expire after about six months.
Why does my site look normal when I visit it?
Many spam hacks use cloaking, showing spam only to search engine crawlers or to visitors arriving from Google. Use URL Inspection in Search Console to see what Googlebot received.
The hack came back after I cleaned it. Why?
Usually a backdoor, a hidden admin user, a cron job, or the original vulnerability was left in place. Rebuilding from fresh files and changing every credential again is often faster than hunting a second time.
