How to Remove the “Deceptive Site Ahead” or “Dangerous Site” Warning From Your Website

Visitors open your site and get a full-screen red warning instead: Deceptive site ahead or Dangerous site in Chrome (the wording depends on the browser version and the reason), Deceptive Website Warning in Safari, a similar page in Firefox, or This site has been reported as unsafe in Microsoft Edge. Google results may show This site may be hacked or This site may harm your computer under your listing. Antivirus apps may block the page outright.

These warnings come from blocklists that browsers and security products check before loading a page. Your site landed on one because something on it, usually something an attacker put there, looked like phishing or malware to an automated scanner. Traffic and sales fall off a cliff until you clean up and ask each list to review you. This guide covers finding the cause behind the listing and getting off each list. The general cleanup routine is in FG-05; redirect injections are covered in depth in FG-23.

What is happening

Google Safe Browsing crawls the web, flags pages that host phishing (called social engineering), malware or unwanted software, and publishes the list. Chrome, Firefox, Safari and Android all use Safe Browsing data, which is why one listing shows up in nearly every browser at once. Microsoft runs its own list, SmartScreen, used by Edge and Windows. Security vendors such as Norton and McAfee run their own reputation systems for their browser extensions and antivirus products.

Warning or label	Maintained by	Where to check	How to get reviewed
Chrome, Firefox, Safari red page; Google search labels	Google Safe Browsing	Transparency Report site status; Search Console Security issues	Review request in Search Console
Edge “reported as unsafe”; Windows download warnings	Microsoft SmartScreen	Visit in Edge	Report link on the warning page, or Microsoft’s site submission portal
Norton browser extension and antivirus	Norton Safe Web	Norton Safe Web site lookup	Dispute from the site’s rating page (account needed)
McAfee WebAdvisor and antivirus	McAfee	McAfee site lookup tool	McAfee’s rating dispute process
Other antivirus and firewall products	Each vendor	VirusTotal URL scan shows many vendors at once	Each vendor’s false positive form

A listing can cover a single URL, a folder, or the whole domain. Phishing listings often name one deep path, for example a login page inside /wp-content/ or /.well-known/, while malware listings often cover the whole site because the injected script runs on every page.

Before you start

• Access: owner access to Google Search Console (verify a Domain property with a DNS TXT record if you have none; you need it to request a review), your hosting panel, SSH or SFTP, and WordPress admin.
• Backup and evidence: copy the files and database before cleaning, and screenshot the warning, the Transparency Report status and the Security issues page. You will quote them in your review request.
• Where commands run: find, grep and wp run in an SSH terminal on the server, in the site folder that holds wp-config.php (some hosts call the tool wp-cli). curl runs on your computer (built into macOS and Linux; curl.exe in Windows PowerShell). Words in CAPITALS are placeholders explained under each command.

Step 1: Find out exactly which list flagged you and why

Google’s Safe Browsing site status

Open Google’s Transparency Report, go to the Safe Browsing section and search for your domain. The result says whether the site is currently considered unsafe and, often, what kind of problem was found (for example, sending visitors to harmful websites, or attempting to trick visitors into sharing personal information). Anyone can use this page, so it is also how you check a client’s site before you have their logins.

Search Console Security issues

In Search Console, open Security issues under Security and Manual Actions. This is the most precise source: it names the category and lists sample URLs. Common categories:

Category	What it usually means on a WordPress site
Deceptive pages (social engineering)	A phishing kit uploaded to a subfolder, imitating a bank, delivery firm, email provider or cloud login
Malware	Injected JavaScript loading code from another domain, or drive-by downloads
Harmful downloads	Executable or app files on your server that scanners classify as malicious
Uncommon downloads	A legitimate file you host that has too little download history to be trusted yet
Hacked: code, content or URL injection	Injected scripts, spam text or generated spam pages (see FG-22 and FG-23)
Deceptive embedded resources	A third-party script or ad on your page showing deceptive content

Save the sample URLs. Then open each one with URL Inspection, run Test live URL and view the tested HTML, because cloaked phishing and malware often hide from your own browser.

Other vendors at a glance

Submit your homepage and each sample URL to VirusTotal’s URL scan. It shows which security vendors currently flag it. Write down every vendor that does; you will contact them in Step 5. Treat one or two obscure vendors flagging an otherwise clean site with some suspicion, but never ignore Google, Microsoft, Norton or McAfee.

Step 2: Hunt for phishing kits

A phishing kit is a folder of HTML, CSS, images and PHP that imitates a login page and sends whatever victims type to the attacker. Attackers upload it through a vulnerable plugin, a stolen admin or SFTP password, or a file manager plugin, then link to it from phishing emails. Your site is the unwitting host. It is the most common cause of a Deceptive site ahead listing.

Recently created folders

