A website redesign can make your business easier to trust and use, but changing the design can also change the pages search engines already know. If important URLs disappear, useful service information is thinned out, or internal links no longer point to the right places, customers may struggle to find the pages they used to reach through search. The risk is not a reason to avoid a redesign; it is a reason to plan what must carry across before development begins. Start by recording the current site’s important URLs, search visibility, key content and technical settings. Then decide which pages should stay, be improved, be combined or be retired, and map any changed address to the closest relevant replacement. Keep the new site crawlable and test redirects, mobile layouts, canonical tags, metadata, analytics and forms before launch. After launch, check that search engines can access the site and watch for broken links, indexing issues and unexpected traffic changes. This guide sets out a practical preservation plan for small businesses. It focuses on decisions you can make with your designer or developer, while recognising that rankings can fluctuate and no checklist can guarantee a particular search outcome.
Content
Record the SEO baseline
Build a useful page inventory
Before changing the design, record how the current website is performing and how it is put together. This gives your team a reference for checking the new site and helps identify pages or settings that need careful handling. Set a clear date for the baseline and note the period covered by any search or analytics reports, so later comparisons use the same timeframe.
Start with a complete list of current URLs. You can collect these from the website’s sitemap and a crawl of the live site, then check the list against URLs in Google Search Console and your analytics platform. Include pages, posts, service descriptions, downloadable resources and other useful destinations—not just the main navigation. Record each URL exactly as it appears, including its path and any relevant trailing slash. Flag duplicates or URLs that appear to serve the same purpose for later review rather than deleting them during the inventory.
Capture search and technical data
Next, identify the pages that already attract organic search visitors. In Search Console, export available data for clicks, impressions, average position and search queries; in analytics, review organic landing pages and the visits or enquiries associated with them. These measures describe different things: Search Console reports how pages appear in Google Search, while analytics can show what people do after arriving. Keep the date range, filters and report settings with each export. Treat the figures as a snapshot, not a promise that the redesigned site will receive the same traffic.
Add practical context to your inventory. For each important URL, note its purpose, its main audience, whether it receives organic visits, and whether it leads to a useful customer action such as a call or enquiry. Record the page title and meta description, indexability, canonical URL and any relevant structured data. Also note site-wide settings that could affect search, including robots directives, the sitemap location, preferred domain and any rules that prevent search engines from accessing a staging site. If a developer or SEO specialist manages these settings, ask where they are controlled and how they will be carried across.
A spreadsheet is often enough for a small website. Keep the source URL and the evidence together, and store exports or screenshots in a shared project folder with a clear date. Restrict access to any customer or business data that should not be widely shared. The purpose is to create a reliable reference, not to collect every available metric.
Hypothetical: A small clinic exports its current URLs and notes which service pages bring search visits. It records the reporting period, the pages’ enquiry role and their current titles and canonical URLs. When the redesign team plans the new structure, it can see which pages deserve particular attention and compare the new setup with the original—without assuming that search performance will remain unchanged.
Agree who owns this record and make sure the people building the site can use it before they change URLs or settings. A careful baseline makes later decisions easier to explain and gives the launch team a practical checklist for checking that important pages and technical details have not been overlooked.
Decide what content stays
Assess each page’s customer and search purpose
A redesign is a chance to make a website clearer, not a reason to delete everything that looks old. Review pages one by one and decide whether to keep them as they are, improve them, combine them with related content or retire them. Make the decision using three questions: does the page help a customer, does it serve a distinct search purpose, and is its information still accurate?
Start with an inventory of existing pages, then add notes about their intended audience, main purpose and any useful evidence of value. Search data can show which pages attract organic visits or enquiries, but it is only one part of the picture. A page may be valuable because it answers a common pre-sale question, supports an important service or helps existing customers, even if it receives few search visits. Ask staff who speak with customers which pages they regularly rely on, and check whether a page is linked from other parts of the site.
Choose whether to keep, improve, combine or retire
Keep a page when it is accurate, useful and focused on a purpose that is not covered elsewhere. It may need only a light edit for clarity or consistency. Improve a page when the subject remains relevant but the information is thin, confusing, out of date or missing details customers need to make a decision. Check practical facts carefully, including service availability, locations, eligibility, processes and contact details. Where advice has legal, health or other professional implications, have the appropriate person verify it before publication.
Combine pages when several cover substantially the same subject and leave customers unsure where to look. For example, overlapping pages about one service might be brought together into a clearer, more complete page. Before combining them, compare the questions each page answers and the search purpose each appears to serve. Preserve useful details and distinct answers; do not simply paste everything into a long page. If the pages address genuinely different needs, keeping separate, clearly differentiated pages may be more helpful.
Retire content when it is no longer accurate or relevant, duplicates another page without adding value, or serves no clear customer or business purpose. Do not remove a page solely because its traffic is low: consider seasonal demand, recent changes, customer enquiries and whether the page supports another important journey. If information is outdated but the topic still matters, update it rather than removing it. When retiring a page, record the decision and the reason so the redesign team can handle its URL and any links deliberately.
A simple review sheet can keep decisions consistent across the business. For each page, note the evidence considered, the chosen action and who is responsible for checking or rewriting it. Agreeing these decisions before new page layouts and copy are finalised helps prevent useful information from being lost and reduces last-minute disputes. It also gives the team a clear list of content to prepare and review before launch.
Treat this as an editorial decision, not just a design preference. The new site should make important information easier to find while retaining the detail customers need and the distinct purpose of each page. Once you know what stays, changes, combines or goes, you can plan the affected URLs and destinations as part of the next step.
Map URLs and redirects
Build a one-to-one redirect map
Before changing the site structure, export or record the existing URLs and compare them with the planned URLs. Include pages, posts, product or service pages, and any other addresses that people or search engines may use. A spreadsheet makes the changes easier to review: list each old URL, its planned status, its destination if it is changing, and who will check it. Include important variations, such as URLs with and without a trailing slash, where relevant to the site.
For every URL that will change, choose the closest equivalent page on the redesigned site. A permanent server-side redirect, commonly a 301, tells browsers and search engines that the page has moved. Hypothetical: If /services/skin-checks/ moves, redirect it to the new skin-check service page rather than the homepage. This gives visitors a useful next step and preserves the connection between the old page and its subject.
Keep destinations relevant and redirects direct
For a removed page, first decide whether its information belongs on an existing page or a new one. If so, redirect the old URL to that relevant destination. If there is no suitable replacement, do not redirect it to a loosely related page simply to avoid an error. Consider whether the page should remain available, or whether it should return an appropriate not-found or gone response. A clear not-found page can help visitors recover, but it does not make an irrelevant redirect useful.
Keep redirects direct. If an old URL points to a second URL that then points to a third, update the rule so the old address goes straight to the final destination. Check for redirect loops, incorrect destinations and accidental temporary redirects where a permanent move is intended. Test both the old and new addresses before launch, including any important URL variations, and confirm that the final page loads successfully. Avoid redirecting a large group of unrelated pages to the homepage: visitors may not find what they expected, and search engines may treat those redirects as soft errors rather than meaningful moves.
Redirects are not a substitute for updating the site itself. Replace old links in navigation, page copy, buttons and other internal references with the new URLs. Check links from important pages, as well as links in downloadable resources or other materials you control. Update canonical tags and the XML sitemap to use the preferred, current URLs; the sitemap should not list addresses that only redirect. This helps visitors and crawlers reach the intended pages without taking an unnecessary detour.
Keep the redirect map with the launch checklist and assign someone to test it after the new site is live. Review server or website logs, crawl reports, and available search-console data for 404s and unexpected redirect behaviour. Fix broken links and add redirects when a genuinely useful replacement exists. Retain redirects for as long as old links may still be used, rather than removing them as soon as the redesign is complete. A careful URL map makes page moves easier to manage and reduces avoidable disruption for returning visitors.
Carry technical SEO across
Audit page-level search signals
A redesign can preserve URLs and content yet still weaken search visibility if important technical signals are lost or changed accidentally. Before launch, compare the current site with the new version page by page. Start with priority landing pages identified in your SEO baseline, then check other pages that will remain available. Record what is changing and who will verify each item; this makes it easier to spot missing settings during testing.
Review page titles and meta descriptions in the page editor or SEO plugin. Confirm each important page has a relevant, distinct title that describes its topic and a useful description for search results. Avoid copying one title or description across the whole site. These elements should reflect the page’s actual content and the wording customers are likely to use; do not add keywords that make the text inaccurate or awkward. A search engine may choose a different description for a result, so treat the description as guidance rather than a guaranteed snippet.
Check heading structure as well as appearance. Each page should have a clear main heading that describes its subject, followed by subheadings in a logical order. Make sure headings have not been removed, duplicated or used only to achieve a visual style. If the design uses different text sizes, confirm that the underlying heading levels still communicate the content hierarchy to visitors and search engines.
Verify canonical tags, structured data and crawl access
Inspect canonical tags on the live and staging versions. A canonical tag indicates which URL should be treated as the preferred version when similar pages or URL variations exist. Confirm that each retained page points to the intended live URL, especially after changes to domains, URL formats or trailing slashes. Check that staging pages do not declare the staging address as the preferred version. Canonical tags are signals, not a substitute for redirects or consistent internal links, so they should agree with the site’s URL plan.
Review structured data, such as organisation, local business, product or service details, only where it accurately describes visible page content. Carry over relevant markup and update details that have changed, including names, addresses or service information. Remove markup for content that no longer exists. Test representative pages with a structured-data testing tool and resolve errors that affect the markup you intend to use. Do not add types or claims simply to seek enhanced search results; eligibility and display are determined by search engines.
Check that the XML sitemap is generated for the new site and lists the intended canonical, indexable URLs—not staging pages, redirects or pages marked noindex. Confirm the sitemap can be accessed and submit or resubmit it through the relevant search engine tools if your business uses them. A sitemap helps discovery but does not guarantee that URLs will be crawled or indexed.
Staging access needs its own explicit check. During development, restrict staging with suitable access controls and prevent search engines from indexing it, for example through authentication and an appropriate noindex setting. A robots.txt block alone can prevent crawling without reliably preventing a URL from appearing in search results. Before launch, remove staging-only restrictions from the live site, then confirm the live pages can be crawled. After launch, verify the staging site remains private or otherwise unavailable to search engines.
Add these checks to the launch checklist and test a sample of key pages on both desktop and mobile. If a technical setting is managed across the whole site, inspect the site-wide configuration as well as individual pages. Keep a record of the final checks so the person monitoring the launch can distinguish an expected change from a configuration error.
Test and monitor the launch
Test key journeys before launch
A redesigned website can look finished while important journeys or search signals are not working. Before launch, test the site on its staging address, then repeat the critical checks on the live site as soon as it is published. Keep a record of issues, who will fix them and whether each item has been checked again. This makes it easier to distinguish a launch problem from a change that was already present.
Start with the URL map from the redesign plan. Test a sample of important old URLs, including high-value service pages and organic landing pages, and confirm each redirect reaches the intended new page. Check that redirects do not loop or pass through unnecessary steps. Also test links within the new site: menus, buttons and contextual links should lead to the right destinations, not to old URLs or error pages. Where a page is intentionally removed, confirm its response is appropriate rather than redirecting every retired page to the homepage.
Run through key tasks on a phone as well as a desktop browser. Check that text is readable, navigation works, buttons can be tapped and important content is not obscured or difficult to reach. Submit each form using a test entry, and verify that validation, confirmation messages and notifications work as intended. Coordinate test submissions with the business so they are not mistaken for genuine enquiries. If the site supports bookings, purchases or other important actions, test those journeys too.
Use a launch checklist such as this, adapting it to the site’s features:
- Confirm the live site is accessible to search engines and is not carrying over a staging-site password or noindex setting. Check robots.txt, canonical tags and the XML sitemap for unintended exclusions or staging URLs.
- Review key page titles, headings and indexable content on the live pages. Check that the sitemap contains the intended canonical URLs, then submit or resubmit it in Google Search Console if the property is set up.
- Test analytics and any configured conversion events. Use a test visit or form submission to check that expected activity is recorded, and ensure tracking does not collect unnecessary personal information.
- Check important pages at common mobile and desktop screen sizes, and test forms, navigation, phone links and other primary actions.
Monitor search and site health after launch
After launch, monitor Google Search Console for indexing changes, crawl issues, excluded pages and new 404 errors. Check the sitemap status and inspect individual priority URLs if they are not appearing as expected. Review analytics for organic landing-page visits and completed actions, comparing them with the recorded baseline. Allow for normal variation, seasonality and reporting delays; a short-term movement alone does not establish the cause. Look for patterns such as several important pages losing visibility or a sudden rise in errors.
Check more frequently in the first days after launch and continue regular reviews over the following weeks. If a problem appears, first confirm the affected URL and reproduce the issue, then check redirects, crawl access, canonical settings and page availability. Record what changed and retest the fix. Keep monitoring in the project plan, with a named person responsible for reviewing reports and escalating issues. This turns launch testing into an ongoing part of protecting the site’s search visibility and customer journeys.
Conclusion: protect what works
Make ownership and follow-up part of the launch plan
Treat the launch checklist as a shared working document, not a last-minute sign-off. Name one person to coordinate it and assign each check to someone responsible for verifying it. The developer might check redirects and crawl access, while the business owner confirms key pages, contact details and forms. Record who completed each item and note any issues that remain. For anything that cannot be checked before launch, agree who will follow it up and set a timeframe.
Keep the checklist active after launch. Schedule a review to check that important pages load, redirects lead to relevant destinations, forms work and analytics are recording visits. Monitor search indexing, crawl errors and organic traffic for changes that may need investigation. Compare what you see with the baseline you recorded, allowing for normal fluctuations rather than reacting to a single day’s data. If a problem appears, assign an owner, document the fix and check the affected page again. A clear handover and planned follow-up help the business protect useful work while dealing promptly with issues the redesign may uncover.
Explore related information: Booking Website Design & Development; Web Design Sunshine Coast.
