‹ Back

Editing the .htaccess file: practical instructions

 

The .htaccess file is a common per-directory configuration file on Apache servers. In this article, we cover how to edit it and give practical instructions for managing redirects, access rules and error pages. Because changes take effect immediately, the file must be edited carefully: a single typo or unsupported directive can cause a 500 Internal Server Error.

 

 

This guide walks you through practical examples of the most common .htaccess use cases: 301 redirects, password protection, custom error pages and disabling directory listings. You will also learn how to edit the file safely and recover quickly if a change fails. In Hostaan's WordPress hosting environment , Plesk, daily backups and a staging environment make changes easier to manage and test.

 

Safe .htaccess editing before the first change

 

 

Before you add or change even a single line, you need three things: you need to know where the file is located, know how to back it up and understand how to test changes without unnecessary risk.

Compatibility note: These examples apply to Apache-compatible hosting where the required modules and AllowOverride permissions are enabled. Nginx-only servers do not read .htaccess files. If you are unsure which directives your plan supports, check the hosting documentation or ask support before making the change.

 

Where the file is located and how to create a new file

The .htaccess file is usually located in the root directory of your website, for example in /public_html/ or /httpdocs/ . The filename starts with a dot, which is why it is hidden by default in many file managers and FTP programs. In an FTP program such as FileZilla, you need to enable the display of hidden files separately.

 

If there is no .htaccess file in the root directory, you can create a new one. Create an empty plain-text file, name it exactly .htaccess (no file extension, no spaces) and move it to the root directory. WordPress can generate or update the file when you save the permalink settings, provided the directory and file are writable. If WordPress cannot write the file, it displays the rules for you to copy manually. Save a manually created file as plain UTF-8 text without a BOM marker.

 

Editing in Plesk or via FTP

In the Plesk control panel, you can edit the .htaccess file directly in your browser:

1. Open Plesk and go to the file manager for the relevant website.

2. Navigate to the root directory.

3. Click the .htaccess file and choose "Edit in Code Editor" or the equivalent editing option.

4. Save the changes and test the website immediately.

 

When using FTP, first download the file to your own computer, edit it with a plain-text editor such as Notepad++, VS Code or a similar tool, and upload the modified file back to the server. Make sure the editor saves plain UTF-8 text without a BOM; do not use a word processor or rich-text editor.

With SSH, you can edit the file directly on the server from the command line using an editor such as nano or vim . This is a direct method, but it requires familiarity with command-line work.

 

Backups, testing and the most common cause of a 500 error

Always back up the .htaccess file before editing it. Download the backup to your own computer or store it outside the public document root. Do not leave an unprotected backup copy in a web-accessible directory. This lets you restore the original file quickly if something goes wrong.

A common cause of a 500 Internal Server Error after editing .htaccess is a syntax error, an unsupported directive or a module that is unavailable on the server. The browser usually shows only a generic error page, while the Apache error log often identifies the failing directive and line. Restore the backup first if you need to bring the site online immediately.

 

In practice, testing should be done like this:

• Add one change to the .htaccess file at a time.

• Save the file and open the website in the browser immediately.

• If the site works, add the next change.

• If you get a 500 error, restore the backup and check the previous change line by line.

 

In an environment like Hostaan's, a staging tool reduces risk: you can try .htaccess changes in a copied environment before moving them to production. Because staging and production settings can differ, test the production site again immediately after deployment.

 

The most common .htaccess use cases with practical examples

In practice, the .htaccess file is most often needed for redirects, directory protection, password protection, custom error pages and selected performance settings. The examples below are starting points: adapt domain names and paths, confirm that the required Apache modules are available and test one change at a time.

 

301 redirects and page redirection

A permanent 301 redirect tells browsers and search engines that a resource has permanently moved to a new address. It is the standard choice when an old URL should consistently lead to its replacement.

Different redirect rules help keep your site's links working and preserve search engine value. The simplest method is the Redirect directive:

    Redirect 301 /old-page.html /new-page.html

