Blog · 7 November 2026 · 9 min read

How to tell your website has been hacked: nine symptoms, a 10-minute check and what to do first

A hack of a small-business website rarely looks like the movies. Nobody replaces your home page with a skull. Instead the site works as usual, except that Google lists a few hundred pages about pills and casinos under your domain, phone visitors land in a counterfeit shop, and your contact form sends spam from your domain. The owner is the last to know – from a customer, from the host, or from a red screen in Chrome. Below: nine symptoms you can spot yourself, a 10-minute check (including how to see the site the way Google sees it), first steps in the right order, and how to get back into search results.

Nine symptoms you can see without logging in to the server

1. Google lists pages you never created. Search for site:yourcompany.com – if the results include addresses in a foreign language, about pills, gambling, cheap shoes or “free codes”, someone has added them to your site. Google calls this URL injection: the hacker creates new pages “often containing spammy words or links”.
2. The site redirects elsewhere – but not always. Typically only on phones, only when arriving from Google, only the first time. The owner opens a bookmark on a desktop and everything works. Google describes redirects set up, among other ways, “by modifying your server's configuration file(s)”.
3. A red warning in the browser. For malware on the site, Chrome shows a “Dangerous” label in the address bar and an interstitial warning page before the visit; in search results the site can get a warning label. That is the moment traffic drops to zero overnight.
4. An e-mail from Search Console about security issues. If the site is verified in Search Console, Google notifies you and shows a report with example URLs. If it is not – nobody tells you; one more reason to set it up today.
5. Your host writes about spam or abuse, or disables the account. Hacked sites send mail, attack other servers or burn CPU. The host sees it before you do.
6. Traffic and rankings drop for no reason. Google demotes pages with spam and warnings; the chart shows a step, not a slow slide.
7. New administrator accounts, plugins or files. An “admin2” account in the CMS, a plugin nobody installed, files with a fresh modification date in folders nobody has touched in a year.
8. The site suddenly got slow. Google lists among malicious code “running cryptocurrency mining software on your browser while the page is open” – the customer's phone heats up and the performance score drops 30 points without any change on your part.
9. Only Google sees the spam. According to Google, “many hackers make changes that are visible only to Google machines”: links rendered only when the visitor comes from Google, hidden from the logged-in owner. This is called cloaking, and it is why “everything looks fine” means nothing.

The 10-minute check

