Record the pages and journeys that already matter.
02
Map
Decide what stays, moves or retires.
03
Monitor
Verify the release and watch the transition.
An example journey, shaped around your requirements.
A practical decision guide
Plan the work with clearer questions.
Written by Softglimmer Services. Use this guide to prepare a brief and compare options against your actual requirements.
Record the current website before designing
Start with a crawlable page list and a copy of the existing site. Include titles, descriptions, headings, canonical URLs, important images and form destinations. If Search Console and analytics are available, identify useful landing pages, search queries and conversion paths. Do not treat every low-traffic page as disposable; some pages answer a narrow but important customer question.
Document the current domain variants, redirects, sitemap and robots rules. Note external links or campaigns pointing to specific URLs. Capture working forms and integrations so they can be checked after launch. This baseline gives the redesign team something concrete to preserve and helps distinguish an existing issue from a new regression.
Make a URL decision for every existing page
Keep a useful URL when the page purpose remains the same. If a URL must change, map it to the closest relevant replacement. Avoid sending every old page to the homepage; visitors expect the subject they requested. Identify genuinely retired pages separately and decide their response intentionally.
Google’s migration guidance describes planning URL mappings, redirects and verification during URL changes. A design-only change may not need a domain move, but it still needs route and internal-link checks. Review proposed navigation against the old inventory before development finishes. A redirect spreadsheet is easier to inspect than emergency rules added after customers report broken links.
Carry forward accurate service descriptions, original project evidence and useful answers. Improve confusing structure and weak wording without replacing everything with generic keyword paragraphs. Check that important text is rendered as text, that headings describe their sections and that images have useful alternative descriptions where needed.
A new page can be better organised while retaining the subject and supporting detail of the old page. Review titles, descriptions, internal links and canonical URLs together. The canonical should describe the public page, not a localhost or preview address. Keep preview environments out of search while you review them, then verify that launch settings allow the intended public pages to be crawled.
Test the release as a visitor and a crawler
Before switching the public site, test the important routes and their redirects, check the sitemap, and confirm that images and scripts load. Follow the enquiry journey using agreed test data. Check analytics configuration and conversion events without confusing a button click with a completed lead.
Inspect the rendered desktop and mobile pages, not only the source files. Look for cropped headings, compressed diagrams, overlapping navigation, unreadable cards and missing form feedback. Verify response statuses as well as appearance. A branded error page served with a successful status can conceal a routing problem. Prepare a rollback route before the final switch.
Watch the transition after launch
Submit or verify the public sitemap in the relevant search tooling, monitor indexing and review important old URLs. Search changes can take time, and a migration does not guarantee stable positions every day. Compare trends against the baseline, investigate meaningful changes and fix specific problems such as missing redirects or excluded pages.
Keep the old mapping and release evidence accessible to the maintenance team. If a campaign or partner later reveals an old link, it should be possible to trace the intended replacement. Treat migration as a monitored transition rather than a single upload. The website can look new on launch day while search systems are still processing the change.
Before you decide
Common questions.
Can you guarantee that rankings will stay unchanged?
No. A migration plan reduces avoidable problems, but search positions and indexing can change. Monitoring is part of the scope.
Should every page URL change during a redesign?
No. Keep relevant URLs where practical. Change them when there is a clear reason and a reviewed replacement mapping.
Is submitting a sitemap enough?
No. Check response statuses, redirects, internal links, canonical tags, crawl settings, rendered content and the important visitor journeys.
Connected services
Build the right combination.
Start with the primary need, then connect the supporting work where it is useful.
