When a WordPress site redirects to another website, treat the behavior as a possible security incident, not just a broken link. A redirect can come from modified files, injected database content, a compromised administrator account, a malicious plugin, hosting-level changes, or a DNS problem.
The safest response starts with containment. Preserve useful evidence, limit further access, and avoid making many unrecorded changes. This guide presents a practical workflow for small businesses and property operators. It does not assume that every redirect proves malware, but it shows how to investigate the risk carefully.
Contain the site before changing anything
First, confirm what visitors experience. Test the site from a private browser window and from a separate network. Record the original URL, destination URL, time, browser, device, and whether the redirect affects every visitor.
Some infections target only mobile users, search visitors, logged-out visitors, or specific referrers. Therefore, one clean test does not clear the site. Do not repeatedly browse a suspicious destination from a business computer.
- Put the site behind a temporary maintenance page or hosting-level block, if practical.
- Restrict WordPress administration to trusted staff or a controlled support connection.
- Do not delete suspicious files before collecting a backup or forensic copy.
- Save hosting, web server, security plugin, CDN, and DNS logs when available.
- Notify the person responsible for the domain, hosting account, and business website.
Take a full backup of the files and database before remediation. Store the copy separately from the hosting account. A backup made after an attacker changed files may preserve the problem, but it can still provide valuable evidence.
If the hosting account itself may be exposed, use a separate trusted device to change its password and review active sessions. The related hosting account compromise investigation guide covers broader access review and evidence preservation.
Confirm whether the redirect is local or external
A WordPress site redirects to another website condition does not always originate in WordPress. Check the response chain with a trusted HTTP inspection tool, browser developer tools, or server logs. Look for the first response that sends a Location header or runs client-side redirect code.
A normal HTTP redirect uses a response such as 301, 302, 307, or 308. JavaScript can also send visitors elsewhere, and HTML can use a meta refresh. Each method points to a different investigation path.
- DNS-level change: the domain resolves to an unexpected server.
- Web server rule: Apache, Nginx, a control panel, or a CDN issues the redirect.
- WordPress code: a plugin, theme, core file, or must-use plugin changes the response.
- Database content: an option, post, widget, menu, or custom field contains hostile code.
- Client-side injection: browser code redirects after the page begins loading.
Compare results from the canonical HTTPS address, the HTTP version, a known page, the homepage, and a nonexistent path. Different results can reveal rules that apply only to certain URLs.
Also check whether the destination appears only after a delay. A delayed redirect often indicates JavaScript or an injected external resource rather than a simple server rule.
Inspect WordPress files without destroying evidence
Start with file timestamps, ownership, and recent changes. Compare the site against a clean copy of the same WordPress core version when possible. Core files should not contain unexplained additions, especially near the beginning or end of a file.
Prioritize these locations:
wp-config.phpand server configuration files such as.htaccess.- The active theme and child theme files.
- Plugin directories, including unfamiliar or recently changed plugins.
wp-content/mu-plugins/, because must-use plugins load without normal activation controls.- Upload directories containing executable files with unexpected extensions.
Search for suspicious patterns such as encoded strings, long unreadable character blocks, dynamic code execution, hidden iframes, unfamiliar domains, and conditional checks for mobile devices or referrers. These patterns deserve review, but they are not automatic proof of malicious code. Some legitimate plugins use complex code.
Do not run a blind “cleanup” script across the site. It may remove legitimate code, damage serialized database values, or leave the attacker’s access intact. Make a copy, document each change, and test remediation on staging when possible.
File permissions also matter, but changing them is not a substitute for finding the entry point. For safe ownership and permission checks, see WordPress file permissions security settings.
Check the database for injected redirects
Database inspection is essential because malicious content may survive a file replacement. Before editing, export the database and record the table prefix. WordPress installations do not always use the default prefix.
Review the options table first. Search values for the suspicious domain, script tags, iframe tags, JavaScript event handlers, meta refresh markup, and unfamiliar administrator settings. Pay special attention to the site URL, home URL, active plugins, widget settings, and theme modifications.
Next, inspect posts, pages, reusable blocks, menus, widgets, custom fields, and plugin-specific tables. Redirect code may appear only in a page template or a custom field. Search broadly, then inspect the surrounding content before removing anything.
Be careful with serialized data. Serialized values store lengths alongside content. Editing a serialized value by hand can corrupt the option and create a new outage. Use a tool that understands serialization, or ask an experienced technician to make the change.
If the database connection fails during this work, stop making unrelated changes. Follow a separate diagnostic sequence such as WordPress database connection troubleshooting rather than treating the connection error as proof of malware.
Review administrator accounts and access paths
A redirect often reflects stolen access rather than a single damaged file. In WordPress, review all users with administrator or other high-privilege roles. Record usernames, email addresses, creation dates, roles, and recent activity where the hosting platform provides it.
- Remove unknown accounts only after recording their details for the incident notes.
- Reset passwords for legitimate administrators from a trusted device.
- Revoke application passwords and unknown API credentials.
- Review hosting, SFTP, SSH, database, CDN, DNS, and registrar accounts.
- Enable multifactor authentication where the service supports it.
Application passwords are separate, revocable credentials for integrations. WordPress documents their use in its official Application Passwords guidance. Review these credentials even when the normal administrator password appears unchanged.
Inspect plugins that add login forms, remote management, scheduled tasks, or API access. Also check email accounts connected to password recovery. If an administrator’s email may be compromised, secure that mailbox before relying on it for account recovery.
For a broader login hardening plan, use WordPress administrator access security guidance. Do not remove every administrator during an emergency. Preserve one verified recovery path, test it, and document who controls it.
Find server, CDN, DNS, and scheduled-task changes
Review .htaccess, Nginx configuration, hosting redirects, CDN rules, and security controls. A redirect outside WordPress will return after a clean reinstall unless you remove the external rule.
Check DNS records and nameserver settings against the approved configuration. A DNS change can send the whole domain to another server, while a web rule may affect only selected paths. Confirm the result with the domain owner and hosting provider before changing records.
Scheduled tasks can restore deleted malware. Review WordPress cron events, hosting cron jobs, and server task definitions. Look for unfamiliar commands, URLs, scripts, or jobs that run shortly after cleanup.
Examine access logs around the first known redirect. Useful clues include successful logins, plugin uploads, requests to vulnerable endpoints, password resets, and repeated calls from unusual addresses. Logs rarely prove the full story, so compare them with file and database timestamps.
Remediate, verify, and monitor
After collecting evidence, choose a clean recovery path. The strongest option is often a known-good backup from before the compromise, followed by updates and credential rotation. If no trustworthy backup exists, rebuild from clean WordPress core, verified plugins, and reviewed themes.
Remove unused plugins and themes. Update retained components from trusted sources. Rotate every credential that could have exposed the site, including hosting, database, SFTP, administrator, API, CDN, DNS, and registrar credentials.
Before restoring public access, test the homepage, representative pages, forms, logins, media, checkout or booking functions, and administrator actions. Test logged-in and logged-out sessions on more than one device. Check both desktop and mobile behavior.
Then monitor redirects, new files, administrator changes, scheduled tasks, and outbound requests. Keep the incident notes, backup hashes when available, timestamps, affected URLs, and remediation decisions. That record helps identify a recurring entry point when a WordPress site redirects to another website again.
When to bring in professional help
If the redirect returns after cleanup, the site handles payments or bookings, evidence may matter, or several accounts are involved, pause further changes. Tech Rescue Ops LLC can help with remote WordPress investigation, containment planning, hosting access review, and controlled recovery. Professional assistance is especially appropriate when you cannot identify a clean restore point or verify that every access path is secure. When a WordPress site redirects to another website and the cause remains unclear, expert review can reduce the risk of repeated cleanup.