Search Console Security Issues: Fix a Hacked Site or Malware Warning

When Search Console reports security issues, Google has found evidence that your site was hacked, or that it behaves in a way that could harm visitors. That can mean spam pages you never wrote, a redirect to another site, malware, or a page that imitates a trusted brand to steal passwords. Affected pages can carry a warning label in search results or an interstitial warning page in the browser.

This guide is for site owners and developers who have received a security issues email or see the report in Search Console. You will learn how to read the report, how to look at infected pages without exposing your own computer, how to match the issue to a cleanup, how to close the way in, and how to ask Google to review the site. It is not a replacement for a professional incident response if customer data may have been taken.

Be realistic about effort. Cleaning malware means reading code and server settings. Google says that if this is beyond your comfort zone, you should build a support team: your hosting provider, a developer or a security professional.

Before you begin

You need access to your server files, database and hosting control panel, plus a verified Search Console property. If the site is not registered yet, add and verify it first, because the report gives sample affected pages that make cleanup much easier. See Set Up Google Search Console.

Before touching anything, take a full copy of the site files and database as they are now, so you keep evidence of what was changed. Also locate your last known-good backup. Prepare a working note where you will record each infected file, the way it was infected and the fix. Do not open infected pages directly in your normal browser, as explained in Step 2.

The three categories in the report

Google groups security issues into three categories:

Hacked content. Content placed on your site without permission because of a security weakness.
Malware and unwanted software. Software designed to harm a device or its users, or to behave in deceptive or unexpected ways. Either a hacker or a site owner can install it.
Social engineering. Content that tricks visitors into doing something dangerous, such as revealing confidential information or downloading software.

Issues are classified as errors or warnings. The specific hacked types you may see are malware, code injection, content injection and URL injection, plus deceptive pages for social engineering.

Step-by-step instructions

Step 1: Open the Search Console security issues report

Open the Security issues report. The top shows a count of issues; if there are none, you see a green check mark. Expand each issue to read the description, the date it was first detected and a sample of affected URLs. The sample is not necessarily complete, and a few issues may list no examples at all. That does not mean no pages are affected.

Google says you may not be able to reproduce the warning yourself, because Safe Browsing warnings depend on the browsing context. Treat the report as the source of truth for whether issues exist or were fixed.

What success looks like: You have a list of issues, dates and example URLs saved outside the site.

Step 2: Look at infected pages safely

Malware often spreads by exploiting browser vulnerabilities, so avoid opening infected pages in a regular browser. Hackers also use cloaking, showing clean pages to you and spam to Google, so a clean-looking page does not prove the site is clean. Two safer ways to look:

Use the URL Inspection tool to view the page as Google sees it. See URL Inspection Tool Live Test.
Fetch the page with cURL or Wget, which also lets you set a referrer and user agent. Hackers often target particular referrers or user agents. Fetch each page with and without a Google referrer, since some malware only activates for visitors from search.

# Without a referrer, then as if the visitor came from Google Search
curl -sS -D - -o page-plain.html https://example.com/some-page
curl -sS -D - -o page-google.html --referer "https://www.google.com/" https://example.com/some-page
diff page-plain.html page-google.html

Read the headers for unexpected 301 or 302 redirects, and search the saved HTML for code you did not add.

You can also search Google for site:example.com to list indexed pages, and add spam terms such as site:example.com pharmacy to find content you did not create.

What success looks like: You have seen the injected content or redirect in a saved response, without loading it in a browser.

Step 3: Match the issue to the cleanup

Each issue type has a typical shape.

Hacked: Malware. The site hosts or spreads malware. Diagnose the malware type and clean the site; Google points to a detailed hacked-with-malware guide. Records of each damaged file will drive the cleanup.
Hacked: Code injection. A hacker injected malicious code into pages, for example a redirect to a malicious site or a cryptocurrency miner. Look for server-level redirects in .htaccess or httpd.conf on Apache, JavaScript redirects that depend on the referrer, scripts loaded from unknown hosts, and obfuscated code. Useful search terms in your files include eval, base64_decode, unescape and search.
Hacked: Content injection. Spammy links or text, often about pharmaceuticals, were added to your pages. Hackers usually get in through an insecure directory, outdated CMS software, or a third-party plugin.
Hacked: URL injection. New pages you did not create were added, sometimes with code that redirects visitors or makes your server attack others. Check example URLs, find the code that generates them, and remove it.
Deceptive pages (social engineering). Pages that pretend to be a trusted entity, or push visitors to share a password, call a support number or download software. Fix the pages. If you believe Safe Browsing classified a page in error, use the report option Google links to.

