Security

How to Recover Your Site from Google Search Console Security and Manual Action Alerts

  • 14 min read
  • Hostragons Team
How to Recover Your Site from Google Search Console Security and Manual Action Alerts

Google Search Console Security and Manual Action alerts indicate that Google has detected spam, malware, hacked content, deceptive pages, or any violations against its quality guidelines on your site. To recover your site, you must first accurately read the type of alert, examine the affected URLs and server logs, close any security vulnerabilities, clean up harmful or guideline-violating content, complete technical SEO checks, and then submit a reconsideration request through Google Search Console with supporting evidence.

This guide was prepared as a practical recovery plan for the Hostragons blog. The aim is not just to remove the alert but to ensure that similar issues do not recur by permanently securing hosting, CMS, plugins, SSL, backup, access, and content processes. We have listed the steps in a way that is actionable, measurable, and minimizes SEO impact, especially for those managing WordPress, custom software, e-commerce sites, or corporate websites.

What Are Google Search Console Security and Manual Action Alerts?

This section in Google Search Console encompasses two main areas: security issues and manual actions. Security issues typically appear when the site poses a risk to users. For example, malware, unwanted downloads, phishing pages, hacked content, or deceptive redirects might have been detected. Manual actions indicate that Google’s quality team has imposed a penalty on a specific section or the entire site. This penalty can directly reduce your organic visibility.

While the two types of alerts may seem similar, the approach to resolving them is different. In security issues, the priority is to stop the attack, clean files, and ensure user safety. In manual actions, it is necessary to correct guideline violations, remove spam signals, and present Google with a clear report of the fixes made. In both cases, it is inappropriate to hastily send just a reconsideration request; the root cause must be identified, and a permanent solution implemented first.

Types of Alerts and Their SEO Effects

When you receive an alert, the first task is to read the full name and scope of the notification in the Search Console panel. Some actions may only affect specific URLs while others can encompass the entire site. A manual action applied to the entire site can increase traffic loss between 30% to 90% within days. Security alerts can present users with a red warning screen in Chrome and Google results, driving the click-through rate nearly to zero.

Types of Alerts and Their SEO Effects
Alert TypePossible CausesSEO ImpactInitial Action
MalwareInjected files, malicious scripts, broken pluginsSecurity warning in results, traffic lossFile scanning and comparison with a clean backup
Hacked ContentHidden spam pages, Japanese keyword attacks, cloakingIndex bloat and ranking dropURL inspection, sitemap and server log analysis
Deceptive PagesPhishing, fake login screens, misleading formsBrowser blockage and loss of trustRemove suspicious page and form codes
Artificial LinksPurchased links, link farms, excessive anchor usageManual ranking lossBacklink audit, removal or disavow
Spam ContentAutomatically generated pages, doorway pages, duplicate contentPenalty for the page or site as a wholeDelete content, noindex, or rewrite

1. Gather Evidence Without Panic

Immediately deleting the site, removing all plugins, or submitting a reconsideration request upon seeing the alert is misguided. First, document the current situation. Take a screenshot of the Search Console, note the date of the alert, list the affected sample URLs, and outline the changes made in the last 30 days. This list should include new plugin installations, theme updates, hosting migrations, adding ad codes, access for content editors, backlink efforts, and interventions from external agencies.

In an experienced recovery process, the most valuable data is the timeline. For instance, if a plugin was updated on March 12, unknown PHP files appeared on the server on March 14, and a Google security alert was received on March 16, the root cause is likely a plugin vulnerability or FTP access. Therefore, keep logs, file dates, and access records before starting fixes.

Quick Checklist

  • Document the Search Console alert text and sample URLs.
  • Check organic traffic changes over the last 7, 14, and 30 days.
  • Review file modification dates from the hosting panel.
  • List FTP, SSH, CMS admin, and database users.
  • Verify the date and cleanliness of the last backups.
  • Backup the sitemap, robots.txt, and .htaccess files.

