Google Showing Pages You Never Created? How We Found and Fixed a Parasite SEO Attack

You searched Google for 'site:yoursite.com' — the search trick that shows which pages of your website Google has indexed. Mixed in with our real pages were links we had never created: fake American stock-market news headlines under a folder called '/expert-time/' that does not exist anywhere on our website.

https://yoursite.com/expert-time/DORM-Q1-2026-Earnings-EPS-Miss-Fails-to-Dampen-Sentiment-as-Stock-Rises-235-35-10775

You scanned every folder on the server. You checked every log file. Nothing. If this is happening to you, this post will save you the confusion we went through — because, as it turned out, there was nothing to find.

Q1. Am I hacked?

Maybe not — and the surprise is common.

Open one of the fake URLs in your browser. If it shows an error page (a 404 "page not found"), then the page does not exist on your server. But there is one trick you must rule out first, called cloaking: some attacks serve the spam content only to Google's crawler and show your normal site to everyone else — including you.

To rule it out, request the same spam URL twice — once as a normal visitor, once disguised as Google's crawler:

As a normal browser

curl -A "Mozilla/5.0" -o /dev/null -w "%{http_code}" https://www.yourdomain.com/the-spam-url

As Googlebot

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -o /dev/null -w "%{http_code}" https://www.yourdomain.com/the-spam-url

Both times your server answered 404 — identical answers, no cloaking. The pages genuinely never existed on your server. (If your test shows the spam page to Googlebot but not to a browser, that IS real malware — stop and contact a security specialist.)

Q2. So what is this? — Parasite SEO

Spammers pick a trusted website (yours), invent fake page addresses on it, and mass-publish links to those addresses from thousands of junk sites. Google follows the links, asks your server for those pages, and — under certain conditions — adds them to its index. Your domain's good reputation is hijacked to rank their fake stock news, casino or crypto pages.

Q3. Why would Google index pages that don't exist?

Because Google indexes what it can successfully fetch — not what you built. Two common mistakes make it possible:

1. The soft 404 — your error page says "not found", but the server technically answers "200 OK".
2. The catch-all rule — your own configuration had a leftover rule that quietly sent every unknown address to a default page. If that target ever answered successfully, every junk address on our domain looked like a real page to Google. You removed it, and this one rule was almost certainly why both spam waves we experienced got indexed.

Q4. The fix: return 410 Gone (web.config)

A 410 Gone tells Google "this page is gone forever". Google keeps re-checking 404 pages for months, but drops 410 pages quickly and permanently.

On your Plesk Windows / IIS server, you added this rule to the '<rewrite><rules>' section of 'web.config' in 'httpdocs':

<rule name="Block expert-time-* pages" stopProcessing="true"> <match url="^expert-time(/.*)?$" ignoreCase="true" /> <action type="CustomResponse" statusCode="410" statusReason="Gone" /> </rule>

On Apache (.htaccess) the equivalent is:

RewriteRule ^expert-time(/.*)?$ - [G,L]

Then the speed-up: in Google Search Console → Removals → New request → "Remove all URLs with this prefix":

https://www.yourdomain.com/expert-time/

The fake pages vanished from search results in about two days. The 410 responses made the removal permanent as Google re-crawled each address.

What NOT to do: never redirect the fake addresses to your homepage — it deindexes slowly and passes bad signals to your real pages.

Q5. Should I block the spam URLs in robots.txt?

No — this is the most common mistake. robots.txt stops Google from visiting the page, so Google can never see your 410 — the addresses then stay in the index essentially forever. Let Google crawl them so it can discover they are gone.

Q6. The permanent shield (never happen again)

You added one final rule that answers 410 Gone for ANY address that is not a real file or real folder on the server:

<rule name="PERMANENT SHIELD - 410 for any URL that is not a real file or folder" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> </conditions> <action type="CustomResponse" statusCode="410" statusReason="Gone" /> </rule>

Your website is fully static — every real page is a physical file or folder — so this is safe for us. All real pages open normally, while every junk address, on any prefix, from any future spam campaign, automatically answers 410. Spammers can keep creating links to our domain (nothing can stop that), but their links now lead nowhere, so Google refuses to index them.

