WordPress redirecting to spam is often first reported by a customer who lands on a gambling page, fake security warning, or unrelated shop. You check the same page and everything looks normal. That inconsistent behavior is often the clue: the redirect may target only mobile visitors, search traffic, first-time visits, or people who are not logged in.
Do not begin by deleting random files or installing several scanners. First, contain the visitor risk and preserve enough evidence to find the real entry point. A redirect can sit in a plugin, theme, database record, server rule, injected script, compromised account, or external tag. Removing the visible redirect without closing that path often leads to reinfection.
Confirm the spam redirect without putting more visitors at risk
Start by recording what the affected person saw. Ask for the original page, destination domain, device, browser, time, and whether the visit started from Google, an advert, an email, or a direct link. A screen recording helps when the redirect disappears after the first visit. Do not ask anyone to revisit a suspicious destination repeatedly.
Next, test your own site from a signed-out browser and a mobile connection. Check the reported page plus the homepage and one normal inner page. If the redirect appears only after a Google click, only on a phone, or only once per browser, write that down. Google describes these conditional mobile redirects as a pattern site owners should investigate, especially when a hacked site sends people to spam domains. Its guidance on unwanted mobile redirects also explains why an owner may not reproduce what visitors see.
Finally, save the destination URL as plain text or a screenshot. Do not open it in wp-admin, paste it into a plugin setting, or share it as a clickable link. That evidence can help a specialist connect the symptom to a script, network request, server rule, or database value later.
Take these containment steps before cleanup
If visitors are being sent to unsafe pages, the priority is to reduce exposure. Put up a simple maintenance response or ask the host to restrict public access while keeping wp-admin and server access available to the recovery team. Avoid a redirect-based maintenance solution because redirects are the behavior you are trying to diagnose.
Then create a recovery copy before changing anything. A backup made after the incident is not a clean restore point, but it preserves logs, timestamps, files, and database records. Those details can show what changed. Keep the copy separate from the live hosting account when possible. The Webless backup restore test guide explains why a backup is only useful when you can restore it in an isolated location.
Also prevent casual changes while the investigation runs. Pause routine content edits, plugin installations, cache experiments, and automatic cleanup jobs. If several people have administrator or hosting access, establish one owner for the recovery work. Otherwise, overlapping actions can erase evidence and make it impossible to tell which change fixed the symptom.
Check whether the redirect is really coming from WordPress
Not every unexpected redirect means the WordPress database is infected. A compromised advertising tag, analytics container, DNS account, CDN rule, hosting configuration, or browser extension can create similar symptoms. The location and timing narrow the search.
| What you observe | Where to check first |
|---|---|
| Every request redirects before a page appears | DNS, CDN, web server rules, and the site address configuration |
| Only some pages or mobile visitors redirect | Theme or plugin scripts, injected database content, tags, and conditional server rules |
| Only Google visitors redirect | Referrer-based scripts, server rules, compromised tags, and Search Console security signals |
| Only one team member sees it | That browser, extension, device, network, and cached service worker before changing the site |
| The redirect returns after cleanup | Compromised accounts, scheduled tasks, hidden plugins, writable files, and the original entry point |
Record the actual HTTP response when possible. A server-side 301 or 302 points toward hosting, CDN, redirect, or application logic. A normal 200 response followed by a browser jump points more strongly toward JavaScript, an embedded tag, or browser-side behavior. This distinction prevents hours of searching in the wrong layer.
Review changes around the first reported redirect
Build a short timeline before touching production. Check plugin and theme updates, new administrator accounts, changed passwords, file modification times, hosting notices, DNS changes, tag-manager publishes, and scheduled jobs. Compare the first report with the last known-good visit. A narrow time window makes logs and backups far more useful.
WordPress activity and error logs can support that timeline, but an error log is not a malware verdict. Look for unexpected file writes, repeated authentication attempts, new scheduled actions, requests to unfamiliar PHP files, or a plugin failure that began at the same time. Our WordPress error log monitoring guide shows how to preserve useful context without publishing sensitive paths or credentials.
Check user accounts as well. Confirm every administrator, application password, hosting user, SFTP key, database user, DNS user, CDN account, and connected automation. Remove access only after you have recorded what existed and confirmed business ownership. An unknown administrator is a serious finding, but one account alone does not explain every persistence path.
Build a small recovery brief before asking someone to fix it
A useful recovery brief saves time without exposing credentials. Include the affected public URL, the unwanted destination as plain text, the first reported time, the last known-good time, and the devices or referrers that trigger the behavior. List recent WordPress, plugin, theme, DNS, CDN, hosting, and tag-manager changes. Note whether forms, checkout, wp-admin, email, or other sites in the same hosting account also behave differently.
Add the current WordPress and component versions, but do not label a plugin as the cause because its version looks old. Version data becomes useful when it matches a vendor advisory, update window, changed file, or log event. Also record the backup dates you have and whether any backup has passed an isolated restore test. This gives the recovery team options without assuming the newest backup is clean.
Finally, explain what containment is already active and who controls each account. Share passwords and private keys only through the secure method agreed with the specialist, never inside the brief or a normal contact form. For WordPress redirecting to spam, clean ownership information is part of the technical fix because recovery often spans more than the WordPress dashboard.
Why deleting one suspicious file is rarely a complete fix
A visible redirect may be only one part of the incident. Attackers and automated malware can add a second administrator, scheduled task, hidden plugin, modified server rule, database payload, or external script. If you delete the first file you notice, the remaining path can rebuild it.
Scanners help identify known patterns, but they do not prove that every custom file, database row, server rule, or connected account is clean. Conversely, a scanner warning does not always prove active compromise. Compare flagged files with verified copies from the same plugin, theme, or WordPress release. Check whether a file belongs there before removing it.
A safer cleanup replaces compromised software with verified packages, removes unauthorized persistence, patches the entry point, and rotates credentials after the environment is under control. It also checks other sites in the same hosting account. Shared credentials and writable directories can let an infection move between installations.
Do not use these shortcuts on a live business site
- Do not restore the first old backup you find. It may contain the same compromise, overwrite valid orders, or remove recent content.
- Do not update everything at once. Large untested changes can break checkout, forms, tracking, or the evidence needed to find the entry point.
- Do not delete unfamiliar code by filename alone. Custom integrations and licensed plugins often use files a generic scanner does not recognize.
- Do not trust one clean homepage test. Conditional redirects may wait for mobile, search referrers, new cookies, or a particular page.
- Do not rotate only the WordPress password. Hosting, database, SFTP, DNS, CDN, and email access may also need review.
- Do not clear every log before recovery is verified. Logs can show how the redirect returned and which account or request changed the site.
If the site processes orders, bookings, forms, or memberships, test those paths in staging before a broad replacement or update. A security cleanup that silently breaks revenue or lead collection is not a complete recovery.
Verify the WordPress redirect hack is actually gone
Verification should repeat the conditions that exposed the problem. Test signed out, on mobile, from a normal connection, and through the search result or referrer that triggered the report. Clear only the test browser state you intend to clear. If the redirect happened once per visitor, a previously used browser may hide a failed cleanup.
Check the homepage, affected landing page, key service pages, contact form, and any WooCommerce cart or checkout flow. Review server responses, browser network requests, console errors, and fresh logs. Confirm that public pages return their expected status, canonical URL, and content. Then purge the site and edge caches in the correct order so visitors receive the repaired version.
Search Console should also be reviewed for security issues, unexpected indexed pages, and strange search queries. Do not request indexing until the public site is clean, stable, and returning the intended pages. If spam URLs entered the index, recovery may require removal of injected content, correct status responses, refreshed sitemaps, and patient recrawling rather than a blanket URL-removal request.
When professional WordPress recovery is the safer choice
Basic owners can safely collect evidence, restrict access, preserve a backup, and identify affected pages. Cleanup becomes specialist work when the redirect is conditional, returns after removal, affects several sites, involves unknown administrators, or touches orders and customer data. The same applies when hosting, DNS, CDN, and WordPress all need to be checked together.
Webless WordPress maintenance services can connect the incident timeline, file and database checks, update path, recovery testing, cache purge, and monitoring into one controlled process. If the original entry point involves custom theme or plugin behavior, the WordPress development team can repair that layer without replacing unrelated parts of the site.
For ongoing protection, compare the scope on the maintenance pricing page. If the redirect is active now, use the contact form and include the first affected time, example page, destination domain as plain text, and whether the issue appears on mobile or after a search click. Do not send passwords or private keys.
Recovery means closing the cause, not hiding the symptom
With WordPress redirecting to spam, a clean browser test is only the beginning. A durable recovery preserves evidence, identifies the affected layer, removes unauthorized changes, closes the entry point, rotates the right access, and repeats the visitor conditions that exposed the redirect.
That process takes longer than deleting one suspicious file, but it protects the site from returning to the same state. It also produces a useful maintenance baseline: known administrators, verified software, tested backups, expected server rules, monitored logs, and a clear owner for future changes.