1. site:yourcompany.com in an incognito window. Page through a few result pages. Then repeat with words that should not be on your site: site:yourcompany.com viagra, site:yourcompany.com casino, site:yourcompany.com cheap. Every hit is evidence.
2. Visit the site like a customer: on a phone, via a Google search, not from a bookmark. Check the home page and two subpages. Watch for a different address flashing before the page loads.
3. Search Console → “Security & Manual Actions” → “Security issues”. The report distinguishes hacked content (malware, code injection, content injection, URL injection), malware and unwanted software, and social engineering (deceptive pages, harmful downloads). Each issue comes with example URLs.
4. See the page the way Google does. In Search Console paste the address into the URL Inspection tool and open the crawled page view – Google recommends it precisely to “view your page as Google sees it”. If the code contains links or text you cannot see in the browser, you have cloaking.
5. For technical people: fetch the page from the command line pretending to arrive from Google (Google's help points to cURL or Wget with a custom referrer and user-agent) and compare it with the “normal” version:

   curl -sL -A "Mozilla/5.0 (Linux; Android 14) Chrome/130 Mobile Safari/537.36" \
     -e "https://www.google.com/" https://yourcompany.com/ | grep -i -c "casino\|viagra\|<iframe"

   A result above zero on a site that has nothing to do with casinos means injected content.
6. Do not open suspicious pages in a normal browser. Google warns plainly that opening an infected page “may damage your computer”. Check the addresses from the report with the tool from step 4 or from the command line.
7. Look into the CMS dashboard: the user list (unknown accounts with administrator rights), the plugin and theme lists (unknown, outdated), the last-modified dates in the host's file manager.
8. Write down everything you found – addresses, screenshots, dates. Your host, your developer and the review request will need it.

What to do first – in this order

1. Notify your host. Most hosts have a procedure: file scan, access logs, information on how they got in. Ask for a copy of the last 30 days of logs before they are overwritten.
2. Change every password from a clean computer: hosting panel, FTP/SFTP, CMS (all administrators), database, the e-mail account tied to the site. Turn on two-factor authentication wherever possible. If the passwords were reused elsewhere – there too.
3. Contain the damage. If the site spreads malware or redirects customers, switch on a maintenance page with status code 503 (it tells Google “come back later”, not “the site is gone”). If only spam was added, you can clean live – but quickly.
4. Restore a clean backup or clean by hand. Google says it plainly: “replace affected files with the last good backup” or remove the spammy content yourself. The backup must predate the hack – the date in the logs from step 1 tells you which one. Right after restoring, update the CMS, plugins, theme and PHP, because the old version has the same hole. Remove unknown accounts and plugins.
5. Fix the whole site, not just the examples. Google warns that fixing the issue on just some pages “will not earn you a partial return to search results”. The hacker's backdoor is often in several places: .htaccess files, the uploads folder, cron jobs, database accounts.
6. Check who has access to Search Console and to your Google Business Profile (users and owners). Hackers are sometimes smarter than owners and add themselves so they can come back after the clean-up.
7. Request a review. Only when all issues in the report are fixed on all pages, click “Request Review” in Search Console and describe what happened and what you did – Google wants the request to explain the exact issue, the steps taken to fix it and the outcome. Timing: “from a few days to a few weeks”. Do not resubmit before a decision – premature, repeated requests can get you flagged as a repeat offender and waiting longer.

Symptom → cause → who fixes it

How not to come back to this article

• Updates in the week of release, not “once a quarter”. Most hacks go through known plugin holes that have had a patch for weeks. For WordPress: 10 security settings in an hour.
• Backups off the server, daily, with at least 30 days of history – so there is something to go back to when you notice the hack three weeks later.
• Separate, long passwords and 2FA for the CMS, the hosting and the mailbox. One administrator account per person; revoke access for former staff and agencies the same day.
• Search Console with your e-mail address – a free notification about security issues and the tool for getting back. Without it, you learn from customers.
• Security headers, especially Content-Security-Policy – they will not stop a server break-in, but they make running foreign scripts in your customers' browsers harder: security headers explained.
• Someone outside who looks every day and compares the site with yesterday's: redirect, title, appearance. A hack noticed within a day costs hours; after a month it costs your Google rankings and your domain's reputation.

What Webskan checks

We do not scan files on your server or remove malicious code – that is the job of your host, your developer and security plugins. We look at the site from outside, like a customer and like Google. The in-depth audit finds things that make a hack easier or are its trace: server headers revealing software versions, missing security headers (including Content-Security-Policy), forms submitted over an unencrypted connection, mixed content, a canonical address pointing to another domain, indexing blocks and error pages. Webskan Monitor checks uptime every minute and once a day compares the home page with the previous day, alerting you when the site starts redirecting to another host, loses its title or its canonical points to a foreign domain, returns almost no content, stops redirecting to https, or when its appearance changes significantly (more than a third of the pixels; the e-mail carries yesterday/today screenshots and the alert text explicitly tells you to check for a hack). What Monitor will not see: spam rendered only for Googlebot or pages that are not in the navigation – that is what steps 3 and 4 of the check above are for.

Sources and tools

• Google Search Console Help, Security Issues report – issue categories, descriptions of injected URLs/content/code, cloaking, viewing the page as Google (URL Inspection tool, cURL/Wget), the warning against opening infected pages, the review request and its timing
• Google, How do I know if my site was hacked? – the order: Search Console → example URLs → cloaking check (site:, URL Inspection tool)
• Google, Transparency Report – Safe Browsing site status – check whether Google flags a given address as dangerous
• Webskan, WordPress: 10 security settings in an hour and HTTP security headers explained