Redirect set up in cPanel doesn't work

cPanel saves redirects as rules in .htaccess. If they end up after a block that already handles the request, some paths may never reach them. Check the generated file before changing the order.

Having WordPress or Joomla rules doesn't prove there is a conflict. First test the URL with curl -I, check the status code and the Location header, confirm the entry in Current Redirects and open the .htaccess in the correct DocumentRoot.

If the response and the order show that an application block consumes the request before it reaches the redirect, move only the affected rule so it sits before that block. Keep a copy and respect the blocks managed by WordPress, LiteSpeed, plugins and security tools.

For example, a redirect placed after the WordPress block may not run for paths that block sends to index.php:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

RewriteCond %{HTTP_HOST} ^antiguo\.ejemplo(?::[0-9]+)?$ [NC]
RewriteCond %{THE_REQUEST} \s/+([^?\s]*)
RewriteRule ^ https://nuevo.ejemplo/%1 [R=301,L,NE]

If you have confirmed that interception, place the redirect outside the managed block and before it:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^antiguo\.ejemplo(?::[0-9]+)?$ [NC]
RewriteCond %{THE_REQUEST} \s/+([^?\s]*)
RewriteRule ^ https://nuevo.ejemplo/%1 [R=301,L,NE]

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

RewriteEngine On must appear in that context before the rules that need it, but it doesn't have to be literally the first line of the file. To force HTTPS, prefer cPanel > Domains > Force HTTPS Redirect over creating a manual redirect.

The domains in the example are placeholders: replace the source and destination with your own. The host condition limits the rule to the old domain; the path taken from the original request keeps its encoded characters, and the query string is preserved. Don't add NE to other rules without checking how they build the destination.

Test the home page, an internal path, one with accented or encoded characters and another with parameters. Also check that the new domain doesn't go into a loop. Before making the change a permanent 301, you can use a 302 in a controlled test; then confirm the response without relying on a redirect the browser has cached. If curl -I gives a different result from the browser, compare with a GET request: not every application responds the same way to HEAD.