Signs Your Website Has Been Compromised: What to Check Before Customers Notice

The most expensive part of a compromise is rarely the clean up. Understanding Signs Your Website Has Been Compromised matters for any business serious about their online presence. It’s the window where your site quietly leaks trust, leads, and discoverability. If you’ve seen odd redirects, mystery admin users, or sudden slowdowns, treat it like an infrastructure fault, not a marketing hiccup. The aim is to confirm what’s happening quickly, preserve evidence, and contain the spread, without wiping the trail you’ll need for proper remediation.

1) Redirects you didn’t build (and can’t reproduce consistently)

Malicious redirects are often conditional. You can load the homepage ten times and it looks fine, then a customer clicks from Google on a mobile device and lands on a pharmacy site. That’s not “a weird cache thing”. It’s usually one of three patterns: user-agent based redirects (only for bots or only for mobile), referrer based redirects (only when the visitor comes from search/social), or geo/IP based redirects (only in certain regions).

Get clarity faster by isolating where the redirect is happening, because the fix depends on the layer. It could be at the edge (CDN/WAF), the server (Apache/nginx), or inside the application. If you only test in your browser, you’ll miss it. Reproduce with a clean environment and varied headers. A practical sanity check is to run a request with curl using a couple of user agents and referrers. If the Location header changes depending on headers, you’re not dealing with a normal plugin conflict.

Also check your .htaccess (Apache), nginx conf, and any CDN/WAF rules for unexpected rewrite conditions. Attackers like adding a small block that reads like legitimate rewrite logic. If you’re on WordPress, don’t assume it’s “just” .htaccess either. A compromised plugin can inject redirects at runtime so the file system looks clean while users still get bounced.

2) New admin users, or “legit” users doing illegit things

The obvious red flag is a brand new Administrator account you didn’t create. The more operationally dangerous one is an existing account suddenly gaining capabilities, or an editor account being used to install plugins. In WordPress, capability escalation can happen via compromised admin cookies, vulnerable plugins, or database-level tampering. In other stacks, it can be stolen OAuth tokens, leaked API keys, or a session fixation issue.

Find the real story by looking past the user list, because compromise shows up in behaviour. Check auth logs (where you have them), last login timestamps, password reset events, and any spikes in failed logins. If you use a managed host, pull their access logs too. If you don’t have logs retained, that’s a separate infrastructure problem to fix once the fire is out.

If you need a practical baseline for what “normal” looks like in a small business environment, start with what website security actually means for small businesses. It frames security as technical integrity and operational control, not a checkbox exercise.

3) Sudden performance drops that don’t correlate with traffic

Performance drops matter because they’re often an early symptom of resource abuse. Crypto-miners, spam bots, brute-force scripts, and malicious PHP shells all consume CPU, create disk churn, and open outbound connections. The tell is when your site gets slower while analytics traffic stays flat, or when server load climbs at odd hours with no campaign running.

On a typical small business stack, I look for three things because they’re measurable and hard to hand wave away: unexpected outbound requests (especially to unfamiliar domains), a jump in PHP workers or Node processes, and database queries that suddenly become expensive. If you can, compare current process lists and network connections with a known good baseline. If you can’t, build that baseline after remediation, because “it feels slower” isn’t a monitoring strategy.

Also watch for caching behaving strangely. Some malware disables caching to make injection easier or to ensure payloads execute on every request. That can look like a performance regression caused by a theme update, but the timing is the clue. If the slowdown starts immediately after a plugin install from an untrusted source, assume compromise until proven otherwise.

4) Search Console warnings, indexing anomalies, and brand-new pages you didn’t publish

Search Console and Bing Webmaster Tools often flag issues first because crawlers see what normal users don’t. Common signals: “Security issues detected”, “Hacked content”, sudden indexing of spammy URLs, or a spike in 404s for paths you never created. If you see thousands of thin pages appear overnight, that’s usually a spam injection or a rogue sitemap.

Reduce the mess by checking the crawler pathways, because attackers optimise for what bots follow. Check your sitemap output and robots.txt. Attackers will add a second sitemap or modify robots.txt to steer crawlers towards spam pages while hiding the mess from casual browsing. Also check canonical tags site-wide. Compromised templates sometimes rewrite canonicals to point at an attacker domain, which quietly drains citations and disrupts algorithmic alignment.

5) Files changing when you didn’t deploy anything

You get control back faster with file integrity monitoring—because otherwise you’re relying on luck and memory. Compromises often leave fingerprints in modified timestamps, new PHP files with random names, or “helper” files tucked into upload directories. In WordPress, the uploads folder should not contain executable PHP. If it does, treat that as hostile until you can prove otherwise.

Look for these patterns: recently modified core files, unexpected mu-plugins, strange cron entries, and obfuscated code blocks (base64_decode, gzinflate, eval) inserted into theme functions or plugin files. Obfuscation isn’t always malicious, but in small business sites it usually is.

Containment is faster when maintenance is already a system

Most compromises get expensive when basic maintenance has been treated as optional, because outdated plugins, stale credentials, and missing backups turn a small breach into infrastructure failure. A maintenance cadence is also how you preserve technical integrity, because patching, log retention, and access reviews are what give you evidence when something goes wrong. If you want a practical schedule that keeps downtime and surprise incidents out of your week, we break it down in How Often Should a Business Website Be Maintained? A Practical Schedule That Prevents Downtime.

