Treat URLs as part of the content model
A redesign often changes navigation, page templates and the content management system at once. A URL can look like a technical detail in that work, but it is also the address used by bookmarks, campaign links, search results and references from other sites. This analytical exercise uses a fictional regional studio replacing a compact brochure site with a new CMS. It describes no client migration, interviews or measured results.
The first question is not “which old paths can we make shorter?” It is “what does this page help a visitor do, and where will that job live after launch?” Google’s site-move guidance recommends preparing the new site, mapping old URLs to their new format, configuring redirects, and monitoring old and new addresses. It also advises changing one major dimension at a time when possible. [1] That sequence turns URL design into a content decision with a technical handoff.
Build a page inventory before proposing destinations
Start with a joined inventory from the current CMS, XML sitemap, analytics or server logs, and known campaign or partner links. Each source finds a different kind of address: the CMS finds published records, the sitemap shows intended discovery, and traffic or referring-link data helps identify URLs people still use. Google explicitly recommends these sources when compiling important old URLs. [1] Include media files and downloads if those are part of the public experience.
Give each row a stable old URL, page purpose, content owner, current status, and proposed outcome. Useful outcomes include a direct move, a merge into a genuinely equivalent page, a deliberate retirement, or an investigation. Avoid assuming that two pages with similar titles do the same job. For example, a “request a quote” page and a “service areas” page might mention the same service but answer different visitor questions.
Map by visitor intent, then decide what deserves a redirect
For every retained page, write the destination that best continues its purpose. If a project detail page moves from `/work/project-name/` to `/case-studies/project-name/`, the mapping is direct. If three overlapping introductory pages are intentionally consolidated into one guide that covers their subjects, a redirect to that guide may make sense. A homepage is rarely a meaningful destination for a removed service detail: it forces visitors to start over and can obscure whether the old content still exists.
Google warns against sending many unrelated old URLs to one irrelevant destination. It recommends server-side permanent redirects when a move is lasting, and temporary redirects when the change is temporary. [2] A redirect is therefore a statement about the relationship between two resources, not merely a way to make an error disappear. If no useful successor exists, return the correct not-found or gone response and provide navigation that helps a person recover.
Test the new site as a connected system
A redirect spreadsheet is only a plan. Before launch, test the destination itself: it should load, contain the expected content, use its intended canonical URL, and remain accessible to visitors and crawlers. Update internal links so the new site points directly to new addresses instead of sending people through old ones. Publish a sitemap containing the new URLs. Google’s migration guidance also calls for checking canonical annotations, robots rules, internal links and the new sitemap. [1]
Run the mapping against both directions. For each old address, verify the status and final landing page; for each planned new address, verify that it is linked, indexable where intended, and represented in the sitemap. Look for redirect chains, loops, wrong casing, missing trailing-slash behavior and destinations that return errors. A simple worked example: `/services/video/` moves to `/services/production/`; the old path should reach that final page in one step, and links in the new navigation should already use `/services/production/`.
Separate migration signals from redesign results
After launch, compare old and new URL behavior in Search Console and site analytics, and review server logs for old paths still receiving requests. Google says temporary visibility fluctuation can occur while its systems recrawl and process changed URLs; it gives no fixed completion time because processing depends on site size and crawl capacity. [1] That makes a short-term dip a reason to diagnose specific pages, not proof by itself that a redesign succeeded or failed.
Keep a dated issue log that records the old URL, expected destination, observed response, evidence and owner. Group problems by type—missing mapping, incorrect target, blocked page, stale internal link or unexpected deletion—so the team can fix causes rather than patch rows blindly. Search data can show discovery and clicks; it cannot alone tell whether the new navigation is easier to use or whether a campaign’s creative is clearer. Those questions need separate measures and, where useful, direct user research.
Make the handoff reviewable
Before release, have content owners confirm that each destination still answers the old page’s central question. Have the web producer confirm the actual redirects, canonicals, robots directives, internal links and sitemap. Keep the mapping with the release notes so future editors can tell why an address exists and whether a redirect is permanent. Google recommends keeping move redirects for as long as possible, generally at least a year, and updating links under the site owner’s control. [1]
The practical deliverable is a compact, reviewable migration map: source address, destination or response, relationship rationale, owner, test result and follow-up date. It connects content strategy to production mechanics and makes exceptions visible before launch. It does not guarantee ranking stability or traffic growth; it gives the team a disciplined way to preserve useful paths, explain intentional removals, and catch avoidable breaks.
Sources & useful references
- Google Search Central: site moves with URL changes
- Google Search Central: redirects and Google Search
Results are attributed to the original publisher. Proposed tests and creative recommendations are our analysis.