A website redesign redirect map records what should happen when somebody opens an old address after the new site launches. It is particularly useful when a business replaces WordPress, reorganises a blog or introduces a different service hierarchy. The visual redesign may be complete while old article links, campaign destinations and bookmarked service pages still point to addresses that no longer exist. Planning the mapping early gives editors and developers time to resolve those gaps. This guide explains how to build a practical inventory, choose destinations and validate the change. It cannot guarantee unchanged rankings, but it can make a migration more deliberate, testable and easier to maintain.
Inventory real URLs before approving a new structure
Collect addresses from the current sitemap, internal navigation, available analytics, Search Console and the content system. Include important documents and campaign landing pages where they form part of the customer journey. Keep the source of each address in the inventory, because a sitemap alone may omit useful older pages. Record the page title, purpose, current status and proposed owner. This turns an abstract migration into a list of concrete destinations that somebody can review.
Check the inventory against the actual website before assuming that every entry deserves a new page. Some addresses may already redirect, represent duplicates or belong to retired offers. Others may have little measured traffic but still be referenced in a sales document or customer email. Ask the business team about those operational uses. A page should not disappear solely because it was absent from one report. Keep uncertain cases visible until someone responsible for the offer can make the decision.
Keep useful addresses unless a change has a purpose
A new design does not automatically require new URLs. Keeping a clear, established address can reduce the amount of migration work and the number of things that might go wrong. Change a route when it supports a considered information architecture or resolves a real problem, not simply because a new template uses a different naming convention. Document the reason beside the mapping so that future editors understand why the decision was made.
For a blog moving into main and child categories, agree the editorial home of each article before generating its destination. A post about page speed might belong under website performance, while a post about URL handling belongs under technical SEO. The breadcrumb, canonical and visible internal links should agree with that choice. If an article covers several themes, use contextual links to related guides rather than creating multiple public copies of the same article under different paths.
Choose replacements by intent rather than convenience
Match an old page to the closest genuinely useful replacement. A retired article with an updated equivalent can point to that equivalent. A discontinued service without a replacement needs a different decision from a renamed service that still exists. Sending every old address to the homepage makes the rule simple but can leave visitors unable to find the information they requested. Record why the proposed destination fulfils the original purpose and flag weak matches for editorial review.
Use a worksheet with old URL, final URL, decision type, rationale and verification result. For merged articles, explain which content was retained and whether the new page still answers the old questions. For pages deliberately removed without replacement, return an appropriate not-found or gone response instead of manufacturing an unrelated destination. Keep a separate list of unresolved mappings and assign owners. The launch checklist should show those decisions clearly, rather than burying them in a large generated redirect file.
Review technical SEO priorities →
Implement direct redirects and consistent destinations
Google recommends permanent server-side redirects for permanent URL moves and advises pointing to the final destination directly. Update internal links and the sitemap to use the new addresses. Check that the destination is accessible and its canonical reflects the intended page. A working redirect is only one part of the change; the page it reaches must still contain the useful content the visitor expected.
Ask the developer to test existing rules alongside the new map. A previous domain change, trailing-slash rule or language redirect can interact with a new path rule and create a chain or a loop. Include query strings and meaningful section links in representative tests where customers use them. Avoid altering unrelated parameters without understanding their purpose. Keep the configuration readable and versioned so a problem can be traced to a specific change, and make sure the team knows which deployment contains the approved mapping.
Validate the map before and after launch
Before launch, run the mapping against a preview or staging environment and check the expected response for every listed route. Verify representative pages visually as well: titles, main content, images and the enquiry action. A destination returning a successful status can still be the wrong page or an empty shell. Keep automated response checks and human content review as complementary evidence. Record failures with the exact address and the intended result so they are straightforward to fix.
After deployment, repeat the checks on the public domain. Confirm the final canonical, sitemap membership and internal navigation, then open a few important old links from outside the site's menu. Keep monitoring available indexing and traffic reports, recognising that search visibility may fluctuate during a move. Investigate missing content and unintended redirects promptly. Do not interpret a sitemap submission as proof that every URL has been indexed, and do not replace a documented defect with repeated manual submission requests.
Give the migration a recovery and maintenance plan
Define who decides whether to pause a rollout and how to restore the last working configuration if an important journey breaks. Save the inventory, mapping and validation output with the project. Keep responsibility for redirects after the design agency or development team finishes the launch. Old links can continue arriving through bookmarks, references and external websites, so redirect handling is an ongoing operational concern rather than a temporary launch decoration.
Google recommends retaining redirects for at least a year, and keeping useful redirects longer can continue helping visitors. Review them when services or article structures change again, and update old sources to point directly to the latest appropriate destination where possible. For an SEO management discussion, bring the existing sitemap, proposed navigation and a list of high-value pages. A clear mapping review can then happen before implementation, when an editorial decision is easier to change than a rushed production fix after customers discover broken links.