Even a single incorrect rule is enough to make a website inaccessible or send visitors into an endless loop of redirects. An .htaccess redirect is therefore not simply a matter of inserting a line of code: the target URL, the status code and the order of the rules all matter.

It is not always clear where the .htaccess file is located, or when it is advisable to use a 301 or 302 redirect. On an Apache web server, the file may contain settings for a directory and its subdirectories. For it to work, the Apache configuration must also allow its use. In cPanel, you can edit the file using the file manager, provided the server environment supports the necessary rules.

This guide explains how .htaccess redirects work, what rules can be used in common scenarios, and how temporary redirects differ from permanent ones. We’ll also walk you through the process of making changes safely, from taking a backup to targeted testing and reverting the changes. This way, you can check the target URL, the response code and any redirect loops before going live.

What is a .htaccess redirect, and when can it be used?

A .htaccess redirect is an Apache server-side rule that directs an incoming request to another URL or path. The server sends a response containing the new address to the browser, which then fetches the target page. The rules in the file apply at directory level, provided that the Apache configuration permits them.

Redirects are useful, for example, when a page’s address changes, when you want to direct visitors to appropriate new content instead of a defunct subpage, or when you want to redirect an HTTP address to HTTPS. The server can also perform internal URL rewriting. In this case, the request is served via a different route in the background, but the URL in the browser’s address bar does not necessarily change. The two operations are therefore not the same.

A browser-side solution, such as the automatic redirection of an HTML page, only takes effect once the page has loaded. Server-side redirection can be handled by the website’s code. This overview of URL redirection outlines these approaches and the options available with Apache. The advantage of an .htaccess redirect is that the rule can be enforced during server request handling without modifying the application’s code.

• An old website is moving to a new address, and visitors need to be redirected to the new content.
• You want to use a single version of the website’s address, for example, with or without the ‘www’ prefix.
• It would redirect unencrypted HTTP requests to an HTTPS address.
• Instead of a deleted URL, it would select a page with equivalent content.

Where is the .htaccess file located?

The root directory of a website is the folder from which the main web content is served. The rules in the .htaccess file located here may also apply to subdirectories. A subdirectory’s own file may apply to that specific folder and its subfolders. The filename begins with a full stop, which is why some file managers hide it by default. In cPanel, you can use the file manager to browse the website’s directories. Make sure to check the option to show hidden files.

In what kind of server environment does .htaccess work?

The .htaccess file can be used for directory-level configuration of the Apache web server. Apache’s central configuration determines which directives the file may contain. Therefore, a rule may not necessarily work even if the file is in the correct location and its syntax is correct. For certain redirects, the mod_rewrite module is also required. Nginx does not apply .htaccess rules; redirects must be specified in a different server configuration there.

How do redirect rules work in the .htaccess file?

The .htaccess redirect rule specifies how Apache should respond to a request and, if necessary, which new address to redirect the visitor to. For simple URL changes, the Redirect directive is usually sufficient. For more complex conditions, such as pattern matching, the RewriteRule can be used. Please adapt the paths and domain names in the examples to your own website.

301 or 302: which redirect code should you choose?

A 301 status code indicates a permanent change of address. Choose this if the page has moved permanently to a new URL. A 302 status code indicates a temporary redirect, for example, in the case of a short-term test or a temporary change. If you use a 302 for a permanent migration, browsers and other systems may interpret the change as temporary. You should therefore select the code according to the actual intention behind the migration.

Code

Objective

Notice

Typical uses

301

Permanent redirect

The address has been permanently changed

Permanent site or domain migration

302

Temporary redirect

The old address will be available for use again later

Temporary redirection or testing

Redirect or RewriteRule: when should you use which rule?

Redirect is a directive of the Apache mod_alias module. It can be used for simple, straightforward redirection, for example as follows:

301 redirect /regi-page https://pelda.hu/uj-oldal

RewriteRule is part of the mod_rewrite module and allows for more flexible route mapping. To use it, you must enable RewriteEngine. The example below redirects the specified route:

RewriteEngine On
RewriteRule ^regi-oldal/?$ https://pelda.hu/uj-oldal [R=301,L]

In this example, R=301 indicates a permanent redirect, whilst L means that Apache should not process any subsequent rules for the current request. For a temporary redirect, change the value of R to 302. The mod_rewrite module and the necessary directives must be enabled in the Apache configuration; otherwise, the rule will not work or may cause a server error. You can find further examples of setting up 301 redirects in an .htaccess file.

Before going live, check the source path, the destination address and the status code. On cPanel hosting, you can edit the file using the file manager, but you should also test the rule separately.

Which .htaccess redirect is suitable for common website scenarios?

