WooCommerce should send customers only through the journey you intended
If WooCommerce sends a customer to another website unexpectedly, establish where the change happens before editing the store. A configured payment-provider page, an incorrect site rule and a malicious redirect are different cases. The destination, the point in the journey and the conditions that trigger it help separate them.
A shop can look normal to its owner while another visitor gets a different result. That does not identify the cause by itself. It does mean that testing only the homepage from an administrator’s usual computer is an incomplete investigation.
This guide is for a store owner who needs to decide what to record, what to protect and what a specialist should investigate. It is not a claim that your particular shop is infected, nor a completed security or payment test.
Separate an expected handoff from an unexpected destination
| What happens | What to establish | Next route |
|---|---|---|
| A payment page opens after selecting a method | Whether the configured provider and documented flow match | Review that payment integration |
| The shop changes domain or loops without an expected reason | The rule, response or script initiating the change | Investigate configuration and possible compromise |
| Only some visitors reach unrelated content | Device, arrival route, timing and browser state | Investigate the conditional behaviour |
A secure-looking address or familiar logo is not enough to establish the intended payment route. Compare it with the provider’s trusted documentation and the store’s authorised configuration. Do not decide by following instructions on an unexpected destination.
If the problem is simply returning to the same account form, start with our WooCommerce customer login redirect guide. A same-site session loop should not automatically be labelled malware.
A payment redirect can be legitimate, but it must match the integration
Payment interfaces differ. For example, Stripe documents both hosted and embedded Checkout options. That establishes that a provider-hosted page can be part of a designed journey; it does not establish how your WooCommerce extension is configured.
Ask which integration is installed, which method was selected and which destination it is supposed to use. Check the start and return points with the owner of that configuration. Avoid turning a normal provider handoff into a malware-cleanup job, or explaining away an unrelated destination because it appears during checkout.
Do not enter credentials or payment details into an unexpected page to see what happens. A specialist can agree a controlled investigation and any later provider-specific testing separately.
Record the trigger without collecting customer secrets
Write down the public starting URL, approximate time and time zone, visible destination domain and point in the journey. Was it the first product visit, adding an item, opening the cart or returning from a provider? Add the device, browser and whether the visitor arrived from search or directly.
Record observations separately from conclusions. “A mobile visitor arriving from search was sent elsewhere” is useful evidence. “The payment plugin is hacked” needs supporting investigation. Google’s spam policies describe deceptive redirects that can differ between desktop and mobile; the pattern is relevant, not a diagnosis of every mobile problem.
For an initial assessment, share redacted screenshots or a short description. Full URLs, recordings and network exports can contain session identifiers, order keys or personal information. Do not publish them or send customer payment details with the enquiry.
Protect the current store state before choosing a restore
The priority is a current, recoverable record of the store and a containment decision appropriate to the observed risk. Coordinate that decision with the owner and hosting team. The right boundary might involve the affected route or a wider interruption; do not assume every incident requires the same action.
Do not overwrite the current database with an old backup simply because the old homepage looks better. Identify the backup time and the activity since then: orders, customer accounts, refunds and other relevant changes. WooCommerce’s restore guidance explains gap-period risks, including missing records and subscription-related effects where that extension applies.
Agree how the current state will be preserved and how business records will be reconciled before restoration. An archive of public pages is not a substitute for the store’s files and operational data.
Ask for evidence that distinguishes the server from the browser
A technical investigator can compare the initial response with what the browser subsequently does. MDN’s redirection guide distinguishes HTTP, HTML and JavaScript mechanisms. A request that does not execute page scripts cannot establish every result a shopper experiences.
Ask the investigator to record which response or resource initiates the departure and what the evidence actually shows. An address-bar screenshot records a destination, but may omit an intermediate step. Conversely, a browser trace without the relevant customer conditions can miss the reported behaviour.
Keep the shareable incident note separate from any detailed diagnostic export. The note can identify route, time, observed stage and destination domain. A fuller export may need restricted handling and redaction of cookies, authorisation values, personal information and order-specific parameters before it leaves the diagnostic team.
Also label the environment. Desktop mobile emulation, an actual phone, a logged-in browser and a fresh public visit are different observations. Write down which was used and what remains to be checked. That detail gives the next technician something concrete to reproduce without pretending one browser run represents every customer.
A short example makes the next action clearer
Imagine a report saying that a shopper opens a product from search on a phone and reaches an unrelated domain before adding anything to the cart. The owner opens the same product directly on a desktop and sees nothing unusual. Those two observations justify comparing arrival and browser conditions. They do not establish that a payment provider initiated the redirect.
A useful assessment request preserves both observations and the approximate time. It states that no payment step had begun in the reported journey, identifies the public product route and describes any recent store change separately. This fictional example is a way to organise a brief, not an incident we have diagnosed.
Investigate the source of the redirect, not just its visible address
The technical review may need to compare server responses, browser behaviour, store settings, third-party scripts and delivery layers. A server-side redirect and a script that changes location after loading are different paths to investigate.
Review relevant files and data against trusted sources and their intended purpose. The presence of a script tag, an unfamiliar domain or an encoded string is not sufficient reason to delete a record. Store extensions and legitimate integrations can also contain code that needs interpretation.
Include must-use components where relevant. The WordPress must-use plugin documentation distinguishes directly loaded PHP files from subdirectories and the separate administrative listing. Removing ordinary plugins alone does not describe the whole application.
A useful diagnosis identifies the implicated behaviour, supporting evidence and proposed correction. It should distinguish a demonstrated cause from parts of the system that remain unexamined.
Keep the expected checkout journey visible
A simple map of cart, customer information, payment, review and confirmation helps the team locate an unexpected departure. The design reference below makes those intended stages tangible. It does not identify a malicious domain or verify a live payment integration.
Open the full checkout design reference
Use a diagram of your actual shop to mark the allowed entry, provider handoff and return. A polished reference shows interface structure; the trusted configuration and investigation establish what the implementation is supposed to do.
Compare customer contexts and cached responses carefully
Agree a small observation set that reflects the reported symptom: the affected public route, direct and search arrivals where relevant, and the actual device or browser conditions. A logged-in administrator may receive a different response from a new shopper.
If the evidence points to a cached affected response, identify the layer and entries that need invalidation after the source correction. Do not treat deleting every customer session or changing all account state as a routine substitute for finding that layer.
Repeat the known failing case and record the result. Passing it establishes what happened under those conditions. It does not prove that every possible trigger, persistence mechanism or unrelated screen has been examined.
Keep existing order questions separate from the redirect fix
A customer may have been redirected after beginning payment, while an order remains pending or its confirmation is unclear. Do not infer payment success from the browser’s return page, and do not ask the customer to pay again solely to diagnose the redirect.
Where the incident involves an earlier transaction, an authorised team should compare the appropriate store and provider records. Use the references needed for that review without putting card data into logs or public screenshots. Repairing the navigation does not decide whether a particular transaction should be captured, refunded or otherwise adjusted.
Our WooCommerce payment incident handover guide separates new behaviour from unresolved historical cases. Its illustrative and laboratory examples have their own stated limits; they are not evidence about your provider account.
A browser or Google warning has its own follow-up
If Search Console reports a security issue, keep the report and its sample URLs with the investigation. Google explains that samples are not necessarily a complete list of affected pages and that review follows fixing the reported issues.
The technical handover should distinguish the shop’s observed behaviour from an external warning or review still pending. Do not promise a removal time, ranking recovery or approval by another platform because a local retest passed.
Agree what the repair will demonstrate
Before changes, specify the affected journeys, permitted investigation access, preservation plan and acceptance checks. Afterwards, ask for a short account of the cause established, correction made, conditions retested and limitations that remain.
For a store, include the relevant product, cart and customer route without turning a public browsing check into proof of a completed payment. Any provider-specific test needs its own authorised arrangements. The essential tests after a WooCommerce repair help identify which other journeys belong in the agreed scope.
Record who owns monitoring and any unresolved customer cases. A homepage screenshot and a general “all fixed” message are too vague to explain what a merchant can rely on.
Get an assessment around the actual customer journey
Use our malicious ecommerce redirect removal service when customers unexpectedly leave the shop and you need help locating the source and defining a repair. Send the public URL, visible symptom, timing, affected device and recent changes. A redacted example is more useful than a folder of unreviewed customer data.
We agree the investigation and quote before intervention, including relevant store-data preservation and follow-up boundaries. Request an ecommerce redirect assessment without sending passwords, payment details or live order tokens.