A website redesign should make your business easier to understand and easier to contact. What you don’t want is a better-looking website that quietly loses the pages, links, or useful information people were finding on Google.
To protect your Google rankings during a website redesign, start by identifying what already brings visitors and inquiries to your site. Preserve useful content and working URLs where practical, plan redirects for addresses that must change, and test the new site before and after launch. These steps reduce avoidable problems; they don’t guarantee that rankings will stay exactly the same.
If you’ve already decided a redesign is needed, this is the conversation to have before approving the new layout. Search visibility belongs in the project plan, not on a troubleshooting list after the site goes live.
Start with what the current website does well
It’s easy to look at an old website and see only the dated colors, awkward navigation, or photos you meant to replace years ago. But a page that looks tired may still answer an important customer question and bring in worthwhile inquiries.
Before anything is removed, ask for a record of the existing pages and their performance. Which service pages receive search traffic? Which pages lead to calls or quote requests? Are there older articles or downloadable guides that other websites link to?
Google Search Console’s Performance report provides clicks, impressions, click-through rate, and average position. Use those alongside your website analytics and inquiry records. Search clicks alone don’t tell you which visitors became customers, and a low-traffic page may still answer an important question in the sales process.
Save a dated baseline covering a useful period for your business. If demand is seasonal, last month’s results may not be a fair comparison for next month’s launch. Record the dates of promotions and major campaign changes, too, so they don’t get mistaken for redesign effects.
Our article on signs your small business website needs a redesign helps with the decision to rebuild. This inventory helps you decide what the rebuild must preserve.
Keep useful page addresses unless there’s a reason to change them
A new design doesn’t require a new address for every page. You can improve the layout, images, navigation, and wording while keeping an established service URL.
For example, a hypothetical contractor with a useful bathroom remodeling page doesn’t need to change its address just because the new menu says “Bathrooms.” Ask what a proposed URL change accomplishes. If the answer is simply that the new theme generates different addresses, that is worth discussing before launch.
When addresses do need to change, create an old-to-new URL map. Each old page should have an intentional outcome, not a blanket instruction to send everything to the homepage.
| Situation | Planned action |
|---|---|
| The page still serves the same purpose | Keep its URL where practical and improve the page itself. |
| The page moves to a new address | Redirect the old address to its relevant replacement. |
| Two genuinely overlapping pages are combined | Keep their useful material and redirect the retired page to the combined resource. |
| The content is gone with no suitable replacement | Return a proper not-found or gone response rather than sending visitors somewhere unrelated. |
Google’s redirect documentation explains permanent redirects such as 301 and 308. Your developer should implement the appropriate response and test the destination. A visitor following an old service link should reach the corresponding service, not have to start their search again.
Redirects are also not a substitute for updating your own links. Once a page has moved, menus, buttons, and related articles should link directly to the new address.
Improve the content without losing the answers
Shorter isn’t automatically clearer. A new layout may look cleaner after removing several paragraphs, but what did those paragraphs explain? Service areas, project requirements, turnaround times, and what happens after an inquiry can all matter to a potential customer.
Imagine replacing a detailed repair page with a photograph and the line “Solutions for Every Home.” It may look impressive, but someone trying to find out whether you repair their type of equipment has lost a useful answer.
You don’t need to preserve every sentence. Remove outdated claims, repetition, and services you no longer offer. Keep the substance that helps readers decide whether you’re a good fit. If a page needs substantial rewriting, give the writer its purpose, the questions it should answer, and the evidence supporting its claims.
That’s one reason SEO should be built into web design from day one. The structure and the message need to work together. Trying to fit the missing information into the finished layout can create unnecessary compromises.
Don’t let development settings follow the site into production
A development copy needs to be kept separate from the public website. Before launch, agree on how it’s protected and who is responsible for checking the live site’s settings.
One important distinction: blocking crawling with robots.txt is not the same as keeping a page out of Google’s index. Google explains that a crawler must be able to access a page to see its noindex instruction. Private development sites should have appropriate access protection rather than relying on a robots.txt rule to keep them confidential.
At launch, the intended public pages must not retain development-only noindex instructions or access restrictions. Also check the canonical URL, which indicates the preferred address for a page. It should not still point to the staging domain. Google’s canonicalization guidance explains how this signal works; it isn’t a guarantee that Google will choose the nominated URL.
You don’t have to inspect source code yourself. Ask your developer to demonstrate the checks on a service page, an article, and any other important page type. “We installed an SEO plugin” isn’t an answer to whether those settings are correct.
Give launch testing a clear owner
Set aside time for testing instead of treating it as whatever fits into the last hour. Decide who can approve the launch, who handles unexpected problems, and how the previous working version could be restored if necessary.
A practical launch check should include:
- Important old URLs reaching the correct pages, with no redirect loops.
- Public pages loading successfully and using the intended indexing settings.
- Navigation, internal links, images, and downloads working.
- Contact forms, phone links, bookings, and checkout working where applicable.
- Analytics and conversion tracking tested rather than merely copied across.
- Mobile layouts remaining readable and usable on real devices.
A backup is useful only if someone knows what it contains and how to restore it. For a store or busy lead-generation site, the recovery plan must also account for orders or inquiries received after the backup was taken.
Keep major changes manageable. Google’s site-move guidance recommends separating changes where practical and warns that significant moves can bring temporary ranking fluctuations. If the project also includes a new domain, new platform, and new copy, agree on a sequence rather than assuming one dramatic launch is simpler.
Watch what happens after launch
Check the live site immediately, then review it again as search and business data accumulate. Look at important pages individually, not just the sitewide traffic total. An increase in blog visits can hide a decline on a service page that matters more commercially.
If inquiries fall, test the form before assuming your rankings collapsed. If tracked traffic disappears suddenly, confirm the analytics setup. If specific old URLs return errors, check their mappings. Start with observable faults rather than guessing at an algorithm explanation.
Also update the sitemap to reflect the intended live URLs and review indexing information in Search Console. Submitting a sitemap helps discovery; it doesn’t guarantee that every page will be indexed or rank. Google’s sitemap overview makes that limitation clear.
Agree on a post-launch review period and responsibilities in advance. Ongoing website management can provide a place for these checks, but the proposal should say what is actually included.
Ask for the SEO handover, not just the finished design
Before signing off, ask for the final page inventory, redirect map, test results, access details, and a record of any unresolved issues. You should know what changed and whom to contact if a problem appears.
A successful redesign is more than a fresh look. It should preserve what was useful, correct what wasn’t, and make the next step easier for your customers. If you’re planning a project, our SEO services can help you bring search considerations into the discussion before launch.
0 Comments