2. Analyze Server and File for Security Issues

If there is a security alert, simply checking the CMS panel is not enough. Attackers often add PHP files to the wp-content/uploads folder, write hidden redirects into .htaccess, inject obfuscated JavaScript into the index.php file, or add malicious iframes to content fields in the database. If you are using WordPress, compare the core files with the original package. If using custom software, perform a diff analysis with the Git repository or clean backup.

On the server side, review status codes such as 200, 301, 302, 403, and 500 together. A URL may appear clean to a normal user while returning different content to Googlebot. This is known as cloaking and increases the risk of both security issues and manual actions. If there are heavy POST requests from unknown IPs in the log files, excessive use of admin-ajax.php, brute-force attempts on wp-login.php, or access to random PHP files, an attack may still be ongoing.

Files and Areas to Check

  • index.php, wp-config.php, functions.php, and .htaccess files.
  • Executable PHP, phtml, or suspicious js files within the uploads folder.
  • Database entries containing base64, eval, script, iframe, and unknown external domain records.
  • Theme-related header, footer, and template files.
  • Cron jobs, unknown users, and API keys.
  • Google Tag Manager, ad scripts, and third-party widget codes.

At this stage, a quality hosting infrastructure makes a significant difference. An isolated account structure, up-to-date PHP versions, WAF, malware scanning, and regular backups can reduce recovery time to hours. For suitable infrastructure options, check Hostragons Web Hosting and for projects requiring more control, visit Hostragons VPS Server.

3. Clean Hacked Content and Index Bloat

In hacked content alerts, the problem is not always visible on the homepage. Your site may have thousands of spam URLs generated beneath it. Content related to Japanese, gambling, pharmaceuticals, fake support, and coupons are particularly common. The Page Indexing report in Search Console, site:yourdomain.com searches, server logs, and the sitemap file should be checked together. If there are URLs in the sitemap that you did not create, the attacker may have automated content generation.

The cleanup has three goals: remove harmful content, prevent its recurrence, and signal correctly to Google. Truly deleted spam pages should return a 404 or 410 status code. Spam codes that have infected valuable pages should be cleaned and remain as 200. Redirecting all spam URLs to the homepage with a 301 redirect to deceive search engines is not advisable; this method can further degrade quality signals.

Implementable Steps for Index Cleaning

  • Extract the spam URL list and categorize the URLs.
  • Clean real pages, remove fake pages with a 410 Gone status code.
  • Rebuild the sitemap with only clean and canonical URLs.
  • Ensure that you have not accidentally blocked important cleanup areas with robots.txt.
  • Request re-crawling for critical pages using the Search Console URL Inspection tool.
  • Do not consider the process complete until the spam-producing file or database record is found on the server.

4. Correct Violations According to Quality Guidelines in Case of Manual Action

Manual actions often relate to content or link quality. Google’s goal is to protect users from manipulative results. Therefore, while making corrections, it is vital to change not only the visible symptoms but also the processes causing the manipulation. For example, if you received a penalty for artificial links, disavowing a few backlinks may not be sufficient; you need to stop the link-buying campaign, mark sponsored links with rel sponsored, and clean up unnatural anchor texts.

In the case of thin or automatically generated content alerts, the number of pages matters. If 7,000 out of 10,000 pages on a site provide no real user value, Google may perceive the site as low-quality overall. Make a decision for each URL: enhance, merge, noindex, or delete. Product variations, tag archives, search results pages, and filter URLs often present issues in this analysis.

Examples of Manual Action Corrections

  • Unnatural Incoming Links: Gather link sources from Ahrefs, Semrush, Search Console, and server referral data. Remove what can be removed, and add the rest to the disavow file.
  • Unnatural Outgoing Links: Remove sold or reciprocal links. Mark advertising links as sponsored or nofollow.
  • Spam Content: Remove automatically generated, copied, or pages that do not add value to users or rewrite them with expert editors.
  • Hidden Text and Keyword Stuffing: Clean text hidden by CSS, irrelevant keyword blocks, and manipulative footer links.
  • User-Generated Spam: Apply moderation, captcha, and nofollow rules in comments, forums, and profile areas.

