A website migration can combine design, platform, content and URL changes in one project. That makes it easy for useful pages to disappear or important routes to break. SEO planning should therefore begin before launch rather than as a clean-up exercise afterwards.
Record the existing URL set before changing it
Create a reliable inventory of current pages and identify which ones have a continuing purpose. This provides the baseline for decisions about keeping, replacing, consolidating or retiring URLs instead of discovering omissions after the new site is live.
Make the inventory operational rather than simply a spreadsheet of paths. Include the original URL, response code, public title, canonical declaration, content purpose, key internal links and the person authorised to make a retirement decision. Important pages might include active service descriptions, technical guides, product details, contact routes and support information. Mark any resources deliberately excluded from indexing so they are not later mistaken for migration failures. Where the existing site is large, gather records from several sources, including a relevant crawl, CMS exports and approved analytics or Search Console observations. None is necessarily complete on its own.
Keep the original inventory unchanged as evidence of the pre-migration state, then create a separate working mapping. A redesign team may be tempted to use the planned new site as the only source of truth. That can hide resources that were never included in the design brief. A reliable comparison needs both old and proposed addresses, including unusual routes, old campaign pages and files customers may have bookmarked. Decide explicitly which resources require preservation before development work makes those decisions harder to reverse.
Map old destinations to genuinely relevant new ones
Where URLs change, redirects should lead users to the closest useful replacement. Sending every removed page to the homepage hides information loss rather than solving it. If no meaningful replacement exists, make an explicit retirement decision.
For each old URL, classify whether it stays, moves, merges or retires. A page that simply changes path should normally redirect to its true new location. Two overlapping guides may be merged into one carefully prepared successor, provided useful information from both survives. A discontinued offering without an appropriate replacement may deserve an honest not-found or gone response rather than a misleading redirect. A redirect map needs business and editorial review, not only a developer's automated slug matching.
Test both sides of every material mapping: the old URL should return the intended redirect and the final destination should provide the expected content. Avoid redirect loops and unnecessary chains. Google documents URL migrations in its site move with URL changes guide. That guidance supports careful planning and monitoring; it does not promise a fixed time for rankings or clicks to recover.
Protect important content during redesign
Visual improvements can accidentally remove explanations, service detail and internal links that made an old page useful. Compare old and new versions by purpose and information, not merely appearance, so the redesign does not reduce the substance readers rely on.
A designer may replace a detailed service explanation with a shorter promotional banner or move technical content into collapsed panels. The new layout can look cleaner yet leave prospective customers unable to understand eligibility, exclusions or process. Identify critical sections before migration and require their intended purpose to survive the new templates. Where an article is genuinely obsolete, retire it through a documented editorial decision rather than losing it inadvertently during import.
Check the old page against the new rendered page. Are definitions, procedures, sources and important qualifications still available? Have visible links been dropped because the new component only imports plain text? Does a new hero image carry correct alt text and rights information? Content parity is not a demand for identical wording. It is assurance that the new page still fulfils the reader's task and does not make false promises. Avoid applying a common generic summary to every specialist page simply to complete the move quickly.
Check navigation and internal links on the new structure
Confirm that important pages can be reached through sensible site routes and that old internal URLs have been updated. A redirect may rescue a broken link, but correcting the source link creates a cleaner long-term structure.
Review the navigation hierarchy, category pages, contextual article links, breadcrumbs and important footer routes. A URL may be technically accessible but effectively isolated from the customer journey. Use ordinary links whose destinations work and whose labels accurately describe the page. If the new category structure differs, check that specialist guides are located where a reader would expect them. A sitemap is a discovery aid, not a substitute for useful site navigation.
Test mobile menus and deep links rather than confirming only that the homepage loads. A sticky header can cover an anchor destination, and a JavaScript menu can render without meaningful href links. Check keyboard access, focus indication and whether link wording still makes sense after categories are renamed. Google's crawlable link guidance is relevant to link implementation, while accessibility and customer task verification require their own tests.
Test the technical basics before launch
Review indexability, canonical handling, status responses and other essential controls in the environment available to the project. The exact checks depend on the platform and migration scope, so use evidence from the actual build rather than a generic checklist alone.
Staging environments often need access restrictions, but those restrictions must not accidentally reach production. Check public robots configuration, intended noindex directives, final hostnames, HTTPS, canonical signals and sitemap generation. An important public service page should not accidentally identify a development host as canonical. Test the rendered document head and main content, particularly when JavaScript, caches or server-side templates determine the output. A correct CMS record does not prove its public version is correct.
Check representative HTTP responses for homepage, category, article, service and contact templates where applicable. Include unusual data cases: long titles, missing optional images, URLs with parameters and retired resources. Verify real forms, not only their visual layout; a click event does not prove an enquiry was accepted. Keep a rollback or incident plan for serious errors. A launch checklist should describe how faults are recognised and who can authorise a fix, not merely list ideal settings.
Monitor the migration as a change, not a single event
After launch, inspect the new site for unexpected missing pages, redirect problems and changes affecting priority areas. Keep the original inventory and mapping available so issues can be traced back to migration decisions rather than investigated without context.
Monitor the public website immediately for high-impact technical and customer-journey problems, then review search observations over appropriate periods. A migration may require further crawling and processing before search reports reflect all new URLs. Google Search Console can help identify changes in pages and queries, but its observations do not prove every movement was caused by the migration. Compare relevant page groups, record release dates and consider changes in demand or competition.
Run regression checks on old URLs and their final destinations, not just on newly generated sitemap entries. Investigate redirect chains, accidentally excluded pages and resources still pointing to staging. Track each issue with a known source URL, expected destination, owner and public verification result. A native database UPDATE and READ-BACK establish content persistence, not cache invalidation or a successful public redirect. If the public renderer exposes internal editorial notes, treat that as a separate confidentiality defect requiring a template fix.
Control migration scope before combining unrelated changes
A redesign is often presented as one opportunity to change everything: brand identity, platform, URL paths, navigation and content. Each extra dimension complicates diagnosis if search performance changes. Decide which alterations are essential to the business goal and which can safely happen before or after the core migration. If the old URLs are accurate and functional, retaining them while updating design may reduce unnecessary risk. If a structural change is necessary, document it clearly.
Prioritise high-value pages and shared templates for manual review. A small business may not have the resources to inspect every minor archive page individually, but it should not overlook the contact route or the pages that explain its active offerings. Select a proportionate representative sample plus all critical customer journeys. Assign separate owners to design acceptance, technical release and factual content, because one person's approval cannot substitute for every discipline.
Accept the public result rather than the launch announcement
A migration is finished operationally only when the intended public site works and the important transitions have been verified. Confirm old-to-new mappings, page content, indexing directives, responsive layout, source attribution and essential interactions. Record which tests passed and which remain open. A completed deployment ticket is not proof that all customer journeys work.
Later changes in rankings are useful signals, but not deterministic acceptance criteria. Search engines make their own indexing and presentation decisions. A responsible migration report distinguishes confirmed technical corrections, unresolved risks and later search trends. With a preserved URL inventory, relevant redirects, accurate content and public regression tests, a small business can change its website without losing track of the information customers still need.
When should a migration retain an existing URL versus redirect it?
Choose based on genuine content and architecture changes, not a blanket instruction to rename every page.
| Criterion | Retain the existing URL | Map to a relevant successor |
|---|---|---|
| Page identity | Same purpose and suitable public address remain | Resource genuinely moves, merges or changes identity |
| Content handling | Keep useful information in the updated template | Preserve valuable material on the appropriate destination |
| Technical requirement | Verify status and canonical without needless redirects | Implement and test relevant old-to-new redirect |
| Main risk | Existing URL may no longer match a genuine new service | Wrong destination, loop or avoidable chain |
| Sign-off | Public URL and customer task remain functional | Old link reaches useful new page and metadata agrees |
Source A: Google Search Central site move guidance (URL mappings, redirects and testing; checked 31 October 2026). Source B: Google canonical URL guidance (representative URL signals; checked 31 October 2026). Neither guarantees unchanged rankings after migration. Decision: avoid unnecessary moves, but when a real move occurs, map old URLs to correct relevant destinations and verify the public result.
Five questions about small-business website migrations
Should all URLs change during a redesign?
No. Retain healthy descriptive URLs where practical and change them only for genuine content or structural reasons.
Can old pages all redirect to the homepage?
That is usually a poor substitute for relevant mapping. Use meaningful successors where possible and handle genuinely retired resources deliberately.
Is a successful sitemap submission enough?
No. Verify public responses, indexing directives, navigation, content and important redirects independently.
Will search rankings recover on a guaranteed schedule?
No. Search processing and external factors vary, so record actual observations without promising a fixed recovery date.
What evidence closes the migration task?
Tested public old/new routes, correct content and metadata, functional customer journeys and documented unresolved exceptions.