TL;DR: Cloaking is showing search engines one version of a page and visitors another, to manipulate rankings. A sneaky redirect is sending visitors somewhere they didn’t expect, or somewhere different from what search engines see. Google names both in its spam policies and says sites that break them may rank lower or drop out of results altogether. You’re unlikely to do either on purpose, but a hacked site or a forgotten redirect rule can create the same mismatch, so check what Google sees against what a visitor sees.
“Black hat SEO” covers a lot of ground. Cloaking and sneaky redirects are two specific practices Google calls out in its spam policies, and they’re easy to confuse with each other and with normal website behaviour. Here’s what each one is, what it isn’t, and how to check your own site.
What Is Cloaking In SEO?
Cloaking means showing search engines different content from visitors to manipulate rankings and mislead people. For example, search engines might see a page about travel destinations while visitors who click through get a page selling discount drugs. Or a page might add extra keywords only when a search engine is asking for it.
Hidden text, such as white text on a white background, is sometimes called cloaking, but it falls under a separate spam policy on hidden text and links. Cloaking is about serving a different version of a page depending on who is asking.
Some things that look similar aren’t cloaking. A paywall or gated content is fine as long as Google can see the full content behind it, just as a subscriber would, and the site follows the Flexible Sampling guidance. If your site relies on JavaScript or images that search engines struggle to read, the answer is to make that content readable for both, not to serve each a different version.
What Are Sneaky Redirects?
A redirect sends a visitor to a different URL from the one they asked for. Most are harmless, and many are essential. A sneaky redirect is one used maliciously, either to show visitors and search engines different content or to send visitors somewhere that doesn’t meet what they were looking for. Examples include showing search engines one type of content while redirecting visitors somewhere significantly different, or showing desktop visitors a normal page while sending mobile visitors to a spam domain.
Plenty of redirects are legitimate: moving to a new address, merging several pages into one, or sending logged-in users to an internal page. What makes a redirect sneaky is the intent to deceive users or search engines.
The planning behind a genuine site move is a separate job, which we cover in our guide to redirect mapping.
Can This Happen Without Anyone Meaning It To?
Because the definitions turn on intent, most businesses are unlikely to be cloaking on purpose. The risk is a mismatch nobody planned, and the best-documented cause is a hack. Hackers sometimes use cloaking so the owner doesn’t notice, and may add code that redirects only some visitors, such as people clicking a result in Google Search but not someone opening the URL directly. An owner checking their own site may see nothing wrong.
Other causes are less dramatic. These are possibilities we’d check for, not anything Google documents as a cause:
- A redirect rule left over from an old migration, A/B test or security fix that still fires for some visitors or devices.
- A caching, geo-targeting or membership tool that treats search engine crawlers differently from people.
Google’s policy doesn’t say how it treats a mismatch that nobody intended, so we wouldn’t rely on intent as a defence. Whatever the cause, the fix is the same: find what is serving a different version and remove it.
If you think the site has been hacked, treat it as a security problem first and bring in your developer or host, as removing the redirect alone may not remove the access that created it.
Wildcat Digital Example: In one Wildcat technical audit, a hearing care provider’s website used a slide-out “burger” menu for its main navigation. At the time, the site’s platform (Wix) loaded that menu with JavaScript, so the navigation links weren’t in the page’s HTML. Visitors saw a working menu, but Google, reading the HTML, saw a site with no navigation at all, which meant it couldn’t follow those links to the rest of the site. We found the problem when our attempt to crawl the site failed, and a manual review showed why: there were no links for the crawler to follow. Replacing the burger menu with a standard navigation bar put the links back into the HTML, where Google could see and follow them.
How To Check Your Own Site
A few quick checks can show you whether there is something to look into.
Our Top Tip: Don’t type your page address into the browser. Search for the page on Google on your phone, click the result and note where you land. Then open the same URL directly on a desktop. If the two don’t match, or you only get sent somewhere odd when you arrive from Google or on mobile, you may have found a selective redirect of the kind used on hacked sites.
- Compare what Google gets with what visitors get. In Search Console, run the URL Inspection tool on the page, choose Test live URL, then open View tested page to see the screenshot and HTML Google received. Compare that with the page in your browser. Ignore cosmetic differences like a cookie banner and look for different text, links, offers or destinations. The live test shows what Google’s inspection crawler gets at that moment and doesn’t check for manual actions, so a clean result isn’t a clean bill of health.
- Review the redirect rules. Ask your developer or host for a list of the redirects on the site, including any added by plugins, and what each one is for. Anything nobody can explain, or that only applies to certain visitors or devices, needs a closer look.
- Check the Manual actions report. If a manual action applies, you’ll see it in the Manual actions report and the Search Console message centre. An empty report doesn’t rule out a problem, because Google’s automated systems can also affect how a site ranks.
“When Google and visitors are seeing different things, it’s usually a technical problem rather than anyone trying to game the system. In the case I’ve seen, a slide-out menu was loaded with JavaScript, so the links never appeared in the HTML and Google didn’t think the site had a navigation menu. What gave it away was the crawl. We tried to crawl the site; it didn’t work, and when we looked into why, the links simply weren’t there.”
— Jamie Stowe, Senior SEO Account ManagerWhat Happens If Google Flags It?
Sites that break the spam policies may rank lower or drop out of results altogether. Google enforces them with automated systems and, where needed, human review, which can lead to a manual action.
If you do get a manual action for cloaking or sneaky redirects, the fix follows the checks above: find and remove whatever is serving different content or redirecting only some visitors, then select Request Review in the Manual actions report.
Our guide to Google penalties covers penalties more broadly.
FAQs
Google’s cloaking policy doesn’t mention location or language. Its guidance on locale-adaptive pages says Googlebot’s default IP addresses appear to be US-based, so a site that swaps content by country may show Google only one version. Google also crawls from some non-US addresses, and advises treating Googlebot like any other visitor from wherever it appears to come from. In practice, the bigger risk is usually that Google only sees one version of your content, rather than it counting as cloaking.
Google says it generally doesn’t treat dynamic rendering as cloaking as long as it produces similar content, and that serving completely different content to users and crawlers can be cloaking. It also calls dynamic rendering a workaround rather than a recommended solution, and suggests server-side rendering, static rendering or hydration instead. If your developer uses dynamic rendering, ask them to check both versions show the same content, and whether one of those alternatives would suit the site.
How Wildcat Handles This
Cloaking and sneaky redirects aren’t a service of their own for us. We’d treat them as something a technical SEO audit looks into, because that audit covers areas including indexing, crawlability and redirects, so unexplained redirects are within its scope.
Tell us what you’ve noticed, for example, an unexpected redirect, a Manual actions message in Search Console or a traffic drop you can’t explain, through the enquiry form or on a free 30-minute call with our growth team.
To talk it through, book a free consultation on our contact page, or read more about our technical SEO services.
Last Reviewed: 11 October 2026
Kezia Humphries
SEO Account Manager
