How to redesign your website without losing your search rankings

Redesigns rarely lose rankings because of the new design. They lose them for boring reasons: URLs change without redirects, pages that ranked get cut or thinned out, metadata goes missing, or the new site hides its content behind JavaScript. Every one of those can be caught before launch.

Below is the checklist we use, with our own 2026 rebuild of proindies.com as the worked example. The old site was a set of hand-built HTML pages. The new one is a Next.js site exported as static HTML and hosted on GitHub Pages.

1. Take an inventory before anyone opens Figma

You can't protect what you haven't listed. Before design starts, collect:

Every URL that exists today. Crawl the site with a tool like Screaming Frog, and add anything from your current sitemap.
The pages that bring in traffic. Export the Pages report from Google Search Console, sorted by clicks over the last few months.
Pages with links from other sites. These carry authority you really don't want to throw away.
Titles, meta descriptions, headings and structured data for your important pages.

On our site, the list was short and clear: the home page, five inner pages at /services.html, /our-work.html, /about-us.html, /contact-us.html and /start-project.html, plus a calculator app at /calc-app/. Those were the URLs in our old sitemap, and the ones people had linked to.

2. Decide what happens to every URL

Each old URL gets one of three outcomes:

Keep it. Same address, new design. This is the safest option by far.
Redirect it. If the address has to change, send a permanent (301) redirect to the closest new page. Avoid pointing everything at the home page, which Google may treat as a soft 404.
Retire it on purpose. If a page has no traffic, no links and no replacement, let it return a proper 404 and remove it from the sitemap.

Write this down as a spreadsheet: old URL, new URL, outcome. It's dull, and it's the single most useful document in a redesign.

For us, the call was easy. Modern frameworks prefer clean paths like /services/, but our five inner pages were indexed and linked as .html files, so we kept them exactly as they were. The build exports each page normally, then a small post-build script copies it back to its original .html path. GitHub Pages doesn't support server-side redirects, which was one more reason to keep the old addresses rather than move them.

New pages added in the redesign, like individual service pages at /services/ai-automation/ and case studies at /our-work/resync-spaces/, use trailing-slash URLs from day one. The rule was simple: nothing that already existed moved.

3. Tell search engines which URL is the real one

Static exports and modern frameworks often serve the same page at more than one address. Our export produces both /services/ and /services.html. Left alone, that's duplicate content.

The fix is a canonical tag on every page pointing at the one URL you want indexed. Ours point at the .html versions for the five legacy pages and at the trailing-slash URL for everything else. We also keep the site's URLs in a single routes file that every page and component uses for links, so nobody links to /services/ by accident and splits the signal.

4. Keep the content that ranks

It's tempting to cut copy in a redesign because shorter looks cleaner. If a page ranks for something, find out which parts of it answer that search, and keep them. You can rewrite them, restructure them and make them better, but don't remove the substance.

Titles and meta descriptions are worth rewriting when the old ones are weak, as long as each page stays about the same topic. Audit them while you're there. Our old services page turned out to have two meta description tags, one of them a long, generic paragraph. The new page has a single description that says what's on it.

5. Carry over the technical signals

This is where redesigns quietly lose ground. Check each of these on the new build:

Structured data. Our old pages carried ProfessionalService markup for the business, plus Service and BreadcrumbList markup on the services page. The new site keeps the same organization identifier (https://proindies.com/#organization), so the business is described as the same entity before and after. It also adds breadcrumbs to every inner page, Service markup on each service page, FAQPage where there's a visible FAQ and BlogPosting on articles.
robots.txt. We carried ours over unchanged. It points to the sitemap and explicitly welcomes search engines and AI crawlers.
Sitemap. The old one was written by hand and listed seven URLs. The new one is generated at build time from the site's content, so every service, case study and post is included automatically, with the legacy .html addresses listed as they are.
Rendered HTML. View the page source on the new site, not the inspector, and confirm headings and body copy are in the raw HTML. A static export makes this straightforward.
Analytics and verification. Make sure your analytics tag and any Search Console verification move across, or you'll have a gap in your data exactly when you need it.
Anything else with a public URL. Our calculator app, images and downloadable resources all stayed at their old paths.

6. Test on staging, then check again

Run the full list against the staging site before launch:

Crawl staging and compare the URL list to your inventory. Every old URL should resolve or redirect.
Check canonical tags, titles and descriptions on a sample of pages.
Run key pages through Google's Rich Results Test to confirm the structured data is valid.
Check page speed and Core Web Vitals on mobile.

One classic mistake: staging sites are usually set to noindex so search engines don't find them early. Make sure that setting doesn't follow the site into production.

7. Watch Search Console after launch

The SEO work carries on after launch. In the weeks after go-live, we:

Submit the new sitemap in Search Console.
Use URL Inspection on the most important pages to confirm Google sees the right canonical and the rendered content.
Watch the Pages report for new "Not found (404)" and "Duplicate without user-selected canonical" entries, and fix them as they appear.
Compare clicks and impressions for the top pages against the pre-launch baseline. Some movement is normal while pages are recrawled. A steady drop on a specific page means something about it changed that shouldn't have.
Re-test structured data on live pages, since it sometimes breaks between staging and production.

This is standard practice for us after any redesign, and it's the part that's easiest to skip once everyone is relieved the site is live.

The checklist, condensed

Inventory every URL, top page and linked page before design starts.
Keep, redirect (301) or retire each URL, and write it down.
Add canonical tags wherever a page can be reached at more than one address.
Keep the content that ranks, and improve rather than delete it.
Carry over structured data, robots.txt, the sitemap and analytics.
Confirm content is in the raw HTML.
Remove noindex from production.
Submit the sitemap and watch Search Console for the first few weeks.

If a redesign is on your roadmap, our web design & development and SEO & AI search teams can plan it with you.