What Is a Sneaky Redirect?

A sneaky redirect sends a visitor to a different URL than the one Google indexed, in order to show users and search engines different things — or to show the user something they didn't ask for. Google names it in its spam policies. Ordinary redirects are fine; what's banned is redirecting deceptively.

What the policy actually says

Google's definition turns on intent, not on the redirect itself: sneaky redirecting is "the practice of doing this maliciously in order to either show users and search engines different content or show users unexpected content that doesn't fulfill their original needs."

The policy names two examples:

Showing search engines one type of content while redirecting users to something significantly different
Showing desktop users a normal page while redirecting mobile users to a completely different spam domain

And it explicitly lists redirects that are not a problem — moving your site to a new address, consolidating several pages into one, and redirecting users to an internal page once they've logged in.

That last list is the important half. A 301 redirect after a migration is not a sneaky redirect. A 302 pointing at a temporary landing page is not a sneaky redirect. The policy is not about status codes at all.

The one word that separates the two: conditional

Here's the test that maps cleanly to the policy, and it takes one sentence.

Does everyone who requests this URL end up in the same place?

A migration redirect fires for everyone — Googlebot, you, the visitor on an iPhone, the person clicking a five-year-old forum link. One rule, one destination.

A sneaky redirect fires for some requesters and not others. The redirect logic inspects something about the visitor and branches:

Condition checked	What it looks like in practice
User agent	Googlebot gets the article; a mobile browser gets a spam domain
Referrer	Direct visits load normally; arrivals from Google get bounced
Device type	Desktop fine, mobile redirected
Geography	Local visitors see the site; overseas traffic goes elsewhere
First visit vs. repeat	Redirect fires once, then sets a cookie so it never fires for you again

That last row is why site owners so often can't reproduce the problem their users are reporting. They visit their own site, get redirected once, and never see it again.

Conditional serving is the shared machinery between this and cloaking — the difference is that cloaking swaps the content at the same URL, while a sneaky redirect moves the user to a different one. Google treats them as close enough to share a manual action.

The two manual actions

Search Console has a specific message for each. From the manual actions report:

Cloaking and/or sneaky redirects — "Your site may be showing different pages to users than are shown to Google, or redirecting users to a different page than Google saw."

Sneaky mobile redirects — "Some pages on this site appear to be redirecting mobile device users to content not available to search engine crawlers."

Both can be partial (a section of the site) or site-wide, and both can strip URLs out of the index entirely rather than just demoting them. If you're looking at either one, the wider recovery process is the same as any other manual action.

Most sneaky redirects were installed by someone else

This is the part that gets buried, and it's the most likely explanation if you're reading this because a message appeared in Search Console.

The overwhelming majority of sites serving sneaky redirects did not choose to. They were compromised, and the attacker installed a conditional redirect because it's the most profitable thing to do with someone else's rankings. Your pages keep ranking, keep getting crawled normally by Googlebot, and quietly hand every organic visitor to a different site.

The attacker's incentive is to hide the redirect from you specifically, which is why the conditions above exist. Typical hiding places:

.htaccess — a RewriteCond matching HTTP_USER_AGENT or HTTP_REFERER, often appended far below the visible rules
Theme or plugin files — a base64-encoded block in functions.php or a header template
Injected JavaScript — a script tag added to every page, sometimes loaded from a third-party domain, that redirects after checking document.referrer
Database content — injected into post or widget records, so replacing files doesn't remove it
A rogue plugin — one that looks plausible in the plugin list and was never installed by you

How to test your own site

Five checks, in the order that finds it fastest.

1. URL Inspection, live test. In Search Console, run a live test on an affected URL and read the rendered HTML. If Google is being served something different from what your browser shows, this is where it surfaces.

2. Fetch as a bare client. From a terminal, request the page with redirects shown and no browser fingerprint:

curl -sIL -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://example.com/your-page

Then run the same request with a desktop user agent, and again with -e "https://www.google.com/" to fake the referrer. Different Location: headers between those runs is your answer.

3. Test in a fresh incognito window from a search result. Not by typing the URL — by clicking through from Google, on a phone, on mobile data rather than your office Wi-Fi. Cookie-gated and geo-gated redirects only show themselves this way.

4. Diff your files against a clean copy. Compare your theme and core files with a fresh download of the same versions. Injected code is usually obvious once it's on the right-hand side of a diff.

5. Check what the redirect chain does after the first hop. A redirect can look innocent for one step and land somewhere else two hops later. Tools that expand a redirect chain will show the full path.

Fixing it

Remove the redirect at its source rather than layering a rule on top of it — a redirect that overrides an injected redirect leaves the injection in place and it will come back. Then rotate every credential (hosting, CMS admin, FTP, database), update everything, and re-scan before requesting reconsideration. A reconsideration request that says "removed the redirect" without describing how the site was accessed tends to be rejected, because Google has no evidence the hole is closed.

If the redirect was deliberate — an old growth tactic somebody set up years ago — the fix is deleting it, not softening it. There's no compliant version of showing Googlebot one destination and users another.

What to do instead

Sneaky redirects exist because someone wanted rankings to point at a page that couldn't earn them. That's a solvable problem, just not with redirect rules. Rankings follow the pages that genuinely have authority behind them, and authority comes from links from real sites. That's what Backlinkster does: one-for-one in-content backlink swaps with real site owners in your niche, each one verified live by code rather than taken on trust. Five swaps a month are free; plans start at $19.

Frequently asked questions

What is a sneaky redirect? A sneaky redirect sends visitors to a different URL than the one search engines were shown, either to display different content to users and crawlers or to send users somewhere they didn't ask to go. Google names it in its spam policies and it can trigger a manual action.

Is a 301 redirect a sneaky redirect? No. A 301 that moves everyone to the same destination — after a migration, a URL change, or a page merge — is explicitly listed by Google as a legitimate use. Status code has nothing to do with it; conditional, deceptive behaviour does.

What's the difference between cloaking and a sneaky redirect? Cloaking serves different content at the same URL depending on who's asking. A sneaky redirect moves the visitor to a different URL. Both rely on the same conditional logic and Google pairs them in a single manual action, "Cloaking and/or sneaky redirects."

Why does my site redirect on mobile but not desktop? Almost always because it's been compromised. Mobile-only redirects are the most common hacked-site pattern, because site owners check their work on desktop. Google has a dedicated manual action for it called "Sneaky mobile redirects."

Can a JavaScript redirect be a sneaky redirect? Yes. Google evaluates behaviour, not implementation. A JavaScript redirect that fires only for visitors arriving from search, or only on certain devices, is treated the same as a server-side one.

How do I know if I have one if I can't reproduce it? Test from outside your usual conditions: click through from a real search result, on a phone, on mobile data, in a private window. Then request the page with curl using different user agents and referrers and compare the Location: headers.

The bottom line

Redirects aren't the problem — branching on who's asking is. A redirect that treats Googlebot and your reader identically is ordinary site maintenance, no matter how many of them you have. A redirect that inspects the visitor first is doing something it needs to hide, and if you didn't build that logic yourself, the most useful next step isn't an SEO fix at all. It's a security audit.