Signs Your Website Was Hacked and What to Do in the First Hour

The warning signs of a hacked website, from spam search results to rogue admins and redirects, plus a step-by-step first-response plan to contain and recover.

By the MakeItFlow team 8 min read
Share LinkedIn X Facebook WhatsApp
Signs Your Website Was Hacked and What to Do in the First Hour

Most site owners don't find out about a hack from an alarm. They find out from a customer who got redirected to a scam page, a client asking why Google shows Japanese text under their business name, or a hosting provider suspending the account. By then the attacker has often been in for weeks. This guide lists the signs worth checking, explains how to confirm what you're seeing, and gives you a first-response plan that contains the damage without destroying the evidence you need to clean up properly.

Key takeaways

  • Unfamiliar spam pages in Google, Chrome security warnings and alerts in the Search Console Security Issues report are clear signs of a hack.
  • Some hacks redirect only visitors arriving from Google or on mobile, so the owner may see nothing wrong when typing the URL directly.
  • Contain the site and preserve a copy of files, database and logs before deleting anything, then change passwords from a clean device.
  • Rebuild from a backup taken before the compromise or from official sources, and close the entry point before going live again.

Signs in search results and browsers

Spam pages under your domain. Search Google for site:yourdomain.com and scroll. Pages you didn't create, especially pharmacy, casino, replica goods or Japanese-language listings, point to what Google calls URL injection: the attacker created new pages on your site. Spammy links or text inside your real pages is content injection.

Security warnings. Chrome's red "Dangerous site" or "Deceptive site ahead" interstitials, or "This site may be hacked" under your listing in Google Search, mean Google has flagged the site.

Search Console Security Issues report. If you have Search Console set up, open Security & Manual Actions > Security issues. Google lists issue types such as Hacked: Malware, Hacked: Code injection (malicious code like redirects or cryptominers added to pages), Hacked: Content injection, Hacked: URL injection, Deceptive pages and Harmful downloads, often with sample URLs. That's the most direct confirmation you'll get.

A sudden drop in search traffic, or a jump in indexed pages you don't recognize, alongside the above.

Signs on the site itself

Redirects that only some visitors see. A common trick is redirecting only visitors who arrive from Google, or only mobile visitors, while showing the normal site to anyone who types the URL. You, the owner, go straight to the homepage and see nothing wrong. Test it from the command line:

# Normal request
curl -sI https://yourdomain.com/ | grep -i location

# Pretend to arrive from Google on a phone
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
     -e "https://www.google.com/" https://yourdomain.com/ | grep -i location

If the second command shows a Location: header to an unfamiliar domain and the first doesn't, you have a conditional redirect.

Different content for Googlebot (cloaking). Use the URL Inspection tool in Search Console to "Test live URL" and view the rendered HTML Google sees. Spam links that are invisible in your browser often show up there.

Unfamiliar scripts. View the page source and look for <script> tags pointing to domains you don't recognize, long obfuscated strings (eval(atob(...)), String.fromCharCode chains), or iframes sized to zero.

Defacement, pop-ups or fake login and payment forms. These are obvious, but check checkout and login pages specifically. Card-skimming scripts usually hide there.

Signs in your accounts and server

  • Administrator accounts you didn't create, or existing users suddenly promoted to admin.
  • New or recently modified files in places they don't belong: PHP files in wp-content/uploads/, oddly named files in the web root, a modified .htaccess with redirect rules you didn't write.
  • Unknown cron jobs or scheduled tasks. Attackers use them to re-infect a site after cleanup.
  • Your host reports high CPU or suspends the account. Cryptominers and spam scripts eat resources.
  • Outgoing spam. Bounce messages for mail you never sent, or your server IP on email blocklists. If mail from your domain suddenly lands in spam, see why emails go to spam.
  • DNS records you didn't change. A new MX, a changed A record or an unfamiliar TXT record can mean your registrar or DNS account was compromised, which is more serious than a site hack.
  • Unexpected password reset emails or login alerts for hosting, registrar or CMS accounts.

Useful commands if you have shell access:

# Files modified in the last 7 days under the web root
find /var/www/yoursite -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# PHP files inside an uploads directory (should normally be none)
find /var/www/yoursite/wp-content/uploads -name "*.php"

