"Cloaking and/or sneaky redirects" manual action on a WordPress site
Your site "may be showing different pages to users than are shown to Google, or redirecting users to a different page than Google saw." On WordPress, the most common cause is not a deliberate trick by the owner. It is a hack that serves spam to Googlebot, or redirects visitors who arrive from Google, while you see a normal site when you visit directly.
The report entry lists the affected URL patterns. It may be a handful of posts, one directory, or every page when the redirect lives in .htaccess or a sitewide script. Because the action affects pages Google saw doing this, expect those pages to be ranked lower or dropped until the review succeeds.
So the first job is to reproduce what Google and search visitors get. Then find the code doing it, remove it, close the hole that let it in, and request a review. Hydrogen SEO is not a security tool and cannot detect or remove injected code; you will need file and database access, and possibly your host's help.
Reproducing what Googlebot and searchers see
Use URL Inspection → Test live URL → View tested page on an example URL and compare the HTML and screenshot with what you see in a private window. Then request the page from the command line with different identities, because cloaking code checks the user agent, the referrer or both:
# As a normal browser, arriving directly
curl -sL -o direct.html -w '%{url_effective}\n' https://example.com/page/
# As Googlebot
curl -sL -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' -o bot.html https://example.com/page/
# As a visitor clicking a Google result on a phone
curl -sIL -e 'https://www.google.com/' -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' https://example.com/page/
diff <(grep -o 'href="[^"]*"' direct.html | sort -u) <(grep -o 'href="[^"]*"' bot.html | sort -u)
A redirect only in the third request, or spam links only in bot.html, confirms the problem. Some hacks also skip logged-in users, so test while logged out.
Where the conditional code hides in WordPress
Google's tip is that these redirects "are often written in JavaScript or in your .htaccess file," and to check the CMS and plugins. On WordPress, look at:
.htaccess:RewriteCondlines testing%{HTTP_REFERER}for google or%{HTTP_USER_AGENT}for bots or phones, followed by a rewrite to another domain.- Theme files:
functions.php,header.phpandfooter.phpwith code checking$_SERVER['HTTP_USER_AGENT']. wp-config.phpandwp-content/mu-plugins/: an unexpectedincludeor a must-use plugin loads on every request and does not appear in the normal plugin list.- Database:
<script>tags insidewp_posts.post_contentor options rows, often obfuscated. - Legitimate plugins that geo-redirect or device-redirect. If you set one up on purpose, make sure Googlebot and users in the same situation get the same result.
grep -rnE "HTTP_REFERER|HTTP_USER_AGENT|base64_decode|eval\(" wp-content/themes wp-content/mu-plugins wp-config.php .htaccess
wp core verify-checksums
wp plugin verify-checksums --all
Cleaning up and closing the entry point
Take a backup of the infected site first so you can study it later. Then:
- Replace
.htaccesswith the default WordPress rules plus any custom rules you know you added. - Reinstall WordPress core and every plugin and theme from the official source; delete anything you do not recognize or no longer use.
- Remove injected scripts from posts and options, and check for administrator accounts you did not create with
wp user list --role=administrator. - Change all passwords (WordPress, hosting, SFTP, database) and rotate the secret keys with
wp config shuffle-salts. - Update everything, since an outdated plugin is the usual way in.
Also open Hydrogen SEO → Redirections and delete any rule you did not create. Its rules are exact, contains, starts-with or ends-with path matches, so it cannot express a user-agent condition, but a stray rule pointing off-site is still worth removing. If Search Console also shows a security issue, fix that first; see Hacked: Code injection.
Filing the request and what follows
Rerun the curl tests on several affected URLs and confirm the output matches for all three identities. Then select Request Review and explain the cause in plain terms: which file or plugin did it, how it got there, what you removed and what you changed to stop it happening again. If the cloaking was intentional, say so and describe what you stopped doing; reviewers deal with both.
After submitting, you get a confirmation email and a second one with the decision. Most reviews take several days or weeks. If the infection returns before the review, the request will fail, so keep watching the site with the same curl checks for a while. Paywalled sites that serve full text to Google and a teaser to users should add paywalled content structured data, which is how Google tells a paywall apart from cloaking.
Common questions
Why can't I see the redirect when I visit my own site?
Cloaking code usually targets visitors who arrive from a search engine, specific devices, or crawlers, and often skips logged-in users. Test logged out, with a Google referrer and a mobile user agent, using curl or the URL Inspection tool.
Are affiliate link redirects like /go/product cloaking?
A redirect that sends every visitor, human or crawler, to the same destination is not cloaking. The problem is redirecting users somewhere different from what Google saw, or only redirecting certain visitors.
Can an SEO plugin fix a cloaking manual action?
Not by itself. An SEO plugin controls your metadata, sitemaps and redirects, but the cause is usually injected code in files or the database. Hydrogen SEO can help you check redirects and noindex settings afterwards, not remove malware.