Redirect Planning: Carrying Rankings Through a Relaunch

A relaunch changes the design, the technology and the structure of an online shop - and when the structure moves, the URLs move with it. That is where it is decided whether the visibility built up over years survives the switch. If an old URL is left without a target, search engines, existing links and bookmarks run into nothing: in one documented case a manufacturer lost 42 percent of its organic traffic within twelve days, and up to 31 percent of organic search visits were missing in launch week (Practical Ecommerce 2013). A sound redirect plan is therefore not a technical afterthought at the end of the project but the building block that protects the existing base. This article shows how a reliable redirect matrix comes about, which status codes serve which purpose, how to test before launch and how to tell after go-live whether the move held.

Why a relaunch puts visibility at risk

Search engines do not rate pages in the abstract, they rate specific addresses. Ranking history, external links, internal signals and index coverage all hang on one particular URL. If a relaunch changes the address structure - for example because /category/womens-shoes/ becomes /women/shoes/ - then the rated address no longer exists. Without a permanent redirect every request lands on an error page and the accumulated signals do not travel along. That is exactly why the redirect plan is the part of a website relaunch that determines what happens to your stock of organic visibility.

The stakes are considerable. German online retail turned over around 83 billion euros gross in goods in 2025 (bevh), the online share of retail in the narrower sense came to 13.5 percent net (HDE) - the two surveys use different definitions and cannot be offset against one another - and 70 percent of people aged 16 to 74 in Germany bought goods or services online in the preceding three months in 2025 (Federal Statistical Office). Anyone who drops out of the result pages for a few weeks in that environment loses more than sessions; they lose revenue in exactly the phase in which the investment in the relaunch is supposed to start paying off. The damage is not symmetrical either: visibility collapses within days, but it only returns over weeks and months.

How severe the drop turns out to be depends less on the new design than on the care taken over the change of addresses. In one documented case a manufacturer skipped the redirect plan for lack of resources and lost 42 percent of organic traffic within twelve days; in launch week up to 31 percent of organic search visits were missing (Practical Ecommerce 2013). Where the highest-traffic addresses were carried over unchanged, by contrast, traffic showed no discernible drop year over year (Practical Ecommerce 2013). Such figures are not laws of nature but the consequence of missing preparation - and therefore avoidable.

Everything that hangs on a single URL

Before an address is replaced, it is worth looking at what depends on it. The list is longer than it usually appears in the project plan - and it explains why the damage from a missing redirect plan reaches far beyond the search engine:

• Ranking history: The rating of a page builds up over months. It is tied to the address and only travels along if a permanent redirect establishes the connection between old and new (Google Search Central).
• External links: References from specialist articles, directories, forums and partner sites can rarely be corrected after the fact. Every dead target devalues a link you spent years earning.
• Existing links in emails and documents: Order confirmations, newsletters, invoices and PDF catalogues point to individual product pages for a long time. How to keep that chain intact is covered in the article on the order confirmation as a revenue channel.
• Internal linking: Menus, related-content blocks and in-text links point to old targets after the move. They belong directly on the new address rather than running through a redirect permanently - background in the article on internal linking in the shop.
• Campaigns and data feeds: Ads, price portals, marketplace exports and QR codes on printed material carry old addresses onwards, often for several years.
• Images and downloads: Media addresses are indexed too. If the directory moves, results disappear from image search and embedded images on third-party sites break.

The redirect matrix: one decision per URL

The heart of a redirect plan is a plain table. For every address in the existing inventory it holds exactly one decision - no note saying "we will sort that out at go-live", no empty cells. A matrix with five columns has proven itself: old address, page type, decision, status code and new target. Add two metrics per row - sessions over the past twelve months and the number of referring domains - and the table doubles as a priority list.

The last row is the uncomfortable one. There are pieces of content for which no sensible target exists: expired campaigns, discontinued ranges, outdated notices. The reflex to send them all to the homepage does more harm than good. Google explicitly advises against redirecting all old addresses collectively to the homepage; such redirects may be treated as soft error pages (Google Search Central). An honest status code 410 is the better signal in these cases - it states clearly that the content is gone and ends the search engine's follow-up faster than a permanently recurring 404.

The sequence matters just as much. The matrix is created while the new structure is being built, not afterwards. If you only learn the old address list once the new menu is in place, you build targets that simply do not exist for part of the inventory - and then have to improvise under time pressure. Conversely, the matrix provides valuable input for the new information architecture: if a whole group of old addresses has no target, the new structure may be missing a level.

Taking stock: where the complete URL list comes from

A matrix is only as good as the list it rests on. A single crawl rarely suffices: it finds what is internally linked, but not the orphaned pages that still have links or visits. The list only becomes reliable when it is drawn from several sources - merged, deduplicated and normalised, including upper and lower case, trailing slash and parameter order.

1. Crawl of the existing site: A complete pass over the old website supplies the base set including status codes, titles and redirects that already exist.
2. Server log files: They show which addresses are actually being requested - including those linked nowhere. A window of twelve months also captures seasonal pages.
3. Sitemaps and feeds: XML sitemaps, product data feeds and marketplace exports contain addresses that may be missing from the crawl, for example delisted items.
4. Search engine index coverage: The index coverage reports show which addresses were included and which are excluded for what reason.
5. Traffic data: An analytics tool supplies sessions and revenue per landing page - the basis for any prioritisation.
6. External links: The list of referring domains shows which old addresses carry third-party links. Those rows deserve particular care because they cannot be replaced.
7. Print and offline: Catalogues, packaging, vehicle lettering and QR codes carry addresses that can no longer be changed afterwards.

Choosing status codes correctly: 301, 308, 302 and 410

