Seven warning signs your website may be compromised, what to do in the first hour, and how to stop it from happening again.
Most websites do not get hacked with a dramatic "you've been pwned" splash screen. They get quietly abused — sending spam, hosting redirects, or leaking data — while the owner has no idea until an email provider or host flags them. I have cleaned up exactly this kind of mess, and in this guide I will show you the signs to look for and what to do the moment you spot one.
7 signs your website may be compromised
- Your host sends an abuse or spam warning. This is the most common wake-up call. If your provider says outbound spam is coming from your account, take it seriously — it usually means a form or script is being abused.
- Your IP lands on a blocklist. Suddenly your emails bounce with "listed on a DNSBL" errors. That is a downstream symptom of abuse traffic leaving your server.
- Unknown files appear. New PHP files in your uploads folder, files with random names, or double extensions like
image.jpg.phpare classic webshell signs. - Unexpected admin users or logins. Accounts you did not create, or logins from countries you have never visited.
- Search results look wrong. Google shows pages or keywords for your site that you never published — often pharma or gambling spam injected into your pages.
- Your traffic spikes from odd places. A flood of visits from regions with no business reason, often bots probing forms.
- Random redirects. Visitors report being sent to a site you have never heard of, usually from a single unprotected script.
What to do in the first hour
1. Do not panic, but do move fast
The goal is to stop the bleeding and preserve evidence. Resist the urge to delete everything — you will lose the trail you need to find the root cause.
2. Change every password and rotate keys
Start with hosting, database, and admin accounts. If API keys or SMTP credentials live in your code, rotate those too. Assume anything reachable was seen.
3. Find the entry point, not just the symptom
Cleaning a single bad file is not enough — if the door is still open, it comes back within days. Look at recently modified files, your form handlers, and any endpoint that accepts input without a rate limit, a honeypot, or basic validation. In most real cases I have handled, the culprit was an unprotected form being abused, not sophisticated malware.
4. Scan and clean methodically
Search your codebase for the usual webshell signatures — encoded eval, suspicious use of superglobals, known shell names. Quarantine anything you find rather than deleting it blind, and check cron jobs and SSH keys for anything you did not add.
How to make it much harder next time
Prevention is boring and it is also the entire game. Every public form should have a rate limit, a honeypot field, and input validation. Keep backups outside your web root so they cannot be downloaded. Publish SPF, DKIM, and DMARC records so your email cannot be easily spoofed. And review your outbound mail regularly — the first sign of abuse is almost always in the bounces.
When to bring in help
If your site is a real part of your business, an hour of expert review is cheaper than a week of downtime and a damaged sender reputation. This is exactly the kind of work I do through my cybersecurity services at SevinHub — a practical audit that finds the actual entry point, cleans it, and hardens the things that let it happen. No jargon, no scare tactics, just a clear report and a site that is safe to run.
Whether you do it yourself or bring someone in, the principle is the same: find the root cause, close it properly, and build in the small protections that stop it from ever happening again. A quiet, boring, secure website is the goal — and it is completely achievable.