Signs Your Website Has Been Hacked, and What to Do About It

Most small business owners don't find out their website has been hacked from a security alert. They find out because Google flags the site as dangerous in search results, a customer emails asking why the site tried to download something to their phone, or the hosting company suspends the account without warning. By the time any of that happens, the damage has usually been sitting there for weeks. That delay is the real problem. A compromised website rarely announces itself. It keeps loading, the homepage looks fine, and there's no obvious reason to go looking for trouble. Meanwhile the attacker is doing something quieter: injecting spam links into pages to boost someone else's SEO, redirecting a slice of visitors to a scam site, harvesting form submissions, or using the server to send spam email. None of that shows up unless you know where to look. Here's what to actually check, because "the site looks fine to me" is not the same thing as "the site is fine." 1. Search your own domain in Google using "site:yourdomain.com" and scan the results for pages you didn't create, especially ones with drug, gambling, or counterfeit-goods keywords in the title. This is one of the most common signs of a compromise and one of the easiest things to check, in about thirty seconds. 2. Look for content that changes depending on who's viewing it. Attackers often serve the injected spam only to Googlebot, or only to visitors arriving from search results, so the site looks completely normal to an owner logged in from a familiar browser. Checking Google Search Console for a "security issues" warning is usually the fastest way to catch this, often before anything looks wrong to the naked eye. 3. Check for new admin accounts, unfamiliar files in the CMS's plugin or theme folders, or scheduled tasks nobody on the team set up. These are usually left behind on purpose, so the attacker can get back in even after the obvious problem gets cleaned up. 4. Watch for a sudden drop in search traffic with no other explanation. Google actively downranks, and eventually blocklists, sites it flags as compromised, and that shows up in analytics before most owners notice anything else is wrong. 5. Ask the hosting provider directly whether outbound email or resource usage has spiked recently. A compromised site is often used to send spam in bulk, and most hosts monitor for exactly that, even if they don't proactively tell the customer until the account gets suspended. If any of that turns something up, here's the order that actually matters in the first hour. Not a full incident-response binder, just what stops the bleeding. Change every admin password immediately, including the hosting account and any FTP or database credentials, not just the CMS login. A password reused from somewhere else is how most of these start in the first place. Take the site offline or put it into maintenance mode rather than leaving it live while you investigate. A live, compromised site keeps doing damage to search rankings and to anyone who visits it in the meantime. Restore from a backup taken before the compromise started, if one exists and it's actually clean. This is exactly why a maintenance plan that tests its backups matters more than one that just claims to have them. Restoring is almost always faster and safer than manually hunting down and removing every injected file. Patch whatever let the attacker in before putting the site back live. Most of these hacks come through an outdated plugin, theme, or CMS version, not some sophisticated exploit. If the entry point doesn't get fixed, restoring the backup just resets the clock until the same thing happens again. Request a review in Google Search Console once the site is actually clean, so the "dangerous site" warning gets lifted instead of quietly costing traffic for weeks after the fix is already done. The businesses that recover from this quickly are almost never the ones with the fanciest security tooling. They're the ones who already had clean, tested backups, knew what "normal" looked like on their own site well enough to notice something was off, and had someone to call who could act immediately instead of opening a ticket and waiting. That's the actual point of ongoing support: not a service nobody thinks about until it's needed, but someone who already knows your site, already has access, and picks up the phone instead of routing you through a queue when something goes wrong. If you're not sure right now whether your own site would pass the checks above, that's worth finding out before an attacker, or Google, finds out for you.