How to Set Up a 301 Redirect in 1C-Bitrix from URLs Without a Trailing Slash to URLs with a Trailing Slash
When developing and optimizing websites powered by 1C-Bitrix, developers often need to standardize page URLs. One common task is configuring automatic redirects from URLs without a trailing slash to their corresponding versions with a trailing slash.
For example, when a user opens https://example.com/catalog, the website should automatically redirect them to https://example.com/catalog/ with the HTTP status 301 Moved Permanently.
In this guide, we will explain how to configure such redirects in 1C-Bitrix using the .htaccess file, which exceptions should be considered, and how to verify that the redirects work correctly.
Why Redirect URLs to Their Trailing Slash Versions?
Sometimes the same website section is accessible through two different URLs:
https://example.com/cataloghttps://example.com/catalog/
If both URLs return an HTTP 200 status and display identical content, search engines may consider them duplicate pages.
Configuring a permanent 301 redirect helps accomplish several important tasks:
- Standardize the URL structure across the website.
- Prevent identical content from being accessible through multiple URLs.
- Reduce the likelihood of technical duplicate pages appearing in search engine indexes.
- Maintain consistency in internal linking.
- Preserve a predictable URL structure when modifying website routing rules.
This task can be implemented using the standard capabilities of the Apache web server and its mod_rewrite module. There is no need to modify the 1C-Bitrix core or install additional modules.
1. Where Is the .htaccess File Located in 1C-Bitrix?
The main URL rewriting and redirect rules for a 1C-Bitrix website are typically stored in the .htaccess file located in the website's root directory.
You can access this file using FTP/SFTP, SSH, or your hosting provider's file manager.
A standard 1C-Bitrix .htaccess file usually contains the following directive:
RewriteEngine OnIt also contains a rule that forwards requests to the Bitrix URL rewriting mechanism:
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]Important: New redirect rules should be placed after the RewriteEngine On directive but before the standard routing rule that forwards requests to /bitrix/urlrewrite.php.
Before editing the file, it is recommended to create a backup of the existing .htaccess configuration.
2. Configuring a 301 Redirect to URLs with a Trailing Slash
To automatically add a trailing slash to page URLs, you can use the following Apache configuration:
# Redirect URLs without a trailing slash
# Exclude system directories
RewriteCond %{REQUEST_URI} !^/(bitrix|local|upload|api|rest|\.well-known)(/|$) [NC]
# URL must not already end with a slash
RewriteCond %{REQUEST_URI} !/$
# Exclude URLs with file extensions
RewriteCond %{REQUEST_URI} !\.[^/]+$
# Exclude existing files, symlinks and directories
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
# Permanent 301 redirect
RewriteRule ^(.+)$ /$1/ [R=301,L]Add this code to the existing mod_rewrite block in your .htaccess file, immediately before the standard Bitrix routing rules.
After saving the file, requests to virtual sections without a trailing slash will be redirected to the corresponding URLs with a slash.
For example:
https://example.com/catalog
↓ 301
https://example.com/catalog/
https://example.com/catalog/pipes
↓ 301
https://example.com/catalog/pipes/
https://example.com/company/about
↓ 301
https://example.com/company/about/URLs pointing to existing files, physical directories, and system sections are excluded from this rule.
For physical directories, Apache usually handles trailing slash redirects automatically using the DirectorySlash mechanism, provided that it is enabled.
3. How the Redirect Rule Works
Let's examine the main directives used in the example.
Checking for a Trailing Slash
RewriteCond %{REQUEST_URI} !/$This condition checks whether the requested URL does not end with the / character. If the URL already contains a trailing slash, no redirect is performed.
Excluding Files
RewriteCond %{REQUEST_URI} !\.[^/]+$This condition excludes URLs whose final path segment contains a dot followed by additional characters. It prevents trailing slashes from being added to typical file URLs, such as:
/index.php/robots.txt/sitemap.xml/catalog/item.html
This exception is especially important for websites where product or news detail pages use the .html extension.
Keep in mind that the condition also excludes section URLs containing dots in their final path segment, such as /catalog/version.2. If your website uses such URLs and they require trailing slashes, the condition must be adjusted to match your actual URL structure.
Checking Existing Files and Directories
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-dThese conditions prevent redirects for requests targeting existing files, symbolic links, and physical directories.
This approach helps reduce the risk of conflicts with the website's file structure and Apache's built-in functionality.
Performing the 301 Redirect
RewriteRule ^(.+)$ /$1/ [R=301,L]The rule contains the following elements:
^(.+)$— captures the relative request path./$1/— generates a new URL with a trailing slash.R=301— returns a permanent redirect status.L— stops further rule processing during the current rewrite pass.
Using a relative redirect destination eliminates the need to hardcode the website's protocol or domain name. This is particularly convenient when the website uses HTTPS or operates under multiple domain names.
4. Excluding 1C-Bitrix System Directories
When configuring global redirects, it is important to account for the system directories used by 1C-Bitrix.
The example includes the following condition:
RewriteCond %{REQUEST_URI} !^/(bitrix|local|upload|api|rest|\.well-known)(/|$) [NC]This condition excludes requests to the following directories:
/bitrix/— core files, the administration panel, and system handlers./local/— custom components, templates, and application code./upload/— uploaded files and images./api/and/rest/— possible API endpoints and integration routes./.well-known/— service URLs used by various network protocols and services.
If your project uses additional system routes, it is recommended to add them to the exclusion list as well.
Pay particular attention to AJAX requests, REST API endpoints, web forms, and third-party integrations, where changing the URL may cause unexpected behavior.
5. Preserving GET Parameters During Redirects
When configuring redirects, it is important to preserve query string parameters, including filters, sorting options, and UTM tracking tags.
For example, suppose a user opens the following URL:
https://example.com/catalog?sort=price&order=ascAfter the redirect, the resulting URL should be:
https://example.com/catalog/?sort=price&order=ascIn the provided example, the RewriteRule does not define a new query string. Therefore, Apache preserves the existing GET parameters by default when performing the redirect.
There is no need to add the QSA flag in this case.
6. Testing the 301 Redirect
After modifying .htaccess, verify that the redirect works correctly and does not create redirect loops.
You can inspect the HTTP response headers using curl from the command line:
curl -I https://example.com/catalogIf the configuration is correct, the expected response should look similar to this:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/catalog/Additionally, test URLs containing GET parameters, pages with .html extensions, the administration panel, and other website sections.
To inspect the complete redirect chain, use:
curl -IL https://example.com/catalogIdeally, the original URL should redirect to its final destination in a single step, unless additional redirects are required for HTTPS or domain normalization.
Tip: During initial testing, you can temporarily use the 302 status instead of 301. Once the rules have been verified, change it to a permanent 301 redirect. This makes testing easier because browsers may cache permanent redirects.
7. Common Redirect Configuration Errors
500 Internal Server Error
This error usually occurs when the .htaccess file contains a syntax error or uses directives that are prohibited by the server configuration.
Check the added code, review the Apache error log, and verify that mod_rewrite directives are permitted.
The Redirect Does Not Work
Make sure the mod_rewrite module is enabled and that the server allows processing of directives from .htaccess.
Also check the placement of the rule. If it appears after the standard request forwarding rule to /bitrix/urlrewrite.php, the redirect may not be executed.
If the website runs exclusively on Nginx without Apache, the .htaccess file is not processed. In this case, the redirect must be configured directly in the Nginx configuration.
Infinite Redirect Loop
This issue may occur when multiple URL normalization rules conflict with each other. For example, one rule may add a trailing slash while another removes it.
Check the web server configuration, Bitrix components, and any additional SEO redirect modules installed on the website.
Internal Links Still Use URLs Without Trailing Slashes
A 301 redirect changes how requests are handled, but it does not automatically modify links generated by components or templates.
For complete URL normalization, review the SEF settings of your components, information block URL templates, internal links, and canonical URLs.
8. Alternative Ways to Configure Redirects
In addition to editing .htaccess, redirects can be implemented through Nginx configuration, custom PHP code, or specialized SEO modules for 1C-Bitrix.
However, for websites running on Apache, using mod_rewrite is usually the simplest solution. Redirects are handled at the web server level before the request reaches the application, avoiding additional PHP processing overhead.
If you use a dedicated redirect management module, make sure its rules do not duplicate redirects already configured at the web server level.
9. Important Notes Before Configuring Redirects
The example provided in this article is intended for a typical 1C-Bitrix website running on Apache with the mod_rewrite module enabled.
Before making changes to a production website, carefully review the existing rules in the .htaccess file, especially if the website already uses HTTP-to-HTTPS redirects, www-to-non-www redirects (or vice versa), or custom SEF URL rewriting rules.
When multiple redirect rules are present, pay attention to their execution order to avoid unnecessary redirect chains and infinite redirect loops.
If your website uses Nginx without Apache, the .htaccess approach described in this article will not work. In that case, equivalent redirect rules must be configured directly in Nginx.
Recommendation: Always create a backup of the existing .htaccess file before making changes. Initially, test the redirects using the temporary HTTP 302 status. Once the configuration has been verified, replace it with a permanent HTTP 301 redirect.
Conclusion
Configuring a 301 redirect in 1C-Bitrix from URLs without a trailing slash to URLs with a trailing slash can be accomplished using a few rules in the .htaccess file.
The process involves using mod_rewrite, defining exceptions for files and system directories, and placing the redirect rule before the standard Bitrix URL routing mechanism.
When configured correctly, the website will use a consistent URL format while existing pages, files, and administrative tools continue to function normally.
After implementing the redirect, always verify HTTP response codes, query string preservation, the absence of redirect loops, and the correctness of internal links. These checks will help prevent technical issues and ensure predictable URL behavior across your 1C-Bitrix website.