Website Redesign URL Mapping: Keep Useful Pages Reachable
Originally published at https://designtocodes.com on October 31, 2026.
Start with the decision the reader needs to make
Decide which URLs stay and which must move before the redesign launches. Use the tables and worked procedure to create a concrete brief for the website.
How do you map URLs before a website-template redesign?
List the existing pages, decide which URLs can stay unchanged, and map every necessary move to the closest relevant destination. Test the resulting routes before launch, then update internal links, canonicals, and the sitemap where URLs actually change. A different template does not require a new slug for every page.
The risk often starts in the page editor. A replacement template includes its own sample paths, and the team copies existing service content into those pages without recording the old URLs. A customer bookmark, a search result, and the new navigation can then lead to different places.
This guide focuses on the URL decision for a service-site redesign. It does not repeat the existing ecommerce migration guide, which also covers store data and operational migration. The worksheet and example here are planning tools, not a guarantee that a move preserves every search position.
Choose an action for each existing page
| Existing page situation | Preferred planning action | Record in the map |
|---|---|---|
| Content still serves the same task | Keep the URL when practical | Existing path and replacement page |
| The page must move | Redirect to its relevant replacement | Exact old and new URLs |
| Several pages legitimately consolidate | Map each to the appropriate consolidated page | What useful content is retained |
| Content has no replacement | Decide how removal is communicated | No unrelated homepage destination by default |
| Only the title or year changes | Reassess whether a move is needed | Reason for any URL change |
Do not treat a fresh slug as proof of fresh content. The question is whether the page represents the same information or a distinct new task. A new guide can deserve a new URL; replacing a published guide's body is an update to its established page.
Step 1: Collect the URLs people already use
Start with the sitemap, navigation, Search Console page export, and relevant entry pages. Include service details, case studies, useful blog posts, and important image or download destinations. Search data can prioritize checks, but pages absent from a capped export are not automatically unused.
Give every row a page purpose and an owner. The purpose matters when sample-template names differ from business terminology. A path called “services-one” is not a reason to replace a useful established cleaning-service URL.
Google's site-move guidance recommends preparing an old-to-new mapping, including important assets, before changing URLs. Keep the map available to the implementer and the person validating launch.
Step 2: Complete the URL worksheet
| Worksheet field | Example information | Why it matters |
|---|---|---|
| Existing URL | /services/office-cleaning/ | Identifies the actual incoming route |
| Page purpose | Recurring commercial-cleaning information | Helps choose a relevant replacement |
| Decision | Keep or move | Prevents accidental renaming |
| Final URL | Same path or the agreed new path | Supplies the implementation destination |
| Redirect requirement | Only where a move needs it | Distinguishes content edits from migration |
| Links/canonical/sitemap | Pages and systems needing updates | Keeps the new site's references consistent |
| Validation record | Status, destination, and observation date | Shows what was checked |
Treat the worksheet as a decision record rather than an automatic redirect generator. A spreadsheet with a populated destination column can still contain poor mappings. Review destination relevance before implementing it.
Step 3: Implement the chosen routes in the actual platform
Keep existing paths wherever the new structure allows them. Where a permanent move is necessary, configure an appropriate permanent redirect using the site's supported routing system. Google's redirect documentation explains the distinction between redirect types and the preference for server-side implementations where available.
In Framer, confirm the current project's routing and redirect controls. In a Next.js implementation, have the developer configure and test the applicable routing mechanism. In WordPress, check the existing redirect/SEO arrangement before adding another plugin with overlapping rules. Do not copy a platform's configuration syntax into a different implementation.
The Framer and Next.js business comparison explains the broader editing and hosting choice. Use it for that decision; this map governs the routes whichever suitable implementation you choose.
Worked example: redesigning without renaming the service page
This is a fictional service-business example. The existing site has a useful /services/office-cleaning/ page. A new template contains /commercial/, and the team initially plans to paste the same offer there while leaving the old page accessible.
The map identifies that both pages would serve the same task. The team keeps the established service path and replaces its layout in place. A genuinely new maintenance-contract FAQ receives a distinct page only after its scope has been separated from the service description.
One obsolete project page has a relevant replacement case study, so that route receives a documented move. The team tests the old entry path, the final page, and the updated internal links. This illustrates avoiding unnecessary migrations; it does not establish search or sales results.
Step 4: test the map rather than only the homepage
Open important old URLs directly in a fresh session. For a kept page, inspect its status and actual content. For a moved page, follow the redirect and confirm that it reaches the correct final destination without a loop. Check mobile navigation and internal links separately.
When URLs change, align the final page's canonical and sitemap entry with the intended destination. Remove staging-only indexing restrictions from the public launch where appropriate. The existing Google indexing troubleshooting guide helps investigate a specific discovery issue; do not infer successful indexing merely from a sitemap submission.
Monitor the routes after launch
Keep the old-to-new map and check reported missing pages and important entry paths. Compare like-for-like periods when reviewing search activity, and allow for query mix and ordinary variation. Test the business inquiry route as well: a correct redirect can lead to a page whose form is misconfigured.
For the overall launch sequence, use the existing website launch guide. If the redesign needs a new implementation, browse Framer templates or Next.js templates with the map and editing responsibilities in hand.
Frequently asked questions
Does switching templates require changing existing slugs?
No. Keep a useful established URL when the replacement page serves the same task and the implementation supports it.
Should every removed page redirect to the homepage?
Choose a relevant replacement where one exists. A homepage is not automatically equivalent to a detailed service or project page.
Is a canonical tag a replacement for a redirect?
They serve different purposes. Use an actual redirect for a route that needs to move, and align canonical signals with the intended final page.
Should low-traffic pages be left out of the map?
No. Search exports can be capped or incomplete, and visitors may arrive through bookmarks or other links. Review important routes by purpose as well as observed traffic.
Can this procedure guarantee no search traffic loss?
No. It provides inspectable preparation and testing. Monitor actual results and investigate specific errors after launch.
Framer templates to inspect against your URL map. Compare its current format and included scope with the task in this guide.
Comments
Post a Comment