Inventory destinations with a purpose
Start with important product pages, articles, category pages and documents. Record their current paths, language and intended successor. Separate internal application routes from public content. Do not assume every old URL should redirect to the homepage: a visitor looking for a particular guide needs its equivalent or an honest removal response, not an unrelated landing page.
Keep meaning when paths change
A new structure may be easier to maintain, but the mapping must be explicit. Avoid chains in which an old address redirects through several intermediate versions. Update internal links alongside the transition. Language variants should remain equivalents, not all collapse into English. Build a test table that checks the intended status and destination for representative old and new routes.
Review metadata in the new template
A template migration can accidentally give every page the same title or canonical address. Check a product page, an article and a language variant separately. Google uses several signals to produce title links and can choose something other than the supplied title. Write descriptive page-specific text instead of treating an exact character count as a ranking formula. [E07]
Verify before and after cutover
Use a bounded route sample before release and repeat it after the approved cutover. Record unexpected errors and fix the mapping through the normal change process. Public search visibility cannot be guaranteed by a successful redirect test, but broken navigation can be caught directly. Keep the URL map in Product knowledge so the next modernization does not rediscover it from scratch.
Treat URLs as part of the product contract
A new interface can preserve every visible feature and still break the paths customers, search engines and integrations use. Inventory public URLs before changing routing: product pages, category pages, language versions, downloads and important query parameters. Decide which addresses remain and which have an equivalent destination.
For each changed URL, prefer a relevant replacement rather than redirecting everything to the home page. Keep the distinction between permanently moved content, removed content and private content. Test canonical links, internal navigation and sitemap output against the same release, so that one surface does not advertise obsolete addresses.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Unchanged page | Keep its useful stable address. | Direct request and internal-link test. |
| Moved page | Map to the closest equivalent. | Redirect chain and destination check. |
| Language variant | Preserve language relationships. | Reciprocal locale links and content review. |
Where this goes wrong
A robots exclusion is not a redirect or access control. A visually correct page may also return the wrong status code. Include actual HTTP behavior in acceptance instead of reviewing only screenshots. Source-specific ranking effects cannot be predicted from a routing checklist alone.
The migration is not complete while visitors still reach the wrong content.
Turn it into a working checklist
- Map important public URLs.
- Keep language equivalents.
- Test template metadata and canonical values.
- Repeat checks after cutover.
A concrete next step
Keep the URL migration map with the release. Record old address, action, new address and reason. Sample valuable entry paths on desktop and mobile, including a user who arrives without a session.
Watch a related case
The video could not be loaded. Try again later.