Can a hacked site lose its crawl budget due to Google security alerts?

Why does Google maintain crawling of a compromised site?

Google's logic relies on a strict separation between content discovery and result display. Crawling serves to index pages, detect changes, and identify technical issues. If Googlebot stopped crawling a hacked site, it would not be able to verify if the correction had been made.

In practice, a compromised site continues to be crawled at the same frequency — the crawl budget remains intact. On the other hand, display in the SERPs shifts to a degraded mode: red warning "This site may harm your computer," partial or total filtering depending on severity, and sometimes temporary deindexing of infected pages. The crawler itself does not change its pace.

What’s the difference between crawling and display in this situation?

Crawling refers to the exploration phase: Googlebot visits URLs, downloads HTML, follows links, and fills the index. This phase is not affected by security alerts. The bot continues its work, collects signals, and updates data.

Display is the retrieval phase in search results. This is where Google applies security filters: warning banners, removal of certain pages from the SERPs, displaying a message like "Site not recommended." The user does not see the site, even though Google continues to crawl it in the background.

Should you wait for Google to recrawl after correction to lift the alert?

No, the processes are distinct. Once the malicious code is removed, you must request a manual review in Search Console. Google will not automatically lift the alert, even after recrawling clean pages. The review goes through a human or semi-automated examination separate from the crawl pipeline.

The post-correction recrawl allows Google to see that the malware has disappeared, but it is the explicit request for review that triggers the lifting of the warning. Without this step, the alert can persist for weeks, even if the site is clean and crawled daily.

• The crawl budget is not impacted by security alerts — Googlebot continues to explore normally.
• Display in the SERPs is degraded: warnings, filtering, dramatic drop in CTR.
• Correction must be swift: every day with a warning = loss of traffic, erosion of trust.
• Forensic analysis is mandatory: identify the infection vector to avoid immediate recurrence.
• The request for review is manual: Google does not automatically lift the alert after recrawl.

Is this statement consistent with field observations?

Yes, it aligns with documented cases. Compromised sites continue to appear in crawl logs with identical or similar frequencies to those before the infection. The drop in traffic observed stems exclusively from the collapse of CTR — impressions may also drop, but as a cascading effect: fewer clicks = low relevance signal = gradual degradation.

However, Mueller's statement remains descriptive and does not detail the mechanisms. Nothing about the review timeline, nothing about differentiated treatment based on the type of infection (phishing vs. malware vs. SEO spam), nothing on the indirect impact of a prolonged alert. [To be verified] whether a prolonged alert without correction eventually triggers a crawl reduction to conserve resources.

What ancillary risks are not mentioned in this statement?

First risk: contamination of backlinks. A hacked site that injects spam or redirects to malicious pages may see its natural backlinks removed by the source sites, which detect the infection and cut the links. Loss of PageRank, weakening of the link profile — indirect but lasting SEO impact.

Second risk: effect on user trust. A site displayed with a red warning for several days loses some of its loyal audience. Even after the alert is lifted, direct traffic may take weeks to return. Users remember "this site is not safe" and do not return immediately, even after correction.

In what cases does this rule not apply strictly?

If the infection leads to a complete manual deindexing (extreme case: mass phishing, site fully turned into a malware farm), then crawling may indeed be reduced. A site removed from the index loses its priority in the crawl queue — logical: why crawl intensively a site that will not be displayed for weeks?

Another case: recurring infection. A hacked site, corrected, then reinfected within 48 hours may suffer an implicit crawl penalty. Google detects the pattern "fake correction, malicious code still present" and may decide to reduce the crawl frequency to avoid wasting resources on a clearly insecure site. [To be verified] — empirical observation, no official confirmation.

What should be done immediately after a security alert?

Isolate the infection vector as a priority: outdated plugin, compromised FTP password, vulnerability in a custom theme. Cleaning the code without understanding the cause = guaranteed recurrence within 72 hours. Analyze server logs, search for recently modified files, server antivirus scan — everything must be scrutinized.

Next, completely remove the malicious code: do not just remove the visible script, check for injections in the database, modified .htaccess files, suspicious cron jobs. A well-designed malware leaves backdoors — a secret door that allows for reinfecting the site even after superficial cleaning.

How to speed up the removal of the alert in Search Console?

Request a review only after complete cleaning and multi-layer verification. Google rejects requests if traces of infection remain — and each rejection extends processing time. Before submitting, scan the site with at least two independent tools (Sucuri, Wordfence, VirusTotal for suspicious files).

Document corrective actions in the request: “Removal of [specific file], update of [plugin], change of FTP/SSH credentials, complete audit of admin users”. A vague request like "the problem is resolved" is not enough — Google wants proof that you have identified the root cause.

What mistakes should be avoided to prevent exacerbating the situation?

Classic error: restoring an infected backup. If the hack dates back three weeks and your last clean backup is two months old, you lose two months of content. Identify the exact date of compromise before any restoration — check backups with an antivirus scan before bringing them online.

Another error: ignoring the alert hoping it will disappear. It will not disappear. Each day without correction = cumulative traffic loss, erosion of domain authority, risk of blacklisting by other services (browsers, third-party antivirus, public blacklists). The impact rapidly exceeds Google.

• Immediately isolate the infection vector (logs, modified files, compromised access)
• Clean all malicious code, including backdoors and database injections
• Verify with multiple scanning tools before requesting the review
• Change all passwords (admin, FTP, SSH, database)
• Update all plugins, themes, CMS — leave no vulnerabilities open
• Precisely document corrective actions in the review request