Cloaking and sneaky redirects: what Merchant Center forbids

Cloaking shows Google one page and shoppers another; sneaky redirects do the same with a redirect. Google’s Search and Merchant Center policies forbid both. Every visitor at the same address should get the same product, price and page. Most stores caught out never meant it: a country redirect, a firewall rule or a hacked plugin did it for them.

Critical5 min read

By Edvinas Ivanauskas How the guides are reviewed

Why this matters

Google's “Abuse of the network” policy for Shopping ads does not allow “Engaging in practices that attempt to circumvent or interfere with Google’s systems and processes”, and its examples begin: “Cloaking; use of dynamic DNS to switch page or product; manipulating product data or site content in order to bypass our automated system checks”. The landing page requirements say the same thing as an instruction: “Show a product on your landing page that is essentially identical to the product in your product data, regardless of the user’s device, user agent (including bots), browser, location, cookies, your ad targeting choices, or any other consideration.” And Merchant Center's structured data setup page adds prices to it: “Your landing page content, including pricing, must not dynamically change based on user information such as IP address or browser type.”

Google's Search spam policies give the definition: “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” Sneaky redirects are the cousin, with examples such as “Showing desktop users a normal page while redirecting mobile users to a completely different spam domain”. The same policies list honest reasons to redirect, including “Moving your site to a new address”. Redirects are fine; a product link that lands different people on different things is not.

The accidental versions are the ones worth hunting: a country redirect to another store's homepage, bot protection that answers Google's user agent with a stripped-down page, a pricing app that changes prices by visitor. And the ugly one, a hack. In the words of the spam policies: “If a site is hacked, it's not uncommon for the hacker to use cloaking to make the hack harder for the site owner to detect.” If that is you, go to malware and hacked stores first; if country redirects are the issue, see geo-redirect currency displays.

The free scan requests the address you scan twice, once identifying itself with Google's search user agent and once as an ordinary browser. A different status code is reported as a failure; a markedly different page, with a different title, description, canonical tag or structured data, is flagged. If a firewall challenges the Google user agent, the report says so and alleges nothing, because Google's real visits come from Google's own addresses. To see the page from Google's side, use Search Console's URL Inspection tool: “To test the current version of the page as Google would see it, select the Live Test button on the page.” How each check works is on the misrepresentation checker.

Typical evidence

One URL should not show materially different public content

A browser and another request context can receive different content because of redirects, experiments or configuration. Capture the difference, investigate the cause, and remove misleading user-agent-specific behaviour; StoreVerifier cannot assign intent or determine a platform outcome.

rendered as: alternate request

yourstore.com/products

PassCatalogue response captured

rendered as: standard browser

yourstore.com/products → /win-a-prize

FlagRedirected to an unrelated offers page

The captures differ. Investigate the redirect, experiment or user-agent rule before submitting the store; StoreVerifier cannot assign intent or predict the outcome.

Remove unexplained branches that vary public content or destinations by request context. If you did not build one, investigate it as a possible security issue and follow your incident process.

The public signals this check looks for:

A redirect rule sends visitors from some countries to a different store or to a homepage, …
A redirect rule sends visitors from some countries to a different store or to a homepage, including shoppers who clicked a product link from your listings.
A firewall or bot-protection rule serves a challenge, an error or a lighter page to anythi…
A firewall or bot-protection rule serves a challenge, an error or a lighter page to anything that identifies itself as Google.
Server or CDN rules give search engines a page with a different title, price or structured…
Server or CDN rules give search engines a page with a different title, price or structured data from the one shoppers get.
Visitors arriving from Google Search are sent to a spam, pharmacy or gambling page, while …
Visitors arriving from Google Search are sent to a spam, pharmacy or gambling page, while typing the address directly shows the normal store.
A pricing app changes the price on the product page by visitor IP, device or browser
A pricing app changes the price on the product page by visitor IP, device or browser.
An A/B testing tool shows some visitors a different product or price at the same URL
An A/B testing tool shows some visitors a different product or price at the same URL.

What it looks like once it is right

The store removes the user-agent rule, replaces its country redirect with a banner offering the local shop, and checks three views of each product link: a private window, a phone on mobile data and the URL Inspection live test. Same product, same price, same address.

Common mistakes

Common mistake

A store’s server sends requests that identify as Google to a clean product page, while phones arriving from Google Search are redirected to a clearance site on another domain. The owner finds out when a customer emails a screenshot of a page they have never seen.

Fix checklist

Take five product links exactly as they appear in your Merchant Center product data. Open each in a normal browser, in a private window and on a phone on mobile data, and note the final address, the product and the price.
If you sell abroad, repeat from another country, through a VPN or a colleague. The same link should show the same product; offer the local store through a banner or switcher rather than a forced redirect.
In Search Console, run the URL Inspection live test on the same product URLs and compare its screenshot and HTML with what you saw in the browser.
Search for your store on Google on a phone, click through to a product page and note the URL you land on. A redirect that happens only when you arrive from Google Search is a sign of a hack, not a setting.
Go through server, CDN and firewall rules, and any .htaccess or edge rules, for conditions on user agent, referrer or country that change the page or the URL. Remove rules that change the content or destination; keep rules that only block abusive traffic, and check they let Google's verified visits through.
Turn off any feature that changes product prices by visitor IP, device or browser, and stop A/B tests that vary the product or price on URLs you send to Merchant Center.
Keep before-and-after screenshots of what you changed, in case you need them for a review request.

The cleverer cloaks branch on address, not agent

A user-agent test alone misses an IP-based cloak. Render the URL from several vantage points — known Google ranges, ordinary residential IPs, different countries — and watch whether the site it serves changes with who's asking.

multi-vantage fetch · same URL

Google IP rangeclean product catalogue

UK residential IPredirected to /win-a-prize

US residential IPredirected to /win-a-prize

The “safe” page is served only to recognised Google IPs — a possible IP cloak. Preserve both captures and investigate the rule before submitting the store.

Remove unexplained branches that vary public content by request context. If you did not build one, investigate it as a possible security issue and follow your incident process.

Questions merchants ask

Is a geo-redirect cloaking?

Not by Google's Search definition, which is about presenting different content to users and search engines to manipulate rankings and mislead users. But Merchant Center's landing page requirements ask for an essentially identical product regardless of location, so a forced country redirect on a product link is risky. Offer a banner or switcher instead.

Can bot protection make my store look like it is cloaking?

It can, if the rule blocks or changes the page for Google's genuine visits. Real Google visits come from Google's own addresses, so a rule that challenges anything claiming to be Google is not cloaking by itself. Check with the URL Inspection live test in Search Console, which fetches from Google's side.

My site only redirects visitors who come from Google. What is going on?

Treat it as a hack until proven otherwise. Google's spam policies describe injected redirects that depend on the referrer, user agent or device, so a visit from Google Search goes somewhere a direct visit does not. Clean the site, then check Search Console's Security issues report.

Remediation

Risk signal

Cloaking sits under gaming the Google network in Merchant Center policy, so it is no place for clever server rules, even ones added for a good reason. Serve every visitor the same page at the same address, and run the free scan to compare what a browser and Google's user agent receive.

PriorityTreat this and any other highest-severity findings as first-priority work, then document each fix.

EvidenceRecord the current state before each change, apply the fix, then capture the corrected state so every change is evidenced.

Similar cases

Sources

Last reviewed 23 Sep 2026.

That is one issue. The library documents 134.

The free scan lists what it finds on your store. The paid report adds the affected pages, captured evidence and step-by-step fixes. Start free, with no account needed.