Why has Google marked my website as dangerous?

Has Google marked your website as dangerous or deceptive? Learn what the warning means, what to check first and how to clean the site and request a review.

Open a support ticket

If Google has marked your website as dangerous, it has detected, or suspects, that one or more pages could put visitors at risk.

You may see:

  • a red warning page before the website opens
  • a “Dangerous” label in the browser
  • a warning next to your website in Google Search
  • a message saying that the site may be hacked
  • a notification in Google Search Console
  • reports from customers who can no longer access the website

This does not necessarily mean that every page is infected. It also does not automatically mean that your business intentionally published harmful content.

However, the warning should be treated as a real security incident until the cause has been identified. Google may display warnings when it detects hacked content, malicious code, phishing, deceptive pages, unsafe downloads or other behavior that could harm visitors.

The warning will not normally disappear just because the homepage looks correct again. The site must be investigated, cleaned, secured and then submitted to Google for a security review.

What does Google mean by “dangerous”?

Google uses different messages depending on the problem it believes it has found.

You might see warnings such as:

  • “This site may harm your computer”
  • “This site may be hacked”
  • “Deceptive site ahead”
  • “The site ahead contains malware”
  • “The site ahead contains harmful programs”

The exact wording may vary according to the browser, device and type of issue.

These warnings can appear in two main places:

Google may place a warning next to your result or remove some compromised pages from its results.

In the browser

Google Safe Browsing may show a full-page warning before Chrome or another supported browser opens the website.

The fact that you cannot reproduce the warning does not prove that it has disappeared. Safe Browsing warnings can depend on the page, browser or browsing context. Google recommends using the Security Issues report in Search Console as the main reference for understanding whether a detected problem is still active.

Does this mean that my website has been hacked?

Often, but not always.

Google groups security problems into several categories.

Hacked content

Someone may have added pages, links or text without your permission.

Examples include:

  • spam pages about products or services you do not sell
  • links to unrelated websites
  • pages created in another language
  • hidden text
  • unexpected redirects
  • new administrator accounts

Malware or malicious code

The website may contain code designed to harm visitors, redirect them, load unwanted software or perform actions that the site owner did not intend.

Phishing or deceptive content

A page may imitate a trusted service or attempt to persuade visitors to:

  • enter a password
  • provide payment details
  • download a file
  • call a fraudulent support number
  • share other confidential information

Unsafe third-party content

The problem may come from something embedded in the website, such as:

  • an advertising network
  • an external script
  • an iframe
  • a compromised widget
  • a third-party download
  • an external resource loaded by a plugin

A website owner may therefore receive a warning even when the visible page content appears normal. Google’s Security Issues report distinguishes hacked content, malware, unwanted software and social-engineering problems.

First: do not ignore or bypass the warning

When you see a red warning page, avoid repeatedly clicking through it to inspect the website as a normal visitor.

In some cases, loading an infected page may expose the device to malicious content. Compromised websites can also behave differently depending on the visitor, location, browser or referral source, which means the site owner may not see the same content that Google or a customer sees.

A safer first step is to:

  • take a screenshot of the warning
  • record the affected URL
  • note when the problem was first reported
  • check Google Search Console
  • contact the person responsible for the website or hosting

If customers are being directed to a warning page, consider temporarily pausing advertising campaigns and other promotions that send visitors to the affected website. This is a practical precaution to avoid paying for unusable traffic and exposing more people to the warning.

D4Hub can help you confirm the problem without asking you to open suspicious pages or interpret technical security reports alone.

Check Google Search Console

If your website is connected to Google Search Console, open the relevant property and go to:

Security & Manual Actions → Security Issues

The report may tell you whether Google detected:

  • malware
  • injected code
  • injected pages
  • hacked content
  • deceptive pages
  • harmful downloads
  • links to harmful downloads
  • suspicious login pages
  • deceptive embedded resources

The report may also show example URLs.

These URLs are only samples. Fixing the listed pages does not necessarily fix the entire website. Google states that the examples in the report may not include every affected page, so the whole site must be checked.

