How to Redesign Website Without Losing SEO: UK Checklist.

The design is signed off, the build is finished, and launch day goes smoothly. Two weeks later the organic traffic line is heading the wrong way and your marketing lead wants to know why. Nothing looks broken. Every page loads.

That's the trap with a relaunch. It rarely fails loudly on launch day. It fails in the index, page by page, over the following month: a URL that stopped existing, a heading that became an image, a service page whose copy was trimmed to fit the new template.

Most of the damage comes from decisions made long before anyone opens a colour palette. Which URLs survived. What happened to the pages that already ranked. Whether the new templates still render their text for a crawler. Whether anyone wrote down what normal looked like beforehand.

Treat a redesign as a controlled URL migration with a signed-off baseline and agreed rollback thresholds, and the risk drops sharply. That's the process I'd run on any UK relaunch, from a 40-page SME site to a public-sector estate with thousands of URLs.

Key Takeaways and Why Redesigns Lose Rankings

The pattern is familiar across relaunches. A services business relaunches with a cleaner template, a shorter homepage and a new URL scheme that drops the /services/ prefix. Launch week looks fine. By week three, the pages that used to generate quote requests are getting a fraction of the impressions they had, and nobody in the room can say which change caused it. That is the short version of how to redesign website without losing SEO. Five things separate the relaunches that hold their rankings from the ones that don't:

• Treat it as a migration, not a makeover. The visual layer is the visible part. The URLs, templates, internal links and rendered HTML are the part search engines score.
• Give every valuable URL a destination. One retired page, one closest equivalent, mapped in a spreadsheet before build starts. Never a blanket redirect to the homepage.
• Test content, accessibility and rendering on staging. Each of those three carries direct SEO risk, and each fails differently.
• Record a baseline first. Organic landing pages, top queries, indexed pages, conversions and Core Web Vitals, in one dated sheet, agreed by the people who own search and the people who own the build.
• Set rollback thresholds before launch. Keep the old deployment live and reversible until those checks pass.

Rankings rarely fall for one dramatic reason. They fall because URLs changed without redirects, copy got thinner, internal links broke, pages got slower, or headings and image alt text vanished into a page builder.

Some dip is normal for a few weeks while search engines recrawl and reassess. A sustained fall past week four usually has a specific, findable cause, and the rest of this guide works through the checks that prevent it, then the ones that diagnose it when prevention wasn't enough.

Build a Complete URL Inventory and Baseline

A URL inventory is the list of everything the current site serves, and it's the document the whole relaunch depends on. Build it from seven sources, in this order, because each one catches something the previous one missed.

1. Crawl the live site. Use Screaming Frog, Sitebulb or an equivalent crawler and export every URL it reaches, including PDFs and parameterised pages. Crawlers only follow links, so anything linked solely from old emails, retired menus or campaign assets never appears, and those orphans often carry the backlinks.
2. Export the XML sitemaps and the CMS page list. Compare both against the crawl and flag anything appearing in only one source. A page in the sitemap but not the crawl is orphaned. A page in the CMS but nowhere else is usually a template or draft that should stay out of the new build.
3. Pull 12 months of Search Console performance data. Clicks, impressions, top queries, top landing pages. A full year covers seasonality, so a quiet August doesn't get read as damage you caused.
4. Export organic landing pages from analytics with conversions over the same 12 months. Search Console shows where you appeared. Analytics shows which arrivals did something commercially useful.
5. Export server logs. Logs capture requests for URLs outside the navigation, from both people and bots. Some of those URLs have steady traffic and no internal links at all, which makes them the first thing a redesign loses.
6. List referring domains by target page. Flag every URL with external links that you plan to retire. A blog post with modest traffic and a dozen referring domains deserves the same protection as a busy service page.
7. Record the baseline in one dated sheet. One row per metric, with its source and window, signed off before design starts.

