# Is my website hacked? Cloaking, spam links and Google-only redirects

> Google shows pharma or Japanese text for your site, but your browser shows a clean page. See what Googlebot sees, confirm it by hand and clean a hacked WordPress site step by step.

Updated 2026-09-25 · Security · HTML version: https://getreport.app/guides/is-my-website-hacked

The most common hacks today are built not to be noticed by the site owner. They show spam only to Googlebot, or redirect only visitors who arrive from a Google result, and serve the normal page to everyone who types the address. So the owner sees nothing wrong while Google indexes a pharmacy. This guide shows how to see your site the way Google sees it, how to confirm what you find, and how to clean a WordPress site so the spam does not come back. Checking takes five minutes; a cleanup takes an afternoon to a day.

## Quick answer

- Run the [hacked site checker](https://getreport.app/tools/hacked-site-checker). It fetches the page as a normal visitor, as Googlebot and as a visitor from Google, and compares them.
- Differences with pharma, casino or loan links, text in a script you do not publish in, or a redirect to a site you do not own mean an injection.
- Confirm it in Search Console (URL Inspection → View crawled page) and with `curl`.
- Clean in order: back up the hacked state, update, verify core files, find and remove the injection and the backdoor, change every password and key.
- Only then request a review under Security Issues in Search Console.

## Why a hacked site matters

These are the symptoms owners actually report:

- Google results for the site show titles about Viagra, casinos or loans, or whole lines of Japanese text, often on URLs the site never had.
- The result carries the label "This site may be hacked".
- Customers say that clicking the site in Google took them to a casino or a "you won a phone" page.
- Organic traffic drops sharply within a few days, while direct traffic looks normal.
- Search Console sends an email about security issues, or lists owners you never added under Settings → Users and permissions.

The cost is rankings first, then trust. Google demotes or labels hacked pages, and if the attacker also serves malware, browsers show a red warning page to every visitor. The attacker's goal is usually your domain's reputation: their links on your pages help their sites rank.

### Why your own browser shows a clean page

The injected code checks who is asking before it answers. **User-agent cloaking** looks for "Googlebot" in the request and serves spam only then. **Referrer cloaking** looks at where the visitor came from: arriving from google.com triggers a redirect, typing the address does not. Many injections also skip logged-in WordPress users, or fire once per visitor and set a cookie. The one person guaranteed never to see it is the owner checking the home page from a bookmark.

## How getReport checks it

> **Free tool:** [Hacked site checker: Googlebot vs visitor](https://getreport.app/tools/hacked-site-checker): Is your website hacked? The page is fetched three ways, as a normal visitor, as Googlebot and as a visitor arriving from Google, and the copies are compared: injected text, pharma and casino links, hidden links, Japanese keyword spam and redirects that only fire from Google, all with the evidence.

The tool fetches the page three times: with our own user agent as a normal visit, with Googlebot's user agent, and with a Chrome user agent plus a `Referer` header from `https://www.google.com/`. It does not run JavaScript; it compares the HTML each fetch returns.

![The fetch comparison table: columns for normal visitor, Googlebot and visitor from Google; rows for response, final URL, visible words, words not on the visitor page, links, hidden links, spam vocabulary, text in another script and referrer redirect script, with the differing cells highlighted](https://getreport.app/guides/img/is-my-website-hacked/comparison.webp "On a cloaked page the Googlebot column carries words, links and spam vocabulary the visitor column does not.")

What each row compares:

- **Words not on the visitor page.** The most frequent words of each copy are compared. When at least 30% of the Googlebot or Google-visitor copy is missing from the visitor copy and at least 20 words are new, the cloaking finding fires.
- **Spam vocabulary.** A fixed list of 36 words and phrases that injections use and legitimate navigation almost never does: pharma (viagra, cialis, tramadol), gambling (casino, slots, betting), payday loans, replica goods, essay mills, adult terms and crypto giveaways. Matched as whole words in visible text, hidden text and link URLs.
- **Hidden links.** Links to other sites inside an element hidden with the `hidden` attribute, `aria-hidden="true"` or an inline style: `display:none`, `visibility:hidden`, zero opacity or font size, or a position far off-screen.
- **Text in another script.** Runs of Chinese, Japanese, Korean or Cyrillic characters on a page whose `lang` says it is in another language. This is how the Japanese keyword hack shows up.
- **Referrer redirect script.** An inline script that reads `document.referrer`, looks for Google, Bing or Yahoo, and changes `location`.
- **Final URL.** A redirect to another host that happens for one fetch and not the others.

> **Check: Visitors and Googlebot see the same page text.** The page was fetched as a normal visitor, as Googlebot and as a visitor arriving from Google. The bot or Google-referrer copies contain text that visitors never see. That is the pattern of a hacked site that hides spam from its owner, and Google treats cloaking as a violation. Some sites vary content by user agent on purpose; check the evidence.
>
> 1. Open the page as Googlebot (Search Console URL Inspection → View crawled page, or curl with a Googlebot user agent) and compare it with a normal visit.
> 2. If the extra content is not yours: change every password, update WordPress, themes and plugins, scan the file system for modified core files and unknown PHP files (wp-content/uploads, mu-plugins), restore from a clean backup if in doubt, then request a review in Search Console under Security Issues.

> **Check: No spam links and no links served only to bots.** Links with pharma, gambling, loan or replica vocabulary, or links that only Googlebot and Google visitors receive, are the fingerprint of an injection: someone is using your domain's reputation to rank their pages. Google demotes sites that carry them.
>
> 1. Search the database and theme files for the linked domains (wp_posts, wp_options, header.php, footer.php, functions.php) and remove the injection; look for an unknown plugin or a modified core file that re-adds it.
> 2. Update everything, rotate passwords and keys, then request a review in Search Console.

> **Check: No redirect that fires only for Googlebot or Google visitors.** The page sends visitors who come from Google, or Googlebot itself, to another site, while direct visitors see the normal page. Owners rarely notice because they never arrive from Google. Search results show the spam target and the site loses its rankings.
>
> 1. Look for the redirect in .htaccess or the nginx config, in wp-config.php and index.php, in theme header and footer files, in the database (wp_options siteurl/home and injected scripts in posts), and in inline scripts that read document.referrer.
> 2. Remove it, update and clean the site, rotate passwords, and request a review in Search Console.

> **Check: No hidden outbound links.** Links inside containers with display:none, visibility:hidden, zero font size or an off-screen position are invisible to visitors but counted by search engines. Legitimate pages rarely need them; injections use them constantly.
>
> 1. Find the hidden container in the page source (search for the linked domain) and remove it. If it comes from a plugin or theme, that is the compromised or spammy component.
> 2. If the links are yours and intentional (a collapsed menu, a screen-reader-only list), keep them; the finding is a warning, not a penalty.

The panel is headed "differences are evidence, not a verdict", and it means it. A sports blog that links to a betting guide, a booking page with "free slots", a site that serves a lighter page to bots: all of them match. You know which links and words are yours.

The tool also shows the usual ways in: an out-of-date CMS version, plugins closed or abandoned on wordpress.org, a readable `.env` or `.git` and open directory listings. Google's own verdict comes from Safe Browsing: the Web Risk finding carries it once the lookup runs in your report. Until then, look the domain up on the Safe Browsing site status page in Google's Transparency Report.

> **Watch out:**
> "No differences" covers this URL, fetched from our servers, once. It cannot see injections on other pages, spam loaded by external JavaScript, links hidden by a stylesheet class, or code that checks Google's real IP addresses. If Google shows spam for your site, trust Google and test the exact URLs it lists.

## Step by step

### 1. Read the evidence

Open the spam links finding first. Each line names the fetch that received the link, the anchor text and the target.

![The spam links finding opened: pharma and casino links, each marked "googlebot only", with anchor text and the external URL they point to](https://getreport.app/guides/img/is-my-website-hacked/finding.webp "Links that only Googlebot receives are listed with their anchor text and target.")

Write down the domains the links point to and any words that stand out. They are your search terms for step 5.

### 2. Confirm it by hand

**Search Console.** URL Inspection → enter the URL → Test live URL → View tested page → HTML. That is the page as Googlebot fetches it, from Google's own addresses, so it also catches IP-based cloaking. View crawled page shows the copy Google has indexed. Search the HTML for the spam domain.

**Google itself.** Search `site:example.com viagra`, `site:example.com casino` or just `site:example.com` and scroll. Pages you never created, especially with Japanese titles, are generated by the hack.

**curl**, to compare the copies yourself:

```bash
# Normal visitor and Googlebot, saved to two files
curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" https://example.com/ -o visitor.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o googlebot.html

# Links only one copy has
diff <(grep -o 'href="[^"]*"' visitor.html | sort -u) <(grep -o 'href="[^"]*"' googlebot.html | sort -u)

# A visitor from Google: a Location header to another site is a server-side redirect
curl -sI -e "https://www.google.com/" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" https://example.com/
```

A JavaScript redirect only fires in a browser: open a private window, search for your site on Google and click the result.

### 3. Freeze the evidence and take the site offline

Before changing anything, copy the hacked state somewhere outside the web root. You will want it to find the way in and to compare later.

```bash
# Run in the WordPress folder (WP-CLI)
wp db export ~/hacked-$(date +%F).sql
tar -czf ~/hacked-files-$(date +%F).tar.gz .
wp maintenance-mode activate
```

Tell your host. Many have a malware team, and on shared hosting the infection may have come from, or spread to, a neighbouring account.

### 4. Update everything

Dashboard → Updates: core, every plugin, every theme. Delete plugins and themes you do not use, including inactive ones; their files are still reachable. Plugins closed on wordpress.org get no more fixes, so replace them (see [abandoned WordPress plugins](https://getreport.app/learn/wordpress-abandoned-plugins)).

### 5. Find the injection

Start with core files, which WP-CLI can compare with the official checksums:

```bash
wp core verify-checksums
wp plugin verify-checksums --all
```

Any file reported as modified, or "should not exist", in `wp-admin` or `wp-includes` is suspect. Premium plugins have no public checksums and show as unverifiable, which is not a finding.

Then search the files, using the domains from step 1:

```bash
# The spam domain anywhere in the site's files
grep -rl "spam-domain.example" wp-content/ wp-config.php index.php .htaccess

# Obfuscated PHP: legitimate plugins use these too, so review each hit
grep -rlE "eval\(|base64_decode|gzinflate|str_rot13" --include=*.php wp-content/

# PHP files do not belong in uploads
find wp-content/uploads -name "*.php"

# Must-use plugins run without appearing under Plugins
ls -la wp-content/mu-plugins/

# PHP files changed in the last 30 days, newest last
find . -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort
```

Check `.htaccess` at the site root and in `wp-content/uploads`. A referrer redirect often looks like this:

```apache
# Injected: sends visitors from search engines elsewhere
RewriteCond %{HTTP_REFERER} (google|bing|yahoo) [NC]
RewriteRule ^(.*)$ https://spam-domain.example/ [R=302,L]
```

Then the database, where spam links and scripts hide in posts, widgets and options:

```bash
wp db search "spam-domain.example"
wp db search "document.referrer"
wp option get siteurl
wp option get home
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run_relative
```

Delete administrator accounts you do not recognise (reassign their content), and cron hooks that belong to no plugin you run.

### 6. Change every key

The attacker may have copied credentials. Change the passwords of every WordPress administrator, the hosting panel, SFTP/SSH and the database (then update `DB_PASSWORD` in `wp-config.php`). New salts log everyone out, including any stolen session:

```bash
wp config shuffle-salts
```

Rotate API keys stored on the site: payment gateways, SMTP, backups, CDN.

### 7. Reinstall from clean sources

Removing the visible spam is not enough; a backdoor elsewhere puts it back within hours. Replace code you did not write with fresh copies:

```bash
wp core download --force --skip-content
wp plugin list --field=name | xargs -n1 wp plugin install --force
```

Reinstall premium plugins and the theme from the vendor's download, and review your child theme's files by hand. A scanner plugin (Wordfence, Sucuri, MalCare and others) is a useful second opinion afterwards, not a replacement for these steps.

> **Tip:**
> Restore a backup instead when you have one from before the hack and can tell when that was. Check the backup for the injection before you restore it. If the site is complex, the injection keeps returning, or you are not comfortable on the command line, a professional cleanup service is money well spent.

### 8. Stop the next one

- Update weekly, or turn on automatic updates for plugins you trust. The checker's CMS version finding flags an old core.
- Give each person their own account with the lowest role that works, and two-factor login for administrators. [The admin user and author archives](https://getreport.app/guides/wordpress-admin-user-and-author-archives) covers the "admin" account.
- Remove plugins you no longer use.
- Put a WAF in front: your host's, Cloudflare's or a security plugin's.
- Stop file edits from the dashboard, in `wp-config.php` above "That's all, stop editing!":

```php
define('DISALLOW_FILE_EDIT', true);
```

- Watch for file changes (most security plugins can alert you) and keep daily off-site backups with at least 30 days of history, so a clean copy exists when you notice late.

### 9. Ask Google to review

When the site is clean, open Search Console → Security & Manual Actions → Security issues, tick that you fixed the issues and request a review. Describe what you found and removed. Malware reviews usually take a few days; reviews for spam can take several weeks. Pages Google dropped come back as it recrawls them; the steps in [why your page is not in Google](https://getreport.app/guides/why-is-my-page-not-in-google) help after that.

## Platform notes

### Shopify

Shopify runs the servers, so file-level injections are rare. Spam usually arrives through a compromised staff account or an app: review Settings → Users and permissions, remove apps you do not recognise, and compare the theme's code with an older theme version in Online Store → Themes.

### Static sites / custom

The injection sits in the server config, the deploy pipeline or a compromised dependency. Redeploy from your repository to a clean server, compare the live files with the build, and check `nginx.conf` or `.htaccess` for rules matching `Googlebot` or `HTTP_REFERER`.

## Verify

- Re-run the hacked site checker: all three columns show the same words and links, and the four findings pass.
- Test the URLs Google listed with spam, not only the home page.
- URL Inspection's crawled HTML contains none of the spam domains.
- Search Console's Security issues report shows no issues after the review.
- A week later, re-run it; a returning injection means a backdoor survived.

## Common mistakes

- **Cleaning the symptom, not the backdoor.** Deleting the spam links from the footer works until the hidden file re-adds them tonight. Verify checksums and reinstall code (steps 5 and 7).
- **Restoring an infected backup.** The attacker was often inside weeks before the spam appeared. Search the backup for the spam domain before restoring it.
- **Requesting a review too early.** A failed review makes the next one slower. Wait until the checker, URL Inspection and a `site:` search are all clean.
- **Trusting "no differences" alone.** The tool tests one URL; injections often target old posts or generated pages. Test the URLs Google shows, and read the [hacked site learn page](https://getreport.app/learn/hacked-site) for the patterns.
- **Changing only the WordPress password.** Hosting, SFTP, database and API keys are all in reach of the attacker. Change them all, and shuffle the salts.