Short answer
Before redesigning, record the pages, URLs, metadata, internal links, analytics, and search performance that already matter. Preserve useful URLs when possible. When a URL must change, send the old URL to the closest new equivalent with a permanent redirect. Then verify canonicals, internal links, sitemap entries, tracking, forms, and indexing after launch.
Do not begin with a blank canvas.
A redesign team should know what Google and customers can already find before changing the structure. At minimum, inventory the current URLs and identify pages that receive organic traffic, earn backlinks, rank for useful searches, convert visitors, or support important customer questions.
Those pages are not untouchable, but they should not disappear by accident.
Keep useful URLs when the page still serves the same purpose.
If an existing page has a clear topic and the redesigned page is still about the same thing, keeping its URL is often the cleanest option. It avoids unnecessary redirect chains and preserves continuity for users, bookmarks, links, analytics, and search engines.
Change a URL when the information architecture actually needs to change, not because a new design makes a different slug look cleaner.
When a URL changes, map it deliberately.
Every removed or renamed URL should have an explicit decision:
- Redirect it permanently to the closest relevant replacement.
- Leave it gone if the content truly no longer has an equivalent and returning a 404 is appropriate.
- Consolidate overlapping pages into a stronger destination when that genuinely improves the site.
Do not send every deleted page to the homepage. A redirect should help the visitor land somewhere that still answers the reason they used the old URL.
Carry forward the search signals that still describe the business.
A visual redesign does not require throwing out page titles, descriptions, headings, copy, alt text, structured data, or canonical tags that are already accurate. Review them one page at a time.
If the content changes substantially, update the metadata to match the new page. If the page stays materially the same, rewriting every title simply because the site is new can create unnecessary variables during the migration.
Check canonicals and internal links before launch.
Canonical tags should point to the preferred live URL for each page. Internal links should point directly to the final destination rather than relying on redirects. Navigation, footer links, service links, related content, images, and calls to action all deserve a crawl before launch.
Google treats redirects and canonical tags as strong signals when determining which URL should represent duplicate or moved content. Its own documentation recommends consistent canonical signals and using canonical URLs in sitemaps.
Do not forget the operational pieces.
A migration can be technically clean and still fail the business if forms stop sending, analytics disappear, phone links break, or ecommerce tracking is lost.
Before launch, test:
- forms and confirmation behavior
- analytics and conversion events
- Search Console ownership
- robots directives
- XML sitemap
- canonical tags
- redirects
- mobile navigation
- checkout or payment paths
- email notifications
Monitor the new site after it goes live.
Submit or refresh the sitemap, watch Search Console for crawling and indexing issues, test important old URLs, and compare performance against the pre-launch baseline. Some movement after a meaningful redesign is normal. Large unexplained drops need investigation.
This is why STATICMETHOD treats redesign as more than a visual project. The site has history, and that history should be accounted for before the new version replaces it. See the Website Redesign approach or decide first whether a full redesign is even necessary.
Sources & further reading