The correct rule depends on what is changing: the domain name, the connection protocol or the path to a specific page. In the examples below, replace ‘pelda.hu’ with your own domain name, and adjust the paths to match your website’s actual addresses. A rule is safe if the target page exists and the path leading to it from the old address is unambiguous.

Full domain, www and HTTPS redirection

The ‘www’ and ‘non-www’ addresses are two separate hostnames. Choose a primary version, such as www.pelda.hu, and then redirect the other one to it. The rule below redirects unencrypted requests and non-www addresses to the www, HTTPS version in a single step. Place it in the .htaccess file of the website handling the relevant requests.

RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]

RewriteCond %{HTTP_HOST} !^www\.example\.hu$ [NC]

RewriteRule ^ https://www.pelda.hu%{REQUEST_URI} [R=301,L]

Only redirect to HTTPS if the SSL/TLS connection is working at the destination and a valid certificate is in place. Otherwise, the visitor may see a certificate error. Before saving the rule, open the HTTPS version directly and check that the page loads. The SSL/TLS guide provides further information on the role of certificates and encrypted connections.

If you choose the non-www address as your primary one, amend the target host and adjust the matching condition accordingly. Do not use two conflicting rules at the same time. For example, if the non-www address redirects to the www address and the www address redirects back, a redirect loop may occur.

Migration of a page or directory to a new address

When performing a migration of a single article or subpage, simply redirect the old URL to the new address that corresponds to the content. For example, let https://pelda.hu/regi-cikk be the source and https://pelda.hu/uj-cikk the destination:

RewriteRule ^regi-cikk/?$ https://pelda.hu/uj-cikk [R=301,L]

When moving a directory, decide whether to preserve the subdirectory paths. The example below redirects the URL /news/2025/article to the path /blog/2025/article, thereby preserving the path segment following the directory name:

RewriteRule ^hirek/(.*)$ /blog/$1 [R=301,L]

In the case of WordPress, the content management system’s own rewriting rules may also be included in the file. Place any custom redirects before these so that the request first passes through the targeted rule. Before making any changes, check your existing posts and permalink settings. The guide to web hosting solutions will help you understand the details of the hosting environment required for WordPress to function.

How to set up and test redirects securely?

Making changes safely involves four steps: create a backup of the original file, add a single rule, check that it works, and then revert to the previous state if necessary. Managing .htaccess redirects is easier if you make only one change at a time. This makes it simpler to locate the problematic line in the event of an error.

Before modifying the file, make a recoverable backup

Make a copy of the original .htaccess file and keep it in a place where you can restore it if necessary. You can also create a backup of the contents of the file in a separate text document. Keep the original until you are sure the new rule is working correctly.

In the File Manager, download or rename the existing file, then make a copy of it and work on that. In cPanel, the File Manager helps you manage your website’s files. You can also find an overview of the interface amongst the cPanel hosting features. Do not delete or overwrite several unrelated rules at once. Check the new line and its surrounding context separately.

Add a targeted rule, then give it a go

The Apache example below redirects a single path. To use mod_rewrite, you must enable RewriteEngine, and both the module and the directive must be enabled in the given environment.

RewriteEngine On
RewriteRule ^regi-oldal/?$ https://pelda.hu/uj-oldal [R=301,L]

Replace ‘/regi-page’ with your own source path, and the new URL in place of the destination address. Immediately after saving, open the old address directly – do not just go to the homepage. Check that it is working after each change, and do not assume that the change will only take effect after a certain amount of time has passed.

Check the response code, the destination address and the loops

Testing a specific rule and checking the entire website are two separate tasks. First, check the old URL to see if it returns the correct status code and leads exactly to the intended destination. Then open the new address separately, and try navigating through the main menu and a few important subpages. Expect a 301 response for a permanent migration, and a 302 response for a temporary situation.

• Redirect chain: the original address leads to an intermediate URL, then to a further address. Where possible, redirect directly to the final destination.
• Redirect loop: two or more URLs point to each other, preventing the browser from reaching the page being loaded.
• Server error: if the page displays an error or fails to load after making changes, restore the backed-up file, then check the syntax of the rule and the permitted directives.

When testing, check the old URL, the destination page and the website’s main paths. If the redirect isn’t working as expected, don’t add further conditions at random. Restore the backup file, then restart the check with just one change.

What should you do if your .htaccess file is causing a redirect error?

If your website is not working properly after adding a rule, first identify the symptom. A 500 server error may indicate a configuration or syntax issue, an incorrect target page may indicate a faulty route, and repeated redirects may indicate conflicting rules. These are different types of errors, so do not modify several lines at once at random. When fixing an .htaccess redirect, undoing the most recent change provides the safest starting point.

In the event of a 500 error or a page failing to load

