Bitrix Trailing Slash Redirect: A Practical Setup Guide

Where the duplicates come from

Bitrix builds section addresses like folders, so by default they end with a slash. But the same page can still open without it: an editor pasted a link by hand, a component template assembled the address differently, or an outside source linked to it, such as an Instagram bio, a Telegram channel post or an OLX listing.

When the server answers 200 for both versions, crawlers index both. Link and behaviour signals get split between two addresses, the wrong version may show up in search, and analytics shows one section as two separate rows.

Which format to choose

Technically it makes no difference: search engines do not prefer one over the other. What matters is having a single format. In Bitrix, sections and infoblock pages normally use a trailing slash, so that is the path of least resistance. Addresses ending in .php or .html should not get a slash.

The exception is a site that has sat in the index without slashes for years and gathered external links to those addresses. In that case it is safer to keep the existing format as the main one. Open Search Console and Yandex Webmaster, see which version is actually in search, and go with the one that dominates.

How to set up a Bitrix trailing slash redirect at server level

The right place is the web server, before Bitrix takes over. On Apache the rule goes into .htaccess in the site root, above the standard Bitrix rules. On nginx it goes into the virtual host configuration. The catch is that many Bitrix hosting setups run both: nginx accepts the request and hands it to Apache. Ask your administrator which one actually processes the request, otherwise the rule ends up in a file that changes nothing.

The logic is this: the server adds a slash and answers with a 301, but only when the conditions below are met. The exact rule text depends on your configuration, so write and test it on a copy of the site rather than pasting something from a forum. The rule should fire only when:

• the requested address is not an existing file;
• the path does not end in an extension such as .php or .html;
• there is no trailing slash yet.

What the rule must not touch

The most common mistake is catching too much. Service addresses are the riskiest: if a Payme or Click notification gets a 301 instead of a proper response, the payment system may not follow the redirect and a paid order stays unconfirmed. Exclude the following:

• images, styles, scripts, PDFs, robots.txt and sitemap.xml;
• addresses with a file extension;
• requests with parameters: the slash goes before the question mark and the parameters are preserved;
• the /bitrix/ admin area and AJAX requests;
• notification handlers for payment systems and CRM.

One hop instead of a chain

The slash rule is usually set up together with the switch to https and the choice between www and non-www. The goal is for any wrong variant to reach the main address in a single step. For example, http://www.site.uz/catalog should go straight to https://site.uz/catalog/, not through three intermediate addresses. A chain slows down both the crawler and the visitor. If you also have an index.php rule, fold it into the same order.

Internal links, canonical and verification

A redirect hides the duplicate but does not fix its cause. If the menu, breadcrumbs and in-text links point to the slashless version, every click takes an extra step. Components usually build addresses on their own, but links typed by hand into articles and banners will need correcting.

The sitemap and canonical tags must use the chosen format as well. If canonical points to the slashless address while the server redirects to the slashed one, the signals contradict each other. After setup, run through this checklist:

• slashless section and product URLs give one 301 to the slashed version;
• there is no chain through http or www;
• an image and a stylesheet open without any redirect;
• a URL with parameters keeps its parameters;
• a crawler finds no internal links that lead to a redirect;
• a test notification from the payment system still reaches the handler.

What to do after launch

For the first few weeks, watch the page reports in Search Console and Webmaster. Some URLs moving to a redirected status is normal. New 404 errors or a sharp rise in excluded pages mean it is time to check whether the rule caught something extra, starting with payment and integration addresses.

If you would rather not dig into server configuration yourself, the markdev team can run a technical audit and set up a consistent URL format as part of SEO optimisation in Uzbekistan. Tell us about your site and we will suggest where to begin.