Kits arrive as a new folder, sometimes several. List folders created or changed recently:

find . -type d -ctime -DAYS -not -path "./wp-content/cache/*" -not -path "./wp-content/upgrade*" | sort

Replace DAYS with how far back to look; start with 30, and extend it to reach before the date in the Security issues report. -type d limits the search to folders. -ctime uses the time the folder’s entry last changed on disk, which an attacker cannot easily backdate the way they can a file’s modified date. The two -not -path parts skip cache and update folders that change constantly. Good output: plugin and theme folders you recently updated, and this month’s uploads folder (for example wp-content/uploads/YYYY/MM). Bad output: a folder with a brand name, a random name, or a name like secure, login, verify, update, office or webmail, especially inside wp-content/uploads, a theme folder, wp-includes, wp-admin or .well-known.

index.php files where they should not be

Most kits have an index.php or index.html entry page so the link in the email can end at the folder name:

find wp-content/uploads .well-known -iname "index.*" -exec ls -l {} \; 2>/dev/null
find . -iname "index.php" -newer wp-includes/version.php -not -path "./wp-content/plugins/*" -not -path "./wp-content/themes/*"

Type both as shown. The first lists every index file in uploads and in .well-known (the folder used for SSL validation, which should hold only small validation files); 2>/dev/null hides the error if a folder does not exist. Some plugins place an empty index.php containing only a comment in uploads folders to stop directory listing; open each one, and anything longer than a few lines is suspect. The second lists index.php files modified after your last WordPress core update, outside plugin and theme folders. On a clean site it lists only the root index.php, if anything.

Leftover archives and kit signatures

Attackers often upload the kit as a zip file and unpack it on the server, leaving the archive behind. Kits also need somewhere to send stolen details, often an email address or a messaging bot. Search for both:

find . -iname "*.zip" -not -path "./wp-content/updraft/*" -newer wp-includes/version.php -exec ls -l {} \;
grep -rliE "api\.telegram\.org|chat_id|\$_POST\[.?(pass|password|email|card)" --include=*.php wp-content/uploads .well-known 2>/dev/null

In the first line, -iname "*.zip" finds zip files in any letter case, and the -not -path part skips a common backup plugin’s folder (add more exclusions for your own backup tool). A zip you did not create, next to a folder of the same name, is a kit archive. In the second line, -r searches subfolders, -l prints only file names, -i ignores case and -E enables the pattern. The pattern finds PHP that talks to the Telegram bot interface or reads password, email or card fields from a submitted form. Real plugins do not live in uploads, so any match there is almost certainly malicious.

When you find a kit, look inside before deleting it: the files often name the brand being imitated and the address the stolen data goes to. Note those for your report, copy the folder into your evidence archive off the server, then delete it from the site.

Step 3: Rule out malware and harmful downloads

If the category is Malware, the cause is almost always injected JavaScript that loads code from another domain or redirects visitors. Follow FG-23 to find and remove it from the database, theme files and JavaScript files.

For Harmful downloads, look for executable files that should not be on a website:

find . -type f \( -iname "*.exe" -o -iname "*.apk" -o -iname "*.msi" -o -iname "*.scr" -o -iname "*.dmg" \) -exec ls -l {} \;

Type it as shown. The \( and \) group the alternatives, and each -o means “or”, so it lists files with any of these program extensions. Most WordPress sites should return nothing. If you deliberately offer software downloads, the listing may be about one of your own files: check it on VirusTotal, and sign your software with a code-signing certificate so it builds reputation.

For Deceptive embedded resources, the problem is a third-party script or ad network. Remove or pause the ad and widget tags one at a time and confirm with the URL Inspection live test which one carried the deceptive content.

Whatever you found, close the way it got in (outdated plugin, stolen password, file manager plugin) before you request any review. FG-05 covers that sequence.

Step 4: Request a Google review

Only request a review once you are confident the site is clean. Confirm by running the URL Inspection live test on every sample URL: removed kit pages should now return a 404, and pages that carried injected scripts should show clean HTML.

Then, in Security issues, confirm that you have fixed the issues and click Request review. A box asks you to describe what you did. Reviewers want specifics, not reassurance. A good request covers:

• What you found, using the category name from the report.
• Where it was: file paths, folders, database tables.
• What you removed, and confirmation that the sample URLs now return 404 or clean content.
• How the attacker got in, and how you closed it.
• What you changed to stop it happening again.

For example, adapted to your own findings:

We found a phishing kit imitating BRAND_NAME in the folder FOLDER_PATH, uploaded on YYYY-MM-DD through an outdated PLUGIN_NAME plugin. We deleted the folder and two others from the same upload, and the listed URLs now return 404. We removed PLUGIN_NAME, updated all remaining plugins and themes, reinstalled WordPress core, reset all admin, hosting and database passwords, removed an unknown admin account, and blocked PHP execution in the uploads folder.

