Setting Up HTTPS Redirects in 1C-Bitrix: A Guide

HTTP to HTTPS redirect in Bitrix: where the chain breaks

The site opens both at the regular and the secure address, and both serve real content.

Some sections have already been moved to the secure protocol, while some remain on the regular one — this is how duplicate site addresses appear: the search engine sees two pages with identical content and splits weight between them.

The browser warning about an insecure connection here is not a random failure, but a sign that the switching rule is not configured everywhere.

The break is almost always in one thing: the http https redirect in Bitrix is specified at one entry point, although there are several points.

The rule may reside in the web server configuration, in the site settings, or in both places at once — then the redirect chain breaks: the browser receives two or three hops in a row, loses addresses, or loops.

A separate cause is mixed content on the page: the document itself is served over the secure protocol, while images, scripts, and forms are loaded over the regular one.

The browser marks such a connection as insecure and partially blocks loading — forms are not submitted, images are not displayed.

Reports diverge as well: the same page arrives in analytics under two addresses, and sources and goals are counted across different data sets.

We'll look at how this is closed: where to build a single chain of hops, how to remove mixed content, and how to bring all addresses to one variant.

What a unified secure redirect scheme provides

A unified secure redirect scheme reduces the site to a single canonical address.

Search engines stop seeing duplicates: the main mirror and secondary ones are merged, page weight is not scattered between variants with HTTP and HTTPS, with and without www, with and without a trailing slash.

One address remains in the search results, so positions are not split between copies, and external links work for one version of the site.

For the visitor, this means no browser warnings about an insecure connection — trust in the site is formed before the first click on the menu.

The browser does not block forms, scripts, and external widgets, form submission goes through on the first try, and data is not lost along the way.

Form integrity matters from the other side as well: if a visitor opens the secure version of a page, but the form submits to the old address, some requests disappear unnoticed.

Analytics reports match. When the redirect does not break the chain from the source tag, end-to-end analytics sees one entry per visit, not two or three, and channels are not duplicated in reports.

Otherwise, part of the traffic is attributed to direct entry, and decisions about channels are made on distorted data.

A separate effect is the eliminated class of failures on transitions between page versions: redirect chains are reduced to a single hop, and loops and "jumps" between addresses no longer remain.

In 1C-Bitrix, such rules are described declaratively and applied at the site configuration level, so new sections and subdomains inherit the scheme without manual editing for each one.

Redirect configuration options: comparison of approaches

A forwarding rule lives on four levels — from the external perimeter to settings inside the platform.

The choice affects behavior during web server configuration updates, operation behind a reverse proxy, and on a multisite: the same rule behaves differently in different layers, up to and including a loop.

A separate trap is determining the original scheme.

If a request arrived over HTTPS at the proxy, but reached the site over HTTP and the header with the original scheme is lost, the platform considers the connection insecure and builds absolute links over HTTP — we get mixed content and a redirect loop. Therefore the rule itself and scheme recognition are configured consistently.

In practice, the layers are combined: a strict rule is placed on the external node, and inside the platform the secure scheme is confirmed — the redirect does not depend on which server received the request.

Implementation order: from inventory to handover

We work sequentially: first we record the current state, then design the rules, and only then touch the production environment. This order eliminates the classic mistake when a redirect is set "by eye" and results in redirect chains or pages dropped from the index.

1. Inventory of addresses and subdomains. We collect a map from site settings, server configuration, and statistics: which domains, mirrors, and old addresses actually respond, which already serve content, and which should lead to the canonical variant.
2. Redirect scheme. We define the single primary address and the rule for redirecting to it from all others — with exceptions for service sections, forms, payment, and data exchange, where a redirect breaks operation.
3. Configuration on a copy. We transfer the rules to a test environment and edit the server configuration, not just the site settings — otherwise some addresses remain on the old variant.
4. Verification on a site copy. We run through the address map and check response codes, chain length, loops, slashes, case, and mixed content. It is cheaper to find an error here than on live traffic.
5. Transfer to production. We enable the rules in stages, starting with subdomains and secondary mirrors, and keep a ready rollback: restoring the previous configuration takes minutes.
6. Post-release monitoring. For the first days, we monitor response codes, error growth, and crawling by search bots. We record the rules in the configuration so that a core update does not remove them.
7. Handover. We provide the address map, redirect scheme, and rollback procedure — so support can add a new subdomain without re-analyzing the logic from scratch.

This way, the HTTP to HTTPS redirect in Bitrix stops being a one-time edit and becomes a managed rule with a clear area of responsibility.

Redirect map, configurations, and regulations

After the work is completed, the settings do not remain "in the contractor's head." Everything related to redirects is recorded in documents that can be read without access to the server and control panel.

The set is assembled for the specific site configuration, not as a generic cheat sheet from the internet.

