Google's warning
A red screen appears before your page, your result carries the label "This site may be hacked," or Search Console reports a security issue. These are three distinct signals, sent by three different systems, and they clear through the same work. Here is where each one comes from, the order of operations, and what the review request demands of you.
Three signals, three origins
They usually arrive together, and are mistaken for a single thing. The distinction matters: they originate in different places, they cost different things, and only one of the three tells you what Google has seen.
"This site may be hacked"
The mention appears beneath your title in the results, and it comes from Google Search: pages added by someone else were found on your domain. The link is still clickable, and almost no one clicks it. It's the most discreet of the three signals, often the first, and the one you discover while searching for your own name.
The red screen before the page
It comes from Google Safe Browsing, a list that Chrome consults and that other browsers and tools adopt as their own. It stands between the visitor and your page whatever the source: a customer typing your address from memory sees it too. It's the costliest signal, and the only one whose effect reaches well beyond Google.
The one signal that speaks to you
In Search Console, the "Security issues" section names the category identified — hacked content, malware, social engineering — and generally provides sample URLs. It's the only place where Google says what it saw and where it saw it, and it's from there that the review request is submitted. If the property still needs to be verified on your end, that's your first step.
The order of operations
Each step protects the next. Requesting the review before establishing what has changed means spending a review for nothing; cleaning up before making a copy means losing the evidence of what happened.
Read what Google wrote, in Search Console
Open "Security Issues" and note three things: the category assigned, the date, and the URLs given as examples. If the property is still unverified, verify it now, via the DNS record or the verification file, depending on what your host allows. As long as it remains unverified, you're subject to the other two signals with no channel to respond.
Keep a copy before touching anything
Copy the files AND the database in their current state, onto separate storage. This state, however damaged it may be, is the only thing that will later allow you to date what happened, and to answer a host, an insurer or a client. Once cleaned up, it's gone forever.
See your pages the way Google sees them
The URLs given as examples often open a perfectly normal page from your own machine: what was added is frequently conditional — served to the crawler, or only to visitors arriving from a search. The "URL Inspection" tool tests the URL live and shows the HTML returned: that's where what your browser hides from you appears. Compare the two — the difference is the issue.
Take back your access, starting with the hosting
Hosting control panel password, then FTP and SSH, then the database, then your content management system accounts. Changing the admin password first is the natural reflex, and the least useful: whoever controls your FTP will put it back within the minute. Take the opportunity to remove any accounts you no longer recognise.
Draw up the exact list of what has changed
This is where the human eye reaches its limit, and it's exactly the limit the review request will ask you to hold. A live site carries tens of thousands of files, and the one that was added looks just like its neighbours. The question that can actually be answered is the reverse one: how many files can account for their presence, and which ones cannot?
Restore, then remove the added pages
Restoring vendor files to their authentic versions handles the bulk of the work; what belongs to you alone — themes, settings, add-ons — has to be read through by hand. The foreign pages, for their part, must stop existing: a deleted URL returns 404 or 410, and your sitemap becomes accurate again. A page that redirects to your homepage is still a page that exists.
Request the review once the work is done
The request goes through Search Console, under "Security Issues." State what was found, what was fixed, and what closes the point of entry: a review that lands on a single forgotten page restarts the whole cycle. The processing time is Google's alone. The red screen and the label in search results then clear on their own, on Google's schedule — and the tools that pick up the list follow on theirs.
Establish what has changed, and be able to show it
The analysis answers the question raised in point 05 by turning it around: instead of looking for what is known to be bad, it asks each file to justify its presence, by comparing it with the authentic code published by its vendor. Whatever is justified is counted; the rest is named, one by one, with its date and its location.
You receive the exact number, the list of files, the probable point of entry, and three signed documents: the findings, the certification of the state achieved, and the item you can hand over to your host or to your client. This is the substance of the review request, and it is what makes it short. The service costs €99 per site; with the restoration operation and the new analysis that verifies it, €199.
Each of these documents can be verified with us, free of charge and forever, by anyone — that's what makes them enforceable. We do not, however, offer any free analysis, and that is deliberate: it would almost always answer "nothing found", the expected good news, delivered without proof, to people who didn't need it. We sell certainty, not anxiety.
One caveat, written here as it is on every document: a fully accounted-for site is a site in which every file has been held to account — which is already a great deal, and still something other than a secure site. A weak password, or an up-to-date but vulnerable extension, remains beyond the reach of a file comparison.
After the clearance, the following month
A warning cleared once often returns a second time, through the same door, because the door was left open — and the second visit costs more than the first, in visibility as in trust. What really changes what comes next boils down to two things: knowing the same day that an executable file has moved, and knowing that an extension installed on your site has been pulled from the official repository or that a vulnerability has since been disclosed. Monitoring does both, including on days when your site itself hasn't budged. It costs €99 per site per year, as a single payment, with no renewal.
It states things precisely: when the attestation breaks, it announces that this site differs from the one that was attested. Your own deployment breaks it in exactly the same way — which is why you re-attest after every deployment, and why a break with no deployment deserves a close look.
What Google saw, established file by file
You'll have the exact number, each file named, the likely date, and three signed documents that someone else can verify.