A single unexpected redirect, not a loop, means something is deliberately sending visitors from one URL to another and you didn't expect it or don't want it anymore. The fix is almost always in one of four places: your .htaccess file, WordPress's stored site URL, the Domain Redirects tool in cPanel, or Cloudflare. Check them in that order, since .htaccess and WordPress cause the vast majority of these.
If you're instead seeing the same URL bounce back and forth endlessly, that's a different problem with its own fix: fixing ERR_TOO_MANY_REDIRECTS (redirect loops). This article covers the single-hop case, where a URL lands somewhere you didn't expect.
Confirm what's actually happening
Open the URL in an incognito window with the browser's network tab open. Look at the status code on the redirect: 301 means permanent, 302 means temporary. Browsers and crawlers treat these very differently. A 301 tells search engines to transfer ranking signals to the new URL permanently and to update their index. A 302 tells them the move is temporary, so they keep the original URL indexed and check back later. Using the wrong one is a common source of confusion: a site that's permanently restructured but still serving 302s will keep the old URLs floating around in search results for months. For the full rundown of what each status class means, see HTTP status codes explained.
Trace the hop
From a terminal, curl -I the URL to see the redirect target without following it:
curl -I https://yourdomain.com/old-page
The Location header in the response tells you exactly where it's pointing. Compare that against what you expect. If the target is wrong, or the redirect fires on a URL that should load normally, you've confirmed the problem and know where to start looking.
Check .htaccess first
Most single-hop redirects on shared hosting live in .htaccess in your site's root directory. Rules look like:
Redirect 301 /old-page /new-page RedirectMatch 301 ^/blog/(.*)$ /articles/$1
Open the file through File Manager in cPanel (one-click login from the service page), or connect over FTP. Common causes of an unwanted redirect:
- A rule from a previous site migration or theme change that never got removed.
- A leftover rule from a plugin (WordPress SEO plugins in particular write their own redirect blocks into
.htaccess). - A wildcard
RedirectMatchthat's catching more URLs than intended, because the regex is broader than the person who wrote it realized.
To test whether .htaccess is the cause at all, rename it to .htaccess.bak via FTP or File Manager and reload the URL. If the redirect disappears, you've found it. Edit the specific rule rather than leaving the file renamed, since .htaccess also normally handles things like your SSL/HTTPS enforcement.
Check WordPress's stored URLs
If the site is WordPress, the redirect might not be a server rule at all. WordPress stores its home and site URL in the database (wp_options, the siteurl and home fields), and every page load checks that value. If it points at a different domain, a staging subdomain, or the wrong protocol, WordPress itself issues the redirect before your theme or plugins even run.
Go to Settings → General in wp-admin and confirm both fields show the correct domain. If you can't reach wp-admin because the redirect happens immediately on login too, the values need to be corrected directly in the database via phpMyAdmin, or by adding overrides to wp-config.php:
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');
Also check for a redirect plugin. Yoast, Rank Math, and dedicated redirect managers all keep their own rule tables separate from .htaccess, and a stale rule in one of those is invisible until you open the plugin's settings page specifically.
Check cPanel's Domain Redirects and your DNS settings
Log in to cPanel from the service page and open Domain Redirects. If a redirect exists there and you didn't set it, or it's pointing somewhere outdated, that's your answer. Also confirm the domain's DNS is actually pointed where you think: DNS records live under Services → your hosting → DNS Zone Editor, not under the domain's own DNS tab, which only controls nameservers.
Check Cloudflare, if the domain is proxied
If the domain runs through the portal's Cloudflare CDN page with the proxy toggle on, Cloudflare sits in front of every request and can add its own redirect behavior, particularly around HTTPS enforcement. Always Use HTTPS and Automatic HTTPS Rewrites both issue redirects at the edge, before the request ever reaches your server. If you've already fixed a redirect at the origin and the browser is still bouncing, check these two settings first. Purge the cache from the same page afterward, since Cloudflare will keep serving a cached redirect response until it expires or you clear it.
When to open a ticket
If you've confirmed the redirect isn't coming from .htaccess, WordPress's stored URLs, cPanel's Domain Redirects, or Cloudflare, and it's still happening, open a ticket from Support in the portal. Include the exact URL, the status code from your curl -I check, and the Location header value. That's usually enough for a real person to spot what's left.