Hacked Website Recovery for SEO: Step by Step Guide

To recover a hacked website for SEO, contain the breach, find every injected file and spam URL, clean or restore the site, close the vulnerability, then request a review through Search Console’s Security Issues report. Fixing only some pages will not earn a partial result, so clean the whole site before asking Google to look again.

The 2024 HTTP Archive Web Almanac security chapter found Content Security Policy headers on 19% of hosts, up from 15% in 2022, so most sites still run without one of the layers that can limit what injected code is able to do.

A hacked site is a business problem first and an SEO problem second. Visitors may be redirected to spam or malware, browsers may warn them away, and Google may flag your results. This guide follows the order I would work in: recognise the signs, stop the damage, clean properly, close the hole, ask Google to review, and then deal with the search clean-up. I cannot promise how fast rankings return, because that depends on how long the infection lasted and what the site looked like before. What I can show is the sequence that avoids reinfection and wasted review requests.

Signs your site has been hacked

Many compromises are quiet. The owner often hears about them from a customer or a drop in traffic, not from an alarm. Look for these patterns.

Spam pages you did not create. Search site:yourdomain.com and scan the results for unfamiliar titles about pharmaceuticals, gambling, counterfeit goods or casino terms. Google’s own malware prevention advice recommends this check as a regular habit.
The “Japanese keyword hack”. This is a long-running pattern where thousands of auto-generated pages with Japanese text, often selling counterfeit products, appear on a site. They frequently use odd URL patterns and may be shown only to search engines.
Cloaked content. Hackers commonly show spam to search crawlers and clean pages to owners, so the site looks normal when you visit. Checking how a URL looks to Google, which I explain in my guide to rendering in SEO, can reveal the difference.
Unexpected redirects. Visitors arriving from search are sent to another domain, while direct visits behave normally.
A “This site may be hacked” label. Google explains in its help page for the hacked-site notice that the label means it believes someone changed existing pages or added new spam pages, and that it will not be removed until the owner takes action.
Search Console alerts. A message about security issues or a spike in indexed pages deserves immediate attention.
Odd admin accounts, modified core files, new files in uploads folders, or a changed .htaccess.

What Google reports, and what each category means

The Security Issues report in Search Console groups problems into three categories: hacked content (content placed on your site without permission because of security vulnerabilities), malware and unwanted software, and social engineering such as phishing or deceptive pages. The report lists sample URLs and a description to help you start. Open it first, enable email notifications, and keep a record of every sample URL it shows.

This is separate from the Manual Actions report. A manual action is a penalty applied by a human reviewer for a policy violation, and it has its own review process, which I describe in Google manual actions: types, causes and reconsideration. A hacked site can appear in either place, so check both.

Rather have an expert do this for you?

Hand it over and get back to running your business.

Hand it over to me

The recovery process, step by step

Contain the damage. Put the site behind a maintenance page or take it offline if it is serving malware. Change all passwords: hosting, database, FTP or SFTP, CMS admin, email accounts that can reset them. Tell your host, who can often identify the entry point from server logs.
Take a backup of the infected state. Keep a copy for diagnosis, then work from it carefully. Do not simply overwrite everything and lose the evidence of how the attacker got in.
Scan and identify. Check files modified recently, unknown files in writable folders, database tables for injected posts, users with admin rights who should not exist, and scheduled tasks you did not create.
Clean or restore. The most reliable route is restoring from a known clean backup taken before the infection and then updating everything. If you have no clean backup, replace core files, plugins and themes with fresh copies from their official sources, and manually inspect uploads and configuration files.
Close the vulnerability. Cleaning without fixing the cause invites reinfection. See the next section.
Verify the site is clean. Re-scan, crawl it yourself, and check from Search Console that the sample URLs now show the correct content or return an error.
Request a review. Do this only after the whole site is clean.
Clean up search results. Handle the spam URLs and sitemap, as described below.

Closing the hole so it does not happen again

