A browser warning saying your site is deceptive or dangerous stops essentially all traffic. It is also recoverable, and the recovery has a specific order: find out who flagged it, fix the cause, then request a review, requesting first simply fails.
Work out what is actually flagging it
Several different systems produce similar-looking warnings, and they are cleared in different places.
A browser warning ("deceptive site ahead" or "the site ahead contains malware") comes from a safe-browsing service the browser uses. Cleared through that service's review process.
A security-tool warning from antivirus or a corporate filter. Cleared with that vendor.
Mail rejections are a blocklist, which is separate from the website entirely. For that case, see What to Do When Your IP or Domain Is Blocklisted.
A search console message naming a security issue is the most useful of all, because it usually names the sample URLs.
Read the exact wording before doing anything. It tells you which of these you are dealing with.
Assume the flag is correct
The instinct is that it must be a mistake. It usually is not.
These systems flag sites because a crawler saw something: injected script, a redirect to another site, a page that appeared and was not yours. The site looks fine to you because the injected behaviour often targets visitors arriving from search, or from mobile, and not someone typing the address directly.
So check properly rather than concluding it is wrong. Load the site from a phone on mobile data, and try arriving via a search result instead of the address bar: conditional injections are specifically written to hide from the owner.
Find it before you fix it
Search console lists sample URLs when it has them, and those are the fastest route to the actual problem.
Then check the usual places: files modified around the time it started, any .php file in the uploads directory, and unexpected administrator accounts. How to Clean Up a Hacked WordPress Site explains the full sweep, including the database, which reinfects a site whose files you cleaned.
Third-party scripts are worth checking too. An advertising or widget script that was compromised can flag your site without anything on your server being touched, and the fix is removing the script rather than cleaning your files.
Then request a review, once
When the site is genuinely clean, request the review through the search console or the service's own form.
Say what the cause was and what you did. A review requested with the problem still present is refused, and repeated failed requests take longer to get a second look.
Reviews typically take a day or two. The warning is removed when it passes, and browsers pick that up within hours.
A warning that is not about malware
Two cases people mistake for a compromise.
A certificate problem produces a full-page warning that reads as dangerous to most visitors. It is an expired or mismatched certificate, not an infection, and it is fixed in minutes. For reading which, see SSL Certificate Troubleshooting Guide.
A deceptive-content flag on a legitimate site can be triggered by a login form on an insecure page, or by a form asking for details in a way that resembles phishing. That is a genuine finding about your page in place of a compromise, and the fix is changing the page.
Check what visitors and search engines see
Your own browser is the least reliable witness: it has your cookies, your cache, and possibly an address the injected code deliberately ignores.
Use an online scanner that fetches the page as a crawler, and check the page source rather than the rendered view. Injected code is usually near the top or the bottom of the source and often obfuscated, which makes it easy to spot even when you cannot read it.
Compare a fetch with a search-engine user agent against a normal one. A difference between the two is the signature of a conditional injection, and it is the thing that explains "it works for me".
Expect a lag after cleaning
The warning does not disappear the moment the site is clean. The service has to re-crawl and the browser has to update its list.
That is hours rather than days once a review passes, and it means an impatient second request while the first is pending does nothing except delay it.
Traffic recovers afterwards, and not instantly: some of it was lost to people who will not return, and rankings can move if the site was flagged for a long period.
Reduce the chance of a repeat
The flag was a symptom. The cause is nearly always an outdated plugin or theme, a weak password, or nulled software with a backdoor built in.
Update everything, delete what you are not using rather than deactivating it, put two-factor on administrator accounts, and get backups onto a schedule with enough history to reach back past an infection you did not notice for a fortnight. There is more on the set in How to Secure WordPress Against Vulnerabilities.
Then add monitoring that would tell you sooner. Being told by a browser warning means it had already been happening long enough for a crawler to notice. How to Set Up and Read Uptime Monitoring walks through watching from outside.
A site that is unreachable under load rather than blocked needs the log read before anything is concluded. How to Recognise and Handle a DDoS Attack has the detail.
A complaint about content rather than about security follows a different path, with a deadline. How to Respond to a Copyright or Takedown Complaint explains handling it before your host has to.