What success looks like: Each issue has a named cause and a plan.

Step 4: Clean the site

You can restore affected files or directories from the last good backup, or remove the unwanted content and files yourself. Fix every example Google listed and then search for more: use site: searches, search your source files, and compare against a clean copy of your CMS and plugins. Remove files and accounts that you do not recognize, such as new administrator users, which is a common sign of a hack.

Do not stop at the visible symptom. Hackers often leave a way back in, and a restored page can be re-infected within hours if the entry point remains open.

What success looks like: Fetching the example URLs again returns clean responses with and without a Google referrer.

Step 5: Close the way in

Google's guidance on how sites get hacked names common causes: compromised passwords, missed security updates and insecure themes or plugins. Match your fixes to them:

Change passwords for hosting, FTP or SFTP, the database, the CMS and email accounts used for the site. Use a unique password for each, and turn on two-factor authentication where offered.
Update the server software, your CMS and every plugin and theme. Remove plugins and themes that are no longer maintained.
Delete unused administrator accounts and review file permissions.
Take extra care with free plugins or themes from untrusted sources.

HTTP security headers can reduce some risks but will not clean an infected site. See Add HTTP Security Headers for what they do and do not cover.

What success looks like: The entry point is identified or all common ones are closed.

Step 6: Request a review

When all issues are fixed on all pages, select Request Review in the Security issues report. Describe what you found, what you changed and what the outcome was. Google says a review can take from a few days to a few weeks.

Do not resubmit before you get a decision. Sending a request when the issue is not fixed can lengthen the turnaround for the next request or even get you marked as a repeat offender. If you recently bought the site and it had issues before you owned it, say so in the request.

What success looks like: The report shows your review as pending, then the issues disappear.

Step 7: Monitor afterward

Keep the backups of the infected state for a while, then monitor file changes, new users and unusual traffic. Warning signs include unusual traffic spikes from unrelated search terms, visitors reporting malware, newly created accounts with administrator privileges and suspicious new pages. Search Console emails you about new security issues, but your own monitoring is faster.

What success looks like: You have a routine that would notice the next compromise.

Final verification checklist

The Security issues report lists no active issues, or only issues in review.
Example URLs fetch clean with and without a Google referrer.
No unknown files, pages or administrator accounts remain.
Passwords are changed and two-factor authentication is on where available.
Server software, CMS, plugins and themes are current.
Your review request describes the cause, steps and results.
You have a written record of the incident.

Common mistakes to avoid

Opening infected pages in your browser. Fetch with cURL or the URL Inspection tool instead.
Cleaning only the listed examples. The list is a sample. Search for more.
Restoring a backup without closing the entry point. The site can be hacked again.
Requesting a review too soon. An unfixed request can slow the next one.
Ignoring cloaked content. If the page looks clean to you, test it with a Google referrer and the URL Inspection tool.
Resubmitting while a review is pending. Wait for the decision.
Fixing only one issue type. If the report lists several, fix them all.

Frequently asked questions

How long does a security review take?

Google says a review can take from a few days to a few weeks. You are told the outcome in Search Console.

My site looks fine. Why is Google reporting a hack?

Hackers often use cloaking to show clean pages to site owners. Check with the URL Inspection tool and a Google referrer.

Is a security issue the same as a manual action?

No. A manual action means a reviewer found a spam policy violation. Security issues cover hacked content, malware and social engineering. See Search Console Manual Actions.

Do I need a developer?

Often. Cleaning malware means reading code and server settings. If that is outside your skills, involve your host or a security professional.

What if the warning is wrong?

If you believe Safe Browsing classified a page in error for deceptive content, Google provides a report option. Confirm first by checking the pages carefully.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.