How to Tell if a Website Has Been Hacked

If you suspect your website has been hacked, the fastest way to find out is to check a handful of signals together — what visitors and search engines actually see, what external scanners report, and what has changed on the site. A compromise is not always obvious: the most common attacks today are designed to hide from the owner while quietly abusing your site's reputation. This guide is a defensive walkthrough of the signs of a hacked website, how to confirm a compromise from the outside, and the first steps to take if it has happened.

This is the detection counterpart to how to protect your website from common attacks, and it leans on the same external checks as is this website safe?.

Why a hacked site often looks fine

Start with the most important and counterintuitive point: a normal-looking homepage does not mean your site is clean. The era of attackers defacing your front page with a triumphant message still exists, but it is now the minority. Modern compromises are usually about quietly monetising your site's traffic and search reputation, so they are built to stay hidden:

• Conditional redirects send visitors arriving from a search engine to a scam or malware page, while returning visitors and logged-in admins see the real site.
• SEO spam (often "pharma hacks", counterfeit-goods links, or gambling spam) is injected so it is shown mainly to search-engine crawlers, poisoning your search listings without changing what you see when you log in.
• Cloaking shows different content to bots than to humans, specifically to evade the owner's notice.

The practical consequence: to detect these, you must look at your site the way a stranger or a search engine does, not the way you do as an admin in your usual browser.

The signs of a hacked website

Here are the symptoms to watch for, grouped by where you would notice them.

What visitors experience

• Unexpected redirects to unfamiliar sites, especially from search or on mobile.
• Spam pop-ups, adverts or overlays you did not add.
• Defacement — altered pages, strange messages, or content you did not publish.
• The browser showing a "Dangerous site" / "Deceptive site ahead" warning (driven by Google Safe Browsing).

What search engines show

• Your listings in Google contain spam keywords, foreign-language text, or pages you never created ("This site may be hacked" can appear under a result).
• A flood of junk pages indexed under your domain.
• A sudden, unexplained drop in rankings or traffic, or a spike from irrelevant queries.

What changed on the server / in the CMS

• New admin or user accounts you do not recognise.
• Unfamiliar files, modified core files, or files with recent timestamps you cannot account for.
• New, suspicious scheduled tasks (cron jobs) — a common persistence mechanism.
• Unexpected outbound email from your server (your site being used to send spam), or your domain landing on email blocklists.
• Unusual entries in server and access logs, or sudden resource spikes.

Other tells

• Your host or security provider suspends or flags the account.
• Browser console errors referencing unknown external scripts or domains.
• Customers or partners report spam or strange behaviour coming from your site.

Symptom	Likely cause
Redirects only from search / on mobile	Conditional redirect / cloaking malware
Spam keywords in your Google listings	SEO spam injection (pharma/counterfeit)
"Deceptive site ahead" browser warning	Safe Browsing blocklisting after malware/phishing found
New admin users you did not create	Credential compromise or privilege escalation
Unknown files / modified core files	Backdoor or web shell installed
New unexpected cron jobs	Attacker persistence mechanism
Site sending spam / on email blocklists	Server abused as a mail relay
Sudden traffic or ranking collapse	Spam pages, cloaking, or Safe Browsing penalty

No single item is definitive, but several together are a strong signal — the same weigh-the-evidence logic that applies when judging any site's safety.

How to check externally (no server access needed)

You can confirm a great deal from the outside, which is useful when you are unsure or do not have server access:

