Setting Up 301 Redirects in 1C-Bitrix: Preserving Traffic and Rankings

301 redirect in 1C-Bitrix: where traffic is lost during a migration

Migrating a site to a new domain, changing SEF URLs, or moving a catalog to another branch of the structure is always a break between old addresses and new ones.

A search engine bot arrives via a link from the SERP, gets a 404, and after a few crawls drops the page from the index. If a 301 redirect is not configured, the accumulated positions, link weight, and behavioral signals go away along with the page, and recovery takes months. Let's break down exactly where traffic is lost and how this is closed.

The first scenario is a domain change without a site-wide rule. In 1C-Bitrix, addresses live in three places: address processing rules in the module settings, .htaccess files at the web server level, and the physical directory structure.

If a rule is added in only one layer, some old addresses return 404, while others return 200 with duplicate content. Duplicates dilute weight between copies, and the version that gets fixed in the SERP is not the one you were promoting.

The second scenario is mirror consolidation. When a site is available both with and without www, and over both protocols, the search engine sees four copies of the same content. There should be one canonical address, and all the others should return a 301 to it.

Without this, robots.txt and the sitemap point to different versions, crawling proceeds inconsistently, and pages compete with themselves.

The third scenario is a change in the catalog or section structure. Old product and article addresses remain in other people's bookmarks and external links, while new ones appear only in internal navigation.

What matters here is a mapping table: for each old address, its own target, rather than dumping everything onto the homepage. A mass redirect of "everything to the homepage" is read by the search engine as a soft 404 and resets the page's weight.

Separately, there is migration while preserving parameters. Addresses with UTM tags, filters, and pagination must not be redirected blindly — otherwise filter SERP pages get merged and the long tail is lost.

The rule should trigger on the path without parameters, and the query string should be carried over separately.

Each of these scenarios is diagnosed using web server logs and crawl error reports: you can see which old addresses are still receiving requests and what they return in response. After that, it is a matter of an accurate redirect map and the order in which it is applied.

What correct redirect setup gives you

A correct redirect is not "a redirect for the sake of a redirect," but a way to preserve the accumulated weight of a page when its address changes.

When a rule returns a permanent code instead of a temporary one, the search engine transfers signals from the old URL to the new one: rankings, external links, impression history.

If the code is temporary, the weight stays on the old address, and the new one cannot reach the top for months — traffic drops even though the content has not changed.

The second task is consolidating addresses and fighting duplicates.

The same product is available at an address with and without www, with and without a trailing slash, with filter and sort parameters — for a search engine these are different pages that compete with each other and dilute relevance.

Rules bring all variants to a single canonical address, and one page enters the index instead of five. This directly affects rankings: the weight is not divided among copies but works for a single URL.

The third effect is predictability when the structure changes. Migrating to a new section, changing URL slugs, merging catalogs — all of this breaks old links if a redirect map is not prepared in advance.

When the rules are described and tested before release, visitors and bots land on the current page rather than an error.

External links and bookmarks keep working, behavioral factors do not drop, and indexing is rebuilt smoothly, without sections falling out of the search results.

In practice it looks like this: before the changes we record the current rankings and traffic for key addresses, and afterwards we verify that no URL returns an error and does not lead into a chain of multiple hops.

Chains and loops are a separate class of problems: the browser and the bot go in circles, the page does not open, and the cause is not visible in the interface. That is why the rules are gathered in one place, tested against the full list of addresses, and only then published.

Methods for configuring redirects: comparison of approaches

Redirects in 1C-Bitrix can be implemented at three levels — and the choice of level determines who can edit the rules going forward and how quickly.

Server configuration provides minimal latency in returning a response, but each edit requires access to the configuration and a reload. The Bitrix module stores the redirect map in the database, so rules are added through the admin panel without a deployment.

A mixed approach is when static rules live on the server and frequently changing ones live in the module.

In practice, they are most often combined: the server handles infrastructure redirects, the module handles content ones, and the redirect map is used as a one-time migration tool.

It is important to establish the order of triggering: first the server rules, then the module, otherwise the same address may go through two chains and get a loop. Before deployment, the map is checked for conflicts and cycles — after release, debugging costs more.

If the site has already accumulated rules from different sources, we first collect them into a single map, remove duplicates, and only then distribute them across levels.

Workflow: from URL audit to verification

