A WordPress website that suddenly redirects visitors to suspicious websites may be showing signs of a serious security problem.**
Imagine a customer clicks your website from Google, but instead of reaching your homepage, they are redirected to a gambling website, a fake verification page, or a phishing site.
Sometimes the website works perfectly for the administrator, while ordinary visitors experience malicious redirects.
This is a common symptom of compromised WordPress websites, although not every unexpected redirect is caused by malware.
In this tutorial, I'll explain how to identify suspicious redirects, investigate potential WordPress security vulnerabilities, and safely fix the underlying problems.
1. Understanding WordPress Redirect Vulnerabilities
Two different security problems are often confused:
Open Redirect Vulnerabilities
An open redirect occurs when a website allows untrusted input to control the destination of a redirect without appropriate validation.
For example, a vulnerable application might accept a URL parameter and redirect users to an external website controlled by an attacker.
This can be abused to make phishing links appear more trustworthy.
Malicious Redirect Infections
Malicious redirects are often caused by injected JavaScript, compromised plugins, modified server configuration files, database injections, or malicious WordPress code.
Attackers may redirect visitors to:
- Phishing websites
- Fake software updates
- Spam and gambling websites
- Fraudulent login pages
- Malware distribution websites
A malicious redirect is not necessarily evidence of an open redirect vulnerability. Identifying which problem exists is essential before attempting a fix.
2. How to Detect Suspicious Redirects
Method 1: Check Your Website in a Private Browser Window
Open your WordPress website in an incognito or private browsing window.
Test multiple pages, including:
- Homepage
- Blog posts
- Contact page
- Login page
- Landing pages appearing in Google Search
Some malware only activates for visitors who aren't logged in or who arrive from search engines.
If the redirect occurs only in certain situations, document those conditions.
Method 2: Inspect HTTP Redirect Headers
You can examine server-side redirect responses using cURL.
curl -I https://example.com/
To follow HTTP redirects:
curl -IL --max-redirs 5 https://example.com/
Look for HTTP status codes such as:
HTTP/1.1 301 Moved Permanently
Location: https://unexpected-example.com/
A Location header pointing to an unexpected external domain deserves investigation.
However, JavaScript-based redirects may not appear in these responses. Use browser developer tools to inspect client-side navigation as well.
Method 3: Review Browser Developer Tools
Open Chrome Developer Tools.
Navigate to:
Network → Preserve log → Reload
Look for:
- Unexpected 301 or 302 responses
- Suspicious external requests
- Unknown JavaScript files
- Third-party scripts loaded from unfamiliar domains
- Unexpected document navigation
Check the Initiator column to identify scripts or requests associated with the navigation.
This can help distinguish between server-side and browser-based redirects.
3. Safely Identify Open Redirect Vulnerabilities
If you own the website or have explicit permission to test it, examine application features that legitimately redirect users.
Examples include:
- Login redirects
- Logout redirects
- Return URL parameters
- Custom authentication pages
- Third-party integration callbacks
Review how parameters such as redirect_to, return_url, or next are processed.
For example, a custom login handler might receive:
https://example.com/login/?redirect_to=https://external.example/
This example is a test input, not proof of a vulnerability.
Determine whether the application allows an arbitrary external destination and whether that behavior violates the intended redirect policy.
WordPress developers should generally use wp_safe_redirect() for redirects that must remain within an approved set of hosts, together with appropriate validation and exit after the redirect.
wp_safe_redirect( home_url('/dashboard/') );
exit;
Remember that custom permitted-host filters and application-specific redirect requirements must also be reviewed.
Never perform unauthorized vulnerability testing against websites belonging to other people.
4. Inspect the WordPress .htaccess File
On Apache-based WordPress hosting, the .htaccess file can contain redirect rules.
Attackers sometimes modify this file to redirect visitors.
Connect to your hosting account using SSH or a secure file manager.
Locate the WordPress installation directory and inspect:
public_html/.htaccess
Look for unexpected rewrite rules or external destinations.
For example:
RewriteRule ^(.*)$ https://unexpected-example.com/$1 [R=302,L]
Such a rule could redirect website traffic to another domain.
Not every unfamiliar rewrite rule is malicious. Some are created legitimately by caching, security, multilingual, or redirect plugins.
Compare the configuration with a trusted backup before making changes.
Important: Nginx websites may use server configuration files instead of .htaccess.
5. Check WordPress Core Files and Plugins
Attackers may hide malicious code inside modified WordPress files or vulnerable plugins.
Inspect important locations:
/wp-config.php
/wp-content/plugins/
/wp-content/themes/
/wp-content/mu-plugins/
/wp-content/uploads/
Pay particular attention to unexpected PHP files in upload directories and unfamiliar must-use plugins.
If WP-CLI is installed, verify WordPress core integrity:
wp core verify-checksums
You can also check supported WordPress.org plugins:
wp plugin verify-checksums --all
Checksum mismatches can indicate unexpected file changes, but they do not automatically prove malicious activity.
Custom or premium plugins may not have checksums available through WordPress.org.
Review suspicious differences carefully instead of automatically deleting files.
6. Investigate WordPress Database Injections
Some redirect infections are stored in the WordPress database.
Potential locations include:
- WordPress options
- Widget content
- Post and page content
- Custom plugin settings
- Injected scripts stored in theme configuration
Check the WordPress site addresses:
Settings → General → WordPress Address / Site Address
Confirm that both addresses are correct.
Database table prefixes may differ from the default wp_.
If suspicious scripts or redirect URLs are found, identify their source and affected records before making corrections.
Always create a verified database backup before editing or replacing database values.
Avoid blind SQL replacements, especially where serialized WordPress data may be affected.
7. Remove Malware and Restore Website Security
When a WordPress redirect is caused by compromise, removing a single script may not solve the underlying problem.
A safer recovery workflow involves:
Step 1 — Preserve evidence and create backups
Record redirect destinations, affected URLs, relevant logs, and timestamps.
Create appropriate file and database backups before remediation.
Step 2 — Identify the entry point
Review outdated plugins, vulnerable themes, compromised credentials, insecure integrations, and unauthorized administrative accounts.
Step 3 — Remove confirmed malicious changes
Replace compromised core files and software components with trusted versions where appropriate.
Remove confirmed malicious files and database injections.
Step 4 — Update and secure WordPress
Apply supported security updates, rotate affected credentials, remove unauthorized accounts, review permissions, and enable multifactor authentication where supported.
Step 5 — Check for persistence
Investigate backdoors, scheduled tasks, must-use plugins, server configuration changes, and other mechanisms that could allow reinfection.
Step 6 — Verify recovery
Test the website using clean browser sessions, multiple pages, and relevant request conditions.
Monitor logs and website behavior after the cleanup.
If Google Safe Browsing has flagged the site, follow the applicable review process after resolving the issue. Warning removal is controlled by Google and is not instantaneous or guaranteed.
8. When Should You Contact a WordPress Malware Removal Specialist?
Basic troubleshooting may reveal the redirect source, but some infections require deeper investigation.
Professional assistance may be appropriate when:
- Redirects return after cleanup
- Visitors see phishing pages
- Unknown administrator accounts appear
- Security warnings remain after remediation
- Multiple WordPress files are compromised
- Malware affects website performance or customer access
I work with website owners to investigate hacked WordPress installations, identify malicious redirects, remove confirmed malware, investigate backdoors, and improve website security.
If your WordPress website has been compromised, you can learn more about my professional WordPress malware removal and hacked website recovery service.
My focus is on careful investigation, clear communication, and restoring website functionality while addressing the security problems identified during recovery.
9. How to Prevent WordPress Redirect Infections
Prevention requires more than installing a security plugin.
Keep WordPress core, themes, and plugins updated. Remove unused extensions, enforce strong authentication, restrict privileged access, maintain recoverable backups, and monitor unexpected file and configuration changes.
Developers should also validate redirect destinations, use appropriate WordPress redirect functions, and avoid trusting user-controlled URLs.
A properly maintained website is less likely to suffer from common attacks, although no website can be guaranteed completely secure.
Final Thoughts
Unexpected redirects are often one of the first visible signs that a WordPress website needs security attention.
The important question is not simply how to stop a redirect.
It is why the redirect happened, whether attackers still have access, and what needs to change to prevent the same incident from recurring.
Understanding the difference between open redirect vulnerabilities and malware-driven redirects helps website owners and developers investigate problems more accurately.
Website recovery should focus on identifying the cause, removing confirmed threats, restoring normal functionality, and strengthening security for the future.
About the Author
Nithu is a website developer and cybersecurity specialist working on WordPress malware removal, hacked website recovery, web application security, and technical troubleshooting.
Website: NithuDev
Top comments (0)