5. Reset Access and Harden Infrastructure

5. Reset Access and Harden Infrastructure

After cleanup, the most critical step is to prevent reinfection. If the attacker's access remains open, the Google Search Console alert may return a few days after it has been lifted. Change all admin user passwords, delete unused accounts, enable two-factor authentication, and use SFTP instead of FTP if possible. Ensure that the database user has only the necessary permissions.

CMS, theme, and plugin updates should not be postponed. However, take a complete backup before performing updates. Outdated PHP versions also pose significant risks. As of 2026, sites running PHP versions without active security support will generate weak signals in terms of both performance and security. An SSL certificate should also be considered mandatory; HTTPS is not just a ranking signal but a fundamental layer for user trust and data integrity. For SSL options, the Hostragons SSL Certificates page can serve as a useful starting point.

Permanent Security Measures

  • Weekly file and database backups; take daily backups for critical sites.
  • Use a WAF and malware scanning system.
  • Limit admin panel login attempts.
  • Keep file writing permissions at a minimum; avoid 777 permissions.
  • Keep the PHP version updated and disable unnecessary modules.
  • Regularly check your domain's DNS records. You can use the Hostragons Domain Lookup page for domain management.

6. Complete Technical SEO Checks

After security cleanup, it is essential to verify that the site is being crawled correctly by search engines. If robots.txt accidentally blocks the entire site, if noindex tags remain, or if canonical tags are incorrect, traffic may not recover even after the alert is lifted. Therefore, technical SEO checks should be included in the recovery plan.

Use the URL Inspection tool for the homepage, category pages, most trafficked content, and conversion pages first. Check if the HTML seen by Google matches the HTML visible to users. Then, resubmit the sitemap. Prevent indexing of URLs with unnecessary parameters. Map 404, 410, 301, and 302 status codes logically. For the first two weeks post-recovery, crawl statistics, indexing reports, and performance graphs should be monitored daily.

Metrics to Track After Recovery

  • Status of the alert in the Security and Manual Actions section.
  • Number of clean pages indexed and number of excluded spam URLs.
  • Changes in organic clicks, impressions, average position, and TO.
  • Server response times and 5xx error rates.
  • Googlebot crawl frequency and purpose.
  • Whether a security warning appears in brand searches.

7. How to Write a Reconsideration Request?

A reconsideration request is a short but evidence-based correction report sent to Google. This document should not use defensive, vague, or marketing language. The Google team wants to see what happened, why it happened, which URLs have been fixed, and what measures have been taken to prevent recurrence. Early submission of the request often results in a rejection. After a rejection, it is possible to resend, but each rejection prolongs the process.

A good reconsideration request consists of four sections. In the first section, acknowledge the problem. In the second section, explain the root cause. In the third section, list the corrections made. In the fourth section, specify the permanent measures taken. If you are applying for a backlink penalty, describe your removal efforts, communication dates, and the disavow file. If applying for a security issue, state the types of files cleaned, users removed, plugins updated, and security measures implemented.

Example Reconsideration Request Template

We have identified a security issue on our site that violates Google’s guidelines. Upon investigation, we found that unauthorized files were uploaded via an old plugin and spam content was generated on some URLs. The relevant plugin has been removed, core files have been compared with a clean backup, spam URLs have been removed with a 410 status, the sitemap has been rebuilt, all admin passwords have been changed, and two-factor authentication has been activated. Server logs have been reviewed, suspicious IPs have been blocked, and regular malware scanning has been enabled. To prevent recurrence, we have established update, backup, and access policies. We kindly request a re-evaluation of our site.

