Your site is clean and the warning is still there

The part the cleanup quote usually stops before

A cleanup has a satisfying shape. Someone finds the injected code, removes it, closes the hole, and hands the site back. That work is measured in hours, and there is a whole market of specialists who do it well.

Then the site sits there, cleaned, with a red interstitial in front of it and no traffic, and the questions start. How long does this last? Who decides? Why is the warning still up when the malware is gone?

The answers are all in Google's documentation. Some cleanup vendors do sell delisting as a separate line item; many quotes simply end at the removal. The removal is a technical job. What follows is a procedural one, it runs on someone else's queue, and the two things that make it take a month instead of a week are both done by the site owner.

Why can you not see the warning yourself?

Because the warning depends on the browsing context. It is not a property of your site that you can check by visiting it.

Google says this plainly, and also says what to trust instead:

Google SafeBrowsing displays warnings to users based on the browsing context. Therefore you may or may not be able to reproduce the warnings. However, you should rely on the Security Issues report as the source of truth to verify whether any security issues exist for your site, or if they have been fixed.

• Security Issues report, Google Search Console Help

This single sentence resolves the argument that starts almost every one of these incidents. The owner opens the site, sees it load normally, and concludes it is fixed. A customer on a different machine sees a full-page red warning. Both are looking at reality; neither is looking at the source of truth.

It also means the first practical step is not a browser at all. It is opening the Security Issues report and reading what is listed there - including the date the issue was first detected, which is usually the first honest answer to "how long has this been going on".

Should you open the infected pages to look at them?

No, and Google says so directly:

Because malware often spreads by exploiting browser vulnerabilities, opening an infected malware page in a browser may damage your computer.

• Security Issues report, Google Search Console Help

The same documentation offers a different way to look, and it doubles as a diagnostic: many hacks only reveal themselves when the visitor arrives from a search engine. Google's own suggested command sets the referrer for that reason:

curl -v --referer "https://www.google.com" \
  --user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FSL 7.0.7.01001)" \
  http://www.example.com/page.html

If the page returns clean HTML to you and a redirect to whoever came from Google, that is not a mystery, it is cloaking, and it is why "I checked and it looks fine" keeps being wrong.

How long does the review actually take?

Days to weeks, and Google gives the range twice in the same document.

For a security issue after you have fixed it:

A review can take from a few days to a few weeks to complete.

• Security Issues report, Google Search Console Help

And for reconsideration requests generally:

Most reconsideration reviews can take several days or weeks, although in some cases, such as link-related reconsideration requests, it may take longer than usual to review your request.

• Security Issues report, Google Search Console Help

Note what this range is not. It is not a queue you can pay to skip, and it is not a number the person who cleaned your site controls. Cleanup vendors that sell tiers are generally selling how fast they start. How fast Google answers is outside that purchase, and everything after the cleanup runs on Google's clock.

What is the first mistake that extends it?

Cleaning most of it.

Fixing the issue on just some pages will not earn you a partial return to search results.

• Security Issues report, Google Search Console Help

The report shows a sample of affected URLs, and Google says so on the same page. So a cleanup that works through the listed examples and stops has not finished - it has finished the sample. Requesting a review at that point starts the second mistake.

What is the second, and much more expensive, mistake?

Asking again before the answer arrives.

Submitting a reconsideration request when the issue hasn't been fixed can cause longer turnaround time for the next request, or even get you marked as a repeat offender.

• Security Issues report, Google Search Console Help

And the repeat offender label is not a scolding. It is a lockout with a fixed term:

Once Safe Browsing has designated a site as a Repeat Offender, the website owner will be unable to request additional reviews via Search Console. Repeat Offender status persists for 30 days, after which the website owner will be able to request a review.

• Google Safe Browsing Repeat Offenders Policy, Google Search Central, last updated 10 December 2025

Read those two together and the trap is obvious in hindsight. The site is down, every day costs money, the owner is anxious, so they resubmit. The resubmission is judged against a site that is not fully clean. Now the review queue is longer, and in the bad case the site cannot request a review at all for thirty days.

The behaviour that feels like urgency is the behaviour that produces the month.

What does a correct single pass look like?

In the order Google's own documentation implies:

1. Read the Security Issues report before you read the site. It lists the issue types, a sample of affected URLs, and the date of first detection.
2. Fix every issue listed. If the report shows several categories, all of them block the return, so the first one is only the first one.
3. Treat the URL list as a sample. Find the rest by the same signature across the whole site, including the files that generate pages rather than the pages themselves.
4. Check what the site returns to a search engine referrer, using the command above.
5. Close the way back in before requesting anything. A review that passes on a site that gets reinfected next week produces exactly the alternating pattern the repeat offender policy exists to catch.
6. Then request the review, once. Google asks a good request to do three things explicitly: explain the exact issue, describe the steps taken to fix it, and document the outcome of those efforts.
7. Wait without resubmitting. You will be emailed. Sending a second request while the first is open is the mistake that costs the month.

What about the rankings afterwards?

Recovery of the search listing is a separate clock from removal of the warning, and it is the one nobody can put a date on. The warning is a switch: it is either shown or it is not. Position in results is an accumulation, and the hacked URLs Google indexed do not vanish the moment the site is clean.

The practical consequence is that "we are back" happens twice, weeks apart, and an owner who is only told about the first one will think the second never came.

Who does which part?

Splitting this correctly is most of the value, and it is worth being blunt about where the line falls.

Malware removal belongs with a specialist. The state after they finish is the part that tends to have no owner: a site that technically works but has lost functionality along with the infection, an open Security Issues report that nobody has answered, and an anxious owner deciding alone how often to resubmit.

That second half is bounded, procedural work with a known shape - the same category as a site that is down while the host insists everything is fine, and the same reason the update that broke it in the first place usually turns out to be the cheaper problem.

When this is a job to hand over

Doing it yourself is reasonable when the report lists one issue type, you can read the code that was injected, and you can tell which files legitimately belong to your site.

It stops being reasonable at two specific points: when the cleanup removed the infection and the functionality together, and when the site came back from the removal vendor with nobody answering the Security Issues report since. If the report still lists issues, that is unfinished removal, and it belongs back with the vendor who did the removal. Putting the site back together afterwards, and running the review process to its end, is scoped work with a known shape and a known price - that part is what Fix S and M are for.

Sources

• Security Issues report - Google Search Console Help, read 18 August 2026. Warnings shown by browsing context, the report as source of truth, the danger of opening infected pages, the curl command with a search referrer, partial fixes earning no partial return, review times, and the resubmission warning.
• Google Safe Browsing Repeat Offenders Policy - Google Search Central, last updated 10 December 2025. Repeat offender designation, the block on requesting reviews, and the 30 day duration.