SEO Cloaking: What It Is & How to Detect It from Multiple Locations

SEO cloaking means showing search engines one version of a page and showing people another. The crawler gets a clean, keyword-rich page that ranks; the visitor who clicks gets something else, often a redirect, a different offer or outright spam. Google lists cloaking in its spam policies, and a site caught doing it can lose rankings for single pages or the whole domain.

Most teams meet cloaking from the defensive side: a hacked site that ranks for pharma or casino terms its owner has never seen, or a competitor whose ranking page does not match what the snippet promised. Either way, finding it is an SEO monitoring problem: you need to see the page the way each kind of visitor sees it, and compare.

What counts as cloaking

Google’s definition is about intent: presenting different content to users and search engines in order to manipulate rankings and mislead users. Its own examples include serving a page about travel destinations to the crawler while visitors get a page about discount drugs, and inserting text or keywords only when the requester is a search engine.

The mechanism is always the same. The server, or a script on the page, decides what to send based on who seems to be asking. The signals it uses are:

• User agent. The crude version: anything that says “Googlebot” gets the clean page.
• IP address. The careful version: requests from Google’s published crawler ranges, verified by reverse DNS, get the clean page, so a spoofed user agent alone does not unlock it.
• Referrer. Visitors arriving from a Google results page get the redirect; people who type the URL, including the site owner, see a normal site.
• Location and network. Visitors from the target country on home connections get the payload; office, cloud and datacenter ranges get the clean version, because that is where reviewers and security scanners come from.
• Device. Some schemes redirect only mobile visitors, because that is where they monetise.

Most real cases combine two or three of these, which is why a single check from your desk usually shows nothing.

What is not cloaking

Plenty of legitimate setups serve different responses to different visitors. Google says these are fine as long as the crawler sees what a comparable user would see:

• Geo and language personalisation. Showing prices in euros to visitors in Germany is not cloaking. Treating Googlebot differently from a user in the same place would be. Our guide to localized Google results covers how location changes what people see.
• Paywalls and gated content. Google documents structured data for paywalled content precisely so publishers can let the crawler see the full article without it counting as cloaking.
• Device-specific layouts. Different markup for mobile and desktop is fine when the main content is equivalent.
• Rendering for bots. Serving pre-rendered HTML to crawlers was once recommended as a workaround for heavy JavaScript. Google now calls it a workaround rather than a long-term solution, but it is not cloaking when the content matches.

The test for each one is the same question: would a real user in the crawler’s position get the same content?

Why you cannot check it from one place

A cloaked page is built to look clean to exactly the viewers most likely to check it. That gives you three blind spots:

1. You are the excluded audience. If you check your own site while logged in, from the office, or by typing the URL, a referrer-based hack will never show itself. Site owners often learn about it from Search Console or from customers.
2. You cannot be Googlebot. Sending a Googlebot user agent catches only crude cloaking. Anything that verifies the crawler’s IP will treat you as a user.
3. You are in the wrong market or network. A scheme that only fires for mobile visitors from one country on home connections is invisible from a cloud server in another.

So detection is a comparison, run from enough vantage points to cover the conditions the cloaker filters on.

A detection workflow

Step 1: get Google’s view first. In Search Console, the URL Inspection tool’s live test fetches the page as Googlebot from Google’s own infrastructure and shows the rendered HTML and a screenshot. The Rich Results Test does the same for pages you do not own. This is the only reliable way to see the crawler version, because it comes from a real Googlebot IP.

Step 2: collect the user views. Fetch the same URL as ordinary visitors, varying one condition at a time:

Variant	User agent	Referrer	Network
Baseline	Desktop browser	none	your office
From search	Desktop browser	google.com results page	your office
Mobile from search	Mobile browser	google.com results page	home IP in the target country
Desktop from search, market	Desktop browser	google.com results page	home IP in the target country
Crude bot check	Googlebot string	none	your office

The home-IP rows are where a residential proxy comes in: a household connection in the country you are testing, so the request looks like the visitors the scheme is waiting for. Keep the locale, timezone and language consistent with the exit country, as described in our guide to matching proxy geo, timezone and locale, or a well-built scheme will treat you as an outlier.

Step 3: compare what matters. Raw HTML differs between any two requests because of tokens and timestamps. Compare the parts that change rankings or the visitor’s experience:

• the final URL after redirects, and every hop in the chain;
• the title, meta description, canonical and robots directives;
• the main text, normalised and hashed;
• the outbound links, especially to unfamiliar domains.