• Redirect map — a table "old address → new address → response type → rule source": you can see where each rule came from and which addresses it covers.
• Set of rules and exceptions — request processing order: first exact matches, then templates, then the general transfer to the secure protocol; a separate block lists what we do not touch.
• Site configurations — working files and module settings with line-by-line explanations of which directive is responsible for what and what happens if it is removed.
• Exception bypass scheme — the chain of checks for an incoming request: at which step the rule takes effect, and where it may not apply.
• Verification regulation — a set of control addresses and the frequency of runs: after a release, after a migration, when connecting a new domain or section.
• Instructions for the content manager — what to do when publishing a page or changing an address, so as not to create a duplicate or break an existing redirect.
• Change log — who, when, and why changed the rules: when investigating unexpected behavior, you can see after which change it began.

The instructions for the content manager are written briefly and step by step: address check, task creation, expected result. This way, edits stop depending on one person and do not require contacting the developer every time.

Case study: removed duplicate addresses and mixed content

Before

The catalog on 1C-Bitrix responded at several addresses at once — secure and insecure, with and without www. About 4,800 addresses had accumulated in search, every fifth was a duplicate, and some sections served an insecure address. The browser showed a warning, and the visitor left before they could see the product.

What we did

We brought everything to a single canonical address: permanent redirects from all other variants, strict security headers, a rebuilt sitemap. Internal links in templates were replaced with secure ones, and canonical was brought to a unified form. We separately went through the forms — during a redirect, a request must not be lost.

What changed

Two months later, about 3,100 addresses remained in search: duplicates were gone, and page weight converged on one mirror. There are no more mixed content warnings, redirects work without chains — transitions from old addresses were preserved, so positions did not drop.

Form submissions became more stable: submissions that failed to arrive due to an insecure connection failure were eliminated, and the total number of requests grew by about one fifth. Analytics goals were configured so that an event is not counted twice in the redirect chain.

How does a server-side redirect differ from a site setting?

A request does not reach the platform immediately. First, it is received by the web server: if the redirect is described in its configuration, the response with code 301 goes to the client before the site core loads and routing occurs. This is the upper processing level — the shortest path and minimal load on the application.

A redirect set inside the site works differently: the request goes through the full application startup — core initialization, address parsing, module settings check — and only then is the redirect header formed.

Extra steps in the chain cost time on every request, and under load they increase the load on the application server.

The priority of rules is set by processing order. If the redirect has already been issued at the server level, the rule in the site settings will not take effect — the request will not reach it.

This leads to a typical settings conflict: two rules for one address, different response codes (301 and 302), sometimes a looped chain of redirects.

The conclusion is a single entry point. The transfer from HTTP to HTTPS is described at the web server level, and inside the platform only what requires application logic remains: multisite, regions, language versions. Then the same address is processed predictably, regardless of the page or section being opened.

This is verified by response headers and logs: how many hops are in the chain, what code each has, and who returned the response — the server or the platform. The goal is one hop without intermediate addresses and with the path preserved.

Common technical questions about redirect configuration

Before putting redirects into operation, engineers resolve the doubts that most often come up during acceptance: will search results drop, what to do with subdomains and sections, will form submissions be lost, and how to make sure the transition is fully completed. Below are brief answers to each.

What happens if redirects are configured partially?

The rule must cover the address with and without the prefix, with and without the trailing slash, as well as nested sections. Partial configuration produces duplicate pages and chains of two or three hops: response time grows, and the weight of inbound links is lost.

We take an address map with current response codes and close each group with a separate server-level rule.

Will forms and calls to external services break?

Things that are hard-bound to the old protocol break: form handlers, account scripts, request addresses to external systems, old integrations. Before switching, we verify these addresses and change them to secure ones, otherwise requests go nowhere. Afterward — test submissions and review of the server request log.

Do subdomains, sections, and the mobile version also need rules?

A redirect on the main domain does not affect subdomains: without their own rules, part of the site remains on an insecure protocol. For individual sections, the rule is set at the catalog level.

We check the mobile version and old addresses separately so that from any entry point the user lands on one address.

Let's discuss the task and come back with an estimate and plan

To keep the review on point rather than based on guesses, a few inputs are enough at the start.

The more precisely the current environment is described, the fewer iterations will be needed for approval: the estimate and work plan are assembled from the actual configuration, not from general words.

What to send to start:

• a list of domains and subdomains indicating the main one — the unified forwarding scheme is built from it;
• current forwarding rules: web server configuration, rules in the site root, module settings;
• a diagram of sections and addresses, including the catalog, forms, and pages with parameters in the address bar;
• a description of integrations: external services, payment acceptance, exchanges, personal accounts — everything that may fail when the protocol changes;
• access to the administration panel, server, and domain records;
• certificate details: whether it is current or being renewed and who is responsible for issuance.

Then we work as follows: we analyze the configuration, mark addresses that produce duplicates or long forwarding chains, and provide a staged plan with responsible parties.

The team includes a web server engineer, a developer on the site management system side, and a specialist who checks addresses and search results after implementation.

We state timelines by stages: rule preparation, transfer to the secure protocol, verification of old addresses and search results.

Describe the task and send this data — we will come back with an estimate and work plan.