Website Redesign SEO: Protect What Already Works

A service page has disappeared, a useful guide now redirects to the homepage and a form no longer records the source of a lead. These problems rarely begin on launch day. They begin when a redesign is treated as a visual project with SEO and measurement added near the end.

The existing website contains more than old layouts. It contains URLs customers have saved, pages search engines know, links other websites have earned for you and evidence about which content supports sales. A redesign needs to account for those assets before replacing them.

This website redesign SEO guide explains what to preserve, what to change and how to check the result. It includes a page-decision table, a practical launch checklist and a monitoring plan for the first weeks after release. The goal is to improve the website without losing sight of the demand and customer behaviour it already supports.

Create an inventory before approving the new structure

Export the current URLs from your content management system, crawl and sitemap where available. Add information from Search Console, analytics and backlink reports to identify pages with continuing value.

Do not restrict the inventory to pages visible in the main navigation. Old articles, campaign resources, PDFs and product pages may still attract useful visits or external references.

Record each page's role. Is it generating leads, supporting a sales conversation, answering a common question or attracting relevant links? A page with modest traffic can still matter if the visitors are commercially suitable.

Useful fields for the inventory

• Current URL and page type.

• Main topic or customer need.

• Organic traffic and enquiries.

• Relevant external references.

• Proposed action and destination.

• Content owner and approval status.

This inventory becomes a decision record. It helps the design and development teams see what must survive a complete change of layout.

Give every valuable page an explicit decision

A redesign is a chance to remove weak material, but deletion should follow a reason. Do not remove content solely to reduce page count or make a menu look simpler.

Some pages need a rewrite. Others need consolidation. A few should remain largely intact until there is evidence that changing them will help.

Decision Suitable situation Required action Keep Page serves a clear need and performs usefully Preserve its role and verify the new template Improve Useful topic with incomplete or outdated contentRevise with the original intent in view Merge Several pages overlap substantially Create a suitable combined destination Move Content remains useful under a necessary new URL Map the old URL to its closest replacement Remove Content has no continuing purpose or replacement Return an appropriate removal response

Keep the reason beside the decision. That makes later investigation much easier than trying to reconstruct a conversation from a launch meeting.

Avoid URL changes that serve no real purpose

A cleaner-looking URL can be appealing, but changing established addresses creates additional migration work. Preserve useful URLs where practical.

If the platform or structure requires a change, map every important old address to its relevant new destination. Review mappings manually for commercially important pages.

Google's site-move guidance recommends preparing URL mappings, using appropriate permanent redirects and monitoring the move. It advises keeping redirects for at least a year and notes that ranking fluctuations can occur as pages are processed.

Do not send unrelated removed pages to one general destination. A visitor following a product reference expects that product or a useful replacement, not an unexplained trip to the homepage.

Update internal links to the new destinations too. Redirects should support old references, not become the permanent navigation method inside the rebuilt website.

Treat the redirect map as a deliverable with an owner, not a technical detail someone will handle later.

Preserve intent when rewriting the content

A page can keep its URL and still lose much of what made it useful. A rewrite that replaces specific service detail with broad brand language may weaken the answer for both visitors and search engines.

Review the searches and customer questions associated with each important page. Preserve the useful substance, then improve clarity, accuracy and presentation.

For a service page, that could mean retaining the scope, relevant process detail, examples and fit criteria. For a product page, it could mean protecting specifications, compatibility and availability information.

Avoid letting visual symmetry dictate content decisions. Different services may need different amounts of explanation. A complex implementation page should not be reduced to three short cards simply to match a simpler service.

Brand language can create distinction, but the visitor still needs to know what the business does and whether it can solve the problem.

Design navigation around actual customer tasks

A new menu should make the website easier to use without hiding valuable content. Test it with realistic tasks: finding a service, comparing options, checking an example and making an enquiry.

Keep the relationship between overview pages and detailed pages clear. Use contextual links where a reader needs the next layer of information.

For large sites, review whether important pages have become difficult to reach after sections were consolidated. A page that survives the migration but loses meaningful internal links may receive less attention from visitors.

Ask users to complete a task