We structure the work so that no old URL gets lost or turns into a chain of multiple redirects. First, we build the full picture: exporting URLs from logs, the sitemap, search engines, and internal links, then cross-checking them against the new site's structure.

At this stage, it's important to catch URLs with parameters, letter case, and a trailing slash — these are the ones that most often produce duplicates and "soft" errors.

Next, we design the rules: we map each old URL to a new one one-to-one, remove intermediate hops, and separately describe template redirects for sections and pagination. After the redirect map is approved, we move on to implementation and verification.

1. URL audit — we export all old URLs from logs, the sitemap, and external sources, and flag pages with traffic and inbound links.
2. Cross-check against the structure — we match each old URL to a new one, record URLs with no direct equivalent, and decide where to send them.
3. Rule design — we describe the redirect map: one-to-one pairs, templates for sections, and handling of parameters and letter case.
4. Implementation — we set up rules at the server level and in the CMS itself so that the redirect fires before the page is served.
5. Redirect testing — we run through the entire list, checking the response code, the absence of chains and loops, and parameter preservation.
6. Post-launch monitoring — we check indexing and logs, clean up any remaining errors, and adjust rules if needed.
7. Handover — we provide the redirect map and instructions for adding new rules to your team.

Each stage ends with a verifiable result, so what you get at the end is not a set of scattered rules but a manageable map that can be extended without the risk of breaking existing URLs.

What the client receives as a result of the work

The work does not end with the fact that "redirects are configured," but with a set of artifacts by which the system continues to live without us.

Each item below is what remains with your team: it can be handed over to a new contractor, checked during a review, or pulled up when investigating a traffic drop.

• Redirect map — a table of "old address → new address → rule type → source" for all pages taken out of publication, sections, and old addresses after a structure change. It is compiled from visit logs and the sitemap, not "from memory": this way it includes addresses that no one remembers but that are still being reached from search and external links.
• Rule configuration — the rules themselves, laid out by levels: permanent addresses in the server configuration, bulk templates in the redirect module, and individual exceptions — separately. This separation is needed so that editing one page does not affect the others and does not turn into editing the entire file.
• Address handling procedure — the sequence of actions when taking a page out of publication, changing a section's address, merging duplicates, and moving a catalog. With it, a new content manager does not create broken links, because the route "took the page down → added a rule → checked" is described before it is needed.
• Support documentation — where the rules are stored, how to add a new one, how to roll back an erroneous one, and which checks to run after deployment. A separate block covers typical errors: chains of multiple hops, rules pointing to a non-existent address, and conflicts between a template and an exception.
• Verification report — a list of addresses for which response codes were checked, and a list of discovered chains with their resolution. This is proof that the rules work, not just that they are written down.
• Accesses and control points — where to view transition logs, which reports show the error rate, and whom to contact when there is a discrepancy. So that diagnostics do not begin with finding out who last touched the configuration.

Everything listed above is handed over within your environment: the rules, the procedure, and the documentation remain in the project repository and in the knowledge base, not in a chat thread.

Describe the task — we will come back with an estimate and a plan for the order in which to assemble these artifacts for your site structure.

Case: restoring positions after a structure change

The project is an online store on 1С-Битрикс with a catalog of several thousand product items.

When migrating to a new section structure and renaming categories, the URLs of product pages and listings changed, but the redirect map remained from a previous migration: some rules pointed to broken pages, and some pointed to general sections instead of specific products.

Two weeks after release, search engines were already showing a drop in commercial queries, and organic traffic was falling more noticeably than expected.

What we did

First, we took a complete snapshot of the current URLs and matched them against historical ones from server logs and analytics system exports.

For each "old URL → new URL" pair, we determined the target correspondence: a product page leads to a product page, a section leads to a section, not to the homepage.

The rules were collected in one place, checked for conflicts and loops, and chains of two or more redirects were handled separately — they were collapsed into a single step so as not to lose link equity.

Next, we configured the serving of permanent redirects at the server level rather than through scripts — this way the response comes faster and does not depend on application load.

For URLs that had no direct match, we wrote rules preserving the URL structure: the category and filter parameters are carried over to the new URL automatically.

Metrics before and after

Three weeks after the fixes, the bulk of commercial queries returned to their previous positions, and some rose above the original ones: the old URLs no longer competed with the new ones, and link equity stopped dissipating.