Important: this shield only suits static websites. If your site builds pages dynamically (WordPress permalinks, Laravel, a shopping cart), the shield would block your real pages too — scope it to specific prefixes instead.

Q7. Protecting a static PHP site against injected scripts

For hackers who try to upload real script files, we layered the defence in 'web.config':

1. Block code-injection and webshell patterns in query strings (→ 403):

<rule name="Block code-injection and webshell patterns" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{QUERY_STRING}" pattern="(eval|assert|passthru|shell_exec|proc_open|popen|system)(\(|%28)|php://|data:text/html|https?://|\.\./|/etc/passwd|c99|r57shell|phpspy|b374k|wso\.php" ignoreCase="true" /> </conditions> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" /> </rule>

This kills '?cmd=eval(...)', '?x=system(...)', file inclusion ('../../../etc/passwd', 'php://input', 'http://evil.com/shell.txt') and classic webshell names — while leaving normal tracking parameters ('utm_source', 'gclid', 'fbclid') untouched.

2. Block script-variant extensions and sensitive file types (→ 410): dropped shells use '.php5', '.phtml', '.phar', '.aspx' — and nothing legitimate should ever be downloadable as '.env', '.sql', '.bak', '.zip' or '.log':

<rule name="Block script-variant extensions" stopProcessing="true"> <match url=".*\.(php3|php4|php5|php7|phps|phtml|phar|asp|asax|aspx|ashx|asmx|cer)(/|$)" ignoreCase="true" /> <action type="CustomResponse" statusCode="410" statusReason="Gone" /> </rule> <rule name="Block sensitive file types" stopProcessing="true"> <match url=".*\.(ini|env|bak|sql|log|csv|zip|rar|7z|tar|gz)(/|$)" ignoreCase="true" /> <action type="CustomResponse" statusCode="410" statusReason="Gone" /> </rule>

3. PHP runtime hardening — in '.user.ini' (httpdocs):

display_errors=Off log_errors=On session.cookie_httponly=1

And in Plesk → Domains → PHP Settings → Additional configuration directives:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source allow_url_fopen = Off allow_url_include = Off expose_php = Off

Even if a malicious script somehow landed on the server, it cannot run system commands or open remote addresses.

4. File-integrity monitoring + read-only lockdown — a scheduled PowerShell job fingerprints every file daily and alerts on any new or changed file (a hacker's upload is discovered within 24 hours, not after Google flags the site). And since a static site never modifies its own files, all files are set read-only: defacement and most malware simply fail with "access denied".

Q8. One honest mistake we made along the way

In an earlier attempt we locked the server down too aggressively — and the entire website went down with a 500 Internal Server Error. One over-strict 'requestFiltering' setting broke the whole request pipeline.

Two lessons we now follow religiously: always download a backup of web.config before touching it (recovery then takes seconds), and change one setting at a time, testing after each. On Plesk/IIS, prefer '<rewrite>' rules over 'requestFiltering' locks — a mistake in one rewrite rule fails that rule, not the whole site.

Q9. How long until the spam URLs are completely gone?

• Day 1: 410 rule live + removal request submitted
• Day 1–2: addresses vanish from search results
• Week 1–6: Google re-crawls each address, sees the 410, drops it permanently
• Ongoing: any new fake address, on any prefix, automatically answers 410

Don't measure progress with 'site:' searches — they lag by weeks. Watch the Page indexing report in Search Console, and keep the rules in place for 6–12 months (spammers re-link old campaigns).

The checklist

1. Test spam URLs with a browser user-agent AND a Googlebot user-agent — both must show "not found"
2. Make sure unknown addresses return a clear not-found — never a success page
3. Answer 410 Gone for the spam prefix (web.config rule above) + prefix removal in Search Console
4. For static websites: add the permanent shield rule
5. Block injection patterns, script-variant extensions and sensitive file types
6. Harden PHP: disable_functions, allow_url_fopen=Off, display_errors=Off
7. Monitor file integrity daily; keep site files read-only
8. Rotate all passwords, use SFTP only, keep PHP and Plesk updated
9. Never block spam addresses in robots.txt
10. Never redirect spam addresses to your homepage

If your website is showing pages you never created, or you want your server hardened the same way — that is exactly the kind of work we do. Get in touch with us.