Post-Move Redirects: Match Map instead of lost traffic
Setting up 301-redirects after moving the site is not a line in the server configuration, but a correspondence map: a list of old addresses, in which a specific new one is opposite each one. The amount of work is measured by the lines of this map, not by hours on the server. Then there are the rules in nginx or .htaccess, one transition instead of a chain of two or three, and selective verification of the final address. The last part is more important than the response code: 301 is perfect in code and wrong in address.
old address list, match map, 301 rules, sample check
after a free audit
Price
30
Guarantee
days after project sign-off
old address list, match map, 301 rules, sample check
What are we doing?
5-20
Term
business days, depending on the number of card lines
50
The worst we found
out of 150 checked addresses led to another item
about 37,000 addresses in the catalog for 110,000 items
The scale of the same error
free address counting, 2-4 working days
Before the estimate
traffic growth — redirects keep existing
What we do not promise
What's included
Complete list of work and what you get as a result
A consolidated list of old addresses from the site map, indexing report, server logs and archive snapshots — so that the map is not built on memory, but on the list
Table Match Map: Each old address gets a specific new one, and you see that decision line by line, not take it for granted
Grouping of addresses into templates: thousands of cards of the same type are closed by one rule, so the estimate does not grow linearly with the catalog
Permanent 301s without chains - one transition instead of two or three, so that the visitor does not wait in circles, and the signal is not lost along the way
Post-implementation sampling run with the end address fixed, not just the response code - this is where the "wrong position" transitions are caught
Separate solutions for pages that are not on the new site: analogue, section or honest 410 - with your signature under each item
Removing redundant redirect from bare domain where it is added on every first visit
Protocol and domain matching throughout the chain so that a secure connection is not lost in transit
Updating internal links to new addresses - redirects should serve the outside world, not the site's own menu
The new site map without old addresses and without duplicates, the old one is left available for the transition period
Follow-up of crawl errors in Search Console 30 days after the switch with a written summary
When this service isn't right
What's not included — so there are no surprises at delivery
Moving to a new platform is a separate job and a separate estimate
Restoration of pages that are deliberately not on the new site
Guarantee of preservation of items: the issue is not managed by any contractor
Working with other people's sites that link to your old addresses
Who it's for
Situations where this service delivers results
Scenario 1 of 4
The structure was changed, traffic flowed, redirects were put in haste
Most often, they apply just like this, a week or two after the switch. There are usually rules, but no one has verified that they close the entire old list and lead to the closest analogue in terms of content. We start not with the config, but with the list: how many addresses existed and how many of them now give something meaningful.
We'll review your situation in a free audit
Scenario 2 of 4
The change of structure is yet to come and the addresses are known in advance
The cheapest moment. The compliance map is built before the day of the switch, rules are enabled with the new structure, and there is no drop-off between states at all. This is where the most unpleasant question is resolved — where to put the addresses of the sections that will not be in the new structure.
Scenario 3 of 4
Redirects have been around for a long time, but no one checked them with the final address
Code 200 in the report does not prove anything, because it is given by the page where the address eventually came. In the underwear directory, we sampled 150 addresses: a third gave a transition, and none of them led to the same position. Such things are not visible either from the admin panel or from the hosting panel.
Scenario 4 of 4
Merge two sites or remove entire sections
Directory merging gives the longest map: two old addresses often claim one new one, and the decision here is made by the business, not the server. Removed sections are a separate line of work: the address must either be compared with the closest analogue, or deliberately give 410 and not pretend that the page is alive.
Free count of addresses that need to be redirected
The main number in this work is one: how many old addresses exist and how many of them should lead somewhere. It is visible from the outside - from the site map and archival traces - and this is exactly what we calculate for free before naming the amount.
What we measure
Volume of old addressesHow many unique addresses are there in the current sitemap and how many of them are really needed. This is the number of lines of the future correspondence map.
How many of them are closed with a templateCards of the same type are folded into one rule, the rest remains manual work. The relationship between these two parts determines the term.
Current chainsWhat is already being redirected and after how many steps. Chains of two or three transitions are a typical legacy of previous migrations.
Redirects that lead to the wrong placeThe most dangerous type: the code is correct, the address is someone else's. We found a catalog where a third of the verified addresses led to another product.
Redirect at the entranceWhat happens on a bare domain: switching to a language branch, to www or from www, protocol change. Each such step is added to each first visit.
Protocol inside the chainIs the secure connection lost at some step - this happens and breaks the trust of the browser silently.
Sources of old addressesSitemap, indexing report, logs, external links. Forgotten addresses often bring the most consistent traffic.
What you get
Number: How many addresses will have to be redirected, broken down by page type.
Estimation of the part that is closed by template rules and the part that will have to be disassembled by hand.
List of found chains and false transitions in the current state.
A compliance map template that you can continue to work with — even without us.
Conversation for 30-40 minutes on the document.
Timeline: 2-4 working days
Why is it free
Because this is the same number from which the estimate is calculated. Calling the plug to the count would mean overestimating the stock - it's not profitable for us as much as it is for you.
What's next
After the calculation, we name the cost and term by stages. Fair warning: redirects at best keep what is there; growth is another job and another budget.
Short form: your contact and site URL
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
The number of rows in the correspondence mapPrime factor. Not the number of pages of the new site, but the number of old addresses that once existed: in the catalog of 8.6 thousand cards there are 8,690 of them, in the lingerie catalog of the same size/color — more than one hundred thousand. The difference here is measured in weeks.
The proportion of addresses that match the patternCards of the same type are collapsed into a single regular expression rule, and a thousand addresses cost the same as ten. The remainder is expensive: merged categories, renamed sections, unmatched products. It is he who sets the upper limit.
Is the old site available?A live old site gives a list of addresses per day. Disabled - the list has to be restored from the indexing report, logs and archive: it is longer, incomplete, and part of the addresses has to be written off consciously.
Language branchesEach language multiplies the list and adds a separate check: does the old Ukrainian address lead to the new Ukrainian one. We have seen site maps where only one of the two announced branches is present - after moving, such a skew is fixed.
Status of current redirectsA clean server is cheaper than a legacy server. Chains and old rules must first be untangled, otherwise new ones will lie on top of them and give a third step instead of the first.
Access to the serverWe implement it - sooner for a few days. Implemented by your team - we give ready-made rules and check the result, but the calendar then depends on someone else's task queue.
Cases
Tasks and results in numbers — all metrics measured by us
online retail underwear store with a catalog of more than 110,000 product items
Task
Understand where the search buyer is actually coming from when the old card address gives the transfer.
Solution
A random sample of 150 product addresses of the site map: for each, the response code and the final page were recorded, then the size and color in the final card were compared with those sewn into the old address.
Result
50 addresses out of 150 gave a permanent transition, and all 50 led to a different position: 70B to 70A, 75G to 65S, L to XL, white to black. On the scale of the catalog, this is about 37,000 addresses where the buyer receives the wrong size — that is, exactly the problem for which the store was built. Nearby, 3,774 duplicate entries were found in the product subcards, individual addresses are repeated up to 55 times. Measurement 01.08.2026.
online store of professional tools, catalog of over 6,000 items
Task
Check the chain of transitions on the entrance - from the bare domain, not from the internal page.
Solution
Running from the bare domain to the final address with protocol and code fixation at each step; separately — a site map walkthrough with a count of unique addresses and repetitions.
Result
The certificate is valid, but the protected root gives a transition to an unprotected language version: whoever dials the domain without a path ends up on an unencrypted connection. Internal addresses via HTTPS work normally, it is the language transition from the root that is broken. Nearby are 25,537 sitemap entries for 6,857 unique addresses: one map on average 3.9 times under different category paths, and such repetitions are collapsed into one rule instead of thousands of lines. Measured on 07/31/2026.
official online store of garden tools, catalog of about 8,600 cards
Task
Calculate how much it costs for each first visit to move from the root to the language branch.
Solution
Measurement of the first response at the root, taking into account the transition and without it; comparison of the language composition of the site map with what is declared in the markup.
Result
Main gives the transition to the language branch, and this step sits within 789.4ms to the first byte and 914.7ms to the full document. At the same time, only one language branch out of the two announced was included in the site map: 8,690 unique addresses with 33,493 entries. Measured on 07/31/2026.
Did not find your case?
Describe how it works on your side — we will tell you whether “Redirects after moving the site” fits and what it means in your situation. No brief and no call: one question, one answer.
Process steps
Transparent stages with approval at every step
Total duration:5–20 days
1
Collection of the list of old addresses
1-3 working days
Sitemap, indexing report, server logs, archive snapshots, external links. The sources are compiled into one list with deduplication — it is he, and not the structure of the new site, that determines the scope of the rest of the work.
2
Correspondence map
3-10 working days
Addresses are grouped into templates, a rule is written under each template, and the rest is analyzed piece by piece. There is a separate list of things for which there is no analogue: these lines come back to you for a decision, because it is a business decision.
3
Rules on the server
1-3 working days
301 in nginx or .htaccess first on a test loop. We check that the broad rulebook did not touch too much, and that no new rule became a second step on top of the old one.
4
Run and check the end addresses
1-3 working days
We run through the list and look not at the response code, but at the page where the address actually came. We check the selection for each template with our eyes: in catalogs with sizes and colors, this is where the transition to the next position appears.
5
Internal links and sitemaps
1-2 working days
Menus, links and filters are transferred to new addresses so that the site does not go through its own redirects. A new site map is generated without the old addresses, the old one remains available for transition.
6
30 days of observation
30 calendar days after launch
Scanning errors, rate of indexing of new addresses, complaints about missing pages. The indexing report shows the status with a delay of several days, so we draw conclusions not the next morning after the switch, but after a month.
Technologies & integrations
What we build on and what it connects to
Stack
301 in nginx or .htaccess: permanent redirect. The server does not know the content of the page, so the broad rule catches the extra.
Regular expressions on template groups: one line instead of thousands. What does not fit into the template remains a manual work.
Map of compliance with the table. The machine only compiles matches by article or tag, a person closes the disputed ones.
Screaming Frog to run the list. Sees only what is in the sitemap or in the links.
Search Console, indexing report: the actual listing in the index. The data comes with a delay of several days.
Wayback Machine when the old site no longer exists. The archive is incomplete and moved to popular pages.
Server logs show addresses that are actually being used. They live for weeks - you need to pick them up before they turn off.
Integrations
Google Search Console
Bing Webmaster Tools
GA4
Cloudflare
Match map against one general rule
How this option differs from the alternative
The general rule "everything old - to the main or to the section"Our approach
Where does the buyer come from the old addressto the storefront, from where he is looking for the product again or leavingto the closest analogue in terms of content, and only in its absence - to the section
How does a search engine read such a transitionoften as a soft error, after which the page is dropped from the indexas page replacement: signals are moved to a new address
How much does it cost?half an hour of work — and months of analyzing the consequencesby card lines: templates are cheap, manual balance is expensive
What can be seen in a montha drop in traffic without explaining where exactly it came froma report on scanning errors and a list of addresses that were left without an answer
What we need from you
We can't start without this — best to prepare in advance
1Access to the old site or at least to its site map - you need to get a list of addresses from somewhere.
2Access to the server of the new site, or a person from your side who will implement ready-made rules.
3Access to Search Console: without it, no one, including us, can see the actual list of addresses in the index.
4Logs of the server of the old site, if it is still working: there you can see the addresses that are actually used.
5Decisions about pages that will not be on the new site: analogue, section or honest rejection.
6The observation window is calculated from the date when the structure changed or will change.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
Why can't everything be redirected to main?
For the visitor, this is the same as an error: he was looking for a specific product, but ended up in a shop window. The search engine also reads such a transition not as a page replacement, but as a soft error, and the page disappears from the index. There is one rule: each old address leads to the closest analogue in terms of content, and only if there is no analogue - to a section at a higher level. Mass switching to the main one saves half a day of work and costs months of analysis.
301 or 302, and when is 302 appropriate?
After moving - 301, because the address has changed forever. 302 tells the search engine to keep the old address in the index and wait for a return, and when the structure changes, it directly hurts. It is appropriate for truly temporary things: a technical page for the duration of work, a regional plug, a test. Practical advice is not to put 302 "for now, then we will change". Such rules live for years, and no one mentions them until they start looking for the cause of subsidence.
How dangerous are chains of two or three transitions?
Each extra link is a delay for the visitor and the loss of part of the signal along the way. You can calculate it: in the garden tool store, the transition from the root to the language branch sits within 789.4 ms to the first byte - and this step gets every first visit. In addition, chains are often interrupted in the middle: the second step leads to an address that no longer exists, and instead of a transition, the visitor sees an error.
How do you check that a redirect goes where it should?
By running the list with a fixation of the final address, and not the response code. Code 301 means only that there is a transition; where exactly - you can't see from it. In the underwear catalog, on a sample of 150 addresses, 50 gave a transition, and all 50 led to another position: another size or color. On the scale of that catalog, this is about 37,000 addresses where the buyer received the wrong product from the search. Therefore, a person looks at the sample for each template.
Can a compliance card be collected automatically?
Partly, and this is exactly the part that makes the work uplifting. Matches by article number, tag or product identifier are automatically compiled, and groups of the same type are collapsed into one rule with a regular expression. The rest does not add up: merged categories, renamed sections, products that are no longer in the assortment. It is disassembled by hand, and in a large catalog, this residue eats up most of the time.
How long to keep the rules?
At least a year, for a large catalog - longer. Some external links and bookmarks live for years, and each such transition is a visitor who would otherwise see an error. Removing a rule makes sense only when there have been no requests for it for a long time, and this can be seen from the server logs. Separately: the domain of the old site must also remain extended, otherwise the transitions disappear along with it, no matter how many of them are in the config.
And if the old site no longer exists?
We restore the list from what is left: the indexing report in Search Console, archived snapshots, server logs, if they were collected. This is how it works, but with two limitations that you should know before starting. The archive is shifted towards the popular pages - the long tail of the catalog is incomplete in it. And Search Console shows what's in the index, not what once existed. Part of the addresses has to be written down deliberately, and we name this part before starting the work.
Will the traffic resume after that?
Redirects remove technical loss, not create demand. They return a visitor who has already clicked on your old link and give the search engine a reason to redirect signals to the new address - that's all. If the structure was changed a month ago and the traffic has declined, some of this decline is recoverable, some is not. One more thing you should know in advance: after cleaning duplicates, the number of pages in the index drops for a while. This is an expected course, not a deterioration.
Send the site address and tell me when the structure changed.
In response, how many old addresses will have to be redirected, how many of them are already leading through the chain or not, and the plan by stages. If the address structure has not changed, we will say so in the first email and we will not accept the job.
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.