Website Redesign URL Mapping: Keep Useful Pages Reachable

How do you map URLs before a website-template redesign? List

October 31, 2026
Abu Rasel

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. Also 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.