For moving an address there is a clear recommendation: server-side, permanent redirects with status code 301 or 308 (Google Search Central). Permanent means the old address is not coming back - which is exactly the case in a relaunch. Temporary codes signal the opposite and keep the old address in the index, which drags out the move and can lead to duplicate entries.

The redirect belongs on the server, not in the page. A redirect via JavaScript or meta refresh is often understood, but it is slower, more error-prone and not what search engines prefer to rely on. Server-side rules take effect before the first byte of content and apply equally to every request - including requests that do not execute JavaScript.

# Individual mappings taken from the redirect matrix
map $request_uri $redirect_target {
    default "";
    /category/womens-shoes/ /women/shoes/;
    /product/sku-4821/ /p/sneaker-luna-4821/;
    /campaign/summer-2024/ /sale/summer/;
}

server {
    # Permanent redirect, one hop without an intermediate stop
    if ($redirect_target != "") {
        return 301 $redirect_target;
    }

    # Content removed on purpose, no replacement
    location = /service/faq.html {
        return 410;
    }
}

With very large mapping lists, a maintained file of key-target pairs is easier to maintain than hundreds of individual rules, and it can be generated straight from the matrix. What matters is that the list stays versioned and traceable: anyone who no longer knows after two years why a line exists will eventually remove it by accident. A short comment per block - origin, date, reason - costs little and saves discussions later.

The most common mistakes in a redirect plan

The failure patterns repeat across projects. Six of them typically cause the bulk of the damage - and all six can be dealt with before go-live:

• Blanket redirect to the homepage: Convenient to implement but wrong in substance. Google explicitly advises against it (Google Search Central), because the target page does not meet the expectation set by the old address and visitors are left without orientation.
• Redirect chains: Old points to an interim state, interim state points to new. Every additional hop costs load time and crawl effort; chains should be resolved so that the old address points directly to the final target (Google Search Central).
• Temporary instead of permanent: A 302 tells the search engine the old address remains valid. In a relaunch that is the wrong statement and it delays the adoption of the new addresses (Google Search Central).
• Protocol, host and trailing slash forgotten: Rules for the variant with and without www, for http and https as well as with and without a trailing slash are frequently missing. Four variants per address are quickly overlooked.
• Parameters stripped: Filter, sorting and campaign parameters get lost during the redirect, which means campaigns can no longer be attributed later. How to keep filter addresses under control is covered in the article on faceted navigation.
• Internal links not updated: The redirect works, but every internal click takes a detour. Menu, related-content blocks and body text belong on the new addresses, otherwise the detour stays in the system permanently.

Before go-live: test the plan in full

A redirect plan that runs for the first time on launch day is a promise without cover. Testing belongs on the staging environment, with the same server configuration as later in production. It runs automatically, because a spot check typically misses exactly the rows that cause trouble later.

1. Deploy the rules and run through the complete address list automatically - all rows, not just the prominent ones.
2. Check status codes: Expected are 301 or 410. Every 302, every 404 and every direct 200 response on an old address is a finding.
3. Track down chains: The first hop has to reach the final target. Interim stops are resolved before they go into service.
4. Review the target content: A technically correct 301 to an unsuitable page is not a solved case. Samples per page type show whether the mapping holds up in substance.
5. Test the special cases: Addresses with umlauts and special characters, with parameters, in upper case, and with and without a trailing slash.
6. Check behaviour under load: Large mapping lists cost processing time, and launch day brings additional crawl pressure. How a shop behaves under load is covered in the article on load testing and the emergency plan.

The check does not end at the status code. A move is only complete when the sitemap, canonical references and language annotations also point to the new addresses. Old sitemaps can be kept available for a transitional period so that the search engine requests the old addresses once more and reliably finds the redirects (Google Search Central). Very large moves can also be carried out in sections - one area first, then the next - which makes causes far easier to isolate when something goes wrong.

After launch: measure, follow up, leave in place

After go-live the phase begins in which the plan proves itself. Search engines need time to request every old address again and process the redirect; with large inventories that stretches over weeks. All the more reason for a fixed measurement rhythm instead of daily nervousness - and for the willingness to add missing rows as soon as they surface.

• Watch error pages: The 404 report from the server and the search engine shows which addresses were missing from the matrix. Every row gets added, not clicked away.
• Follow index coverage: Old addresses gradually disappear from the index, new ones are added. If both curves diverge over several weeks, that is a warning sign.
• Compare rankings and sessions: It makes sense to compare weeks two to eight after launch against the same period of the previous year. Fluctuations of a few percentage points are normal, a marked and sustained decline is not.
• Verify load time: A new front end changes load time - and with it one of the factors that affect visibility and conversion.
• Update external links: For the most important referring sites a short message with the new address is worthwhile. It does not replace a redirect, but it permanently shortens the detour.

And then one thing matters above all: leave them in place. After a move, redirects should remain active for at least a year (Google Search Central). In practice there is little reason not to keep them permanently - as long as they are documented and form no chains, they cost hardly any processing time. Anyone who tidies up after three months loses precisely those links that are rarely requested but keep working in the rankings for years.

Special cases a plan has to account for

Not every relaunch is a pure change of structure within the same domain. Four constellations deserve their own line in the plan because they require additional steps or different rules:

Anchoring the redirect plan early in the project

A redirect plan is not a task for the final project week. It is created alongside the new information architecture, reconciled with it and tested before content is migrated. The effort involved is manageable - measured against what a decline of 42 percent (Practical Ecommerce 2013) costs in revenue over several months, it is the cheapest building block of the entire project.

Whether it is a change of structure, a change of system or a domain move: what counts is that every address in the inventory carries a documented decision and that this decision was tested before it went live. If you are planning a relaunch, let us talk about the address structure early as your Shopware agency - long before the first template exists. How such a project runs with us is shown in the project process.