# Common obfuscation patterns
grep -rlE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(|assert\(\\\$_" /var/www/yoursite --include=*.php

# WordPress: compare core files against official checksums
wp core verify-checksums

These are leads, not proof. Some legitimate plugins use base64_decode. Investigate before you delete.

The first-response plan

Work through these in order. The instinct is to start deleting suspicious files right away. Resist it until you've done steps 1 to 3.

1. Contain

  • Put the site into maintenance mode, or have your host temporarily restrict access, especially if it's serving malware, phishing or card skimmers to visitors.
  • If the site handles payments, contact your payment provider. Card skimming has notification obligations.

2. Preserve evidence

  • Take a full copy of the files and database as they are now, and store it separately from your clean backups.
  • Download the web server access and error logs before they rotate. They show how the attacker got in and what they touched.

3. Secure your access, from a clean device

Change passwords and enable two-factor authentication, in this order: email account, domain registrar, DNS provider, hosting control panel, SFTP/SSH, database, CMS administrators. Use a device you trust. If your own computer is infected, the new passwords are stolen too. Revoke SSH keys, API keys and application passwords you don't recognize, and log out all sessions.

4. Find the scope and the entry point

Use your logs and the file timestamps to answer: when did it start, which files changed, and how did they get in? The usual entry points are:

  • An outdated plugin, theme or CMS version with a known vulnerability.
  • A stolen or reused admin, FTP or hosting password.
  • Exposed secrets, like a public .env file or backup (see exposed .env and .git files).
  • Another compromised site in the same hosting account.

If you can't find the entry point, assume it's still open.

5. Clean

The most reliable approach is to rebuild rather than scrub:

  • Restore from a backup taken before the compromise. Your timeline from step 4 tells you which one.
  • Or reinstall CMS core, plugins and themes from official sources, then carefully restore only your content (uploads with PHP files removed, plus the database after reviewing users and options).
  • Remove unknown admin users, cron jobs and .htaccess rules.
  • Search the database for injected scripts or spam links in posts, widgets and options.

If the site is complex or you can't be sure it's clean, a professional incident response or malware cleanup service is worth the cost.

6. Close the hole and rotate secrets

Update everything, remove unused plugins and themes, and fix the specific weakness you found. Rotate every credential the attacker could have read: database passwords, API keys, SMTP passwords, payment gateway keys and the CMS secret keys and salts, which logs out everyone. Our WordPress security checklist covers hardening to apply now.

7. Request a review and monitor

Once the site is clean, request a review in the Search Console Security Issues report. Explain what you found, what you fixed, and how. Google says reviews take anywhere from a few days to a few weeks. Web.dev's recovery guidance gives a few days for malware and up to several weeks for spam hacks, with warnings removed within about 72 hours of approval. Don't resubmit before you get an answer. Repeat requests slow things down.

Then watch closely for a few weeks. Re-infection is common when a backdoor was missed: check for new admin users, new files and changed .htaccess rules.

Frequently asked questions

Can I just restore yesterday's backup?

Only if you're sure the compromise started after that backup. Attackers often sit quietly for weeks, so yesterday's backup may already contain the backdoor. Use your file timestamps and logs to pick a backup from before the first sign of tampering, then patch the entry point before going live.

Will my site's search rankings recover?

Usually, once Google confirms the site is clean, warnings are removed and spam URLs drop out of the index over time. Return URLs for injected spam pages as 404 or 410 so Google can drop them faster. The quicker you clean up and request a review, the less lasting damage.

Does an SSL certificate or security header stop hacks?

No. HTTPS and headers protect visitors' connections and limit some attacks in the browser, like XSS and clickjacking. They don't fix vulnerable plugins or stolen passwords, which are how most sites get compromised.

Do I need to tell my customers?

If personal or payment data may have been accessed, you may have legal notification duties, depending on where you and your customers are located. Get advice from your payment provider and legal counsel early rather than after cleanup.

What to do next

Set up Search Console now if you haven't, so Google's warnings reach you directly. Keep off-site backups with several generations, and write down where your registrar, DNS and hosting logins live before you need them in a hurry. Once you've recovered, run a free audit to check your security headers, certificate, exposed files and DNS records. Our paid plans add scheduled re-scans with email reports, which can help you spot changes such as altered DNS records or missing headers. Note that the audit is a configuration check, not a malware scanner.

Sources

#hacked website #incident response #website malware #search console #wordpress security

Written by the MakeItFlow team

We build the website audit these guides are based on. Every fact is checked against the primary sources listed above . How we research and check

Share LinkedIn X Facebook WhatsApp

Check your own site in 30 seconds

Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.

Weekly newsletter

One practical website fix, every week

New guides on speed, SEO, email deliverability and security — straight to your inbox. No spam, unsubscribe in one click.

Keep reading