Website Redirects to Another Site: How to Find and Fix the Cause

When a visitor says your website redirects somewhere else, treat it as a real report even if you cannot reproduce it immediately. Redirects can be conditional. They may trigger only once, only on mobile, only from search results, or only for visitors who are not logged in.

First confirm the redirect path

Check the final URL, not only the first page that loads. A normal redirect from http to https is expected. A redirect from example.com to www.example.com may also be expected. A redirect to an unfamiliar domain, a tracking-heavy URL, or a page unrelated to your business is not normal.

Write down the starting URL, final URL, browser, device, and approximate time. If the issue later disappears, that record may be the only clue.

Common causes

Unexpected redirects usually come from one of five places:

• CMS plugin or theme code
• Server rewrite rules such as .htaccess or nginx config
• JavaScript injected into pages
• DNS, CDN, or proxy settings
• Compromised advertising or third-party script tags

The important point is that the visible page is not always where the redirect begins. A redirect can happen before HTML loads, after JavaScript runs, or only after a search visitor lands on a specific URL.

Check source and public files

If the redirect happens after the page starts loading, inspect page source for unfamiliar scripts, encoded JavaScript, or calls to unknown domains. If it happens before the page appears, check server rules, CDN page rules, and DNS.

Also check whether public files such as backups, config files, or debug files are exposed. Redirect spam and public exposure sometimes appear together after a weak plugin, old CMS, or bad deployment leaks more than expected.

Do not clean blindly

It is tempting to remove the first suspicious line you find. Before doing that, take a copy of the rule, file path, and affected URL. Cleanup without notes can make it harder to know how the change happened and whether it will return.

After cleanup, monitor the final URL

Redirect problems are often intermittent. A one-time clean check is useful, but it does not prove the issue will stay fixed. Keep watching the final URL and redirect chain for important pages.

Separate server redirects from browser redirects

A server redirect happens before the browser receives the page. A browser redirect happens after HTML or JavaScript loads. This distinction tells you where to investigate. Server redirects usually come from hosting rules, CDN rules, DNS or proxy configuration, CMS redirect plugins, or web server files. Browser redirects usually come from JavaScript, injected HTML, tag managers, advertising scripts, or compromised third-party widgets.

If the address bar changes before any page content appears, look at server and CDN rules first. If the page flashes for a moment and then moves, inspect scripts and page source.

Test more than one entry point

Do not test only the homepage. Check a search result URL, an old blog post, a product page, and a URL with common campaign parameters. Redirect spam often targets search traffic or older high-ranking pages because those URLs already have authority.

Also check both the root domain and the www version. A certificate, DNS, or CDN rule can be correct on one host and wrong on the other.

What not to ignore

Be especially careful when the redirect sends visitors to a different registrable domain, when only mobile visitors see it, when the target contains unrelated commercial keywords, or when the problem returns after cache clearing. Those patterns suggest the issue is not a harmless misconfiguration.

Cleanup checklist

Review redirect plugins, CMS options, .htaccess or nginx rules, CDN page rules, DNS records, tag manager containers, and recently changed scripts. Then rotate passwords for CMS admins, hosting, FTP, CDN, and domain registrar accounts if compromise is possible.

Questions to answer before cleanup

Before changing anything, answer four questions. Does the redirect happen for every visitor or only some visitors? Does it happen before the page loads or after scripts run? Does it affect one URL or many URLs? Does the destination domain belong to you?

These questions point toward the source. A redirect that affects every URL may be a server or CDN rule. A redirect that affects only search visitors may be injected JavaScript or cloaking. A redirect that affects one old blog post may be content-level spam or a compromised redirect record.

After the redirect is fixed

Check logs if you have access. Look for unfamiliar admin logins, plugin uploads, file changes, and repeated requests to suspicious paths. Then monitor the same starting URLs for several days. Redirect issues are often considered fixed too early because they disappear for the person testing them once a cookie or cache changes.

How to remove an unexpected redirect

Start where the redirect happens. If the redirect happens before the page content loads, check DNS, CDN forwarding rules, hosting redirects, .htaccess, nginx config, framework middleware, and CMS redirect plugins. If the redirect happens after the page appears, inspect JavaScript, tag manager containers, ad scripts, theme files, and injected HTML.

On WordPress and similar CMS platforms, review redirect plugins, SEO plugins, recently modified theme files, mu-plugins, widget areas, and database options. On custom apps, search the codebase and database for the destination host. If the target host appears nowhere, inspect third-party scripts loaded by the page.

Verification after cleanup

Check several starting URLs, not only the homepage. Include old search result URLs, campaign pages, and mobile visits. A redirect that only appears for first-time visitors or search traffic can look fixed when you test repeatedly from the same browser.

If Google indexed the redirect target or spam pages, use Search Console to inspect affected URLs after cleanup. You may need to request reindexing for important pages and monitor whether the final URL stays correct over the following days.