How to redesign your website without losing SEO

What actually loses the rankings

Visual design is almost never the cause. A site can look completely different and hold every position it had. What loses rankings is a short list of specific, mechanical things:

• URLs changed with no redirect, or with redirects that chain through several hops, or loop
• Pages removed or merged into others without a decision about which URL survives
• Body copy cut because the new template only had room for 80 words
• Title tags and H1s rewritten in brand voice, so the words people search for are gone
• Internal links dropped when the old nav and in-body links didn't carry over
• A staging site launched with its noindex tag or robots.txt block still in place
• A page that's slower, or harder to use on a phone, than the one it replaced

Every one of those is decided before launch day.

Start with an inventory of what you have and what it earns

Before anyone talks about design, you need a list of your current pages and what each one does for you. Either produce it yourself or make it the first deliverable you ask for.

Five sources:

• A full crawl of current URLs. Screaming Frog's free tier covers up to 500 URLs, which is most small-business sites. Export the list.
• GA4. Landing pages by organic entries, last 12 months, in the standard Landing page report. Twelve months, not three, so you catch seasonal pages.
• Search Console. Top queries and top pages, 16 months. This tells you which pages rank for something you care about.
• Backlinks. Which pages have links from other sites. Ahrefs or Semrush free tools will get you the top ones. A page with links from elsewhere is expensive to lose.
• Conversions. Which pages produce form fills and calls. If you don't track this yet, fix it before the rebuild, not after.

The output is one ranked spreadsheet in three groups: pages that must survive untouched, pages that can merge, and pages nobody reads. That document drives every decision after this one. Expect to spend a day or two on it.

Decide the new URL structure before anyone designs a page

The cheapest answer is to keep your existing URLs wherever the page still exists. A URL you don't change can't break. "Modernizing" the URL structure for its own sake buys you nothing and costs you a redirect for every page.

Changing them is genuinely worth it in three cases: you're moving platforms and the old platform forced a structure on you (/product-page/1234), the current structure is nonsensical or inconsistent, or you have duplicated location pages competing with each other and need one clean set.

Whatever you choose, pick one version of every page and stick to it:

• Trailing slash or no trailing slash — one, not both
• www or non-www — one, redirecting to the other
• HTTPS everywhere, with HTTP redirecting to it
• Lowercase URLs, since /Services and /services can be treated as two pages
• Query strings (?utm_source=, filters, session IDs) canonicalized back to the clean URL

Write these down as rules for the build. They're easy to get right up front and tedious to unpick later.

Build the redirect map: one old URL to one new URL

The redirect map is a two-column sheet: every old URL in column A, its closest equivalent new URL in column B. That's it. Build it from your crawl so nothing is missed, including pages you forgot existed.

The mechanics that matter:

• 301, not 302. A 301 is permanent and passes the signals across. A 302 says "this is temporary," and temporary is not what you mean.
• One hop. Old URL straight to final new URL. If you're also moving to HTTPS or changing www, make sure the page redirect lands on the final version rather than bouncing through two more.
• No mass redirect to the homepage. Pointing 200 dead URLs at / can be treated as a soft 404 and it's a bad experience for the person who clicked.
• Pages with no equivalent. If a page has no replacement and earns nothing, let it 404 — that's an honest answer. If it has links or traffic, redirect it to the nearest genuinely relevant page, or rebuild it.

This map should be agreed with you before a single URL changes. It's your document to approve, not a developer's internal note, because you're the one who knows that the quiet page about private events is the one that books the parties. Ask for it in a shared sheet, read it row by row for your top pages, and sign off.

That's how I run a rebuild: a page plan and one-to-one redirects agreed before anything moves, website build and migration handled end to end, and the option to manage the site after launch — weekly or as needed, agreed up front. The client owns the finished site: domain, hosting and code.

Keep the content and signals that earned the rankings

Page by page, carry across:

• The body copy that answers the query. All of it.
• Title tags and H1s, word for word unless you have a search reason to change them
• Image alt text
• Internal links between related pages, in the body copy as well as the nav
• Structured data — review markup, FAQ, local business, product
• Name, address, phone and hours on location pages, identical to the format used elsewhere

If a page genuinely needs rewriting, improve it: answer the question better, add what's missing. Don't shorten it to fit a template. If the new design can't hold the content a ranking page needs, change the design, not the page.

Merging two pages that both rank is a real decision, not a tidy-up. Pick the URL with more links and stronger query coverage as the survivor, move the useful content from the other into it, and 301 the loser to it. Expect the merged page to settle somewhere between the two for a while.

Launch day: the short list that has to be checked

Do this within the first hour, not the first week:

• Remove the staging noindex meta tag and any robots.txt block. Check the live source, not the developer's word.
• Crawl a sample of 50 old URLs from your map and confirm each resolves in one hop to a 200.
• Submit the new XML sitemap in Search Console, and check it lists live URLs only. Keep a sitemap of the old URLs submitted alongside it for a few weeks, so Google crawls the redirects sooner.
• Check canonical tags point at the live, final version of each page.
• Re-verify GA4 and conversion tracking — form submissions, call clicks, booking events. If this breaks you lose the ability to see inquiries, which is worse than losing a ranking.
• Update the website link on your Google Business Profile, and any citation or directory link pointing at a URL that moved.
• Run a PageSpeed Insights lab test and check mobile rendering on real pages: a service page, a location page, a blog post. Not just the homepage. Real-user Core Web Vitals take about four weeks to show up, so check them again a month after launch.

What normal looks like for the first 60 days

Some fluctuation while Google recrawls the new URLs is normal. Positions move, impressions dip, a page drops and comes back. Recovery is measured in weeks, and on a larger site it can run longer. Don't change anything in week one on the strength of a bad Tuesday.

Monitor four things weekly:

• Organic entries to the pages on your "must survive" list, not sitewide traffic
• Search Console's Pages report — indexed versus not indexed, and why
• Crawl errors and your server's 404 log
• Rankings for the handful of queries that actually bring you buyers

The signals that mean something is broken rather than settling: a whole page type missing from the index (all your location pages, say), 404s showing up on URLs that used to get traffic, canonical tags pointing at staging, or a decline that keeps going steadily past the first few weeks instead of flattening out.

If it's still falling after that, it's a diagnosis job — find the broken signal, fix the page, rebuild what was cut — and that's SEO work rather than another design round. Worth bringing in help at that point, or earlier if you want the redirect map and page plan reviewed before the build starts. That's the cheaper moment.