The inventory is complete when the sources agree once duplicates are removed. Any URL that appears only in logs or backlinks becomes a redirect candidate by default.

Practical rule: if a page appeared in this inventory, it gets an explicit decision. Keep, improve, consolidate or redirect. No page leaves the conversation by accident.

The baseline to capture looks like this. Organic clicks and impressions from the Search Console performance report over the past 12 months. Top queries and top landing pages from the same report and window. Indexed pages from the indexing report, as a current snapshot. Organic landing-page conversions from analytics across the same 12 months. Priority keyword rankings from a rank tracker, saved as a weekly snapshot. Page speed and Core Web Vitals from PageSpeed Insights or CrUX data, captured the week before launch and again at week four. Internal search terms from analytics site search, same 12 months.

Search is rarely a side channel, which is why this record matters commercially. The Government Digital Service reports that approximately two-thirds of GOV.UK visits in 2025 originated from external search engines (Inside GOV.UK's 2025 usage report). A retired URL without a destination is a revenue question, not a technical footnote.

When a client needs a redesign, we audit the current site, identify what works and what doesn't, and build the new solution around the client's goals. The audit is step one in our website redesign and development service, not a formality before the interesting work starts.

Map Every Old URL to a New Home

Intent decides the destination. A retired service page points at the new page that serves the same need, not at the homepage, because unrelated redirects strip out the relevance that made the original rank and leave visitors somewhere they didn't ask to be.

Here's how that plays out. A page at /services/web-design moves to /web-design-services and redirects there with a single 301. A retired case study with no direct equivalent goes to the closest project category page, or returns a 410 if there is no replacement. Both outcomes are defensible. Sending either one to the homepage is not.

The redirect map itself is a spreadsheet with four columns, and every rule looks like one of these:

• /services/web-design → /web-design-services, 301. Tested on staging.
• /case-studies/retail-site → /our-work/retail, 301. Pending owner review.
• /case-studies/old-campaign → none, 410. Retired with no replacement.
• /services/web-design?page=2 → /web-design-services?page=2, 301. Query behaviour checked.

Then work through six steps in order. One: build the map one URL per row with old URL, new URL, redirect type, owner and status. Two: run a crawler over the staging site with the old URL list to catch chains and loops before anyone sees them. Three: deploy permanent server-side 301s, or 308s where the request method has to survive, and preserve query-string behaviour where pagination or filtering depends on it. Four: update internal links so users stop arriving via redirects and crawlers stop rediscovering old paths. Five: update canonicals, hreflang, structured data and the XML sitemap to match the new URLs. Six: submit the new sitemap in Search Console and inspect a sample of priority URLs individually.

The GOV.UK transition guidance for agencies sets the standard here. It requires a complete URL spreadsheet, redirects for archived content and pre-launch testing of the mappings, and it recommends using traffic logs to identify actively used URLs and watching for high volumes of 404 responses after launch, because missing mappings are exactly what those 404s reveal. Correctly mapped redirects let search engines discover the new URLs and help content retain its rankings.

Practical rule: if you can't name the page a retired URL should point to, it doesn't have a destination yet. That's an unfinished row, not a homepage redirect.

Keep redirects live for at least 12 months and don't delete them while old links still exist anywhere. If the relaunch also involves a new domain, the same discipline applies twice over, and our guide to switching domains covers the extra steps that a URL-only migration doesn't need.

Protect Content, Accessibility and Crawlability on Staging

Start with the difference between what your browser shows and what the server sends. For each template, compare the raw HTML with the rendered DOM and confirm that the main copy, internal links and metadata appear in the source rather than only after scripts run. A page that builds its product description client-side can look perfect in a browser and arrive at a crawler as an empty shell.

The on-page checks worth automating

Run a staging crawl and review it template by template rather than page by page, because a single component decision propagates across hundreds of URLs. Check for one H1 per page, a logical H2 and H3 order, descriptive link text, meaningful alt text, unique titles and descriptions, and canonicals that point at the intended live URL rather than a staging host. Then look for orphan pages, broken breadcrumbs, and pagination that pushes deep pages out of reach. Compare word counts and key copy on priority landing pages against the old site: a service page that shrank from 1,800 words to 600 has lost more than padding.

Semantic markup is part of this. Descriptive, well-structured HTML helps search engines and assistive technology read the same page the same way, and using HTML elements to describe content properly is cheaper to get right in a template than to retrofit later.

Accessibility is an SEO risk, not a separate audit

Template changes, new component libraries, navigation rewrites and mobile breakpoints can introduce accessibility problems across hundreds of URLs at once. They also weaken organic performance indirectly, because inaccessible navigation hides pages from users and crawlers alike, while poor reflow on small screens pushes mobile visitors away.

The scale is documented. The UK Government monitored 1,203 public-sector websites and 21 mobile apps between January 2022 and September 2024 and identified 29,787 accessibility issues; organisations fixed 16,482 of them (55.3%), while 3,693 (12.4%) remained unresolved on retest. The most common problems were missing visible keyboard focus (13.3% of all recorded issues), insufficient colour contrast (13.0%), keyboard-operation failures (10.8%) and poor reflow across screen sizes (9.2%), according to the accessibility monitoring report. The same report notes that automated tools detect only approximately 30–40% of problems, so pair them with keyboard checks, screen-reader sampling, contrast testing and manual review of critical templates.

Automated tools will tell you an image has no alt text. They won't tell you the alt text is useless.

This is familiar ground for us, from public-sector builds such as the Edinburgh Council website to smaller content sites. The principles behind it are worth reading before a template gets signed off: our notes on inclusive design principles map directly onto the checks above.

Before launch, complete the staging sign-off. Password-protect the environment, apply noindex as a second layer so nothing leaks into the index, and keep a written list of every restriction added, because someone has to remove each one on launch day. Confirm the sign-off covers rendered content, headings, alt text, canonicals, sitemap output, keyboard access and reflow at 320px.

Launch Day and Four Weeks of Monitoring

Three days before launch, freeze content and sign off the redirect map. Nothing changes after that without a re-test, because late copy edits are how unmapped URLs slip through.

On launch day, in a low-traffic window, deploy the redirects before switching DNS. Remove the staging noindex and password protection. Check that robots.txt isn't blocking a key section. Submit the new sitemap, then crawl the full old URL list against the live site and confirm every mapping returns the status code you intended.

Days one to fourteen: check organic clicks, impressions, indexed pages, 404 and 5xx counts, crawl errors and conversions daily. Compare each day with the same weekday in the baseline, not with yesterday, because weekly cycles create noise that looks like a trend. Don't judge the launch inside the first 48 hours. Search engines need time to recrawl.

Weeks three and four: move to weekly reviews, grouped by template and by key query rather than as one site-wide total. A flat total can hide a service page that has dropped ten places.

Practical rule: agree the review period before launch. Teams argue about opinions when they haven't agreed when the verdict is due.

The reason to judge behaviour over a defined window, rather than on whether stakeholders like the new design, is that interface changes produce measurable shifts that only show up in the data. The Government Digital Service reported that in the week after its new GOV.UK homepage launched, homepage searches rose 40%, from 82,000 to 115,000 per week, and the share of homepage visits leading to an internal search rose from 13% to 19% (GDS on how the new GOV.UK homepage performed). That's a findability result, measured, not a taste judgement.

Set the rollback thresholds before staging sign-off and name the person who can revert the release:

• Organic clicks against baseline. A sustained fall below the agreed floor across five consecutive working days means hold the rollout and review.
• 404 and 5xx responses. A ceiling on daily 404s and any sustained 5xx rate triggers a revert if it holds.
• Canonical mismatches. A systematic pattern, not a stray tag, means fix on staging or revert.
• Indexed pages. A decline that persists past week three means check noindex, robots.txt and sitemap before anything else.

We monitor this the same way on every launch, from content-heavy estates such as Cultaholic down to compact marketing sites, and the routine is the same one our performance monitoring notes describe.

Diagnosing Post-Launch Ranking Drops

Work down the list in order of frequency, because most drops have one of five causes and the first is the most common.

A spike in 404 responses. Compare the redirect map against server logs and add the missing mappings, starting with the URLs receiving the most requests. Those are the ones costing you most per day.

A drop confined to one template. Inspect headings, internal links, canonicals and rendered content on that template only. A removed related-links module or a body-copy block that no longer prints affects every URL the template serves. Loss of wayfinding shows up the same way: GOV.UK carries more than half a million pages and around 15% of users move through topic pages rather than starting from search, which is why both routes need crawlable HTML links rather than client-side interactions (GDS plans to improve GOV.UK navigation).

Indexed pages falling. Look for a leftover noindex tag, a robots.txt block added during staging, sitemap errors, and parameterised URLs that now duplicate a live page.

Rankings lost on key queries while total traffic holds. Compare the new copy and structure against the version that ranked. Trimmed sections, a shifted search intent or dropped structured data usually explain it.

Mobile visitors leaving quickly. Test layouts at 320px and 375px and measure speed on a throttled connection, not on office wifi.

Two decisions matter more than any single fix. Keep the old deployment and its redirect rules in place until the rollback checks pass, and never delete redirects after launch because the traffic looks fine. The quiet risk is a link you didn't know about.

If the cause can't be isolated internally, ask for an outside review through our contact page. Our web development work runs from planning and design through frontend build, backend development and post-launch support, which means the same team that ships the release stays around to read the logs afterwards. For regulated products, that continuity matters, as it did on H2OiQ.

Common Questions About SEO-Safe Redesigns

Can we change our URL structure and keep our rankings?
Yes, provided every retired URL is mapped one to one and redirects permanently. The risk isn't the new structure, it's the gaps: pages nobody remembered that then 404. Expect some fluctuation for several weeks while search engines recrawl and reassign signals. The mapping discipline described earlier is what keeps that fluctuation temporary rather than permanent.

How long should old redirects stay live?
At least 12 months, and longer in practice. Keep each one for as long as anything on the web still links to or cites the old address, because removing a redirect turns a working inbound link into a dead end for visitors and crawlers. Backlink profiles update slowly, and some never do. There's no maintenance saving worth that risk.

Can we redesign in phases instead of all at once?
Yes, and for large estates phased releases are often safer. What matters is that each phase carries its own redirect map and staging test, so phase two doesn't overwrite phase one's rules or route traffic through an intermediate URL that creates a chain. The usual failure is treating phases as delivery milestones rather than as separate migrations.

Does accessibility work affect SEO?
Yes. Headings, link text, alt text and keyboard-reachable navigation are the same signals that help a crawler understand a page and find its way around the site. For UK public-sector bodies it isn't optional either: the equality and accessibility regulations require sites and apps to meet WCAG 2.2 AA and publish an accessibility statement.

What if the page looks right in a browser but search engines see something else?
Compare the raw HTML with the rendered DOM for that template, then check what Google indexed using URL Inspection. A browser will happily run the scripts that assemble the content; a crawler may not, or may give up first. If the copy only exists after JavaScript runs, either render it server-side or pre-render that template.

A redesign that protects its rankings is a project with a paper trail: an inventory, a redirect map, a staging sign-off, a baseline and thresholds everyone agreed to before launch. Arch has been building and rebuilding websites since 2005, and every engagement starts with an audit of what currently earns traffic before a single layout is drawn. If you want a second pair of eyes on a redirect map, or a team to run the whole relaunch from inventory through the four-week review, Arch can take it from there.

About the Author

Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the significant potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.

Hamish's LinkedIn: Hamish Kerry on LinkedIn