Capture the visitor path without completing a suspicious journey
Write down the original URL, approximate time with timezone, device, whether the visitor was signed in and how they arrived. A redirect that appears only after a search click or on mobile needs that context. Ask for the warning or destination shown, rather than asking a customer to repeat a potentially harmful interaction or enter information on the destination.
An authorized technician can inspect the redirect chain and page behavior in a controlled environment. Distinguish the first unexpected hop from later advertising or scam destinations. Preserve relevant response details, available logs and a copy of the affected state before cleanup changes. Do not publish session-bearing URLs or complete private request headers in a support thread.
Locate the layer that changes the destination
HTTP redirects, HTML refresh behavior and JavaScript navigation are different mechanisms. A changed DNS answer can route a hostname to a different server before any page redirect occurs. The address bar alone cannot identify which layer made the decision. Compare the response and the code that produced it with the intended hosting and application configuration.
Use the matrix to assign the next check to the person who owns that layer. A suspicious database value does not rule out a server rule, and a clean homepage does not settle what a specific landing page loads. Keep the observations separate until there is evidence linking them.
| Observed stage | Check with the authorized owner | Avoid concluding |
|---|---|---|
| Wrong host receives the request | DNS answers, delegation and intended hosting target | That a WordPress plugin caused it. |
| Server returns an unexpected Location | Hosting/CDN redirect rules and application response | That deleting page text will fix it. |
| Page loads, then navigates away | Loaded scripts, injected markup and embedded resources | That DNS is necessarily wrong. |
| Only one browser is affected | A clean comparison and local browser extensions | That every visitor is safe. |
| Only selected visitors are redirected | Entry page, referrer/device conditions and evidence window | That an administrator test disproves the report. |
Contain exposure while retaining a recovery path
If visitors are being sent to a harmful destination, agree a targeted restriction or a temporary service notice with the business owner and hosting provider. Decide how enquiries or orders will be handled through an existing trusted channel. Containment is a business decision as well as a technical one; record who approved it and what remains available.
Preserve evidence before purging logs or overwriting the installation. Avoid a public maintenance page that repeats the attacker destination as a clickable link. If payment or account information may have been exposed, include those systems in the response scope instead of treating the incident as a cosmetic website fault. The initial incident guide covers broader response responsibilities.
Correct the entry point and persistence, not only the symptom
Review the implicated files, database content, users, scheduled tasks and relevant hosting configuration within the authorized scope. Compare components with trusted releases and the business's known customizations. Replacing one altered file may remove a symptom while leaving another mechanism that restores it. A detection tool can help locate evidence, but its clean result is not a complete causal explanation.
Plan updates or replacement of the vulnerable component, correction of unauthorized access and appropriate credential/session handling from a trusted device. If restoring a backup, establish why the copy predates the compromise and how recent business records will be preserved. A restore that reintroduces the vulnerable component needs another corrective step.
Retest the original conditions and the business workflow
Create a small test register: original URL, device/session condition, expected destination, actual first hop, timestamp and reviewer. Include affected landing pages, direct visits, search-entry behavior where reproducible and the important form or checkout route. Inspect relevant caches and content delivery paths after the underlying change rather than assuming a cache purge repairs the source.
Retest after the change and schedule a follow-up observation appropriate to the evidence. A normal request at one moment does not establish that conditional behavior can never recur. Record what was checked, any remaining unknowns and who investigates a recurrence. If Google also shows a security warning, complete the separate cleanup-and-review process for that report.
Prepare a useful handover or request for help
Provide the affected address, time, entry route, visible symptom and any authorized changes already made. Identify who controls DNS, hosting, WordPress and third-party scripts. Keep passwords and private logs out of the initial form. When access is agreed, use an appropriate controlled route rather than forwarding reusable administrative secrets in a message.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide, specializing in websites and digital infrastructure. Our Israeli technical knowledge is applied through scoped diagnosis, repair and verification for the actual platform involved. We can discuss website recovery and WordPress security work; the access, availability and acceptance checks are agreed for the situation.
