Cloaking manual action: how do we find redirects that only some visitors see?

Google's spam policies describe cloaking as deceptive differences between content for users and search engines. Sneaky redirects instead move visitors to an unexpected destination. Both can be conditional, which is why we avoid concluding that the notice is wrong after a single direct visit.

Start with the exact notice, affected scope, and available examples. Our first investigation question is observable: which request receives which content or destination? Keep that separate from the later question of intent or responsibility. A plugin defect, malicious injection, and a deliberately configured rule might produce similar symptoms while requiring different remediation owners.

We recommend a small comparison matrix rather than random repeated visits. Use the same affected URL and vary the relevant conditions: desktop or mobile, a fresh session or an existing one, direct navigation or the reported entry path. Record the time and final URL. Do not claim to reproduce a search-engine request simply by changing a user-agent string.

Choose combinations from the evidence. If a report identifies a mobile-only problem, begin with that path and a desktop control. If a suspicious destination appears only after a search visit, preserve that difference. Keep potentially harmful destinations isolated during technical investigation; the useful evidence is the redirect behavior, not interacting with the destination. A logged-in administrator session should not be your only test. We preserve the failing conditions before changing settings: losing the ability to reproduce the problem can make a later clean visit impossible to interpret.

Google's dynamic-rendering documentation distinguishes comparable content delivered through different rendering methods from deceptive content differences. It describes dynamic rendering as a workaround and recommends alternatives. A server-rendered page and a hydrated browser page do not need identical source code to communicate the same substantive content.

We compare the main answer, headings, visible links, and destination behavior. Record any legitimate difference caused by authentication, localization, or product state rather than labeling all variation as cloaking. A missing interactive widget may be a rendering defect; a different commercial subject or unexplained destination calls for another investigation. Define what users should receive before deciding which branch is incorrect.

Our recommended investigation works backward from the response. A redirect may originate in hosting configuration, application middleware, a CMS extension, a template, or a third-party script. Preserve the chain and determine which layer first changes the destination. Avoid changing several layers simultaneously if doing so would make the cause impossible to establish.

Review recent changes and older conditional rules alike. Write down the owner of each candidate component and the evidence connecting it to the behavior. If you find unauthorized code, the work expands beyond removing a visible redirect: the team needs to investigate how it arrived and whether the access path remains open. A rollback can contain a symptom, but it is not proof that the root cause has been closed.

Google's redirect documentation explains supported redirect methods and their search implications. We do not remove migration redirects or login routing indiscriminately because a manual action mentions redirects. First state the expected destination and the reason that move should occur.

For an illustrative investigation, an old product URL might correctly point to its replacement for every visitor, while an injected script diverts a fresh mobile visitor elsewhere. The fix should address the injected branch and preserve the intended product journey. Test the original failing condition and the normal control path afterward. Otherwise a rushed cleanup can trade a policy problem for broken navigation. We include a legitimate journey in the acceptance check because removing every redirect may hide the symptom while breaking the product.

The URL Inspection tool provides indexed and live-test information; these are different views. Record which one you used. We compare available rendered output with the browser evidence, while recognizing that a test represents its own request conditions and may not reproduce every conditional branch.

Keep a short verification record: conditions, before result, change, after result, and remaining uncertainty. If a behavior appears intermittently, say so rather than selecting a clean visit as proof. Investigate cache layers and conditional state with the technical owner until the explanation matches the evidence. Our manual action recovery support can help turn that engineering record into a coherent remediation case.

A useful reconsideration request connects the notice to the observed difference, the responsible component, the completed correction, and the verification. We include representative affected paths and explain how other pages using the same component were checked. A statement that a plugin was disabled needs the supporting result.

Keep the security and search conclusions distinct. Correcting a public response does not by itself establish that an intrusion is fully contained, and a clean security scan does not establish that all routing is appropriate. Assign each conclusion to the evidence that supports it. If no manual action is present, follow the diagnosis guide before treating a traffic decline as manual enforcement.