Fake Google Referrals: 892 in the Log, 55 in Search Console

Over twelve days our server log recorded 892 page requests arriving from Google. Search Console recorded 55 clicks in the same window.

That’s a factor of sixteen, and most of the difference is fake Google referrals: requests that set a Google referrer header without ever passing through Google. On one of those days Google recorded no clicks at all while the log showed 186 arrivals.

Here’s how we measured it, the four tells that prove part of the traffic is forged, and what the gap doesn’t prove.

What We Measured

Twelve days, 10 to 21 September 2026, chosen because Search Console data is complete for that range.

• Log: the nginx access log, counting page requests and ignoring assets.
• Search Console: clicks by date, across every search type.
• Excluded: our own automated requests to the server.

The Search Console figure covers all Google surfaces, not only web results. Image, video, news and Discover each returned zero clicks for the period, so 55 is the complete count of people Google says it sent.

Counting only real page views

A browser loading one article also requests stylesheets, scripts and images. Those carry the article as their referrer, not the search engine, so counting them would inflate both sides.

Every number here is a page request. That’s the closest thing a log has to a visit.

The Day That Settles It

On 20 September, Search Console recorded zero clicks. The log recorded 186 arrivals from Google on the same date.

There’s no reading of that which works. Google can’t send 186 visitors on a day it reports sending none, and a reporting lag doesn’t explain it, because the surrounding days are complete.

The full twelve days

The two lines move in opposite directions

Log arrivals climbed steadily across the period, ending roughly six times where they started.

Clicks didn’t. They stayed in single figures throughout and finished lower than they began. Whatever was producing the log entries was growing while genuine search traffic was flat.

That shape is the practical danger. A report built on log referrals would have shown organic traffic rising sharply in a fortnight when the truth was mild decline.

Four Tells That Prove Forgery

The ratio alone shows something is wrong. These four show part of it is deliberately faked.

Search engines that don’t exist

Thirty requests carried referrers from domains like google.link, yahoo.link, yandex.link, baidu.link and bing.link. None of those is a search engine.

Our own domain ends in .link, which is presumably why that ending was picked. Skimmed quickly in a report, the referrer reads as Google.

A Google endpoint that isn’t real

Twenty referrers pointed at a path on google.com that takes a long encoded parameter and claims to forward somewhere. Google publishes no such endpoint.

The encoded string is what sells it. It looks technical enough that nobody checks whether the URL resolves.

Misspelt user agents

A hundred and two requests carried browser strings with typos in them: Mozilla spelt Mozlila, and Build spelt Bulid.

Real browsers don’t misspell their own names. These come from a copied template that had the errors baked in, which also means they’re trivial to filter once you’ve seen them.

Pages no searcher would land on

Nine requests claiming a Google referrer asked for a database file inside a theme folder. Nobody reaches that from a search result.

It’s a probe for a known backdoor, dressed up with a Google referrer so it reads as ordinary traffic in a log summary.

What We Found When We Checked That

The file doesn’t exist on the server, and every one of those nine requests returned a not-found error. The probe failed.

We’re saying so explicitly because a tell like that is easy to misread as a break-in. It wasn’t one. It’s worth checking on your own server rather than assuming either way.

Check the status, not the request

A log full of probe requests tells you that you’re being scanned, which is true of every site on the internet. What matters is what the server returned.

A 404 means the probe found nothing. A 200 on a file you don’t recognise is the one that needs attention today.

What the Gap Doesn’t Prove

Three honest limits, and they matter more than the headline.

• Not every arrival is fake: Docs, Gmail and Translate links all send a google.com referrer.
• No visitor counts: the site sits behind a proxy, so every logged address is the proxy’s.
• One site, one window: twelve days on a single domain isn’t a survey.

So the claim isn’t that 892 minus 55 equals fraud. It’s narrower and firmer.

A meaningful share of the log’s Google traffic carries proof of forgery. The total sits too far from the recorded clicks to be used as a measurement of anything.

Why the proxy limit matters

Because every address belongs to the proxy, we can’t tell one visitor from another. A single script looping could have produced most of those requests.

That cuts against the log, not for it. The arrival count may represent a handful of real sources, which makes it less trustworthy rather than more.

How to Check Your Own Logs

You need the access log and about ten minutes.

• Count the claims: page requests whose referrer names a Google domain.
• Pull the real figure: Search Console clicks for the identical dates.
• Compare by day: the divergence shows up in daily numbers first.

Then read the referrer strings and user agents themselves rather than a summary of them. Every tell above was visible in the raw text and invisible in a dashboard.

Check the log you think you’re reading

Ours writes to a named file, while the default access log on the same server has sat empty since June. A report built on the default would have shown nothing at all.

Confirm which file your server is writing before you trust a count from it. That took us one command and would have invalidated the whole study if we’d skipped it.

What to Do About It

Treat log referrals as an upper bound and keep the number you report grounded in Search Console.

Blocking the traffic is optional. Failed probes cost nothing, and a filter you have to maintain is worse than a number you’ve learned to distrust.

The practical risk isn’t the spam. It’s a monthly report showing organic traffic growing because a script pointed itself at your site, while real clicks fall. We’ve written before about impressions that never produce clicks, and this is the same lesson one layer down.

Frequently Asked Questions

Why does my server log show more Google visits than Search Console

It happens because referrer headers can be set to anything by whoever sends the request, so a log counts claims rather than verified visits. Search Console counts clicks Google recorded.

How can I tell a fake Google referral

You read the raw strings. Look for referrer domains that aren’t real search engines, Google URLs with endpoints that don’t exist, misspelt browser names, and requests for files no searcher would open.

Is referrer spam harmful to rankings

We found no evidence of ranking harm and make no claim either way. The measurable damage is to reporting, because inflated arrival counts can hide a real decline in clicks.

Does this mean my site has been hacked

Not by itself. Some forged requests probe for known backdoor files, so check whether the requested file exists and what status it returned. On our server the file was absent and every probe failed.

Should I block these requests

Blocking is optional, since failed probes do no damage. Fixing the reporting matters more, because a number nobody trusts is worse than no number.

Which log file should I check

The one your server is configured to write, not the default path. Ours writes to a named virtual-host log while the default file has stayed empty for months.

Report the Number You Can Defend

Our log said Google sent 892 visits. Google said 55. One of those numbers can be checked against its source, and the other can be set by anybody with a script.

Run the comparison on your own twelve days before your next report goes out.