Keep useful URLs when you change a website template

Keep a published URL when the page keeps the same purpose and your new system supports that address. When an address must change, prepare its destination before release. A new template alone does not justify changing every page URL.

This guide covers a public content website. A domain move, authenticated application, or complex store can require additional migration work.

Build the current address list

Collect the URLs that the website currently publishes. Use the sitemap, navigation, content records, and available server or search reports. Each source can reveal pages that another source omits.

Include important images and downloadable files when their addresses will change. A link to a PDF can matter to a visitor even when it does not appear in the primary menu.

Record which addresses you intend to keep. Identify the pages that need a new destination or deliberate removal. Do not let the new template's demonstration folders make that decision for you.

Map each changed address to its purpose

Choose a destination that preserves the old page's useful function. A renamed service page can lead to the corresponding new service page. An unrelated homepage is not a useful substitute for every removed article.

Google's site move guidance describes URL mapping, redirects, and release monitoring. Apply the parts that match your actual move. A temporary search change can occur while Google processes a move.

Keep the map readable for the person who configures hosting. For example:

These paths are examples. Replace them with your site's addresses before implementation.

Separate redirects from canonical metadata

A redirect sends a request to another address. A canonical declaration identifies a preferred address for a page. They serve different purposes.

Check both when you change a URL. A new page with the old canonical address can send conflicting information. A canonical declaration also does not move a visitor away from a broken old link.

Use the template SEO checklist to review titles, public links, and canonical information together.

Review the redirect path

For each changed address, request the old URL and inspect its response. Confirm that the redirect reaches the intended page. Check the resulting destination directly as well.

Use the redirect type that describes the actual move. Follow your hosting provider's instructions and the applicable search guidance. A permanent move and a temporary preview are different conditions.

Avoid unnecessary chains through several old addresses. Keep the old URL connected to its intended final destination when your system permits it.

Check useful query parameters and fragment links where the site relies on them. A page move can succeed while a link to a specific section stops reaching that section.

Update links that you control

Change internal navigation, article links, canonical addresses, and the sitemap to the intended published URLs. Review email templates or downloadable instructions that contain old links.

Keep redirects for external links that you do not control. Do not remove a redirect merely because your new navigation no longer uses the old address.

Check forms and related services after a domain change. Their allowed origins, destination settings, or confirmation links may need separate work. The contact form checklist provides a delivery review.

Make the release record explicit

Record the version, publication date, address map, and person who can change the redirect configuration. Keep the previous working configuration available through the owner's recovery process.

After publication, repeat the address checks on the public domain. Monitor available missing-page and search reports for unexpected results. A local configuration check does not prove the public server response.

Use the launch checklist for the rest of the release. Keep the URL map in the handover record so the next maintainer understands the remaining redirects.