Separately, we established a rule for the future: any structure change goes through a redirect map before release, not after.

How a 301 redirect differs from a 302 and when it matters

A 301 redirect is a permanent redirect: the server tells the search engine that the page has moved for good, and all the accumulated weight of the address must be transferred to the new one.

A 302 redirect is temporary: the old address remains the primary one, and the new one is considered intermediate.

The difference lies in a single response code, but it is precisely this code that determines which page ends up in the index and whether it retains its previous traffic.

The mechanics are simple: with a 301, the search engine, over the course of several crawls, locks in the new address as canonical and gradually removes the old one from the search results.

With a 302, the old address retains its status as the primary one, and the new one may not be indexed at all — the system keeps visiting the previous URL, expecting the "temporary" state to end.

If a 302 stays in place for months, it looks like a configuration error: rankings drop because both pages compete with each other, and the weight is not consolidated.

In practice, the choice of code is dictated by the scenario. Migrating to a new domain, changing the catalog structure, merging duplicates with and without www, switching from http to https, combining product cards — these are permanent changes, and here only a 301 will do.

A temporary 302 is appropriate when the address will return: maintenance work, an A/B test of a landing page, a seasonal promotion, restricting access for part of the audience. As soon as the reason is gone, the redirect is removed.

Redirect chains deserve separate mention. When a 301 leads to an address that itself returns a 301, the search engine wastes crawls and may never reach the final page. The correct setup is a single hop straight to the final URL, with no intermediate links.

The same applies to loops: if A redirects to B and B redirects back to A, both pages drop out of the index.

In 1C-Bitrix, codes are set in the address processing rules, in the redirect settings, and through the SEO module — it is important that the code matches the actual intent rather than being assigned "just in case." A mistake in choosing here costs not cosmetics but lost rankings, which take months to recover.

Common technical concerns during setup

Before approving the redirect map, clients usually ask the same questions — about chains, conflicts with modules, and behavior when changing domains. Below are the answers that resolve most concerns before work even begins.

Can rules conflict with modules and components?

Yes, and this is the most common reason for "the redirect is configured but doesn't work." Server-level rules trigger before the module has a chance to process the address, so some hops simply don't reach the application.

We check the processing order and separate the rules so that server-level and internal ones don't overlap. After that, the hops work consistently across all types of addresses.

What happens to redirects when changing domains?

The old domain continues to receive traffic, and it can't simply be disabled — otherwise the hops would break. We configure the rules so that each address of the old domain leads to its corresponding address on the new one, including nested sections and parameters. We separately verify that the hops don't loop and don't lose addresses with non-standard endings.

How can you make sure the setup hasn't broken existing addresses?

Before deployment, we run through the list of key addresses and check the response code for each: where there should be a direct hop — it's there, where the page is live — it's served as before.

If a rule affects a working section, it's visible before publication, not from a traffic drop a week later. We make edits one at a time so that the previous state can always be restored.

Let's discuss your redirect task

Redirects almost never exist in a vacuum: they come up when a catalog structure changes, sections are moved, duplicates are merged after a rebrand, or a migration to a new template happens.

That's why we start the conversation not with pricing, but with your current address map: which URLs are changing, how many there are, whether there's already accumulated redirect history, and what's happening with indexing right now.

To come back with an estimate and a plan rather than generalities, we need a minimum of input. Describe the task in free form — we'll clarify the details ourselves from there.

• Current situation: what's changing — catalog structure, domain, template, a section, or individual pages.
• List of addresses: whether you have an export of old and new URLs, and in what form — a table, server log, sitemap.
• Reason: migration, merging duplicates, changing URL slugs, deleting a section, or recovering from an error.
• Constraints: deadline, downtime window, requirements for preserving rankings and traffic.
• What's already been done: whether you tried configuring rules yourself, what errors you're seeing.
• Access and environment: product edition, hosting, whether there's a test environment for checking chains.
• Definition of done: what counts as a result for you — no broken redirects, preserved rankings, a clean log.

Based on this input, we'll put together a work plan: auditing current addresses, designing the redirect map, configuring rules at the server level and in the control panel, checking chains and response codes, and monitoring indexing after implementation. We provide estimates based on scope — from a pinpoint fix to a full structure migration.

If the situation is urgent and the site is already losing traffic, say so, and we'll work through priorities first. Describe the task, and we'll come back with an estimate and a work plan.