"Sneaky mobile redirects" manual action: phones sent somewhere else

Seeing it the way a phone user does

The redirect often fires only for visitors who arrive from a search result on a phone, and sometimes only once per visitor, so testing from your bookmarks proves nothing. Google recommends visiting your pages from Google search results on a smartphone. Also try:

• Chrome DevTools device emulation, loading the page with a Google referrer after clearing cookies.
• A private tab on a real phone over mobile data rather than office Wi-Fi, since some scripts skip known IP ranges.
• A command-line check for server-side redirects:

curl -sIL -e 'https://www.google.com/' -A 'Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 Chrome/126.0 Mobile Safari/537.36' https://example.com/post/ | grep -iE '^(HTTP|location)'

If curl shows a Location header to another domain, the redirect is on the server. If curl shows no redirect but the phone still jumps, it is JavaScript in the page, most likely from a third party.

Tracing it to a script or a hack

Check the Security issues report first; Google lists that step before anything else. If it shows a problem, treat the site as hacked and look for mobile user-agent rules in .htaccess and theme files, as described in cloaking and sneaky redirects.

If the site is not hacked, Google's method is simple and slow: remove third-party scripts and elements you do not control from a redirecting page one at a time, and test on a mobile device or emulator after each removal. On WordPress the candidates are:

• Ad network tags and header bidding wrappers.
• Push notification, popup and "monetize exit traffic" plugins.
• Snippets pasted into a header-and-footer plugin or theme options.
• Social, comment or recommendation widgets that load further scripts.

On a staging copy, deactivating plugins in halves narrows it down quickly. When you find the script, remove it and consider raising it with the provider. In DevTools, the Network panel filtered to "Doc" shows which request started the navigation away.

Choosing ad partners who do not do this

Google's prevention advice for this action is mostly about ads: choose advertisers who are transparent about how they handle your traffic, and research industry practices before joining an ad network. It names the Trustworthy Accountability Group's Inventory Quality Guidelines as a starting point.

It also suggests watching your analytics. A sudden fall in time on site for mobile users only, or a drop in mobile users, can be the first sign that phones are being sent elsewhere. Set alerts on those metrics if your analytics tool supports them, and take user complaints about "being sent to a weird site" seriously; visitors often notice before you do.

Hydrogen SEO does not load ad or redirect scripts on the front end, and its Redirection Manager applies the same rule to every visitor, so it cannot create a device-specific redirect. It also cannot detect one that another script creates.

Confirming the fix and requesting review

Before filing, confirm the fix by visiting affected pages from Google results on a phone or in an emulator, several times, including after clearing cookies. Google asks that you request review only when the issue is fixed on all pages of your site.

Mobile visitors arriving from search were redirected by a script loaded
through our ad network's tag. We removed the network from all pages and
confirmed on Android and iOS, from Google results, that /news/* and
/reviews/* no longer redirect. The site was not hacked (Security issues
report clear; core and plugin checksums verified).

After you select Request Review, watch for status messages. The review usually takes days, and sometimes a few weeks. Google can remove affected URLs from its index while the action stands, so the pages may need recrawling before they return, and there is no guarantee of the same positions.