# How to Redesign Website Without Losing SEO: 6 Checkpoints
**URL:** https://mettevo.com/blog/article/how-to-redesign-website-without-losing-seo
**Published:** 2026-10-02
**Updated:** 2026-10-02
**Author:** Oleg Silin
**Category:** Blog | Mettevo
> Learn how to redesign a website without losing SEO. Follow a practical process for protecting rankings, traffic, URLs, redirects, visibility.
---
A website redesign without losing SEO comes down to six checkpoints: a one-hop 301 redirect map, a metadata inventory, matching structured data, preserved internal links, Core Web Vitals on the new stack, and a monitored launch with rollback. [Google](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) says a medium-sized site can wait a few weeks or more for new URLs to replace old ones.
A website redesign without losing SEO is a relaunch that carries over every URL, tag, structured data block and internal link that earns search traffic, then verifies each one on the live site.
## **TL;DR: how to run a website redesign without losing SEO?**
1. URL map and 301 redirects: pair every indexable old URL with one permanent redirect to its closest new equivalent, and keep the redirects at least 1 year.
2. Metadata inventory: compare titles, meta descriptions, canonicals and Open Graph tags between the live site and a staging crawl.
3. Schema and structured data: diff the schema.org types per template. FAQ rich results ended in Google Search on 7 May 2026, per [Google's changelog](https://developers.google.com/search/updates).
4. Internal link preservation: export the old link graph before the build and keep inbound links to traffic pages as crawlable links in the server response.
5. Core Web Vitals on the new stack: aim for Largest Contentful Paint (LCP) within 2.5 seconds and Interaction to Next Paint (INP) under 200 milliseconds. Keep Cumulative Layout Shift (CLS) under 0.1, per [Google Search Central](https://developers.google.com/search/docs/appearance/core-web-vitals).
6. Monitoring and rollback: name an owner, a watch period and a revert path before launch day.
## **What breaks when a website redesign goes live?**
A website redesign changes URLs, templates and code in one release, so failures cluster in five places. Each one maps to a checkpoint below, and staging shows each one before launch:
- URLs: old addresses answer 404 or a temporary redirect that Google does not treat as a canonical signal.
- Metadata: new templates fall back to default titles and descriptions.
- Structured data: markup disappears with the old theme or plugin.
- Internal links: navigation moves into scripts that some crawlers do not run.
- Speed and rendering: heavier JavaScript slows pages, and content that exists only after scripts run is invisible to crawlers that skip them.
## **Checkpoint 1: URL map and 301 redirects**
Build the map from three exports: a crawl of the live website, the sitemap and Search Console's Performance report by page. Merge them into one sheet, sort by clicks and give every row a new URL. Map the top slice by hand and cover the long tail with pattern rules.
In Next.js, declare each rule in redirects() with permanent: true. According to the [Next.js documentation](https://nextjs.org/docs/app/api-reference/config/next-config-js/redirects), true returns status 308 and false returns status 307 for temporary redirects. [Google's redirect documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects) lists 301 and 308 as permanent moves and says temporary redirects are not a signal that the target should be canonical. A source such as /old-blog/:slug skips nested paths, so test deeper URLs separately.
// next.config.js
module.exports = {
async redirects() {
return \[
{ source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
\]
},
}
After launch, request every old URL and require a single hop to a final 200 status. [Google's crawlers follow up to 10 redirect hops](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) by default. These two commands print the first response's status line, then the final status, hop count and destination.
curl -sI https://example.com/old-url | head -n 1
curl -sIL -o /dev/null -w "%{http\_code} %{num\_redirects} %{url\_effective}\\n" https://example.com/old-url
Where no close equivalent exists, choose a 404 or 410 on purpose instead of sending the URL to the homepage. [Google generally advises](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) keeping redirects at least 1 year, because signals move as it recrawls and reassigns links from other sites. Our own crawl logged two URLs with status 308 and recorded no destination for either, which is the gap a redirect map exists to close.
## **Checkpoint 2: Metadata inventory**
Crawl the live site and the staging build with the same crawler. Export URL, title, meta description, canonical, robots meta tag, H1 and Open Graph title and image to one sheet per environment, then join both sheets on the URL map. Review every row where the new title or description equals a template default or changed without a decision.
In the Next.js App Router, a route that skips generateMetadata() inherits its parent's title and description without an error, as our article on [Next.js metadata changes that break indexing](https://mettevo.com/blog/article/next-js-seo-metadata-changes-that-break-indexing) explains. Google lists [repeated boilerplate text in title elements](https://developers.google.com/search/docs/appearance/title-link) across a subset of pages as one reason it rewrites title links.
## **Checkpoint 3: Schema and structured data**
Record the schema.org types each template emits today, record them again on the staging build and diff the two records. On Mettevo's article template the types include BlogPosting, Person, Organization, BreadcrumbList and WebPage.
Judge each type by what it still earns. According to [Google's Search Central changelog](https://developers.google.com/search/updates), FAQ rich results stopped appearing in Google Search from 7 May 2026 onward. Google removed the documentation page on 15 June 2026, per the same changelog. Do not budget redesign time to rebuild FAQPage markup for a rich result. Keep it only where the question and answer text is visible, because [Google's guidance on artificial intelligence (AI) features](https://developers.google.com/search/docs/appearance/ai-features) asks that structured data match the visible text. A template-level gap is easy to miss: in our crawl, Organization markup appears on 57 of 58 URLs, and only a per-template diff shows that the exception is the blog index.
## **Checkpoint 4: Internal link preservation**
Export the old site's internal link graph before the build: source URL, target URL and anchor text for every link. Export it again from the staging build and compare inbound link counts for the pages that carry traffic.
Test the server response, not the browser. [Google can only crawl a link](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) that is an element with an href attribute, and it cannot reliably extract URLs from links that depend on script events such as onclick. Fetch each key template with curl -s and confirm that the main navigation, breadcrumbs and related-post links are present as plain anchors in the response body.
## **Checkpoint 5: Core Web Vitals on the new stack**
Set targets before design starts. [Google Search Central](https://developers.google.com/search/docs/appearance/core-web-vitals) sets the good thresholds at 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for Cumulative Layout Shift. According to [web.dev](https://web.dev/articles/vitals), the value to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. Run lab tests on every staging build as a gate, but treat field data as the verdict, since web.dev says only field measurement captures the complete picture. [Google says](https://developers.google.com/search/docs/appearance/page-experience) Core Web Vitals are used by its ranking systems, and also that it keeps showing the most relevant content when page experience is weak.
## **Checkpoint 6: Monitoring and a rollback plan**
Script the launch-day checks. Confirm that production robots.txt carries no leftover staging rule. Then submit the new sitemap in Search Console and watch traffic on both old and new URLs, two of the steps in [Google's site-move overview](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes).
Set the watch period past two weeks, close monitoring for the first two weeks. Google says a medium-sized site can wait a few weeks or more for new URLs to replace old ones. Plan weekly reviews for eight weeks, then monthly reviews until the redirects pass their first anniversary.
Write the rollback before launch. Keep the previous build deployable and the old redirect map in version control, and name one owner. Agree the trigger in advance, for example any old URL from the top-click slice that does not end in a final 200 status.
A headless stack adds a second clock: the cache. Our [Next.js 16.3 upgrade guide](https://mettevo.com/guides/nextjs-16-3-upgrade-guide) documents Mettevo's configured windows: 3,400 seconds for content from the content management system (CMS) and 1,800 seconds for blog content. According to the [Next.js documentation](https://nextjs.org/docs/app/api-reference/functions/cacheLife), a request that arrives after that period still receives the cached version while a fresh one is generated in the background. Unless on-demand revalidation is wired to the CMS, a fix made in WordPress can stay invisible to crawlers for roughly 30 to 57 minutes, plus one more request. These are configured windows, not measured delays.
## **What does Mettevo's own WordPress and Next.js site show?**
Mettevo runs headless Next.js in front of a WordPress GraphQL backend. Our [Next.js 16.3 upgrade guide](https://mettevo.com/guides/nextjs-16-3-upgrade-guide), based on a repository scan dated 14 August 2026, counts 15 route entry points and 256 blog posts served from one shared WordPress origin. We crawled the live website on 28 September 2026 with Mettevo's crawler (user agent SEOContentForge/0.1) and fetched 60 URLs with JavaScript rendering off. Fifty-eight returned status 200 and were parsed, and two returned status 308. The table lists the findings that matter for a website redesign without losing SEO rankings.
Crawl check, 28 September 2026
Result
Relevant checkpoint
Stack markers in the page source, such as /wp-content/ and /\_next/static
WordPress and Next.js on 58 of 58 parsed URLs
Whole redesign.
Pages missing a title, meta description, H1, canonical or structured data
0 of 58
Metadata and schema.
Titles over 60 characters; meta descriptions outside 120-165 characters
8 and 5 of 58
Metadata.
Duplicate titles
1: the homepage, crawled as mettevo.com and mettevo.com/
URL map.
URLs without Organization markup
1 of 58: the blog index
Schema.
URLs with no inbound link from any crawled page
34 of 58, all blog articles
Internal links.
Responses with status 308
2 of 60 URLs fetched
URL map.
robots.txt, sitemap and llms.txt
All present; 0 of 12 AI user agents blocked
Launch day.
The crawl is one snapshot taken after the stack was in place, so it holds no before-and-after traffic and is no evidence that a hybrid stack helps or hurts rankings. It fetched 60 URLs with JavaScript rendering off, including 54 of the 256 blog posts, so the unlinked-URL count may reflect links the crawler could not see. It cannot say which findings come from the migration and which predate it.
Search Console's Performance report for the seven days to 28 September 2026 (Web search, Pages tab) lists 247 pages with impressions, and 11 of them received clicks. Four pages took 87% of the clicks, and the top page is an article about invalid URLs, not a service page. One week of clicks is a small sample, so we use it only to show which URLs a redirect map must protect first.
## **Need a website redesign without losing SEO?**
Mettevo's [web design services](https://mettevo.com/web-design) include website redesign with an audit, migration and redirects, and its [web development services](https://mettevo.com/web-development) cover WordPress, React and Next.js builds. If you are choosing a redesign agency, send it the six-item list above and ask for the URL map before design sign-off. For the Next.js side of a hybrid rebuild, our [Next.js 16.3 upgrade guide](https://mettevo.com/guides/nextjs-16-3-upgrade-guide) walks through the metadata and cache work that redirect maps alone cannot catch.
## **FAQ**
### **How to redesign a website without losing SEO?**
Work through six checkpoints. Map every indexable URL to one permanent redirect, inventory titles, descriptions and canonicals, diff structured data, keep crawlable internal links, test Core Web Vitals on the new stack and plan monitoring with a rollback. Google says a medium-sized site can wait a few weeks or more for new URLs to replace old ones.
### **Does website redesign affect SEO?**
Yes. [Google says](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) any significant site change can cause ranking fluctuations while it recrawls and reindexes the site. The effect follows what changes: URLs, titles, structured data, internal links and speed. Keeping those assets in place, or replacing them on purpose, limits the damage but does not remove the temporary fluctuations.
### **What is the 80/20 rule in SEO?**
The 80/20 rule, or [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle), says roughly 80% of results come from 20% of causes. In SEO it is a prompt to check whether a few pages bring most organic clicks, so a redesign protects those URLs first. On mettevo.com, Search Console shows four of the 247 pages with impressions taking 87% of clicks in the seven days to 28 September 2026.
### **Is SEO still worth it in 2026?**
Yes, but searches with an AI summary send fewer clicks to traditional results. Users clicked a traditional result link in 8% of visits with an AI summary and 15% without one. [Google says](https://developers.google.com/search/docs/appearance/ai-features) its AI features need no special optimization, and a page must be indexed to appear in them.
### **What is replacing SEO?**
Nothing has replaced it. For Google's AI features, Google says existing SEO fundamentals remain worthwhile, and a page must be indexed and eligible to show with a snippet to appear as a supporting link.