If you do not have access to Search Console, check whether it is managed by:

  • your web agency
  • a developer
  • an SEO consultant
  • an internal marketing account
  • the person who originally launched the website

D4Hub can also help verify the property and interpret the report.

What should you do immediately?

You do not need to start deleting files or reinstalling WordPress.

The most useful first actions are organisational rather than technical.

1. Record what you are seeing

Collect:

  • a screenshot of the warning
  • the exact message
  • the affected URL
  • the date and approximate time
  • emails received from Google or the hosting provider
  • reports received from customers
  • unusual behavior you noticed recently

WordPress recommends documenting the symptoms and recent changes when dealing with a suspected compromise. These details help establish what happened and when it may have started.

2. Check what changed recently

Ask whether anyone recently:

  • installed or updated a plugin
  • changed the theme
  • added a tracking script
  • connected a new advertising platform
  • uploaded a file
  • created a new administrator
  • changed the hosting configuration
  • migrated or restored the website
  • shared access credentials with an external supplier

A recent change is not automatically the cause, but it provides a useful starting point.

3. Contact the hosting provider

The hosting provider may be able to confirm:

  • whether malware was detected
  • whether suspicious files were quarantined
  • whether unusual server activity occurred
  • whether the account was temporarily suspended
  • whether a clean backup is available
  • whether other websites in the same account were affected

Hosting support may help contain the incident, but it may not perform a complete WordPress investigation or remove the original vulnerability.

4. Contact the website developer or security specialist

A proper cleanup may require access to:

  • WordPress
  • website files
  • the database
  • hosting logs
  • backups
  • DNS or CDN settings
  • Search Console

Google’s own guidance notes that malware cleanup can require understanding code and server configuration. When that is outside the site owner’s expertise, involving qualified support is the recommended option.

Can I simply restore a backup?

Sometimes, but a restore is not automatically a complete solution.

A backup can be useful when:

  • it was created before the compromise
  • you know approximately when the problem started
  • it contains clean files and a clean database
  • restoring it will not remove important recent information

However, a restore may also:

  • reintroduce the vulnerability that allowed the attack
  • contain malware that was already present but undetected
  • overwrite recent orders, leads or content
  • remove useful evidence
  • fail to clean other websites or files in the same hosting account

After restoring a backup, you still need to understand how the website was compromised and remove the original access point. Otherwise, the site may be infected again.

For an ecommerce, subscription or membership website, a restore should also account for transactions and user data created after the backup.

D4Hub can help verify whether a backup is suitable and plan the restore without unnecessarily losing recent data.

Can I just install a security plugin?

A security plugin can help detect suspicious files and improve protection, but installing one after the warning appears does not prove that the website is clean.

A scan may:

  • identify known malicious patterns
  • flag modified files
  • detect unexpected administrators
  • highlight outdated components
  • block some suspicious activity

It may not:

  • recognize every type of malware
  • understand legitimate custom code
  • identify the original access method
  • clean external accounts
  • repair damaged business functionality
  • confirm that every hidden backdoor has been removed

A security plugin can be one tool in the investigation, not the entire response.

What does a complete cleanup involve?

The exact process depends on the problem, but a reliable investigation usually follows these stages.

1. Contain the incident

The first objective is to reduce further damage.

This may involve:

  • restricting access to the website
  • temporarily disabling affected functionality
  • removing unsafe downloads
  • blocking malicious redirects
  • suspending compromised accounts
  • preserving a copy of the current files and database

Whether the site should be taken fully offline depends on the type and severity of the incident.

2. Identify the affected areas

The investigation should determine:

  • which URLs are affected
  • whether the problem is in files, database content or both
  • whether the website contains unexpected users
  • whether another site in the same hosting account is compromised
  • whether the issue comes from a plugin, theme or external resource
  • whether malicious code is still active

The URLs provided by Google are examples, not a complete inventory.

3. Remove the malicious content

Depending on the incident, this may include removing:

  • injected scripts
  • modified files
  • spam pages
  • hidden links
  • unknown administrator accounts
  • malicious scheduled tasks
  • unsafe downloads
  • deceptive external resources
  • database injections
  • unauthorized redirects