Instead of asking whether they like the navigation, ask them to find the right service for a defined need. Notice the labels they interpret correctly, the paths they abandon and the information they expect to find.

A small number of observed sessions can expose obvious problems before the new structure becomes expensive to change. Treat those observations as design evidence, not as a precise estimate of conversion impact.

Test the staging website with a clear checklist

The staging environment should allow a thorough review without accidentally becoming the public search version of the website. Coordinate access controls and indexing settings with the development team.

Before launch, check representative pages from every template. A single product or article test does not prove every page behaves correctly, but it can expose a shared issue early.

Area Check Content Main copy, headings, images and downloads are present Links Navigation and contextual links reach intended destinations Indexing Live settings are planned for the correct pages CanonicalsTags use the intended public URLs Forms Valid submissions arrive in the right system Tracking Events fire once and carry the expected information Mobile Reading, selection and submission work on small screens Redirects Old priority URLs reach relevant replacements

Record issues with an example URL, reproduction steps and expected behaviour. “The mobile page feels wrong” is harder to fix than a clear description of a button hidden behind a banner.

Keep performance connected to the new design

Large images, video backgrounds, animations and third-party scripts can affect the experience. Test them as part of the actual page rather than approving them only in design files.

Use performance measurements to locate problems, then inspect the relevant interaction. A layout shift near a booking button can interrupt the task on an otherwise polished page.

Review the new forms closely. Design changes can remove labels, weaken error messages or introduce fields that are awkward on a phone. These are commercial issues, not cosmetic preferences.

Retain enough baseline information to compare the new site sensibly. If you change the analytics implementation at the same time, document the effect on reporting definitions.

The new design should improve the customer's work, not merely the screenshots used to announce the launch.

Use a launch decision, not just a launch date

A calendar deadline should not be the only condition for release. Agree on what must be complete, which issues are acceptable and who can approve the final decision.

Identify problems that block launch: inaccessible priority pages, failed forms, broken checkout, missing redirects or accidental indexing restrictions. Keep minor refinements separate so the team can see the real risk.

Prepare a rollback or recovery plan appropriate to the platform. Confirm who can restore the previous release, what data might change during the transition and how the team will communicate if something fails.

Choose a launch window that gives the responsible people time to observe and respond. A handover at the end of the working week can leave avoidable problems unattended.

The release is complete when the live website has been checked, not when the files have been deployed.

Monitor the pages that mattered before launch

Review live priority URLs immediately. Then monitor traffic, indexing, form delivery and sales outcomes over the following weeks, allowing for reporting delays and the sales cycle.

Use Search Console's URL Inspection tool to investigate specific pages when their status is unclear. Compare the live page with the available indexed information rather than assuming the two update at the same time.

Break the review down by page group. A stable sitewide total can hide a fall in one profitable service category. Brand traffic can mask weaker non-brand visibility too.

If performance falls, inspect the changed pages and technical behaviour before making another major redesign decision. Check content removal, mapping errors, internal links, tracking changes and availability.

Keep a log of releases and repairs. It gives later analysis a timeline and reduces the chance of treating several overlapping changes as one unexplained event.

Frequently asked questions

Can a website redesign affect SEO?

Yes. Changes to URLs, content, navigation, templates and indexing settings can affect search performance. Planning and testing reduce avoidable disruption, but no process can guarantee that rankings will remain unchanged after a substantial redesign.

Should I keep the same URLs during a redesign?

Keep useful existing URLs where practical. Change them when there is a clear structural or platform reason, then map old pages to relevant replacements and update internal references. Cosmetic preference alone rarely justifies extra migration work.

How long should I monitor the site after launch?

Check critical functions immediately and continue reviewing priority pages through the following weeks and relevant sales cycle. Larger migrations may need longer observation. Keep routine technical monitoring after the launch period rather than treating SEO as finished.

Make the redesign accountable to the business

A successful redesign preserves useful demand and improves the way customers act on it. Build the inventory, decide what each page should become, test the live behaviour and keep monitoring the pages that support sales. Design, development and SEO work best when those responsibilities are agreed before launch.

Talk to The Coral Room about website design, development and SEO planning for a redesign that respects what already works.