301 redirect not working: where migration breaks and traffic is lost
During a site migration, addresses change, and the redirect becomes the only bridge between the old and new structure. If it doesn't work, the server returns 404: the page falls out of the index, and the accumulated weight is not transferred to the replacement.
Traffic loss during migration almost always starts not with content, but with a broken redirect chain.
The mechanics are simple: a 301 response leads to the final address in one hop. When a rule points to an intermediate page that redirects further, the chain lengthens and some hops break.
If the server returns a temporary response instead of a permanent one, search engines keep the old address in the index, and copies of the same page live on the site.
Scattered rules are the main source of breaks. Some redirects are defined in the server configuration, some at the application level, some added manually; when merged, they conflict, and sections and addresses with parameters are left without rules.
URL consolidation breaks separately: versions with and without www, different protocols, and trailing slashes must converge to a single canonical form, otherwise duplicates share the weight between them.
There are also silent failures: the server returns a success code on a stub page "nothing found". Search Console reports on the redirect map, chains, and internal links show such places before they eat up positions.
We'll cover how this is closed — from address inventory to a single point of rules and post-launch control.
What correct setup delivers: results in numbers and timelines
A correctly built 301 redirect map delivers a measurable effect right at entry: 98–99% of visits via old addresses land on the target page in the first hop, not on an intermediate response.
The user sees the needed content, not a stub, and doesn't waste seconds on an extra round of requests — for high-traffic sections, this is a noticeable share of retention.
Preserving positions depends on how search engines transfer signals from old addresses to new ones.
If each address returns exactly one permanent response and does not participate in a chain, the index rebuilds predictably: the visibility dip is limited to the first days and returns to previous values within one to three weeks.
With broken links, stub responses, and overlapping rules, the same path stretches over months, and some pages fall out of the index permanently.
Post-migration monitoring closes this risk window. Comparing web server logs with search engine reports shows which addresses still return an error and where a chain of three or more hops has formed.
Errors in redirect chains are caught in the first 24 hours — before the page loses accumulated weight.
A separate effect is the amount of manual work. The redirect map is assembled from an export of addresses and rules at the configuration level, rather than edited one address at a time in an interface.
Adding a new section or changing the catalog structure becomes updating a single file, and manual edits become many times fewer — migration without losses stops being a one-off heroic effort.
Redirect methods: when each mode is appropriate
The response code and configuration level decide different things: the code determines how search redistributes page weight, the level determines whether the rule takes effect before the request reaches the application. A mistake in either parameter results in either dropped positions or extra load on the application.
| Option | When suitable | Limitations |
|---|---|---|
| Permanent redirect (301) | Completed domain or structure migration, duplicate consolidation | Browser and search remember the response; rollback requires cache reset |
| Temporary redirect (302/307) | Tests, seasonal sections, phased migration | Weight remains on the old address |
| Server-side rules | Template cases: scheme, slash, case | Rule order is critical, easy to get a chain or loop |
| Address map at application level | Thousands of unique old → new pairs | Requires application response; without cache, response time grows |
| Redirect at load balancer level | Single entry point, multiple sites | Few conditions, inconvenient to maintain a large address list |
A permanent redirect is used for a completed migration — domain change, duplicate consolidation, new section structure. A temporary one — for tests and phased migration, when the old address must return.
If a temporary response stays up for months, search continues to consider the old page the main one, and the new section does not gain weight.
Server-side rules are cheaper in response time but handle thousands of unique pairs poorly: templates get confused, chains of two or three hops appear.
An address map at the application level is read from a versioned list and edited without a restart, but it requires an application response.
Redirect at the load balancer level is convenient as a single entry point and for emergency switches between sites, but the conditions there are limited — a large address list is not maintained in it.
Migration order: from address inventory to verification
What breaks a migration is not content transfer but addresses: search engines and external links continue to hit old URLs for months after the switch.
Therefore, the redirect scheme is designed before the structure change, not after traffic drops — otherwise some visits go nowhere in the first hours.
- Address audit. We collect a complete map of entries: web server logs for several months, sitemap, indexing reports, external links. It includes addresses with parameters, trailing slashes, and different letter cases — these are the ones most often left without a pair.
- Design the redirect scheme. Each old address gets exactly one target, without chains or intermediate links: several hops in a row consume weight and response time. For pages without an equivalent, we set an honest "gone" code instead of sending them to the homepage.
- Build a test environment. A copy of the structure and rules on a separate staging environment: we run the address map with a script and verify response codes, headers, and final destinations.
- Configure redirects. At the web server or load balancer level, not in page markup — this way the rule takes effect before content is served and does not depend on the engine.
- Coverage check. We compare the list from the audit with actual responses: we calculate the share of addresses returning the correct code and make sure no new chains have appeared.
- Switchover and monitoring. After launch, we track response codes on former addresses and the dynamics of entries through them; we close discrepancies point by point.
- Rollback plan. The rule configuration is versioned alongside the project: if the structure turns out to be a bad choice, returning to the previous scheme takes minutes, without manual edits to the production environment.
Redirect map, logs, and update procedures
After migration, the client's team is left not with a "work completed" report but with a working set of artifacts. Without them, the first platform change or new section turns the address history into a pile of exceptions that no one dares touch.
We hand everything over to the client's repository and document who makes further edits and by what rule.
- Redirect map — a table "old address → target → redirect type → owner", including collapsed chains where several links lead to one page in one hop.
- Migration documentation — what was moved and why, which addresses were intentionally left, which sections were closed, and where their visitors are now directed.
- Address change log — date, author, reason for the edit, and the previous rule: it shows when duplication appeared and exactly what to roll back.
- Update procedure — where new rules are created, in what order they are applied, and how they are checked before publication to production.
- Support guide — scenarios for typical cases: renamed a section, merged a catalog, deleted a page without a replacement.
- Rule configurations — web server files and application-level settings with comments, so an engineer who was not involved in the migration can make the edit.
- Set of checks — a crawl of the address map that catches "page not found" and extra chains before visitors and search robots see them.
All of this sits next to the project, not in a chat thread. A new engineer does not have to reconstruct the redirect logic from indirect signs.
E-commerce migration: traffic and positions before and after
The catalog on 1C-Bitrix lived in a flat structure: 12 thousand addresses, sections at one level, some cards along service filter paths. Search visits brought more than half of orders, so changing the section structure meant the risk of losing visibility and revenue at once.
We built a mapping map for all old addresses: we cross-checked data from search engines, the sitemap, and web server logs, and marked up every product card, section, and blog page.
Without such a map, a catalog migration turns into guesswork, and some pages simply do not find a new address.
How redirects were set up
Based on it, we deployed 301 redirects — strictly one hop each, without "old — intermediate — new" chains: every extra step loses link weight and increases response time.
Service addresses of filters and sorting were closed from indexing, and separate rules were written for pagination pages so search engines would not pick up empty listings.
Everything that could not be matched was given an honest refusal — it is better than a site-wide redirect to the homepage that blurs relevance.
What was the result
In the first week after the switch, the share of search visits dropped by 12% — an expected reaction to the address change.
By the third week, visibility recovered to 95% of the previous level, and after two months — to 104%: the new section structure added coverage due to more precise queries.
404 errors remained at 0.4% of all requests instead of 6% in the first days — they were eliminated with pinpoint rules based on logs.
How does a 301 redirect differ from a temporary redirect?
301 is a permanent move: the search engine replaces the old address with the new one in the index and transfers the accumulated signals to it.
A temporary redirect (302 and 307) says the opposite — the address will return, so the original URL remains the main one, and the new one is ranked as a separate page. Hence the difference: with 301, the page weight moves; with a temporary one, it stays in place.
In practice, the scenario dictates the choice. Duplicate consolidation — with and without a slash, with and without www, old and new template — always via 301: all versions converge to one canonical address, and signals are not smeared between copies.
Temporary mode is appropriate for test landing pages, geo-switches, and maintenance: Google continues to serve impressions to the original address, and after the redirect is removed, nothing needs to be rolled back.
A repeat migration is a separate risk. A 301 → 301 → 301 chain blurs signals: the robot goes through several hops, and part of the weight is lost along the way.
Therefore, on the second move, we set the redirect directly to the final address, and update internal links, the sitemap, and canonical addresses in the same release — so that no chains or loops remain at all.
We check the result by response headers, not by eye: the code, the number of hops, the absence of a loop to itself, and coverage of all old addresses. Then the migration preserves positions and traffic instead of resetting the page history.
Technical doubts: questions about redirects and consolidation
Some objections about redirects repeat from project to project: how long rules live, what to do with a site that has already migrated, how to make sure search engines have seen the new addresses.
The principle is one: a rule is considered working not when it is created, but when the response code and final address are verified. Therefore, we build chain checking and the old-to-new address mapping into the migration plan from the start, not after delivery.
How long should redirect rules be kept?
Indefinitely, not "for the migration period." External links, bookmarks, and documents live for years, and search engines re-crawl old addresses for months — if the rules are removed earlier, traffic will go to an error.
An address with no remaining inbound links can be closed with a 410 code: the page will fall out of search results faster than with endless waiting.
The site has already migrated, but some addresses return an error — what should be done?
First, the source: server response errors on needed addresses usually mean that the rule did not take effect, is overridden by another one, or points to an intermediate address.
Next — re-migrate only the problematic segment: compare the request log with the address map, collapse chains like A→B→C into a direct A→C, and route to the final page.
How can I make sure the new addresses are indexed?
We run the list of old addresses in batches and look at three things: the response code, the final address, and the absence of extra hops between them. Then we compare the result with the sitemap and the crawl report. A 200 response on a stub page or a long chain is a reason to rewrite the rules in that section.
We are changing the structure again — will the rules have to be rewritten?
No. We keep template rules by section, not line by line, so the new catalog structure is covered by changing a few templates. Exceptions are individual pages with old external links: we check them separately.
Let's discuss your migration: what to send for an assessment and plan
To come back with a migration assessment and work plan, the entire project is not needed — source address data is enough.
The more complete the list, the more accurate the setup timeline: from the logs, it is immediately clear which pages collect traffic and which can be closed without risking lost visits.
- Export of current addresses: sitemap, server log for one to two months, address table with request frequency.
- Structure of the new site: a list of sections and addresses, so old and new can be matched one-to-one and no "dangling" pages are left.
- Existing rules: redirects at the web server and reverse proxy level, robots.txt, canonical addresses, pagination settings, and parameters in links.
- Special cases: language versions, closed sections, documents and files, addresses with trailing slashes and uppercase.
- Access: test environment, hosting panel, repository with configuration — we will check response codes and redirect chains before the switch, not after.
- Dates: desired switch window and periods when the production site must not be touched.
In return, we provide a redirect map, a response code report, and a post-switch support procedure. The project handover includes rules by which you or your team can add new addresses independently. Describe the task — we will come back with a scope estimate, plan, and timeline.