Simply deleting the page mentioned by Google may leave the mechanism that created it still active.

4. Remove the original vulnerability

After cleaning the visible infection, the cause must be addressed.

This may require:

  • updating WordPress
  • updating or replacing vulnerable plugins
  • updating the theme
  • correcting unsafe file permissions
  • removing abandoned software
  • resetting compromised accounts
  • replacing exposed credentials
  • reviewing hosting and server configuration

Without this stage, the website can be reinfected after apparently successful cleanup.

5. Test the website

Before requesting a Google review, check:

  • public pages
  • WordPress administration
  • contact forms
  • login and registration
  • checkout and payments
  • subscriptions
  • redirects
  • tracking scripts
  • scheduled tasks
  • mobile and desktop behavior

The objective is to confirm both that the malicious behavior has stopped and that the legitimate website still works.

6. Request a security review

Once every issue has been resolved, return to the Security Issues report in Search Console and select Request Review.

The request should explain:

  • what caused the problem
  • what was removed or repaired
  • what was done to prevent it from returning
  • how the result was verified

Google advises fixing all listed issues across the entire site before requesting the review. Reviews can take from several days to several weeks, depending on the case. Repeatedly submitting new requests before receiving a decision does not speed up the process.

What should you avoid doing?

Avoid:

  • assuming the warning is a false positive without investigating it
  • repeatedly opening suspicious pages
  • deleting files at random
  • restoring the oldest available backup immediately
  • updating everything before preserving the current state
  • removing only the example URL shown by Google
  • installing several security plugins at once
  • requesting a review before the cleanup is complete
  • sharing passwords through ordinary email
  • bringing the site back online without testing it

A partial cleanup can make the warning disappear temporarily while leaving the website vulnerable to another compromise.

What if the website looks completely normal?

This is common.

Malicious content may:

  • appear only to visitors from certain locations
  • target mobile users
  • activate only after a click from Google
  • appear intermittently
  • be visible only to search crawlers
  • exist on hidden URLs
  • be loaded from an external resource
  • redirect only some visitors

Google specifically notes that compromised content may use cloaking to hide itself from the site owner. The inability to reproduce the issue is therefore not sufficient evidence that the site is safe.

Check the Security Issues report and the example URLs before assuming that the warning is incorrect.

Could Google have made a mistake?

A mistaken classification is possible, but it should be considered only after the website and any embedded third-party resources have been checked.

For example, a legitimate page might include:

  • an external script that has been compromised
  • an advertisement that redirects visitors
  • a download that Google considers unsafe
  • a login design that appears deceptive
  • a third-party resource over which you have limited control

If the site has been thoroughly checked and the reported behavior is genuinely absent, Search Console provides a process for requesting a review. Google also provides reporting options for pages believed to have been classified incorrectly.

Do not submit a review saying only that the site “looks fine.” Explain what was checked and why you believe the classification is no longer applicable.

When should you ask for specialist support?

Ask for technical support when:

  • Google reports malware or injected code
  • customers are seeing browser warnings
  • the website redirects to unrelated pages
  • unexpected pages appear in Google
  • the hosting provider has suspended the account
  • you cannot access WordPress
  • you do not know when the compromise started
  • no clearly clean backup is available
  • the site processes payments or personal data
  • more than one website shares the hosting account
  • the warning returns after an initial cleanup
  • you are unsure whether all backdoors have been removed

You do not need to identify the malware yourself before asking for help.

D4Hub can support any stage that feels unclear or blocking, from reading the Search Console report to completing the cleanup and requesting Google’s review.

How D4Hub can help

A D4Hub investigation can include:

  • reviewing the warning and Search Console report
  • identifying affected URLs and website components
  • checking WordPress files, database content and users
  • investigating suspicious plugins, themes and external resources
  • coordinating with the hosting provider
  • removing malicious code, spam pages or redirects
  • evaluating backups and recovery options
  • updating or replacing vulnerable components
  • resetting and securing access
  • testing essential website functions
  • preparing and submitting the Google security review
  • recommending measures to reduce the risk of reinfection

