To visitors a relaunch looks like a new design. Technically it is a move: content is given new addresses, old addresses disappear — and with them the references that have pointed at them for years. Plan the redirects only after launch day and the problem typically surfaces four to eight weeks later in the traffic figures, at a point where the cause is hard to reconstruct. This article walks through the sequence that carries visibility across a switch: a full inventory of addresses, a careful mapping from old to new, the right status codes, resolving redirect chains, updating internal links, sitemap and canonicals — and a round of checks that does not stop on launch day.
What a relaunch actually puts at risk
The web forgets faster than most project plans assume. A Pew Research Center study on the durability of online content found that 38 percent (Pew Research Center) of the pages that were reachable in 2013 could no longer be retrieved ten years later. Among news pages, 23 percent (Pew Research Center) of those examined contained at least one link that led nowhere; on the pages of public bodies the figure was 21 percent (Pew Research Center). Most of that loss is not caused by servers being switched off. It is caused by moves without redirects: the content still exists, only under a different address — and nobody recorded the way there. For a company that is expensive twice over. It loses the positions an address has earned in search results over the years, and at the same time it loses the references from other websites that point precisely at that address. Neither can be replaced quickly by spending more budget. Both are largely preserved when every old address is given a meaningful new target during the move.
A single address carries more weight than a relaunch plan usually accounts for. There are the references from trade articles, association pages, chamber directories and partner listings that nobody will ever update. There are bookmarks held by existing customers, links in email signatures and in quotation and invoice templates. There are QR codes on vehicle livery, window graphics, flyers and price lists — printed material cannot be corrected after the fact, so a working redirect is the only repair route available. On top of that come the internal references of the site itself, the entries in the sitemap, the canonical annotations, the addresses inside structured data and the connections between language versions. 78 percent (Eurostat) of EU enterprises with ten or more employees run their own website, and for a substantial share of them it is the most important channel for enquiries. A switch without a redirect plan therefore affects more than search visibility; it affects reachability as a whole. How a website project runs from structure to publication is set out step by step in how a website project works.
The classic mistake: everything to the home page
Inventory: which addresses exist in the first place?
The first task has nothing to do with the new design. It consists of producing a complete list of every address the existing website serves today or has served in past years. Complete means more than the pages sitting in the navigation. Sites that have grown over time carry a sediment of campaign landing pages, expired promotions, PDF data sheets, print views and parameterised addresses that stopped being linked internally long ago but are still being requested from outside. Those are exactly the addresses that slip through first during a relaunch, because they appear in no menu. A single source is not enough; only the combination of several sources produces a reliable picture. Which building blocks a website project involves and what work goes into them is set out in the services in detail.
- The sitemap of the existing website — it describes the intended state, rarely the actual one
- A full crawl of the old domain, started at the home page and following every internal link
- Server access logs covering at least twelve months — they also reveal addresses that are no longer linked internally
- The page export of the previous editorial system, including archived and unpublished entries
- The reports from search engine webmaster tools on indexed and excluded addresses
- Files outside HTML: PDF data sheets, price lists, brochures and images with their own addresses
- Parameterised addresses from campaigns, filters, sort orders and print views
- Short addresses used offline, QR targets and landing pages from adverts and notices
The raw list usually turns out longer than expected — on grown websites a few thousand addresses are nothing unusual. Collection is therefore followed by prioritisation. In practice the vast majority of traffic falls on a small share of addresses, and that share deserves an individually reviewed mapping. Three criteria have proven useful: visits over the past twelve months, external references pointing at the address, and its contribution to enquiries or revenue. Addresses that score low on all three can be grouped by pattern later — an entire directory routed to a new overview page, for instance. For businesses serving a local area, the pages that catch location and service searches deserve particular attention; the article on local visibility for local businesses describes the part they play.
The mapping: every old address gets a target
The mapping is the substantive core of the move, and it cannot be automated without someone thinking along. The guiding question is not where an address fits structurally, but which page answers the question that made someone open that address. In the fortunate case there is an unambiguous new counterpart for every old address: the same service, the same product, the same article, simply under a new path. Often the situation is more complicated, because content gets merged, split, shortened or dropped entirely. Each of these cases has a customary treatment. What matters is making the decision deliberately and writing it down, rather than leaving it to a blanket rule. How different structures and page types can look is visible in the example websites and their respective navigation patterns.
| Situation | Customary treatment | Reasoning |
|---|---|---|
| The page remains in substance, the path changes | Permanent redirect with status code 301 to the new address | The content is the same; references and positions should travel with it |
| Two pages are merged into one | Both old addresses point permanently to the new combined page | A single shared target concentrates the signals instead of halving them |
| One page is split into several | The old address points to the closest matching part, the others are linked from there | An unambiguous target is required; distribution is handled by internal linking |
| Content is dropped but a sensible counterpart exists | Permanent redirect to the nearest related offering | Visitors get an answer instead of an error page |
| Content is dropped with no replacement, such as an expired promotion | Status code 410, or an informative error page with status code 404 | An honest signal beats a misleading redirect |
| The page is unavailable only temporarily | Temporary redirect with 302 or 307; during maintenance status code 503 | The old address should stay in the index and be served again later |
The outcome of this round is a table with three columns: old address, new address, status code. It is the central working document of the entire relaunch — tested before launch, rolled out on launch day and used as a checklist afterwards. A fourth column for notes helps with traceability: why does this address point at that page? Anyone keeping such a table can still explain weeks later what happened instead of guessing. One thing that is easily forgotten: the annotations that enrich search results also carry addresses in the code. Breadcrumb data, organisation details and article markup contain URLs that must point to the new paths after the move; how that markup is built is covered in the article on structured data in search results.
Status codes: 301, 302, 307, 308 and 410
The answer the server gives for an old address decides how search engines interpret the move. The HTTP standard sets out in RFC 9110 (IETF) exactly what each response means, and the differences matter. Status code 301 (RFC 9110, IETF) reports a permanent move: the resource has a new address, references should point there from now on, and search engines gradually replace the old address in the index with the new one. Codes 302 and 307 (RFC 9110, IETF) report a temporary state instead; the old address remains the authoritative one and stays in the index. Anyone who accidentally works with 302 during a relaunch gives away precisely the transfer that the whole exercise is about. Code 308 (RFC 9110, IETF) matches the permanent 301 but additionally preserves the original HTTP method — for ordinary page requests the practical difference is small, for redirected form submissions it can become relevant. And 410 (RFC 9110, IETF) states that content was deliberately and permanently removed: an honest signal that speeds up cleaning the index.
GET /services.html HTTP/1.1
Host: example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/en/services/
Cache-Control: max-age=3600
Content-Length: 0How long redirects should stay in place
Resolving redirect chains and loops
Redirect chains are rarely created on purpose. They grow over the years: first delivery was switched from unencrypted to encrypted, then the variants with and without www were unified, then the file extension was dropped, and the relaunch adds the new path on top. In the end the server answers a single request with three or four consecutive redirects. Every one of those hops costs a full request and response round trip, which is immediately noticeable on mobile connections. Crawlers also follow only a limited number of hops before giving up — whatever sits at the end of the chain is then no longer reached. The rule is therefore simple: every old address points in one step to the final target, not to the next intermediate stop. In practice that means consolidating the rules after each move instead of stacking them. How much avoidable detours affect loading time is put in context by the article on static delivery with a PageSpeed score of 100. Loops are equally problematic, where two rules call each other: the page then reaches no visitor at all, and testing tools report nothing but an aborted request.
Chain (three responses, two needless hops):
http://example.com/services.html 301 -> https://example.com/services.html
https://example.com/services.html 301 -> https://example.com/services/
https://example.com/services/ 301 -> https://example.com/en/services/
Direct route (one response):
http://example.com/services.html 301 -> https://example.com/en/services/Updating internal links
Redirects are a safety net for references that arrive from outside. For your own website they are not a solution but a legacy burden. After the move, internal links should point straight at the new address — otherwise every click runs through a superfluous redirect and the structure of the site itself stays stuck in the past. This affects far more places than the navigation. The references most often overlooked sit in legal pages, in automatically sent confirmations and on the thank-you pages shown after a form submission. Which mandatory details belong in an imprint and a privacy policy, and why those pages need their own stable addresses, is covered in the article on imprint and privacy policy pages; what matters on the path from enquiry to confirmation is described in the article on contact forms and enquiries. While updating, it is worth reviewing the link text as well: descriptive wording instead of generic phrases is not only clearer, it is also an accessibility requirement under success criterion 2.4.4 (W3C, WCAG 2.2).
- Main navigation, footer, breadcrumb trail and sidebars
- References in body copy, teasers, buttons and image captions
- Legal pages: imprint, privacy policy, withdrawal notice and terms of use
- Forms: the destination after submission, the thank-you page and the automatic confirmation email
- Images, brochures and downloads that have addresses of their own
- Canonical annotations per page and the connections between language versions
- Structured data: addresses inside organisation, breadcrumb and article markup
- Preview annotations for social networks along with the stored preview image
- Sitemap, robots.txt and any feeds
- Newsletter templates, quotation and invoice documents, and the signatures used across the team
Sitemap, canonicals and index control
After the move the website has to describe its own new shape. The sitemap is the most important instrument for that: it lists only the new, final addresses that answer with status code 200. Redirected addresses inside a sitemap send a contradictory signal — here the address is declared valid, there the server answers with a move. The sitemap protocol limits a single file to 50,000 addresses and 50 megabytes (Sitemap protocol 0.9), measured uncompressed. Larger inventories are split across several files and tied together through a sitemap index. The canonical annotations matter just as much: every page points at itself under its new address. If the old address remains there, the page effectively cancels out its own redirect. Media files have their own addresses too and belong in the review; which formats and annotations make sense for them is described in the article on website images, formats and alt text.
- The sitemap contains only addresses that answer with status code 200
- Redirected, blocked or noindexed addresses do not belong in it
- At most 50,000 addresses and 50 megabytes (Sitemap protocol 0.9) per file, measured uncompressed; larger inventories are bundled through a sitemap index
- The canonical of every page points at itself — under the new, final address
- The robots.txt does not block the new directories; a test run before launch is part of the mandatory programme
- The old sitemap stays reachable for a while so that crawlers find the redirects quickly
- After the move the new sitemap is submitted and the progress of reindexing is monitored
Language versions: the part most often overlooked
On multilingual websites the mapping work doubles or triples — and this is exactly where most of it is left undone during a relaunch. The typical pattern is that the main language is mapped carefully while the translated versions are routed wholesale to their respective language home page. The result is a language version that shrinks in the index although the content still exists. Every language version needs its own mapping from old to new address, and where translated paths are used, those change independently of one another. On top of that comes the upkeep of the language connections: an hreflang reference to an address that is only reachable through a redirect counts as unclean and can lead to the entire language pair being discarded. After the move, therefore, every language version should go through the same checks as the main language. How language directories, reciprocal pairs and x-default work together is described in detail in the article on multilingual websites and hreflang.
Checks after the move
A relaunch does not end on launch day. The first four weeks decide whether the move is absorbed cleanly or whether gaps settle in. Two things are needed for that: an automated check of the entire mapping table, and a regular look at the access logs, which record every 404 response together with the address that was requested. If a mapping is missing, it shows up there within days. The choice of comparison period matters as well: traffic figures should be compared with the same period of the previous year, not with the previous month — otherwise every seasonal swing gets read as relaunch damage. A temporary dip in the first weeks is common, as long as the curve comes back afterwards. Which scope of work a switch involves — including the migration of an existing address list — is set out in the pricing and packages overview.
- Before launch: run through the mapping table on a staging environment and request every old address once
- Day 1: check every address on the list automatically and log the status code, the target and the number of hops
- Day 1: manual sample — open the twenty most important entry pages in a browser and verify the content
- Week 1: evaluate the access logs for 404 responses and add the missing mappings
- Weeks 1 to 4: watch the indexing reports and follow the reindexing of the most important pages
- Week 4: compare traffic per entry page with the same period last year, not with the previous month
- Ongoing: keep the redirects in place and extend them with every later path change
Old paths stored per page
Any number of former paths can be stored with each page. The mapping table therefore lives in the page configuration instead of a separate server file that has to be touched again with every rebuild.
Permanent redirects without manual work
On publishing, the stored paths turn into permanent redirects to the current address. When a path is changed later, the previous one moves into the list of old paths automatically.
Language versions included
Every language version keeps its own former paths. When a translated path is renamed, the language connections and the sitemap entries stay consistent.
Cool URIs don't change — good web addresses are designed to stay put.
The short version