Restore the last working .htaccess file to make the website accessible again. Then check the spelling of the added directive, the brackets, the tags and the target URL. Even a rule with correct syntax can cause an error if the server environment does not allow the directive or module. Do not assume that all Apache settings can be used at directory level.

The error log can help you identify which request or file caused the problem. Look for entries relating to the time of the change and compare them with the file’s current contents. Do not jump to conclusions about any specific cause without consulting the log entries. If the error disappears after reverting to the old version, check the rule separately from the other changes.

In the event of an infinite redirect or an incorrect destination

If your browser reports too many redirects, check whether two rules are redirecting the same URLs to each other. For example, one rule might redirect the ‘www’ version to the non-‘www’ URL, whilst another specifies the opposite direction. You should also check whether the target URL once again meets the condition matching the source. In such cases, the rule may be triggered again.

If the destination page is incorrect, compare the requested path with the destination specified in the rule. Check the directory names, slashes and whether the destination is a relative or absolute URL. There may be intermediate addresses in the chain, so trace the path to see which URLs the request passes through.

• Temporarily remove or deactivate the rule in question, then check whether the desired behaviour has been restored.
• Try out a single rule with a specific source and destination address.
• If the test is successful, gradually revert the other changes, checking the result after each step.

If the syntax appears to be correct but the error persists even after a reset, check the server environment and the log entries. The correct Apache configuration and the hosting provider’s file management options make it easier to maintain your rules in a clear and organised manner. Find out more about aWh’s web hosting solutions if you’re looking for a hosting environment that suits your website.

Establish a consistent redirect policy

An .htaccess redirect is not a one-off setup if your website’s URLs change over time. Make a note of which old URLs lead where, and why that particular rule is necessary. This makes it easier to spot outdated entries later on, and reduces the chance of a new change overwriting the previous configuration. Keeping a record is also useful if several people are managing the website’s files.

A reliable hosting environment is a vital foundation for the day-to-day operation of a website. With over 10 years’ experience, aWh offers web hosting, cPanel hosting and VPS hosting. Backups and two-factor authentication may also be factors to consider when choosing a hosting provider.

If you’re looking for a hosting solution that suits your website, take a look at aWh’s web hosting solutions. Automatic backups, HTTPS and two-factor authentication can help make managing your hosting and website more secure.

Frequently asked questions about .htaccess redirects

Do .htaccess redirects work on Nginx servers too?

No, Nginx does not, by itself, read or apply Apache’s .htaccess files. Redirects must be specified in Nginx’s own server configuration. If you are unsure which web server is handling the requests, check your hosting settings. In a mixed environment, it also matters which server the request passes through first, as the redirect may occur at another layer.

What happens if there is incorrect syntax in the .htaccess file?

An incorrect directive or syntax in Apache can cause a 500 server error and may prevent several pages from loading. The exact effect depends on where the error is located and how the server processes the configuration. If the error occurs after modifying a file, revert to the previous working version. Then examine the log entry and check the modified line specifically.

Does the redirect preserve the query parameters?

Often yes, but this depends on the Apache directive used and the format of the target URL. For example, the ?ref=newsletter parameter may be carried over by the redirect if the rule does not replace or remove the query string. You should also test with a URL that contains multiple parameters, such as a tracking code and a filter. Check that the destination page receives the expected values.

Can a redirect be set up for just one specific subdomain?

Yes. By placing the RewriteCond %{HTTP_HOST} condition before the rule, you can check which subdomain the request was directed to. For example, a condition linked to the hostname shop.pelda.hu can exclude the main domain and other subdomains. Ensure the hostname exactly matches the desired address, and check the case sensitivity. This way, the redirect will only apply to requests for the relevant subdomain.

How can you temporarily disable an .htaccess rule?

Place a double cross in front of the rule so that Apache treats it as a comment and does not execute it. If the rule includes a series of conditions, disable those as well; otherwise, a remaining condition may affect another rule. Save a copy of the original file before making any changes. After testing, remove the double cross if you wish to reactivate the rule.

Why doesn’t the redirect change after the rule has been modified?

It may be that your browser has retained the result of a permanent redirect received previously. Try opening the URL in an incognito window or using a different browser. If the old route still takes precedence there, check that you have modified the correct .htaccess file and that Apache is actually handling the request. An intermediate cache or application settings may also affect the test.

Can a separate .htaccess file be applied to a subdirectory?

Yes. The directives specified in a subdirectory’s own .htaccess file may apply to requests for that particular folder, provided the server configuration allows this. For example, you can manage the URLs for your online shop in a file located in the /webshop/ folder without applying the same rule to the entire website. Settings in the parent directory may also affect behaviour, so please test on the relevant path.

• htaccess
• cpanel
• http errors
• guides