Web Design and Development
Website Redesign: A Practical Plan for Existing URLs
Protect existing links during a website redesign. Plan URL mapping, relevant redirects, missing-page responses and production checks with a clear register.
The new homepage opens correctly, but a service link sent to a customer last month now produces an error. Older articles reference missing images, and internal links still point to pages that no longer exist. The visual redesign may be finished while the migration remains incomplete. Preserving address relationships matters to existing customers, sales conversations and previously shared material as well as search discovery.
A URL migration plan records where content moves and what happens to material that is removed. This guide describes a practical process for a corporate website redesign. Addresses and scenarios are illustrative. A real implementation needs review of its server, content and incoming links; copying the same redirect configuration into every environment is not a dependable migration method.
Separate a visual redesign from an address change
A new appearance does not require changing every URL. An existing service address may remain suitable under a new design. Keeping it can avoid unnecessary redirection and link updates. Decide which addresses need to change and explain why, rather than treating a different layout as sufficient justification.
A new content management system does not automatically require new public paths either. The technical team can assess whether the existing structure remains maintainable. If several changes must happen together, record their implications separately. Changing the domain, hosting, content and URL structure at once can make diagnosis harder. The plan should expose those dependencies so the team can investigate problems without guessing which change produced them.
Build the old address inventory from several sources
Crawling the current site provides a starting point, but may miss older pages no longer linked in navigation. Sitemaps, content records, server logs and available Search Console information can contribute further evidence. Ask the sales team about documents and links used regularly. Record the period and limitations of each source.
Separate pages, images, documents and other resources. Moving a PDF can affect links in proposals and articles, even when the main navigation remains intact. Restricting the inventory to visible menu destinations overlooks these relationships. When removing duplicates, examine whether parameter, language or extension differences really represent the same material. Similar-looking paths can perform different jobs, so inspect representative cases before merging them automatically.
Make an editorial decision for each previous address
A migration register can include the old address, its subject, the new counterpart, the intended action and verification status. Some addresses remain unchanged. Others move to equivalent content. Several previous pages may legitimately consolidate into one new explanation, but the decision should follow their purpose rather than the resemblance between their path names.
Distinguish consolidation from an unrelated destination
If a new service page fully covers two previous explanations, it may be an appropriate shared target. Sending a removed technical guide to a generic homepage does not provide the same information. The visitor reaches a working page but may still lose the answer they expected. Google’s site-move guidance discusses mapping old and new URLs and avoiding irrelevant mass redirects.
Handle content without a replacement honestly
Not every removed page has an equivalent destination. When material is no longer available and there is no relevant replacement, an appropriate not-found response may be the correct outcome. The interface can still explain the situation and offer useful navigation. Its visible message and the server’s response should communicate the same underlying state.
Google’s HTTP status documentation explains the distinct meanings of success, redirection and missing-content responses. Showing an error message while returning a successful status can conceal the actual absence. Have the implementation checked at the response level. Writing “404” on screen and opening the homepage for every unknown path do not perform the same function as an appropriate missing-page response.
Apply redirection according to the actual change
A permanent move and a temporary arrangement are different situations. The response should reflect the intended change, with an appropriate permanent option considered for genuinely relocated addresses. Establish where the rule runs. Hosting settings, server configuration and application routing can all affect the same request, sometimes in conflicting ways.
Rule order can influence the result in some environments. A broad rule may prevent a specific mapping from taking effect. Do not assume a sample configuration works merely because it looks plausible. Inspect the initial response, subsequent route and final content for actual requests. Even where the page eventually opens, unnecessary steps may remain. Record the responsible configuration location so future maintenance does not introduce another competing rule.
Find chains and loops before publication
A previous address may lead to another previous address before reaching the current destination. Such chains can survive earlier migrations. Where suitable, map the original request directly to its final equivalent. A loop returns an address to itself directly or indirectly and prevents the visitor reaching the intended result. Opening a handful of pages in a browser may leave many cases undiscovered.
Check the migration register systematically and inspect unusual results manually. Record the final target’s status too. A redirect ending at a missing page needs review even if its first response is technically correct. Language mismatches and document links replaced by unrelated HTML introductions require editorial attention. A functioning technical route and an appropriate content counterpart are separate acceptance questions.
Update internal links to their final destinations
Redirects support older links that remain elsewhere; they are not a reason for the new site to keep using outdated addresses. Navigation, footers, article references, project cards and buttons should agree with the approved structure. Shared components may be easy to update while links embedded in older writing remain unnoticed. A content crawl helps identify that difference.
Inspect images and downloadable files as well. A page can have the correct new address while still requesting a missing cover image. Read the anchor text to check that it describes the new destination accurately. Combining the address map with editorial review during a website redesign reveals links that work technically but no longer make sense in their surrounding explanation.
Align canonical, language and sitemap references
A new page pointing to an old or unsuitable canonical address can send conflicting signals. Language counterparts and sitemap entries should reflect the same approved structure. Examine how the content system or template generates those fields. Correcting a few examples manually does not establish that every other page receives the right values automatically.
Staging addresses should not remain in public content. Restrictions used during development also need review against the launch plan. This does not mean removing every restriction indiscriminately. Public service information, test pages and administration areas have different roles. Evaluate the intended access and indexing behaviour for each rather than applying one rule to the entire environment without context.
Prepare a recoverable launch plan
A backup is more than a collection of files. Understand which content, media and configuration versions belong together and which access is needed to restore them. Assign responsibility for a rollback if required. The existence of a copy does not prove that a functioning site can be recovered from it; the relevant restoration method needs appropriate verification.
Plan how changes around the publication window will be handled. If the old site continues receiving enquiries or content updates after the migration copy is made, the two versions can diverge. Transferring that difference, pausing particular operations or using another approach depends on the system. Everyone involved should know which changes they own during launch. A defined communication channel helps avoid conflicting updates to the same live configuration.
Verify production against the migration register
After launch, test more than the homepage. Check retained pages, moved addresses, removed content and a genuinely nonexistent path. Forms, image loading and language switching also need production checks. Settings for access or email may differ from the test environment, even when the interface looked complete beforehand.
Add dates and findings to the register. Describe which address, response and user task a problem affects. A broken service route or enquiry journey may require immediate attention. Including production verification within a corporate website development scope creates a more realistic definition of delivery than file transfer alone. The final page needs to contain the right information, not merely return something visible.
Schedule observation after the initial move
Old-link traffic and errors can reveal previously missed addresses. Investigate before adding another mapping. Some unknown requests come from automated scans rather than genuine historical content. Their presence in a log does not establish that each deserves a new public destination. Check the address history and the existence of a relevant counterpart.
Search appearance may change as content is revisited, and the timing is not identical for every site. Separate technical checks, editorial changes and measurement conditions before attributing a traffic movement to one cause. Maintain comparable records and keep the migration register current. Documenting resolved issues also gives a future redesign a clearer starting point instead of forcing the next team to reconstruct the site’s history.
Frequently asked questions
Must every address change for a new design?
No. Existing addresses can remain when they are clear and appropriate. Change them for a genuine structural reason, not simply because the appearance is different. Separating those decisions can reduce unnecessary mappings and the amount of internal content that needs updating.
Is redirecting old pages to the homepage enough?
Not generally. A relevant destination should correspond to the previous information. An unrelated homepage may leave visitors without the answer they expected. Where no equivalent exists, consider an appropriate missing-content response with useful navigation rather than manufacturing a misleading replacement.
Does displaying 404 prove the response is correct?
No. Screen content and HTTP status are different layers. Inspect the actual server response. An error message delivered with a successful status may fail to communicate that the requested content is unavailable. The visible design and implementation need to be checked together.
Should internal links change when redirects already work?
The new site should use final addresses directly where appropriate. Redirects can continue supporting older external references. Remember to inspect article text, downloadable documents and media paths as well as navigation, because these locations may contain links that a menu update does not reach.
Will Google results update immediately after migration?
There is no guaranteed completion date. Revisiting and processing addresses takes time and depends on the site. Technical verification, appropriate sitemaps and monitoring support the process, but they do not justify promising a particular indexing change or ranking outcome on a fixed day.
What if the complete old address list is unavailable?
Combine sources to improve coverage and review genuine missing-content requests after launch. Record the limitation honestly. When a historical address is discovered, investigate its relevant counterpart. Automatically sending every unknown request to one page does not replace that assessment.