If you don’t have logs retained, that’s a separate infrastructure problem to fix once the fire is out. Without retention, you can’t verify what changed, when it changed, or whether your remediation actually restored Technical Integrity. That same gap also undermines discoverability and citations, because a compromised site trains machines and humans to distrust your domain; the practical fix is to turn security into a maintainable routine, not a one-off panic. We map that cadence out in Website Security Checklist for Small Business Owners (That You’ll Actually Maintain), covering access control, updates, backups, monitoring, and DNS in a way that holds up under real-world time constraints.

6) Email deliverability tanks, or your domain starts sending things you didn’t send

Email issues are often part of the same incident, because attackers reuse the trust your domain already has. A common play is to use your server to send spam, or to host phishing pages under your domain because it looks legitimate. You’ll notice contact form submissions stop arriving, customers say they never got invoice emails, or your domain lands on a blocklist.

Check outbound mail logs if you have them, and check your DNS for SPF, DKIM, and DMARC alignment. This isn’t just an email problem. If your domain reputation drops, it can affect how your brand is treated across platforms, including ad accounts and search visibility.

7) Your site “works”, but the HTML is polluted

Some compromises don’t break anything obvious, which is why they stick around. They inject hidden links, spam schema, or cloaked content that only appears to crawlers. You’ll still be able to log in, pages will load, and forms will submit. Meanwhile, the DOM contains blocks of off-screen anchors, Japanese keyword spam, or injected JSON-LD that has nothing to do with your business.

Catch it by checking what actually renders, because runtime injection won’t always show up in the file system. Spot-check rendered HTML, not just source files. Use “view-source” and also inspect the DOM after scripts run. If you see injected content that isn’t in your CMS, you’re dealing with runtime injection or database contamination.

8) Security plugins start failing, or updates won’t apply cleanly

Persistence usually involves disabling alarms, because a noisy site gets cleaned. That can look like a security plugin that can’t reach its API, update checks that time out, or WordPress core updates that repeatedly fail. Sometimes it’s as blunt as a compromised wp-config.php that blocks outbound requests. Other times it’s a subtle permissions change that prevents overwriting a backdoored file during updates.

Don’t write update failures off as “hosting being flaky” until you’ve checked file permissions, outbound connectivity, and whether key files are write-protected in a way that doesn’t match your deployment model.

What to do in the first hour (without making it worse)

Containment comes first because every minute you stay exposed increases the blast radius. If you can’t confidently identify what’s affected, take the site out of the line of fire. Put it behind maintenance mode, restrict admin access by IP, or temporarily route traffic to a static holding page. Then preserve evidence. Take a full backup of files and database as-is before you start deleting anything. Cleaning without a snapshot turns an incident into a guessing game.

Rotate credentials in the right order so you don’t lock the front door while the back door stays open. Start with hosting panel, SSH/SFTP, database, and admin accounts. Then rotate API keys and third party tokens connected to the site. If you only change WordPress passwords but the attacker still has SFTP, you’ve done theatre, not security.

If you need a maintainable baseline after remediation, use this website security checklist you’ll actually maintain as your minimum standard. It’s built around routine controls that protect technical integrity without breaking your marketing stack.

Why early detection matters for discoverability (not just downtime)

A compromised site doesn’t just lose sales while it’s down. It can lose citations and trust signals while it’s still “up”. Spam injections, cloaking, and malicious redirects teach machines that your domain is unreliable. Recovery then becomes a two part job: removing the compromise and rebuilding confidence with crawlers, browsers, and users.

This is the same reason we treat websites as systems, not pages. Security, performance, and discoverability are shared infrastructure. If you want the broader framework for building sites that hold up under modern AI search expectations, read designing a website ecosystem for discoverability. It explains why strong foundations reduce both marketing waste and incident impact.

One last practical note

If you’ve confirmed compromise, avoid the temptation to “just reinstall WordPress” or “just restore a backup” and call it done. Restores often reintroduce the same vulnerability, and reinstalls don’t fix stolen credentials or compromised DNS. Proper remediation means identifying the entry point, removing persistence, patching the vulnerability, and validating the environment with logs and integrity checks. It’s unglamorous work. It’s also the work that prevents the next incident.

About the Author

Nicholas McIntosh

Nicholas McIntosh is a digital strategist driven by one core belief: growth should be engineered, not improvised. 

As the founder of Tozamas Creatives, he works at the intersection of artificial intelligence, structured content, technical SEO, and performance marketing, helping businesses move beyond scattered tactics and into integrated, scalable digital systems. 

Nicholas approaches AI as leverage, not novelty. He designs content architectures that compound over time, implements technical frameworks that support sustainable visibility, and builds online infrastructures designed to evolve alongside emerging technologies. 

His work extends across the full marketing ecosystem: organic search builds authority, funnels create direction, email nurtures trust, social expands reach, and paid acquisition accelerates growth. Rather than treating these channels as isolated efforts, he engineers them to function as coordinated systems, attracting, converting, and retaining with precision. 

His approach is grounded in clarity, structure, and measurable performance, because in a rapidly shifting digital landscape, durable systems outperform short-term spikes. 


Nicholas is not trying to ride the AI wave. He builds architectured systems that form the shoreline, and shorelines outlast waves.

Connect On LinkedIn →