Understand the search risks of redesigning.
Search engines encounter a redesign as a changed collection of addresses, content, headings, links, templates, status codes and signals about which version of a page should be indexed.
A page that previously answered a useful search may disappear. Its address may change without a redirect. Several distinct pages may be merged into one generic page. Important internal links may be removed. A staging instruction may remain live. Canonical tags may point to the wrong host or path.
Search visibility can fluctuate after a responsible migration because the site’s genuinely changed and search systems must recrawl and reassess it. The practical aim is to preserve useful value, minimise avoidable ambiguity and make any movement easier to investigate.
Migration planning begins before design implementation. At that point, the purpose, relationships and value of existing pages can still be recorded accurately.
Audit the existing site before replacing anything.
Create a usable record of the existing public website. At minimum, this should include indexable URLs, page titles, canonical destinations, status codes and the principal internal links.
Where reliable access exists, combine that technical inventory with evidence from analytics, search-performance tools, enquiry records, backlinks, referral sources and the business’s own knowledge.
Assess pages by purpose and value as well as traffic.
A low-traffic page may answer a highly valuable specialist query, support a sales conversation or provide essential evidence, while a high-traffic page may attract poorly matched visitors. The page’s purpose and commercial role belong alongside traffic data.
- Current URL and status code
- Page purpose and intended audience
- Title, main heading and principal subject
- Canonical URL
- Important internal and external links
- Relevant search, traffic or enquiry evidence
- Decision: retain, improve, merge, redirect or remove
Decide what happens to every important URL.
Keeping a useful URL is often the simplest option when the page continues to serve substantially the same purpose. A redesign can preserve established addresses wherever they remain appropriate.
When an address must change, map the old URL to the most relevant new destination. A permanent redirect should lead to a genuine replacement that continues the old page’s purpose as closely as possible.
A redirect map is a project document.
It should be reviewed before launch, implemented deliberately and tested afterwards. It also helps the team identify missing replacements, accidental duplication and pages whose purpose has not yet been resolved.
Avoid unnecessary redirect chains. Where possible, old URLs should lead directly to their final intended destinations.
Preserve search intent, not just old copy.
Useful intent can survive substantial editorial change. The important question is what need the page currently satisfies and how the new site will continue to satisfy it more effectively.
A concise new page can be stronger than a long old one when it retains the distinctive explanations, examples, service details and evidence that give the subject its value.
Review the relationship between pages.
Information architecture changes affect internal linking and topic hierarchy. If several old pages are merged, the new page must carry the relevant intent clearly. If one broad page is divided, each new page needs a distinct purpose and coherent links between them.
Titles and headings should describe the real page and its purpose, informed by the content rather than generated mechanically from navigation labels.
Get redirects, canonicals and status codes right.
A migration review should verify that indexable pages return the intended successful status, redirecting pages return the intended permanent redirect and removed pages are handled deliberately.
Canonicals
Each canonical tag should point to the preferred live URL for that page. Development hosts, obsolete paths and copied production canonicals can all create damaging confusion.
Internal links
Update navigation, body links, breadcrumbs and calls to action so they point directly to current destinations.
Indexing instructions
Confirm that public pages intended for discovery are indexable and technically reachable, while utility, preview and private surfaces remain protected from public indexing.
Sitemaps and discovery
A final XML sitemap should contain canonical indexable URLs only and complement clear navigation and internal linking.
Keep staging and preview environments private.
Development copies can expose unfinished content, duplicate the live site or reveal technical information, so they need access controls as well as appropriate indexing instructions.
Before launch, verify that the live site does not inherit staging hostnames, blocked resources, test credentials, preview banners or indexing restrictions.
The live route needs its own post-deployment check to confirm that staging protections haven’t been carried into production.
Check the new site for users and search engines.
Local and staging checks establish the foundation, while the final public environment still needs direct verification of hosting rules, certificates, redirects, caching, path handling, forms and canonical generation.
- Fetch every priority old URL and confirm its final destination.
- Check status codes and redirect chains.
- Inspect titles, descriptions, headings, canonicals and robots directives.
- Follow principal navigation, breadcrumb and in-content links.
- Confirm that CSS, images and other required assets load.
- Test important pages on mobile and with keyboard navigation.
- Submit and receive the enquiry form through the live delivery path.
- Review the generated sitemap and any public crawl controls.
- Check representative pages with search-engine inspection tools where available.
Monitor the transition after launch.
Migration work continues after deployment. Watch crawl errors, indexing changes, priority landing pages, search queries and enquiry quality. Compare them with the pre-launch record rather than reacting to isolated daily movement.
Investigate patterns. A group of lost pages may indicate a redirect or canonical error. A decline around one subject may indicate that useful content or internal links were removed. Increased traffic with poorer enquiries may indicate a change in intent rather than a technical failure.
Correct confirmed mistakes promptly, then judge further changes from patterns and evidence rather than isolated daily movement.
Avoid common website migration mistakes.
- Changing every URL because the site is new
- Redirecting all removed pages to the homepage
- Discarding useful specialist content during visual simplification
- Launching with staging canonicals or `noindex` directives
- Leaving important internal links pointing through redirects
- Publishing several new pages with indistinguishable purposes
- Removing pages before their replacements are ready
- Failing to test old URLs after deployment
- Assuming a successful visual launch proves a successful migration
Search visibility can’t be frozen in place and rankings can’t be guaranteed. A disciplined migration makes the changes explainable, testable and recoverable.