Step 4: repeat. Hacks and competitor schemes often fire only for a share of visits, or only at certain hours. One clean result is weak evidence. Run the matrix several times across different exits and times of day before concluding a page is clean.

Here is a minimal comparison script. Set PROXY_URL to a residential gateway with a country target, and add more variants for each market you care about:

import hashlib, os, re
import requests

URL = "https://example.com/some-page"
DESKTOP = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36"
MOBILE = "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1"
GOOGLEBOT = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
SERP = "https://www.google.com/"
RESI = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}

VARIANTS = {
    "baseline": dict(ua=DESKTOP, ref=None, proxies=None),
    "from_search": dict(ua=DESKTOP, ref=SERP, proxies=None),
    "mobile_market": dict(ua=MOBILE, ref=SERP, proxies=RESI),
    "desktop_market": dict(ua=DESKTOP, ref=SERP, proxies=RESI),
    "googlebot_ua": dict(ua=GOOGLEBOT, ref=None, proxies=None),
}

def tag(html, pattern):
    m = re.search(pattern, html, re.I | re.S)
    return m.group(1).strip() if m else ""

def fingerprint(ua, ref, proxies):
    headers = {"User-Agent": ua, "Accept-Language": "en-US,en;q=0.9"}
    if ref:
        headers["Referer"] = ref
    r = requests.get(URL, headers=headers, proxies=proxies, timeout=30)
    html = r.text
    text = re.sub(r"<script.*?</script>|<style.*?</style>|<[^>]+>", " ", html, flags=re.S)
    text = re.sub(r"\s+", " ", text).strip().lower()
    return {
        "final_url": r.url,
        "hops": [h.headers.get("Location", "") for h in r.history],
        "title": tag(html, r"<title[^>]*>(.*?)</title>"),
        "canonical": tag(html, r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)'),
        "robots": tag(html, r'<meta[^>]+name=["\']robots["\'][^>]+content=["\']([^"\']+)'),
        "text_hash": hashlib.sha256(text.encode()).hexdigest()[:12],
    }

results = {name: fingerprint(**v) for name, v in VARIANTS.items()}
base = results["baseline"]
for name, res in results.items():
    diffs = [k for k in res if res[k] != base[k]]
    print(f"{name:15} {'SAME' if not diffs else 'DIFFERS: ' + ', '.join(diffs)}")

A difference in text_hash alone may be harmless personalisation. A different final_url, a new redirect hop, or a title that only appears for search visitors is the pattern to investigate. Then compare the user views with the HTML from the URL Inspection live test.

What to do when you find it

On your own site, treat it as a security incident first. Referrer- and IP-based cloaking on a site you did not build almost always means a compromise: injected server rules, a modified plugin or theme, or a script added to the template. Remove the code, close the hole that let it in, then request a review in Search Console if Google has applied a manual action. Re-run the comparison matrix afterwards, from the same markets, to confirm it is gone.

On a competitor’s site, document before you report. Capture the crawler version from the Rich Results Test, the user versions with timestamps, exit country and device, and the full redirect chain. Google accepts spam reports through its search quality reporting form. For the paid search version of the same behaviour, our guide to catching cloaked and geo-targeted ads covers the ad side.

Keep monitoring. Hacks come back when the entry point is not fixed, and they tend to return on the pages that rank best. A weekly run of the matrix on your top landing pages, from the countries that send you organic traffic, is a cheap early warning.

FAQ

Is SEO cloaking illegal?

It is not usually a legal question; it is a search engine policy violation. Google lists it in its spam policies and can demote or remove pages that use it. Where cloaking hides scams or malware, other laws may apply to the content itself.

Is showing different content by country cloaking?

Not by itself. Localising prices, language or offers by country is normal. It becomes cloaking when the crawler is treated differently from a user in the same situation.

Can I check for cloaking by changing my user agent to Googlebot?

Only for crude cloaking. Careful schemes verify the crawler’s IP, so a spoofed user agent is treated as an ordinary visitor. Use Search Console’s URL Inspection live test or the Rich Results Test to see Google’s real view.

Why do I need residential IPs to detect cloaking?

Many schemes show their payload only to ordinary visitors in a target market and show a clean page to office, cloud and datacenter addresses. Checking from home connections in that market is the way to see what those visitors get.

The bottom line

Cloaking hides from whoever is most likely to check, so a single look from your desk proves little. Get Google’s view from its own tools, collect user views across referrers, devices and home connections in the markets that matter, compare final URLs, titles and main content, and repeat before calling a page clean. If it is your site, treat a finding as a compromise and fix the entry point. For tracking how your pages appear across many locations over time, see our geo-grid rank tracking guide.