You enter your WordPress site address and land somewhere else. Perhaps it is just the www version of your own domain. Perhaps it is a site you have never seen before. Those are very different situations, so I would not start by pasting a new rule into .htaccess.
First, look at where the visitor ends up. An intentional switch from HTTP to HTTPS, or from non-www to www, is usually normal. A loop between two versions of your site suggests conflicting settings. A redirect to an unrelated domain, especially one that asks people to log in or download something, deserves a security check.
If the destination looks unsafe, do not enter credentials there. Do not ask customers to test it for you, either. Record what happened and contact your host if visitors may be affected.
Take two minutes to describe the redirect
A useful diagnosis starts with a small record. Write down the exact page you tried to open, the address you reached, when it happened, and whether it happens to everyone or only on a phone, a private window, or a link from Google. Note any recent changes to plugins, domain settings, CDN rules, or hosting. If you need help later, these details are much more useful than “the site is broken.”
WordPress.org recommends documenting the symptoms before investigating a suspected compromise. Ask your host to preserve relevant logs if the destination is unfamiliar. Also keep a backup of files and database before changing configuration; a backup from today may not be clean, but it gives you a record of the current state.
Which of these looks like your problem?
It goes to another version of your own domain
If http://example.com becomes https://www.example.com, that may be exactly how the site was configured. The path should still make sense, and the final page should load. My WWW and non-WWW redirect guide explains how to check the preferred version without creating a loop.
It keeps bouncing between URLs
A browser message such as “too many redirects” often points to two systems disagreeing. A WordPress setting, a hosting rule, and a CDN rule can each send the visitor somewhere else. For example, Cloudflare documents redirect loops when its SSL mode conflicts with an origin server that forces HTTPS. Do not change several layers at once. Find the first rule that sends the request back to where it came from.
It goes to a domain you do not recognize
Treat this as potentially unsafe until you know why. It could be an unwanted redirect rule or injected code. It is not proof of a hack by itself, but deleting the first suspicious-looking plugin is not a reliable diagnosis either. If the site collects payments or personal information, involve the host or a security responder promptly.
Check the simple settings before editing files
- WordPress URLs. In Settings > General, compare “WordPress Address” and “Site Address” with the domain you intend to use. These settings can be overridden in
wp-config.php; WordPress explains the difference. Do not casually change them on a live site. A wrong value can lock you out. - Redirect plugins and recent changes. Review rules added by a redirect or SEO plugin. Look for a rule with the affected path, a wildcard, or an unfamiliar destination. Check who changed it and when, if logs are available.
- Host and CDN rules. Check whether your host or CDN handles HTTPS and domain redirects. A rule there can run before WordPress loads, so changing a WordPress plugin may do nothing.
- Server configuration. If you maintain Apache or Nginx rules, compare the current configuration with a known good copy. Ask your host or developer to review it if you are unsure. Save a backup before touching it.
You can inspect the first server response without following the destination in a browser. In a terminal, replace the example address with a page on your own site:
curl -I https://example.com/affected-page/Look for the status and the Location header. A 301 or 302 with an unexpected Location tells you that the server sent the redirect. This quick check is not conclusive: some redirects happen in JavaScript, and a site may answer a HEAD request differently from a normal page request. If the command shows a normal response but visitors still get sent away, ask your host or responder to inspect the full page and logs. Do not use a command that follows an unfamiliar destination just to see where the chain ends.
When the signs point to a compromise
Check the Security issues report in Google Search Console if you have access. It can show Google’s findings about hacked content, malware, or harmful behavior. A clean report is useful, but it does not prove that every file and database entry is safe. Some unwanted redirects only appear for certain visitors or referrers.
Preserve the evidence and a backup, limit visitor exposure if necessary, and involve your host or a qualified incident responder. The cleanup needs to find the entry point as well as the visible redirect. My guides to choosing a WordPress security scanner and understanding malware removal options explain what those tools can and cannot do. A scanner is a clue, not a guarantee.
I would avoid restoring an old backup or replacing files at random before someone has checked what happened. An unverified backup can bring the problem back, and a rushed edit can remove evidence that explains how the redirect started.
After the cause is fixed, test more than the homepage
- Open a few real page URLs, including the one that originally failed. Check both desktop and mobile.
- Try the HTTP, HTTPS, www, and non-www versions of a representative page. The result should be the one intended domain, without a loop.
- Check a URL with a query string and confirm the page path still works.
- If Search Console reported a security issue, request a review only after the site has been cleaned and the underlying cause addressed.
If all you have is a normal domain redirect, there is no need to treat it as an attack. But if visitors are going somewhere you did not choose, slow down and establish the cause before applying a fix. That one distinction saves a lot of guesswork.
Once the site is safe and working, there may be a different question: does it actually help people understand your business? If you want another pair of eyes on that part, send me the link. I will reply with three specific observations, not an automated score.
The checks here help narrow down a symptom. They are not a substitute for incident response when a site may be compromised.