WordPress Redirecting to Spam? A Safe Recovery Plan

Confirm the redirect pattern before changing files

Record the affected URL, time, device, browser and route into the website. Does the redirect happen when a visitor arrives from search, when viewing a product, or only on the first visit? Google has documented hacked redirects that target selected visitors, so a clean visit from your usual administrator browser is weak reassurance. Do not repeatedly open an unsafe destination on an everyday work device.

A legitimate marketing redirect, an incorrect domain setting and an injected redirect require different fixes. Preserve the evidence that distinguishes them. A browser extension can also alter a single person's experience; reproduce the problem on a separate trusted environment before declaring that every visitor is affected.

Contain the redirect without losing the evidence

Ask the hosting provider to retain access logs, account activity and a snapshot of the affected files and database. Store copies privately, with timestamps and access restricted to the response team. Treat the snapshot as evidence, not as a clean restoration point. Note each emergency change so a later investigator can reconstruct what happened.

If visitors are being sent to harmful pages, restrict the affected application at the hosting or web-server layer. An application maintenance plugin may run after the malicious code and can leave the redirect active. Use a short service notice on a trusted route, and give customers an independently verified contact method. Consider pausing ads that direct people into an unsafe journey.

Trace the redirect to its actual source

Work from the outside inward: domain and DNS changes, CDN rules, web-server configuration, application files, database content and browser-loaded scripts. Review newly added administrators and recent deployments alongside these layers. The first suspicious line found is an indicator, not a complete incident scope.

• Review .htaccess or equivalent server rules, unexpected PHP bootstrap changes and altered configuration files.
• Inspect active themes, plugins, must-use plugins, custom snippets, widgets and database-stored header or footer scripts.
• Check page-builder templates, advertising tags and tag-manager accounts that can add code without changing the visible article body.
• Compare affected responses with approved source packages or a trustworthy deployment record. Record unexplained differences before replacement.

Do not use a blanket search-and-delete operation for every redirect or external domain. Payment gateways, booking systems and sign-in services may depend on legitimate external destinations. Have the site owner confirm business integrations and retain only those that are needed and verified.

Remove the malicious change and the route back in

1. Establish trusted hosting and administrator access from a clean device. Secure the recovery email account if it may be involved.
2. Replace compromised executable components from verified publisher or deployment sources. Review custom code separately; reinstalling WordPress does not replace every custom file or database value.
3. Remove unauthorised accounts, scripts and configuration changes after recording the evidence. Investigate other sites sharing the same hosting identity.
4. Patch or remove the component that allowed access, or revoke the compromised account or deployment credential. If the cause is uncertain, document that uncertainty and consider rebuilding on clean infrastructure.
5. Rotate relevant secrets and invalidate sessions once the environment can protect the new values. Include hosting, CMS, deployment, database and exposed integration credentials as the incident scope requires.
6. Purge relevant application and CDN caches after cleanup, then verify that a cached malicious response is no longer being served.

A scanner can help locate suspicious files, but a clean scan cannot explain a stolen hosting session or an unsafe deployment process. Require a short explanation of initial access, persistence and the controls changed to prevent the same route being used again.

Verify public behaviour, not just the dashboard

Test logged-out and logged-in journeys, mobile and desktop layouts, a fresh browser profile, search entry pages and the pages customers originally reported. An investigator may compare crawler-like requests to expose conditional malware, but the repaired site should serve legitimate equivalent content to visitors and crawlers. Do not create special clean responses solely to pass a review.

Check the response chain, final destination, loaded script domains and forms. Confirm that checkout, contact and account recovery still work. Repeat the checks after the site has handled ordinary traffic and scheduled tasks. Define a monitoring period with the business owner rather than claiming that one successful page load proves permanent cleanliness.

A practical handover example

Hypothetical example: a UK service company finds that visitors from search are redirected, while staff bookmarks work normally. Investigation links the redirect to an unauthorised script in a shared page template. Removing that script restores the page, but the team also discovers an unfamiliar editor account and an exposed deployment password. The handover therefore records both the content repair and the access changes, plus the pages and journeys retested.

For hacked website redirect recovery in the UK, ask for an evidence-led scope rather than a promise to delete a fixed number of files. CyberXperts can help assess the affected layers and plan restoration. Provide the domain, symptoms, hosting platform and last known good date through a secure contact route; never send passwords in an ordinary enquiry.