You can contact D4Hub at the beginning of the incident, after receiving information from your hosting provider or after attempting an initial cleanup.

If a step in this guide is unclear, you do not need to proceed alone. Explain what you are seeing and what access or information you currently have. D4Hub can identify the safest next action.

Open a support ticket

What information should you include in the support request?

Provide whatever is easily available:

  • the website URL
  • a screenshot of the warning
  • the exact warning message
  • the approximate time it first appeared
  • any Search Console notification
  • example URLs listed by Google
  • emails from the hosting provider
  • recent website changes
  • whether WordPress is accessible
  • whether a recent backup exists
  • whether the site handles orders, subscriptions or user data
  • any cleanup attempts already made

Do not worry if you cannot access Search Console or understand the technical description. D4Hub can help retrieve and interpret the missing information.

Do not send passwords, private keys or complete credentials in an unsecured message.

For hands-on users: additional checks

The following checks are intended for people who are comfortable with Search Console, hosting panels and WordPress administration.

They are useful for collecting evidence, but they do not replace a complete security cleanup.

Review the Security Issues report

For every reported issue:

  • record the issue category
  • save the example URLs
  • note when Google first detected the problem
  • check whether multiple issue types are listed
  • avoid assuming that the samples represent every affected page

Google requires all reported security issues to be addressed before the site is submitted for review.

Search for unexpected pages

A Google search restricted to your domain can reveal content you did not publish.

For example:

site:example.com

You can combine the search with terms unrelated to your business, such as unexpected pharmaceutical, gambling, loan or luxury-product terms.

This does not detect every compromise, but it may reveal injected pages that are already indexed. Google recommends domain-restricted searches as one way of finding unexpected hacked content.

Review WordPress users

In WordPress, open:

Users → All Users

Check for:

  • unknown administrators
  • recently created accounts
  • unexpected email addresses
  • roles that appear more powerful than necessary

Do not simply delete an account before understanding whether it created content or modified the website. Record the details first.

Review recent changes

Check:

  • recently modified plugins
  • recently modified themes
  • newly installed components
  • code-snippet plugins
  • header and footer script tools
  • tracking integrations
  • advertising scripts
  • file-manager plugins
  • recent deployments

A modified date alone does not prove that a file is malicious. WordPress updates and legitimate development can also change files.

Check other websites in the same hosting account

When several websites share the same account, cleaning only the visibly affected installation may not be sufficient.

Check whether:

  • other sites contain suspicious files
  • the same administrator credentials are reused
  • shared directories are writable
  • one compromised installation could access another

Preserve evidence before replacing files

Before a large-scale restore or reinstall:

  • make a copy of the current files
  • export the current database
  • record the active plugins and theme
  • preserve relevant server logs
  • note which credentials and accounts existed

This evidence can help identify the point of entry and determine whether the cleanup was complete.

D4Hub can perform or review these checks when you do not have the required access or are unsure how to interpret the results.

FAQFrequently asked questions

After the site has been cleaned, secured and submitted for review, Google states that a security review can take from a few days to a few weeks. The warning should not be expected to disappear immediately after files are changed.

Not necessarily. Malicious content may exist in plugins, themes, uploads, the database, server configuration or another website in the same hosting account. Reinstalling the WordPress core addresses only part of the installation.

Changing passwords is an important security measure, but it does not remove malicious files, injected database content or vulnerable software. Credentials should be secured as part of a wider cleanup.

You can technically submit a request, but Google advises correcting all security issues across the website first. An incomplete request is unlikely to resolve the warning and may delay the process.

The affected content may be limited to certain pages, devices, users or browsing contexts. Google also notes that Safe Browsing warnings are context-dependent, so they may not appear identically for every visitor.

No. A manual action generally concerns violations intended to manipulate search results. A Security Issue concerns behavior that may harm users, such as hacking, phishing or malware. The two reports are separate in Search Console.

Yes. Share the hosting report and explain what actions were already performed. D4Hub can check whether the infection was fully removed, investigate the original vulnerability, test the website and support the Google review.

Yes. D4Hub can help identify who manages the property, verify access where possible and determine what Google has reported.