• Google Safe Browsing — the service browsers use to warn users. You can check whether a URL is currently flagged via Google's Safe Browsing site-status tooling. A flag here is why visitors see the red warning.
• Sucuri SiteCheck — a free remote scanner (sitecheck.sucuri.net) that fetches a public URL and checks for known malware, injected spam, defacement and blocklisting. Remote scanners cannot see everything on the server, but they catch a lot.
• VirusTotal — submit the URL and it is checked against many security engines and blocklists at once, giving you a broad second opinion.
• Google Search Console → Security Issues — if you have verified the site, this report tells you directly whether Google has detected hacked content, malware or social-engineering, often with example URLs. This is the single most authoritative source for an owner.
• View as a bot / fresh session — open the site in a private/incognito window, and use a "fetch as Google" style tool or change your user agent, to reveal content shown only to crawlers or first-time search visitors.
• Search site:yourdomain.com in Google and skim for pages and keywords that are not yours — a quick way to spot SEO spam.

Broader audits can help establish a baseline too: tools like StackOptic record what technology, headers and configuration a site exposes, which makes it easier to notice when something has changed. For reading the raw signals a server returns, see how to read a website's HTTP headers.

First response: what to do if you are hacked

If the checks confirm a compromise, work calmly and in order. Speed matters, but so does not destroying the evidence you will need to find the entry point.

1. Contain. Put the site into maintenance mode or take it offline so it stops harming visitors and spreading. If your host offers it, isolate the account.
2. Preserve evidence. Before you start deleting things, take a copy/snapshot of the site and the logs. You will want them to find how the attacker got in.
3. Change every credential. Hosting control panel, CMS admin accounts, database, FTP/SSH keys, and any API keys. Assume all secrets are exposed. Do this from a clean device.
4. Restore from a known-good backup if you have one from before the compromise — usually the cleanest way back. (This is why tested backups matter so much.)
5. Find and patch the entry point. Most often it is an outdated CMS, theme or plugin, a weak/reused password, or an exposed admin panel. Fix the actual vulnerability, or you will simply be reinfected.
6. Scan thoroughly and clean. Remove injected code, backdoors, web shells, rogue admin users and unexpected cron jobs. A server-side scan finds more than a remote one.
7. Request a review. Once clean and patched, request a review in Google Search Console (Security Issues) to clear the "hacked"/"deceptive" warning, and ask any blocklist providers to re-scan. Until you do, the warnings persist even after cleanup.
8. Monitor closely for re-infection over the following weeks, watching logs, files and search listings.

If the site is business-critical and the compromise is serious, bringing in a professional incident-response or site-cleanup service is money well spent — they do this daily and will be faster and more thorough.

Prevention recap

Recovery is stressful and costly; prevention is cheap and dull. The measures that stop most compromises are well known:

• Patch relentlessly — keep your CMS, themes, plugins, libraries and server software current. Outdated, vulnerable components are the leading way sites are breached.
• Harden authentication — strong, unique passwords, multi-factor authentication on every admin account, and least-privilege roles so a single compromised login does limited damage.
• Deploy HTTPS and security headers — see HTTP security headers explained; a good Content Security Policy in particular limits what injected scripts can do.
• Validate certificates — a working, current certificate is the foundation; see what is an SSL certificate and how to check yours.
• Consider a web application firewall (WAF) to filter common malicious requests before they reach your application.
• Back up regularly, store backups off-site, and test the restore — an untested backup is a hope, not a plan.
• Limit and monitor admin access, remove unused accounts and plugins, and review logs periodically so anomalies surface early.

A quick detection checklist

• Search site:yourdomain.com and scan for spam pages or foreign keywords.
• Open the site in a private window and as a crawler to reveal hidden redirects/content.
• Run the URL through Google Safe Browsing, Sucuri SiteCheck and VirusTotal.
• Check Search Console → Security Issues.
• Review admin users, recently modified files, and scheduled tasks for anything unfamiliar.
• Watch for traffic/ranking anomalies and unexpected outbound email.

Go deeper

• Prevent it in the first place: how to protect your website from common attacks.
• Judge any site's safety: is this website safe?
• Harden the browser's behaviour: HTTP security headers explained.
• Check the foundation: what is an SSL certificate and how to check yours.

Want a fast external read on a site's headers, certificate and configuration? Analyse any URL with StackOptic — free, no sign-up.