You should tailor this text to your situation. Adding specific data such as file paths, dates, URL counts, and the number of actions taken adds credibility instead of using vague statements. For example, stating that 326 spam URLs were removed with a 410, 4 unauthorized users were deleted, and 17 plugins were updated provides strong signals in terms of E-E-A-T.

8. When Will Traffic Recover?

The removal of the alert does not equate to an immediate return of traffic. With security issues, the alert can be lifted a few days to a few weeks after Google re-crawls. In the case of manual actions, the evaluation period is typically longer. After the alert is lifted, Google needs to re-crawl the pages, recalculate quality signals, and balance user behavior data. This process can vary from 2 weeks to 3 months based on the level of competition, site size, and extent of damage.

During the recovery period, avoid aggressive SEO moves. Publishing hundreds of new pieces of content at once, acquiring quick backlinks, or changing the entire URL structure can complicate recovery. The priority should be reliability, speed, technical cleanup, and user value. Update the pages that generate the most revenue or leads, add expert-level content, strengthen internal links naturally, and complete the communication, about us, privacy policy, and support pages that enhance brand trust.

9. Common Mistakes

Errors made during this process delay the removal of the alert and further harm the site’s organic performance. The most common mistake is to delete only visible harmful code without identifying the root cause. The second mistake is redirecting all spam URLs to the homepage. The third mistake is submitting a superficial reconsideration request for manual action. The Google team often rejects vague and unsupported requests.

  • Restoring an unclean backup and restarting the issue.
  • Using robots.txt to prevent Google from seeing harmful pages, complicating verification of the cleanup.
  • Adding all backlinks to the disavow file, losing natural authority as well.
  • Checking only the homepage and missing spam content in subdirectories.
  • Leaving old themes and plugins in a passive state; passive files can also become attack surfaces.
  • Seeing SSL, DNS, and hosting security as independent from SEO.

A Safer Recovery Process with Hostragons

Google Search Console alerts should often be viewed not only as SEO problems but also as infrastructure and operational issues. Secure hosting, regular backups, up-to-date PHP, SSL, domain checks, and access policies, when combined, accelerate the recovery process and reduce the risk of recurrence. You can create an internal linking structure to strengthen your site’s foundation by exploring topics like Choosing Secure Web Hosting, WordPress Security Measures, What is SSL Certificate, and Website Backup Guide.

In short: properly classify the alert, gather evidence, clean files and content, reset access, verify technical SEO, and only submit a reconsideration request once everything is genuinely fixed. A strong hosting infrastructure and regular security routine are the best insurance for this process. If you wish, you can start a more secure beginning by exploring hosting, domain, and SSL options suitable for your site’s needs through Hostragons.

Frequently Asked Questions

Does a Google Search Console Security and Manual Action alert immediately cause ranking loss?

Yes, especially if there is a site-wide manual action or malware alert, ranking and click-through rates can drop rapidly. Some URL-based alerts may have limited effects, but quick intervention is still necessary.

Should I completely shut down the site when an alert comes?

Not always necessary. It may be sensible to put it in maintenance mode if user safety is at risk. However, the corrected pages must be accessible for Google to verify the cleanup. You should make the decision based on the alert type.

How long does it take for a reconsideration request to be processed?

There is no definite timeframe. Security issues may receive a response within a few days, while manual actions can take weeks. Incomplete cleanup or vague explanations lead to rejections and additional waiting periods.

Should a disavow file be used for every manual action?

No. The disavow should only be used if there is a problem with unnatural incoming links and you cannot remove harmful links. If misused, it can weaken your site’s natural link authority.

Can the same issue recur after the alert is lifted?

Yes, if the root cause is not resolved. If old plugins, weak passwords, open FTP accounts, insecure themes, or poor hosting isolation continue, Google alerts may reappear.

Share this article:

Hostragons Team

Up-to-date guides from our expert team on hosting, servers, and domain names. Let's find the right solution for your project together.

Contact Us