Referral Spam Is Back in Your Reports: Ghost Referrals and Language Spam
Referral sources you have never heard of, a language setting that is not a language, and sessions that never touched your server. Identifying referral spam, and why it can only be filtered, not blocked.
Somewhere in your referral report there is a site you have never heard of sending you hundreds of sessions, all landing on your homepage, all leaving instantly. In another store's reports the oddity shows up as a language: a string of text where en-gb should be, sometimes containing a message, because the language field is easy to spoof and somebody thought that was a clever place to advertise. Both are referral spam, and the first thing to understand about the ghost kind is that no visitor, human or bot, ever loaded your website at all.
Ghost referral spam works by sending fake hits directly to an analytics property using its measurement ID, which used to be visible in page source and easy to harvest. The hit exists only in your data. That is why it cannot be blocked with a firewall, a robots file, or a server rule: nothing arrived at your server. Recognising which type you have decides whether you call your developer or fix your analytics configuration.
Two kinds of spam, two different fixes
Crawler referral spam involves a real bot visiting your site and leaving a referrer behind, often to get its domain seen in your reports in the hope you will visit it. Do not visit it. Those visits can be blocked at the edge like other unwanted automation, and they also consume real resources, so there are two reasons to deal with them. Ghost spam, by contrast, appears in analytics with a hostname that is not yours, or with no hostname at all, because the fake hit was never served by your infrastructure.
The hostname check is the diagnostic. Filter your reports by hostname and look at what appears. Legitimate traffic carries your own domains, plus a small set of known services such as payment providers, translation proxies, and cached page services. Everything else claiming sessions on your property is fabricated data, and it can be excluded with a view filter that includes only your valid hostnames, which is the most durable single fix in this whole area.
Cleaning reports without hiding real problems
Apply include filters for valid hostnames, exclude known spam referrers where your platform supports it, and annotate the date you cleaned up, because every comparison across that date is otherwise meaningless. Keep an unfiltered view. Filters in analytics are destructive to the view they are applied to, and the day you need to check whether something real was excluded, the raw data is the only place to look.
Segment rather than delete when you are still investigating. Build a segment for the suspect sources and compare behaviour: engagement, pages per session, geography, and whether any of it ever reached a product page. Spam referrals almost never do anything. If a strange referrer does show real browsing and occasional orders, you may be looking at a genuine, if odd, source of customers, such as a forum or a price comparison page, and blocking it would be an expensive mistake.
Why it matters beyond untidy reports
Referral spam is small until it is not. At scale it corrupts acquisition reporting, makes a channel look productive, and can trigger real spending decisions. It also pollutes audience building, since fake sessions can fall into remarketing pools in some setups. And there is a security angle worth one line: a measurement ID and a property receiving fabricated hits is a reminder that analytics identifiers are not secrets, and that any system trusting client side data alone can be fed fiction.
Review the referral report monthly with a sceptical eye. Sort by sessions, read the names, and question anything you cannot identify that is large enough to matter. That habit, which takes ten minutes, catches this class of problem and several others, including misattributed partner traffic and test hits from your own tools, before they make it into a board report.
Related reading: Glossary, About, Bots Abusing Gift Card Balance Check Endpoints.
Frequently asked questions
Can I block referral spam in robots.txt?
Not the ghost kind, because it never requests a page from your server. It sends fabricated hits straight to your analytics property. Crawler based spam does visit and can be blocked at the edge or with server rules, but robots.txt is advisory and spam bots are not known for obeying it.
How do I tell ghost spam from real referrals?
Check the hostname dimension. Real visits to your site are recorded with your own hostname. Ghost hits typically show another hostname or none. Also look at behaviour: ghost referrals usually land on the homepage with a single page, no engagement, and no progression into the site.
Should I visit a suspicious referring site to check it?
No. Curiosity traffic is part of the point of referral spam, and some of those domains are unsafe. Identify them from your data, using hostname, behaviour, and volume, and filter them. You do not need to open the site to decide it is not sending you customers.
Will filtering remove historical spam data?
View filters apply going forward and do not rewrite data already collected. For historical reporting, use segments to exclude the spam sources for the period you are analysing, and annotate the change so that anyone comparing periods understands why the numbers shifted.