You notice unfamiliar pages on your domain, a browser warning or a sudden change in search traffic. Before calling the domain “spammy”, identify the symptom and the system reporting it. A compromised website, a search-policy finding and an email blocklist entry require different checks.
Start a short incident record: the exact address, what changed, when it was noticed and who can investigate. The aim is to reach a supported diagnosis and a sensible next action, rather than collect reassuring scores from unrelated tools.
Capture the symptom before changing the site
Save the warning text, affected URL, notification date and relevant screenshots. Note recent hosting, plugin, DNS, content or account changes. If a colleague received an email alert, verify it through the provider’s official account instead of following an unexpected sign-in link.
Describe the observation precisely. “Visitors report a dangerous-site warning” is useful. “Google has blacklisted everything” assumes both the scope and the cause. An unfamiliar search result, a failed page and a recorded traffic decline are also separate observations.
For basic service responsibilities, our domain and hosting guide helps identify the provider and account involved. Ask the person with authorised access to preserve the relevant evidence.
Check the correct owner reports
In the appropriate Search Console property, examine the Manual Actions report. It records manual search-policy findings for that property, with their stated scope. A vendor score or a public search cannot substitute for this owner-account evidence.
Then check the separate Security Issues report, which addresses findings such as harmful or compromised content. Google’s documentation explains that example URLs may be only a sample. Fixing one visible page is therefore not proof that the whole problem has been resolved.
If you lack access, mark the reports unreviewed and arrange access through the legitimate owner or administrator. Do not write “no issues” where the real result is “could not inspect”. Our website warning guide provides supporting context.
Keep search, safety and email findings apart
| Observation | Next evidence |
|---|---|
| Manual search-policy finding | The property’s report, affected scope and official correction instructions. |
| Harmful-content warning | Security report and a technical investigation of affected services. |
| Rejected outbound email | Rejection text, sending identifier and the named receiving or blocklist system. |
| Third-party score increase | Provider, target, definition and the underlying evidence. |
The Spamhaus Domain Blocklist concerns domain reputation for filtering. An IP listing concerns another identifier and may involve the sending infrastructure. Neither is a public Google manual-action report, and an email rejection does not automatically establish a hacked website.
Inspect changes under your control
Review unexpected content, redirects, user accounts and relevant change records with your administrator or host. If compromise is suspected, use an appropriate technical investigation rather than casually opening potentially harmful pages. Preserve evidence before cleanup and identify how the change occurred, not just where it appeared.
For search-policy concerns, compare the actual implementation with Google’s spam policies. The issue is the practice and its purpose, such as deceptive behaviour or manipulative links, rather than a blanket list of words that legitimate sites must never use.
In a hypothetical incident, an unauthorised redirect begins after an account was compromised. The supported response is to investigate access and restore the affected service, then verify the correction. Removing a keyword from an unrelated article would not address that finding.
Use the right review route and record closure
Google’s spam, phishing and malware reporting page accepts reports about suspected problems. It is not a tool that displays whether your own domain has been marked as spam. A remediation review belongs in the process specified by the relevant owner report or reputation provider.
Record the change made, responsible person and verification date. Keep unresolved findings open and revisit them after the relevant review. If no spam or security evidence supports the original suspicion, investigate availability, measurement and other plausible causes.
Our metrics guide helps interpret scores without treating them as verdicts. Close the check with a specific conclusion and its limits, not a promise that the domain is universally free of spam.