You log into your site one morning and find a red warning banner in Google Search Console. Your stomach drops. The Google Search Console security issues report is telling you something is wrong, maybe malware, maybe hacked content, maybe a social engineering attack. Whatever it is, Google has flagged your site, and that means visitors might already be seeing scary browser warnings instead of your homepage.
For small business owners, this situation can feel paralyzing. Your website is how customers find you, and a security flag can tank your traffic overnight. At Avatar Website Design, we build and maintain websites for small businesses every day, and security problems like these are exactly why we stress the importance of ongoing website maintenance and monitoring. We’ve helped clients work through these issues firsthand, and this guide reflects that experience.
Below, you’ll learn exactly what the Security Issues report is, how to identify what triggered the warning, and the specific steps to fix each type of security problem and get your site back in good standing. We’ll walk through the process from start to finish so you can take action quickly and confidently, even if you’re not technical.
What the Security Issues report shows
The Security Issues report is one of the most critical tools inside Google Search Console, and it only becomes prominent when something has already gone wrong on your site. You’ll find it under "Security & Manual Actions" in the left sidebar. When you open it, you’ll see either a clean green confirmation that no issues were detected or a detailed breakdown of specific security warnings Google found. Each warning includes a description of the problem type and, in most cases, a sample list of affected URLs. That list is your starting point for fixing the problem.
Where to find it in Search Console
Log into Google Search Console, select your property from the top-left dropdown, and navigate to "Security & Manual Actions" followed by "Security Issues" in the left menu. If you manage multiple websites under one account, check each property separately. A warning on one domain does not carry over to another, even if both sites share the same hosting account. Once you open the report, you’ll see a status summary at the top and a breakdown of each detected issue below it, with example URLs showing exactly where Google found the problem.
Google can take days or even weeks to discover security problems on your site, meaning by the time a warning appears in the report, the issue may have already impacted real visitors.
The three main warning categories
The google search console security issues report groups problems into three distinct categories. Reading the category label carefully before you start any cleanup work matters because each type requires a different fix and points to a different root cause.
| Category | What it means | Common examples |
|---|---|---|
| Malware and unwanted software | Harmful code installed on your site that damages or compromises visitors’ devices | Injected scripts, fake download prompts, drive-by downloads |
| Hacked content | Content added to your site by an attacker without your permission | Spam pages, hidden keyword stuffing, redirects to unrelated sites |
| Social engineering | Pages that trick visitors into giving up sensitive information or taking harmful actions | Fake login forms, phishing pages, deceptive download buttons |
A hacked content warning means an attacker has already modified or added pages to your site. A social engineering warning means your site, or third-party content loaded by your site, is actively deceiving visitors. Both are serious, but they point to different causes and require different cleanup steps.
What Google does when it detects a problem
When Google identifies a security issue, it adds your site to its Safe Browsing database. That database feeds directly into Chrome, Firefox, Safari, and other major browsers, triggering a full-screen red warning page that visitors see before they can reach any of your content. For a small business, that warning can stop incoming traffic almost completely within hours of the flag going active.
Your site stays flagged until you fix the underlying problem and manually request a review inside Search Console. Google does not remove the warning automatically, even after you fully clean the infection. A Google reviewer manually checks your site before clearing the flag, and that process can take anywhere from a few days to a few weeks depending on the issue type and current review volume. The faster you start cleanup, the sooner you can submit that review and get your site back in front of customers.
Step 1. Confirm the warning and affected URLs
Before you touch any files or plugins, you need to know exactly what Google flagged and where. Open the Security Issues report in Search Console and read the warning label carefully. The report tells you the category of the problem (malware, hacked content, or social engineering) and lists sample URLs that triggered the detection. Don’t assume the issue is limited to just those examples. Google samples a subset of affected pages, which means the actual scope of the problem could be larger than what you see at first glance.
Verify the warning is real
Not every security warning means your server was directly breached. Some social engineering flags come from a third-party ad network or an embedded script that loaded deceptive content on your pages without you placing it there. Open one of the flagged URLs in a browser you don’t normally use, or paste it into Google’s Safe Browsing transparency report to see what Google currently detects on that page. This step confirms whether the threat is still active or whether a previous plugin update or hosting action already removed part of it.
Always test flagged URLs from a device you don’t use for banking or sensitive logins, since active malware can attempt to compromise any device that loads the page.
Run the check on at least three to five of the sample URLs, not just one. A single clean result does not mean your site is safe, especially if the infection only affects certain page templates or URL patterns.
Build a full list of affected URLs
The sample URLs in the google search console security issues report are a starting point, not a complete picture. You need to expand your scope before cleanup begins. Use this process to build a thorough list:
- Copy every example URL from the Security Issues report into a spreadsheet.
- Go to Search Console > URL Inspection and test each flagged URL individually to see what Googlebot last crawled.
- Run a Google Safe Browsing site status check on your root domain to see if Google flags the whole site or only specific pages.
- Search Google for
site:yourdomain.comand scan the results for unexpected pages or spam content you did not create. - Check your hosting file manager or FTP for recently modified files, especially inside
wp-content/uploadsor theme directories if you run WordPress.
This spreadsheet becomes your cleanup checklist in Step 2, so the more thorough you are here, the fewer surprises you’ll run into during the fix.
Step 2. Clean malware, spam, and deceptive pages
With your list of affected URLs ready, you can start the actual cleanup. The approach you take depends on which warning category the google search console security issues report flagged on your property. Malware requires you to find and remove injected code, hacked content means deleting unauthorized pages and files, and social engineering flags mean you need to eliminate deceptive elements, whether they live on your server or inside a third-party script your site loads. Work through each category that applies to your site before moving on.
Remove malware and injected code
Malware almost always arrives through outdated plugins, themes, or CMS core files that an attacker exploited to push a script onto your server. Start by logging into your hosting control panel and checking your file modification timestamps. Any PHP or JavaScript file modified on a date you don’t recognize is a candidate for review.
If you run WordPress, use a security scanner available through your hosting provider’s built-in tools to identify modified core files before you touch anything manually.
On WordPress, compare your core files against the official versions using FTP or the file editor. For non-WordPress sites, your hosting provider may offer a malware scanning tool directly in cPanel or Plesk. If the infection is severe and you have a recent clean backup, restoring from that backup is often faster and more reliable than hunting down every modified file individually.
Delete hacked spam pages and content
Attackers who gained access to your site often created new pages to rank for pharmaceutical keywords, gambling terms, or foreign-language spam. These pages won’t appear in your normal CMS dashboard because the attacker either added them directly to your file system or used a plugin backdoor. Pull your spreadsheet from Step 1 and visit each suspicious URL. If a page exists and you did not create it, delete the file directly through your hosting file manager or FTP client.
After deleting the files, check your .htaccess file for unauthorized redirect rules. A common attack pattern adds RewriteRule entries that send visitors to external spam sites without any visible sign on your end. Remove any rules you did not write, then save the file.
Fix social engineering issues
A social engineering flag often traces back to a third-party script or ad tag your site loads from an external source. Open your site’s source code and look for any <script> tags pointing to domains you don’t recognize. Remove unfamiliar scripts from your theme files or tag manager. Once removed, confirm the fix by checking your domain in Google’s Safe Browsing transparency report to verify the deceptive content is no longer detected before you request a review.
Step 3. Secure the site so it stays fixed
Cleaning the infection only solves half the problem. If you skip hardening your site after cleanup, the same attacker, or a different one, can get right back in through the same door. Before you submit anything through the google search console security issues report, you need to close every entry point that made the breach possible in the first place. Skipping this step means you could be running the entire cleanup process again within weeks.
Update everything and remove what you don’t need
Outdated software is the leading cause of site infections. After cleanup, update your CMS core, every plugin, and every theme to the latest available version immediately. Do not leave inactive plugins or themes sitting on your server, even if they are deactivated. Attackers can still exploit vulnerable files inside deactivated plugins, so delete anything you are not actively using.
- Update WordPress core at Dashboard > Updates
- Update every active plugin and theme on the same screen
- Delete deactivated plugins and unused themes entirely
- Log into your hosting control panel and update PHP to the current stable version your host recommends
Running an outdated PHP version is one of the most commonly overlooked vulnerabilities that allows re-infection after a cleanup.
Change credentials and lock down file permissions
Every account connected to your site needs a fresh, unique password after an infection. Change your CMS admin password, your hosting account password, your FTP credentials, and any database user passwords inside your hosting control panel. If you reused the same password across multiple accounts, change all of them. Reusing credentials gives attackers a second way back in if they captured your login during the breach.
Set correct file permissions after updating your credentials. Files on a WordPress site should be set to 644, and directories should be set to 755. You can update permissions in bulk through your hosting file manager or FTP client. Never set any file or folder to 777, since that allows anyone to write to those locations.
Files: 644
Directories: 755
wp-config.php: 600
Add two-factor authentication to your CMS admin login using a plugin from the official WordPress plugin repository. Two-factor authentication means a stolen password alone is no longer enough to reach your admin panel, which blocks the most common reentry method attackers use after a site has been cleaned.
Step 4. Request a review and recover in search
Once your site is clean and hardened, you’re ready to tell Google about it. The google search console security issues report includes a direct path to submit a review request, and you need to use it because Google will not lift the warning on its own. Before you click anything, do a final check: visit three to five of the originally flagged URLs, run your domain through Google’s Safe Browsing transparency report, and confirm that no malicious content or deceptive elements remain on any page. Submitting before your site is fully clean will result in a failed review, which delays recovery further.
Submit the review request in Search Console
Open the Security Issues report, expand the warning you received, and look for the "Request a Review" button at the bottom of the issue detail. Clicking it opens a text field where you need to describe what you did to fix the problem. This description matters. A vague submission like "I fixed it" is far less effective than a specific account of the actions you took. Use the template below as a starting point:
Issue found: [Name the warning category, e.g., Hacked content / spam pages]
Root cause: [e.g., Outdated plugin exploited to inject files]
Actions taken:
- Removed all unauthorized files and spam pages via file manager
- Restored clean backup from [date] / Manually removed injected code from [files]
- Updated CMS core, all plugins, and all themes to current versions
- Changed all admin, FTP, hosting, and database passwords
- Enabled two-factor authentication on CMS admin account
- Set correct file permissions (files: 644, directories: 755)
- Verified site clean via Google Safe Browsing transparency report
Fill in the specifics from your own cleanup work before you submit. Each issue type listed in the report needs its own separate review submission, so if your report shows two categories, submit two separate requests.
What to expect after submission
Google’s review timeline varies, but most security review requests receive a response within a few days to a few weeks. You’ll get a notification inside Search Console and by email when the review is complete. If Google confirms your site is clean, the Safe Browsing warning in Chrome and other browsers clears within roughly 72 hours of the review decision. Your organic search rankings may take additional time to recover as Googlebot recrawls your pages and reindexes them without the security flag attached.
If your review comes back as failed, Google will tell you which category still needs attention, giving you a specific starting point for a second round of cleanup before you resubmit.
Get back to a clean security report
Working through google search console security issues takes real effort, but the process is straightforward when you follow each step in order: confirm the warning, clean the infection, secure every entry point, then submit your review request with a detailed description. Skipping any step risks a failed review or a repeat infection, so treat the checklist as complete only when every item is done.
Your site’s reputation with Google and with real visitors depends on staying clean after this experience. Ongoing maintenance including regular updates, strong credentials, and routine backups is what keeps you from running through this entire process again next year. If managing that on your own feels like more than you want to handle, that’s exactly the kind of work we take off your plate. Reach out to the team at Avatar Website Design to learn how our maintenance plans keep your site secure and running without the headaches.