This redirects a single page to a new address. If you need a redirect that handles multiple addresses at once, use the RedirectMatch directive with a regular expression:

    RedirectMatch 301 ^/blog/([0-9]{4})/(.*)$ /articles/$2

For more complex redirect rules, you need the mod_rewrite module. The following example redirects HTTP traffic to a fixed HTTPS hostname:

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

RewriteEngine On starts the mod_rewrite engine. RewriteCond checks whether HTTPS is off, and RewriteRule redirects to the canonical hostname. Replace www.example.com with your own domain. A fixed hostname avoids trusting an arbitrary Host header. If a CDN or reverse proxy terminates HTTPS before Apache, use the hosting provider's recommended rule to avoid a redirect loop.

 

Common mistake: Redirect loops happen when a redirect rule points back to the same address. Always make sure the target URL does not match the same condition again. In this situation, the browser typically shows an "ERR_TOO_MANY_REDIRECTS" error.

 

Directory protection and blocking files

If you do not want visitors to browse your server's directory structure directly in the browser, add this to the .htaccess file:

    Options -Indexes

This prevents directory listings from being displayed. You can also define the default filename by using the DirectoryIndex directive. Without these settings, a visitor may be able to see all files in the directory if the directory does not contain index.html or index.php .

You can also block access to specific files or file types with the FilesMatch directive:

    <FilesMatch "(^\.ht|^wp-config\.php$|\.(ini|log|env)$)">
      Require all denied
    </FilesMatch>

This Apache 2.4 rule blocks direct access to .htaccess, .htpasswd, wp-config.php, .ini, .log and .env files. These files can contain credentials or other sensitive configuration data.

Blocking a single IP address works like this:

    <RequireAll>
      Require all granted
      Require not ip 192.0.2.100
    </RequireAll>

 

Password protection with an .htpasswd file

Password protection is a practical way to restrict access to a development version of a site, an admin area or a single directory. The setup requires two files: .htaccess and .htpasswd.

Add the following lines to the .htaccess file:

    AuthType Basic
    AuthName "Restricted area"
    AuthUserFile /var/www/vhosts/example.com/.htpasswd
    Require valid-user

AuthType Basic tells Apache to use basic authentication. AuthName is the text shown in the browser. AuthUserFile points to the absolute path of the .htpasswd file on the server. Require valid-user requires all visitors to log in.

The .htpasswd file contains usernames and password hashes, one line per user:

    username:$2y$...bcrypt-hash-created-by-htpasswd...

Create the file with a bcrypt hash by running htpasswd -cB /path/.htpasswd username . Use -c only when creating the file for the first time; using it again truncates the existing file. To add another user later, run htpasswd -B /path/.htpasswd another-user . Plesk can often configure password protection graphically without direct file editing.

Important note: Always place the .htpasswd file outside the root directory or protect it separately with an .htaccess rule so that nobody can download it through the browser.

 

Custom 404 and 403 error pages

Default error pages are usually generic server text pages that do not tell visitors anything useful. With a custom error page, you can guide the visitor back in the right direction and keep them on your site.

404 error page (page not found):

    ErrorDocument 404 /404.html

403 error page (access denied):

    ErrorDocument 403 /403.html

Create the corresponding HTML files in your website's root directory. On a 404.html page, it is worth adding navigation, a search function or a link to the home page. On WordPress sites, the theme handles the 404 page automatically, but the .htaccess-level ErrorDocument works as a fallback option.

 

Improving performance with caching and compression