Most compromises I see come from a small set of causes: out-of-date plugins or themes, weak or reused passwords, abandoned admin accounts, nulled (pirated) themes, and insecure file transfer. Google’s prevention checklist covers several of these, including strong passwords, vetting third-party content, keeping software current, monitoring logs for suspicious parameters and redirect spikes, and using SSH or SFTP instead of plain-text protocols.

Weak point	What to do
Out-of-date CMS, plugin or theme	Update everything; delete anything unused rather than just deactivating it
Weak or shared passwords	Use unique long passwords and two-factor sign-in on admin accounts
Excess admin users	Remove unknown or unused accounts; give people the lowest role they need
Writable files and folders	Tighten file permissions; block code execution in uploads folders where possible
Insecure transfer	Use SFTP or SSH, not plain FTP
No visibility	Keep logs, regular off-site backups and alerting for file changes
Third-party scripts	Audit adverts, widgets and tags; remove those you do not recognise

A Content Security Policy and a web application firewall can add protection but are not substitutes for patching. If you run WordPress, my WordPress technical SEO checklist includes the maintenance habits that keep a site healthy.

Requesting a review from Google

When you are certain the site is clean and secure, use the review option in the Security Issues report. Google’s documentation is explicit that you must fix the issue throughout the site, because fixing a few pages does not earn a partial return. Your request should state exactly what was wrong and what you did to fix it, for example: “Injected spam pages were created in a plugin folder through an outdated plugin. We restored from a clean backup, removed the plugin, updated all software, reset every password and removed an unknown admin user.” Keep it factual and specific.

Google says most reviews can take several days or weeks, and you will get email updates when the request is received and when it is decided. Do not submit again while a request is pending. If the review is rejected, the response should tell you what remains; go back to the sample URLs, find what you missed, and re-test before asking again.

Cleaning up the search results afterwards

Once the files are clean, the spam URLs can linger in the index for a while. These steps help them leave faster.

Return the right status. URLs that should not exist should return a 404 or 410, as explained in HTTP status codes for SEO. Do not redirect thousands of spam URLs to your home page; that muddies the signals.
Do not block them in robots.txt. Google needs to crawl the URLs to see they are gone. Blocking can leave them stuck in the index.
Refresh your sitemap. Submit a clean sitemap that lists only real pages; the sitemap.xml guide explains how.
Remove injected links and scripts from your own templates, including those hidden in footers or widgets.
Monitor the crawl and index reports for several weeks to confirm the spam is declining and your real pages are indexed.

Rankings often reflect more than the hack itself, so do not assume every loss was caused by it. Cleaning can also leave real pages with broken or missing internal links, and my guide to orphan pages shows how to spot pages that lost their paths and reconnect them.

One habit I recommend after any incident is a short written record: what was found, which accounts were changed, which updates were applied and what date the review was requested. It helps if the site is hit again, and it gives a host or developer something concrete to work from instead of guesswork.

Questions about hacked website recovery

How long does it take to recover from a hacked site?

It varies. Cleaning and securing can take hours or days depending on the infection; a Google review commonly takes several days or weeks, and rankings can take longer to settle. Nobody can honestly promise a fixed date.

Will Google penalise me for being hacked?

Google’s spam policies define hacked content as content placed on a site without permission because of security vulnerabilities, and affected sites may rank lower or lose visibility. That is why a clean site and a review request matter. The Security Issues report and Manual Actions report tell you what, if anything, has been flagged.

Should I delete the spam pages or redirect them?

Delete them and let them return 404 or 410. Redirecting spam URLs elsewhere keeps them alive as far as crawlers are concerned and can confuse the clean-up.

Can I fix this myself?

Often yes, if you can restore a clean backup and update everything. If you cannot find the entry point, or the site keeps getting reinfected, involve your host or a security specialist, because repeated infections damage trust and delay review.

If your site has been hacked or you suspect injected pages, get in touch for a free audit. I will help you work out what is indexed, what to remove and what to monitor as part of technical SEO services.

More in this series (Technical SEO in depth): start with WordPress Technical SEO Checklist: What to Fix First, then explore: