Useful Tips

What to Do If Your Website Redirects Visitors to Another Site

September 2, 2026 18 min read

Your website works normally when you open it, but customers say they are being sent to a casino, an unfamiliar online store, a fake antivirus warning or a page asking them to install an app. The redirect might happen only on a phone, only after a click from Google or an advert, or only on the first visit. When you try to reproduce it, everything appears normal again.

That does not necessarily mean the customer is mistaken. This is a common pattern in a malicious redirect infection: unauthorised code identifies who is visiting and selectively sends part of the audience somewhere else. The site owner, developer and even an automated scanner may fail to see it for a long time.

If your website unexpectedly redirects people to a destination you did not configure, treat it as a potential security incident until proven otherwise. Continuing to send paid traffic to the site or accept orders through affected pages can expose customers, advertising accounts, search visibility and your reputation to further harm.

The short answer: what to do immediately

If you discover an unwanted redirect:

  1. Record exactly what happened: the starting page, destination URL, time, device, browser and source of the visit.
  2. Pause adverts that send traffic to affected pages. If the redirect touches checkout, payment or account pages, temporarily restrict those functions too.
  3. Do not delete files at random or restore a backup over the live site. First preserve a snapshot of the compromised state and relevant server logs.
  4. Contact your hosting provider or a WordPress security specialist. Give them the examples you collected and the exact time the redirect occurred.
  5. Secure critical accounts from a clean device: hosting, domain registrar, DNS/CDN, business email and WordPress. Revoke unknown sessions and enable multi-factor authentication.
  6. Check Google Search Console, especially the Security Issues report.
  7. Once the site is clean, rotate all credentials again, close the original entry point and monitor the site before resuming advertising or requesting a Google review.

The redirect is only a symptom. The real task is not to remove one suspicious line of code, but to find out how it appeared and what could allow an attacker to restore it.

What a malicious redirect can look like

An unwanted redirect does not always behave the same way. A visitor may:

  • be sent immediately to a completely different domain;
  • see your site for a few seconds before an advert opens;
  • get a new window or tab rather than a direct redirect;
  • land on a fake browser update or antivirus warning;
  • be asked to allow browser notifications;
  • reach a casino, betting, cryptocurrency, dating or questionable shopping page;
  • see a fake login or payment form;
  • be redirected only after clicking a button, menu item or blank area of the page;
  • see the correct website on every later visit.

The final scenario is particularly deceptive. Malicious code can store a cookie or browser-storage value and avoid redirecting the same person again. The customer experiences the problem once, while the owner cannot reproduce it after receiving the complaint.

Why the owner may not see the redirect

Attackers benefit from remaining undetected. A redirect can therefore be configured to run:

  • only for visitors who are not logged in to WordPress;
  • only on the first visit;
  • only on mobile devices;
  • only in selected countries;
  • only after a click from Google, social media or a paid advert;
  • only in particular browsers;
  • for everyone except the owner’s or developer’s IP address;
  • only when the URL is reached from a referral rather than typed directly;
  • randomly, perhaps for one visitor in five or ten.

Showing different content or behaviour to different visitors is often described as cloaking. Google specifically warns that hacked content may appear only for certain user agents or referral sources. A normal visit from the owner’s computer therefore does not invalidate a customer’s report.

Does every redirect mean the website has been hacked?

No. Legitimate websites use redirects for many ordinary reasons:

  • moving from http:// to https://;
  • consolidating the www and non-www versions;
  • forwarding an old page to its replacement;
  • sending a discontinued product to a suitable alternative;
  • opening the correct language or regional version;
  • continuing after login or payment;
  • transferring a customer to a recognised payment provider.

The problem begins when a visitor reaches a domain or page the business did not choose, or when the redirect occurs at an unexpected point. An unknown advert, download, fake security check, casino or copied payment form is not a normal WordPress configuration issue.

The cause is not always on the website. If only one person experiences redirects across several unrelated sites, their browser, extension, device or network may be compromised. But if multiple independent visitors report the same destination or trigger, the website and its infrastructure need a full investigation.

Where an unwanted redirect can come from

There is no single “redirect visitors” switch. The instruction can be introduced at several layers.

1. A compromised WordPress plugin or theme

An unpatched component may allow an attacker to upload PHP or JavaScript. The risk also increases when plugins or themes come from unofficial sources. In other cases, a legitimate extension has acquired a vulnerability or remains installed at a version for which a security update is already available.

Disabling the suspected plugin may stop the visible redirect, but it does not prove the site is clean. The attacker may already have created a separate file, administrator account or persistent backdoor.

2. Modified website files

Redirect code is often injected into locations such as:

  • .htaccess;
  • index.php;
  • active theme files;
  • header.php, footer.php or functions.php;
  • wp-config.php;
  • plugin directories;
  • mu-plugins;
  • the uploads directory, which would normally contain media and documents;
  • unfamiliar PHP files in the site root or system folders.

WordPress’s own hacked-site guidance identifies .htaccess, index.php, theme headers, footers and function files as common areas to inspect during recovery.

3. A malicious database entry

The redirect may be stored in page content, a widget, a theme setting, an HTML block, an Elementor template or a value in wp_options. Reinstalling WordPress core will not remove it because the unauthorised instruction remains in the database.

4. An unknown administrator or stolen credential

An attacker with administrative access can install extensions, edit code, schedule tasks and replace anything that has been removed. The investigation should cover more than the visible WordPress user list:

  • WordPress administrators;
  • hosting-panel users;
  • SFTP/FTP accounts;
  • SSH keys;
  • developer and agency access;
  • WordPress application passwords;
  • active sessions;
  • accounts with access to the CDN, DNS and domain registrar.

5. Server, CDN or DNS rules

A redirect can exist entirely outside WordPress:

  • in Apache or Nginx configuration;
  • in the hosting control panel;
  • in CDN redirect rules;
  • in an edge function or worker;
  • through altered DNS records;
  • after compromise of the domain registrar account.

Cleaning WordPress files cannot fix a redirect at this layer. The website may continue redirecting even while WordPress itself is disabled.

6. A third-party script, advert or widget

The unwanted behaviour can arrive through an advertising network, live chat, analytics script, pop-up service, embedded widget or Google Tag Manager container. Google treats deceptive third-party resources and redirects as a security issue for the host page even when the harmful code is physically loaded from another domain.

7. Cache or a service worker

After the server is cleaned, an old script may still be served from the browser cache, CDN or caching plugin. A service worker can also serve stored resources independently of a normal page request. All cache layers should be purged after remediation, and the website should be tested in a clean browser profile or on a new device.

How to confirm the problem safely

Avoid opening a suspicious destination repeatedly on your work computer. Google warns that a compromised page may exploit a browser vulnerability, while hacked content may deliberately hide from the site owner.

For the initial investigation, collect:

  • the page URL where the redirect began;
  • the final URL and any intermediate addresses;
  • the date, exact time and time zone;
  • whether the visitor used a phone or computer;
  • operating system and browser;
  • country and connection type, such as home Wi-Fi or mobile data;
  • how the visitor arrived: Google, an advert, social media, email or direct URL;
  • whether the visitor was logged in;
  • whether the redirect happened again;
  • a screenshot or screen recording.

Checks a website owner can perform without server access

  1. Open the Security Issues report in Google Search Console.
  2. Check the site while logged out, but do not interact with the suspicious destination.
  3. If reports concern mobile visitors, test from a phone using mobile data.
  4. Look for unfamiliar indexed pages with a site:example.com search and relevant spam terms.
  5. Confirm that the domain is using the expected nameservers and that DNS records have not changed unexpectedly.
  6. Review the visible list of WordPress administrators for unknown accounts.

Search Console’s URL Inspection tool can show a page as Google sees it. This is useful when malicious behaviour is enabled only for Googlebot or people arriving from search results.

What a technical specialist should inspect

Layer What to inspect
Domain and DNS Registrar, nameservers, A/AAAA/CNAME records, change history, unknown users and API keys
CDN and proxy Redirect rules, workers, page rules, cache and third-party integrations
Web server Apache/Nginx configuration, .htaccess, virtual hosts and system cron jobs
WordPress core Files against official checksums, plus unfamiliar root and system files
Plugins and themes Vulnerable versions, modified files, untrusted sources and inactive extensions
wp-content mu-plugins, drop-ins, uploads, cache and backups stored under a public path
Database wp_options, widgets, HTML blocks, builder templates, post content and injected scripts
Access Administrators, application passwords, SFTP/SSH accounts, keys and active sessions
Scheduled tasks WP-Cron, system cron, WooCommerce scheduled actions and unfamiliar hooks
External code Tag Manager, advertising, chat, analytics, widgets and remote JavaScript
Logs Requests to suspicious files, changes, logins, uploads, PHP errors and WAF events

On a server with WP-CLI, a specialist may use commands such as these to verify official files and review users and scheduled events:

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

Passing a checksum test does not prove the website is clean. The check does not cover the database, server configuration, DNS, CDN, custom theme, many premium plugins or malicious files outside the verified locations. It is one investigation tool, not a “website is secure” button.

First response: contain the damage and preserve evidence

Pause paid traffic

Continuing to buy visits to a compromised site puts customers and the advertising account at risk. The platform may reject campaigns or suspend the destination, while visitors may associate the fraudulent page with your company.

If checkout, payment or account pages are affected, temporarily restrict them. A script injected into a checkout page could potentially intercept submitted data, so this situation needs urgent investigation and contact with the payment provider.

Preserve a snapshot of the compromised state

A backup is useful even when it contains malware. It may preserve evidence needed to identify the source, approximate time of compromise and mechanism that recreates the redirect. WordPress also recommends taking a snapshot before beginning cleanup.

Do not treat this snapshot as a normal restoration copy or store it in a publicly accessible website directory. Its purpose is forensic reference and recovery of anything accidentally removed during remediation.

Preserve logs

Do not clear logs before the investigation. Useful evidence may include:

  • web-server access and error logs;
  • WordPress login logs;
  • administrator activity records, if enabled;
  • file-change history;
  • WAF and CDN events;
  • login history for hosting, email and the registrar;
  • outgoing email logs;
  • deployment and update history.

The earlier these are saved, the better. Some hosting plans retain logs for only a short period.

Secure accounts from a clean device

If a credential was stolen from an infected computer, changing it on the same device may expose the new password too. Check the device, update the operating system and browser, then secure the accounts.

Initial containment normally includes:

  • rotating hosting, registrar, DNS/CDN and WordPress administrator credentials;
  • rotating SFTP/FTP, SSH and, where appropriate, database credentials;
  • securing the business email account used for password recovery;
  • revoking unknown sessions, tokens and keys;
  • enabling MFA;
  • replacing WordPress salts in wp-config.php to invalidate existing sessions.

Rotate credentials again after cleanup. The first change limits access during the investigation; the second ensures that credentials used while malicious code was still present are no longer valid.

Could this be a reportable personal data breach?

A malicious redirect does not automatically prove that personal data was accessed. However, an injection on login, account, form, checkout or payment pages can create a credible risk that submitted data was exposed.

Do not wait for perfect forensic certainty before involving the person responsible for privacy, legal compliance, cyber insurance and payment security. Preserve the timeline, identify the data that may have been processed and establish which jurisdictions apply.

Notification duties are not identical worldwide. Under UK GDPR, for example, an organisation must assess the likely risk to individuals and, where a risk is likely, notify the ICO as soon as possible and where feasible within 72 hours; high risk can also require notification to affected people. EU GDPR contains a comparable risk-based notification framework. Requirements in the United States, Canada, Australia and other markets vary by location, affected individuals and type of data. An international website should not rely on a single universal deadline.

This section is general incident-response information, not jurisdiction-specific legal advice.

Why restoring a backup is not enough

Restoring the last “clean” backup may appear to be the fastest solution. It can be part of a proper recovery, but a single Restore button rarely completes the job.

The backup may already be infected

Weeks may pass between the initial compromise and the first visible redirect. If a backdoor existed earlier, it may also exist in several recent backups.

The vulnerability remains open

The restore may bring back the same vulnerable plugin or theme version. An automated attacker can exploit it again almost immediately.

Newly created malicious files may survive

Some backup systems overwrite existing files without deleting new ones. A PHP file created by the attacker can remain beside the restored installation.

The cause may exist outside the website backup

A WordPress backup usually does not include registrar settings, DNS, CDN configuration, hosting-panel redirects, system tasks or hosting users. A restore cannot correct a problem at those layers.

Stolen credentials remain valid

Even a perfectly clean copy can be modified again if an attacker still has a password, SSH key, active session or access to the owner’s email.

A sound recovery sequence is: preserve the state and logs, determine the scope, close the entry point, deploy verified files or clean the data, remove persistence, rotate access, test the application and monitor it after launch.

Common mistakes during DIY cleanup

Removing only the visible redirect line

That line may be the final link in the chain. A separate backdoor or scheduled task can add it again hours later.

Installing another security plugin and pressing Scan

A scanner is useful, but it runs inside an already compromised system. Malware can hide files, interfere with results or live at a layer the plugin cannot inspect.

Deleting everything suspicious without a backup

This can permanently break the site, remove orders or destroy evidence needed to identify the entry point.

Changing only the WordPress password

The redirect may be controlled through hosting, SFTP, DNS, CDN, business email or a server key. All access points form one chain.

Updating plugins and declaring the incident resolved

An update may close a known vulnerability but does not remove accounts, files, jobs or database records already created by the attacker.

Requesting a Google review too early

The review may fail if any malicious behaviour remains. Clean every affected mechanism, test the relevant scenarios and only then submit the request.

Resuming adverts after one successful visit

A conditional redirect may not appear immediately. The repaired site needs enhanced monitoring and tests from different devices, networks and referral sources.

How to verify that the site is really clean

The absence of a redirect on one computer is not sufficient. After remediation, confirm that:

  • unknown administrators, keys and sessions are gone;
  • official WordPress and supported plugin files pass integrity checks;
  • themes, plugins, mu-plugins, uploads and root directories have been reviewed;
  • suspicious database entries have been removed;
  • system and WordPress cron jobs have been checked;
  • hosting, CDN and DNS rules match the intended configuration;
  • website, CDN and browser caches have been purged;
  • the redirect does not return on mobile or after visits from search and ads;
  • logs show no renewed requests to the malicious components;
  • Search Console reports no remaining issue after review;
  • forms, orders, payments, email and accounts pass functional testing.

The team should also identify the likely cause. If the malware was removed but nobody can reasonably explain how it entered or persisted, the risk of recurrence remains high.

Recovering Google visibility and search traffic

A compromise may create more than a redirect. Thousands of spam URLs, unrelated links and search snippets in another language can appear under the domain. Google may display a warning in search results or an interstitial warning before the site opens.

After technical cleanup:

  1. Open the Security Issues report in Google Search Console.
  2. Address every listed issue and sample URL. Google notes that the examples may not be a complete list.
  3. Find unfamiliar indexed URLs through site: searches and Search Console reports.
  4. Confirm that malicious URLs are removed and no longer redirect visitors.
  5. Check the sitemap, robots.txt, canonical tags and key commercial pages.
  6. Request a security review.
  7. Monitor new pages, snippets, rankings and branded searches.

Google says a security review can take from a few days to a few weeks. Do not repeatedly resubmit while a review is already in progress.

The Manual Actions and Security Issues reports serve different purposes. Manual actions mostly concern attempts to manipulate search results; Security Issues covers hacking and behaviour that could harm visitors. Check both after a serious incident.

Reducing the risk of another infection

No website can be guaranteed invulnerable, but the risk can be reduced substantially:

  • Update WordPress, themes and plugins without long delays.
  • Back up before updates and test critical functions in staging.
  • Delete unused themes and plugins instead of merely deactivating them.
  • Install software only from trusted sources.
  • Use unique long passwords and MFA.
  • Give each specialist an individual account.
  • Do not share permanent passwords in ordinary messages or email.
  • Use SFTP instead of unencrypted FTP.
  • Limit file permissions and administrative privileges.
  • Disable built-in PHP file editing when it is not required.
  • Store backups away from the live website and test restoration.
  • Monitor uptime, file changes, new administrators and Search Console alerts.
  • Protect the domain registrar and business email as carefully as WordPress.
  • Document installed components, external scripts and everyone with access.
  • Revoke a contractor’s accounts and keys when the relationship ends.

WordPress’s official hardening guide emphasises that security is risk reduction, not one magical setting. A security plugin, responsible hosting, backups and updates each cover different parts of the problem and do not replace one another.

Frequently asked questions

The website works normally for me. Can it still be infected?

Yes. A redirect can exclude logged-in administrators, returning visitors and specific IP addresses. It may run only on mobile or after a visit from Google or an advert.

Why did the redirect happen only once?

The script may have stored a cookie or browser marker so it would not target that visitor again. This helps the infection remain hidden.

The security plugin found nothing. Is the website clean?

Not necessarily. One scanner cannot inspect every infrastructure layer or recognise every form of malicious code. File, database, access, DNS/CDN and log evidence should be considered together.

Will reinstalling WordPress fix it?

It can restore core files, but it does not automatically clean wp-content, the database, server rules, DNS or unauthorised accounts. The infection may be stored in any of them.

Does the whole website need to be rebuilt?

Usually not. Most compromised sites can be cleaned and hardened without a redesign. Rebuilding becomes reasonable when legitimate and malicious code cannot be separated, the system is unsupported or the original state is unknown.

Could customer data have been stolen?

It depends on where the code ran and what it could access. If registration, account, checkout or payment pages were affected, investigate a potential data breach, involve the payment provider and assess notification obligations for the relevant jurisdictions.

How quickly will Google remove a warning?

After the site is fully clean, submit a review through Search Console. Google says the process may take from several days to several weeks. Search snippets and spam URLs can take additional time to update.

Can the redirect return after cleanup?

Yes, if the vulnerability, backdoor, unknown administrator, scheduled task or stolen access remains. Root-cause investigation and post-recovery monitoring are essential.

When to call a specialist

A DIY initial assessment may be reasonable if you understand hosting, server files, databases and logs and can restore the site if something goes wrong.

Avoid experimenting on the live system when:

  • the site processes orders, payments or personal data;
  • the redirect leads to phishing or a download;
  • the hosting provider has suspended the account;
  • several sites under the same account are affected;
  • unknown administrators have appeared;
  • the code returns after removal;
  • DNS, CDN or business email may be compromised;
  • no verified backup exists;
  • the website is critical to daily business operations.

To begin an investigation, provide the specialist with the website address, first known time of the incident, redirect destination, screen recording, referral source and recent update history. Do not send passwords in an unprotected email. Use temporary accounts or a secure sharing method and revoke access after the work is complete.

The key takeaway

An unwanted redirect is not merely an inconvenience or a routine WordPress bug. While visitors are being sent elsewhere, the business can lose ad spend, trust, orders and search visibility. If the redirect appears on a login or payment page, the risk is even more serious.

A proper recovery has four objectives:

  1. contain the harm;
  2. preserve evidence;
  3. remove every part of the compromise and close the entry point;
  4. verify the recovery and monitor the site afterwards.

Deleting one suspicious line is faster. Understanding why it appeared and why it cannot return is far more important.

If your WordPress website is redirecting visitors, 4 Pixels can investigate the source, remove the malicious behaviour, restore the site and create a practical plan to reduce the risk of recurrence.

Join the discussion

Leave a comment

Your comment may be held for moderation before it appears.