Keep useful URLs when possible. Map changes deliberately, test the live responses and monitor indexing after launch.
Take an inventory before replacing anything
Collect the existing page URLs, titles and purpose. Include service pages, products, articles, downloads and landing pages that may not appear in the main menu. If Search Console is available, review which pages receive impressions and clicks. Analytics and actual enquiries can add context to those numbers.
Record pages with valuable external links and pages customers bookmark. A page that looks old may still answer a useful question. Decide whether to retain it, improve it, combine it with a genuinely relevant page or remove it because there is no useful replacement.
Keep a copy of the existing site and its URL list. That gives you a reference when a missing page is discovered after launch. A screenshot of the homepage is not a migration plan.
Build a URL map
Keeping a URL stable removes one source of change. When you must change it, write down the old URL and its most relevant new destination. Google recommends permanent server redirects for permanently moved pages, commonly HTTP 301 or 308.
| Old page | Decision |
|---|---|
| A service page with the same purpose | Keep its URL and improve the content. |
| An article moved to a new path | Redirect directly to the new article. |
| Two overlapping pages combined | Redirect the replaced page to the useful combined page. |
| A removed page with no relevant replacement | Return an appropriate not found or gone response. |
Avoid sending every old URL to the homepage. The destination should answer the same need where possible. Test the original URL from a browser and inspect the HTTP response; a link changed in a menu does not redirect old bookmarks.
Preserve meaning while improving the design
A visual refresh should not accidentally remove the information that makes a service page useful. Keep a clear heading, the service scope, business details, evidence and a practical next step. Rewrite repeated or vague content to answer a more specific question.
Give each important offer a page people can reach through normal links. A visitor should be able to move from website design to a relevant project or guide without guessing where the content lives. Avoid creating many nearly identical pages that differ only by a place name.
Titles and descriptions should describe the actual page. A service page, an article about buying that service and a case study each have a different purpose. Their wording should reflect that difference rather than repeat one keyword phrase across the entire site.
Check the published site, not just the preview
- Useful pages return HTTP 200 and have the intended content.
- Moved URLs redirect directly to the correct destinations.
- Missing pages return a real 404 instead of a success status.
- Canonical URLs use the live domain and the intended paths.
- The production site is not carrying preview noindex instructions.
- Robots rules allow the pages and assets needed for crawling.
- Internal links and article contents anchors resolve correctly.
- The sitemap lists live canonical URLs and accurate modification dates where supplied.
- Structured data describes visible content and real business details.
- Mobile navigation, forms and primary actions still work.
If the domain stays the same, the focus is on page and URL changes. A domain move needs additional planning. Google’s site move documentation explains the distinction and the checks involved.
Watch the pages that matter after launch
Use Search Console to review indexing, submitted sitemap processing and changes in page queries and clicks. Compare the pages that previously brought relevant visitors rather than judging the redesign from a single search performed on your own phone.
Some fluctuation can occur as changed pages are crawled and processed. Investigate missing URLs, incorrect redirects or unexpected indexing exclusions before assuming a design choice caused a ranking change. Keep a dated record of changes so the evidence is easier to follow.
Further reading
Official documentation behind the technical guidance in this article.