This is text you paste into the review box, not a command. Replace BRAND_NAME with the company the kit imitated, FOLDER_PATH with the path you deleted, YYYY-MM-DD with the date you found in file times or logs, and PLUGIN_NAME with the entry point. Keep it factual and short. Do not argue that the listing was unfair if it was not; a reviewer can see the history.

Google states the following review times: phishing reviews take about a day, malware reviews take a few days, and hacked-with-spam reviews can take up to several weeks. The result arrives in Search Console messages and by email. If approved, the warnings come off; browsers update their copies of the list over the following hours. If rejected, the message usually lists URLs that are still a problem. Fix them before trying again: Google warns that requesting a review before the issue is fixed lengthens the next review. Sites that repeatedly go from clean to harmful can be classed as repeat offenders under Safe Browsing policy, and lose the ability to request reviews for a period.

Step 5: Clear the other blocklists

A Google review does not clear anyone else’s list. Work through each vendor that flagged you in Step 1:

• Microsoft SmartScreen: open your site in Edge. The warning page has a link under more information to report that the site does not contain threats. Microsoft also accepts URL submissions for review from site owners through its security intelligence submission portal. Describe the cleanup the same way you did for Google.
• Norton Safe Web: look up your domain on Norton’s Safe Web site, sign in with a free Norton account, and use the option to dispute the rating or request a re-evaluation.
• McAfee: check your domain with McAfee’s site lookup tool, which shows its category and risk rating, and follow its dispute or review process.
• Other vendors shown on VirusTotal: each vendor has its own false positive or URL review form, usually found by searching for the vendor name plus “false positive URL”. Rescan on VirusTotal after a few days to see who has updated.

Vendors do not publish fixed review times, and some recheck automatically. Keep a simple table of vendor, date submitted, ticket number and outcome, so you can follow up.

Step 6: Avoid getting flagged again

• Block PHP in uploads. On Apache or LiteSpeed, a .htaccess file in wp-content/uploads containing a <FilesMatch "\.php$"> block with Require all denied inside stops uploaded scripts from running. On Nginx, add location ~* ^/wp-content/uploads/.*\.php$ { deny all; } to the server block. Many security plugins can set this for you. It would have stopped many kits from working even after upload.
• Remove forgotten installs. Old copies of the site in folders like /old/, /dev/ or /staging/ never get updated, and attackers find them. Delete them or move them off the public web.
• Remove file manager and upload plugins you do not need, and any form that accepts file uploads without type checks.
• Watch your status. Keep Search Console notifications on, and check the Safe Browsing status page after any security scare. A site-scanning service or security plugin that alerts on new files catches kits before Google does.
• Audit third-party scripts twice a year and remove the ones you no longer use.

Advanced: working out how big the phishing incident was

Your access logs tell you when the kit arrived, how it got there, and roughly how many people visited it. That matters for your review request, for the brand being imitated, and sometimes for legal reasons. On the server, find every request to the kit folder:

grep "KIT_PATH" ACCESS_LOG | awk '{print $1, $4, $6, $7, $9}' | head -30
grep "KIT_PATH" ACCESS_LOG | awk '{print $1}' | sort -u | wc -l

Replace KIT_PATH with the folder path (for example /wp-content/uploads/YYYY/MM/FOLDER_NAME/) and ACCESS_LOG with your access log file (your hosting panel’s logs section shows where it is; use zgrep for .gz files and include older rotated logs). In the common log format, awk field 1 is the visitor’s IP, 4 the time, 6 the method, 7 the path and 9 the status code. The first command shows the earliest requests; the second counts distinct IP addresses that requested the kit.

Reading the output: the first request is often the attacker checking the kit works, sometimes from the same IP that made a POST to a plugin file or wp-admin/admin-ajax.php moments earlier. Search the log for that IP to find the upload request, which identifies your entry point. POST requests to the kit’s own files are form submissions, meaning victims typed their details. A large distinct-IP count suggests the kit was linked from a mass email campaign.

If victims submitted data, consider reporting the kit to the brand it imitated (most large companies publish an abuse or phishing report address) and to the Anti-Phishing Working Group. The stolen data went to the attacker, not to your database, but you hold the evidence that helps the brand protect its customers.

When to contact your host

Open a ticket if you cannot reach your access logs, if kits keep reappearing, or if your host has received abuse complaints about the phishing pages (that path is covered in FG-25). Send:

• The Security issues category, the sample URLs, and the Transparency Report status, with UTC dates.
• The paths of every kit folder you removed and their creation times.
• Log lines showing the upload request, if you found it.
• What you changed to close the entry point.

If phishing pages or malware return after a clean removal, the attacker still has a way in; work through FG-26.