Browser caching can reduce repeat-downloads by defining how long the browser stores static assets. The following example uses mod_expires :

    <IfModule mod_expires.c>
      ExpiresActive On
      ExpiresByType text/css "access plus 7 days"
      ExpiresByType application/javascript "access plus 7 days"
      ExpiresByType image/* "access plus 30 days"
    </IfModule>

The mod_deflate module can compress text-based responses before they are sent:

    <IfModule mod_deflate.c>
      AddOutputFilterByType DEFLATE text/html text/plain text/css
      AddOutputFilterByType DEFLATE text/javascript application/javascript
      AddOutputFilterByType DEFLATE application/json application/xml image/svg+xml
    </IfModule>

Many hosting platforms already configure caching and compression at the Apache, Nginx or CDN layer. Check the current response headers and your hosting documentation before adding duplicate rules.

 

What exactly is .htaccess and when should you use it?

.htaccess is an Apache per-directory configuration file. It lets you change permitted server behavior without access to Apache's main configuration files, such as httpd.conf or apache2.conf. This makes it a practical tool in shared hosting environments, where you do not have root access to the server. The available directives depend on the server's modules and its AllowOverride or AllowOverrideList settings.

Apache checks applicable .htaccess files during requests, so changes take effect without restarting the server. This convenience creates overhead because Apache searches the requested directory and its parent directories for configuration files. If you control the main server configuration, Apache recommends placing the directives there instead for better performance and tighter control.

 

.htaccess is the right tool when:

• You use shared hosting and cannot access the main configuration.

• You make directory-specific changes that do not apply to the whole server.

• You need quick changes without restarting the server.

• You want to test redirects or access control in one directory.

 

.htaccess is not the right tool when you have access to the main configuration and the changes apply to the whole server. In that case, performance and maintainability improve when the settings are placed directly in the httpd.conf file.

 

How directory-specific rules are inherited

Apache processes .htaccess files hierarchically. When a visitor requests a page from an address such as /products/shoes/ , Apache first reads the .htaccess file in the root directory, then the .htaccess file in the /products/ directory and finally the .htaccess file in the /products/shoes/ directory. Rules in lower-level directories can override rules in higher-level directories.

 

This behavior depends on the AllowOverride and AllowOverrideList directives in Apache's main configuration. AllowOverride All permits all directive categories that are valid in .htaccess context, while AllowOverride None disables .htaccess processing for the directory. Hosting providers may allow only selected categories or individual directives, so do not assume that every example is enabled.

In practice, this means you can set general rules, such as forcing HTTPS, in the root directory's .htaccess file and add directory-specific exceptions in lower-level directories. Keep the structure simple: the fewer .htaccess files there are at different levels, the easier the whole setup is to maintain and the faster troubleshooting becomes.

 

Frequently asked questions

 

Where is the .htaccess file located and how can I make it visible on the server?

The .htaccess file is typically located in your website's root directory, for example /public_html/ or /httpdocs/ . Because the filename starts with a dot, it is hidden by default in most FTP programs and file managers. In an FTP program such as FileZilla, enable the display of hidden files in the settings. In the Plesk control panel, choose "Show Hidden Files" in the file manager.

 

How do I back up and restore the .htaccess file if the site stops working?

Before editing, download the .htaccess file to your own computer or store a backup outside the public document root. If the site stops working after a change, replace the edited file with the backup via FTP, the Plesk file manager or SSH. Do not leave an unprotected backup in a web-accessible directory.

 

How do I enable permanent 301 redirects correctly without redirect loops?

Add Redirect 301 /old-path /new-path to the .htaccess file and make sure the new path does not match the same redirect condition again. Loops typically happen when a RewriteRule redirects to an address that matches the same rule again. Test each redirect separately and check the browser developer tools to make sure the request is not looping several times.

 

How do I block specific IP addresses or user agents from accessing the site?

On Apache 2.4, block an IP address with <RequireAll> Require all granted Require not ip 192.0.2.100 </RequireAll> , replacing the documentation address with the real IP address. To block a user agent, use RewriteCond %{HTTP_USER_AGENT} BotName [NC] followed by RewriteRule .* - [F,L] . User-agent strings are easy to change, so this is traffic filtering rather than a strong security control.

For the authoritative list of supported contexts and override requirements, see the Apache .htaccess documentation.

If you want to verify a rule before publishing it, you can contact Hostaan.