Website relaunch – a defined task
Website relaunch: Redirect concept for unique URL targets
This detail page defines a technical handover task: Before going live, a decision is made regarding which content-appropriate target should be accessed for old URLs that are no longer available.
This involves processing old and new URLs, target relationships, exceptions, and subsequent monitoring. This concept does not replace the new site structure or content migration; it connects both stages in a transparent manner.
Classify the relaunchDedicated workspace for this URL
Completely collect old URLs
The basis is a consolidated list from the existing system, sitemap, and known page inventory. Only recorded addresses can be deliberately assigned to a new target or a justified removal.
Select content-appropriate targets
A redirect follows the existing page function. A blanket assignment of many different URLs to the homepage does not meet user expectations and obscures missing target decisions.
Test mapping before publication
Source address, target address, and test status are maintained in a single table. This allows missing goals, loops, and unintended chains to be identified before the changeover.
Test sequence for this relaunch component
Merge sources – URL lists from the previous site are cleaned up and standardized. Variants and duplicate entries are identified instead of being planned multiple times.
Define target types – Each old address receives a direct business target, a documented deliberate removal, or a separate review decision. Unresolved entries remain visible and are not silently populated with a generic target.
Prefer individual redirects – The mapping points directly to the final target address. Intermediate links from previous redesigns are identified and resolved to prevent unnecessary redirect chains.
Marking Special Cases Language versions, parameters, downloads, and technically generated variants may require their own rules. They are marked separately to prevent the standard mapping from inadvertently mishandling them.
Checking After Go-Live The approved mapping list serves as a basis for testing. Incorrect or missing targets can be clearly compared to the planned relationship and corrected accordingly.
Questions from Project Preparation
When Does Work on the Redirect Concept Begin?
As soon as the new site structure is sufficiently stable and the old URL inventory is available. If the mapping only begins immediately before go-live, business objectives often remain unclear.
Should every old URL redirect to the homepage?
No. A target should continue the previous function as effectively as possible. If there is no suitable new page, this must be decided upon deliberately, instead of automatically redirecting it to the homepage.
What information does the URL mapping contain?
At a minimum, the old URL, the planned target URL, the decision status, and the test result. In special cases, additional information about the page type or the reason for the mapping is helpful.
How can redirect chains be avoided?
Old addresses are directly mapped to the final new URL. Existing intermediate targets are taken into account during the review and are not carried over as further steps.
What is checked after publication?
The checks specifically address missing mappings, incorrect targets, loops, and chains. The previously approved mapping list remains the reference for the expected relationship.
Suitable basis for the request
Preparation requires the existing URL inventory, the planned new sitemap, and the date of the technical migration.