A WordPress redirect hack quietly sends visitors from your pages to spam, phishing, fake updates or unwanted advertising. The owner may not see it because attackers often target only search visitors, mobile devices or first-time sessions.
That inconsistent behavior is intentional. Treat the redirect as evidence of a compromise, preserve logs and avoid testing dangerous destinations on your normal computer.
How malicious redirects are triggered
- Injected JavaScript in a theme, plugin, widget or page.
- Modified PHP that sends an HTTP redirect before the page loads.
- Host or web-server rewrite rules.
- Compromised DNS, CDN, tag manager or advertising scripts.
- Database content that runs only on selected pages.
- Conditional cloaking based on referrer, device, cookie or IP address.
Redirects can accompany search-spam campaigns such as the Japanese keyword hack. Check both visitor behavior and what search engines have indexed.
Step 1: contain the risk
If visitors are being sent to harmful pages, restrict public access or use a controlled maintenance state while you investigate. Preserve a full file and database snapshot and export relevant server, authentication, firewall and analytics logs.
Do not repeatedly open suspicious destinations. Record the redirect chain with trusted diagnostic tools or an isolated environment, including the affected source URL, device, referrer and time.
Step 2: reproduce the conditions
Test representative pages as a direct visitor, a search visitor and a mobile visitor. Use clean sessions because a cookie may suppress repeat redirects. Compare HTTP responses, page source and loaded scripts. Record what changes instead of assuming the browser is at fault.
Step 3: check WordPress files
Compare WordPress core, plugins and themes with trusted packages. Inspect must-use plugins, the uploads directory, wp-config.php, root files and web-server configuration. Review recent modifications, unexpected includes, encoded code and scripts that evaluate referrer or user-agent values.
Step 4: inspect the database and content
Search a safe database copy for the destination domain, suspicious script fragments and recently modified options, widgets, headers, footers and page-builder content. Review administrator activity around the first observed redirect. Back up first and avoid broad replacements against serialized production data.
Step 5: check infrastructure outside WordPress
Review DNS records, nameservers, CDN workers or rules, tag-manager containers, hosting-panel redirects and injected advertising code. Check sibling sites on shared hosting. A clean WordPress directory cannot stop a redirect generated before traffic reaches it.
Step 6: remove persistence and compromised access
Audit every administrator and application password. If anything is unfamiliar, follow the . Inspect scheduled jobs and hidden backdoors that could restore the redirect after deletion.
Quarantine confirmed malware and replace modified software with trusted packages. Remove unused or abandoned components. Clear page, object, server, CDN and browser caches only after the underlying source is clean.
Step 7: rotate credentials and harden
Change WordPress, hosting, database, SFTP, SSH, CDN and deployment credentials from trusted devices. Update security salts, invalidate sessions and enable multi-factor authentication. Patch the vulnerable component and review file permissions and separation between sites.
Address the preventable gaps listed in and understand how cover different layers.
Step 8: verify SEO and visitor recovery
Crawl important pages and confirm normal status codes, canonical tags, scripts and outbound links. Check Search Console for security issues, unexpected URLs and indexing changes. If Google shows a security warning, complete the full cleanup before requesting review.
Why redirects return
Recurring redirects usually mean that one trigger was removed while another remains: a cron job, stolen credential, database payload, server rule, infected sibling site or compromised third-party script. Use the new file or rule as evidence of the process that recreated it.
For an active incident, follow or request . Our shows the broader cleanup and hardening approach.
Frequently asked questions
What is a WordPress redirect hack?
A WordPress redirect hack sends visitors to an unauthorized website. It can affect every visitor or only people arriving from search, mobile devices, certain countries or specific browsers.
Why does the redirect appear only sometimes?
Attackers use conditional rules to avoid detection. The redirect may depend on referrer, cookie, device, user agent, IP address or whether a visitor has already been redirected.
Can clearing the cache remove a malicious redirect?
Clearing caches may remove a cached copy, but it does not fix malicious code, database injections, DNS changes or compromised accounts. Find and remove the source before rebuilding each cache layer.
Where should I look for redirect malware?
Check plugins, themes, must-use plugins, uploads, wp-config.php, root and server configuration files, database options, widgets, page content, tag-manager scripts, DNS and hosting settings.
Will reinstalling WordPress fix redirects?
Replacing core files helps when core was modified, but redirects can persist in plugins, themes, the database, server rules, DNS, accounts or other sites on the hosting account.
How do I stop redirect hacks from returning?
Remove every persistence mechanism, patch the entry point, rotate credentials, invalidate sessions, update supported software, restrict administrator access, monitor changes and maintain tested backups.
Final redirect-removal checklist
- Contain harmful redirects and preserve evidence.
- Reproduce the affected visitor conditions safely.
- Inspect files, database, server rules, DNS and third-party scripts.
- Remove malware, persistence and unauthorized access.
- Rotate credentials and patch the original weakness.
- Clear caches, verify all visitor paths and monitor for recurrence.
