Website Redesign Without Losing SEO: A Checklist

We redesign websites as part of our web design and development work, and on 2 October 2026 we relaunched our own site, marketlube.in, moving it from a single-page app to a server-rendered build. This checklist follows the runbook we worked from, with the launch-day checks and their results. It is about keeping what a site has already earned in search; our month-by-month results will go in a separate log once there are months to report.

When a redesign loses search traffic, look first at three causes rather than the design: addresses that changed without redirects, a staging setting that reached the live site, or a new site telling search engines that its real home is somewhere else. All three are cheap to prevent and slow to fix.

Does a website redesign hurt SEO?#

It can, and it doesn't have to. Google's guide to site moves with URL changes↗ (opens in a new tab) (last updated 20 August 2026, read 7 October 2026) is frank about the normal cost: "Expect temporary fluctuation in site ranking during the move", and for medium-sized sites, "it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones."

Losses that last come from a short list of mistakes, ranked further down. If the URLs, the content and the technical signals stay the same, a new design is mostly a change of clothes; the risk grows with each of the three you change at once.

What should you record before you start?#

Take a snapshot of what the old site has earned before anyone touches the design. You need it twice: to build the redirect map, and to know whether the relaunch worked.

We saved our own snapshot on 30 September 2026, two days before launch: the old site's speed, page weight, rendered text and search results.

How do you map old URLs to new ones?#

Build one table with a row for every old URL: the old address, the new address and how it gets there. Then apply five rules.

1. Keep URLs that work. The cheapest redirect is the one you never need.
2. One to one wherever you can. Each old page redirects to the new page that answers the same question. The closest equivalent beats a section page, and a section page beats the home page.
3. Never send everything to the home page. Google's guide: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."
4. Let content that is really gone return 404 or 410. Google again: "make sure those URLs correctly return an HTTP 404 or 410 error response code on the new site."
5. Redirect straight to the final address. Googlebot follows up to 10 hops, but Google advises "redirecting to the final destination directly."

Our map for marketlube.in was short, for an unusual reason: the old site was a single-page app with one real route. Every path, including /robots.txt and /about, answered 200 with the same empty shell, so beyond the home page on www there were no individual pages to carry over, only old build files. This is the whole map, as our runbook records it, including a few redirects we added for addresses people might type and two URLs from the new site's own pre-launch drafts:

The Calicut row is the one fair exception to rule 3: our home page is now the page that answers that search. A week after launch, our runbook has us export the old www property's indexed pages, so any URL Google still knows gets a row.

301 or 308: which redirect should you use?#

Either, as long as it is permanent and happens on the server. Google's page on redirects and Google Search↗ (opens in a new tab) (last updated 14 April 2026, read 7 October 2026) lists 301 and 308 as permanent redirects, for which "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." Temporary redirects (302, 303 and 307) don't carry that signal, and JavaScript redirects are a last resort.

We used 308 because our framework sends it for permanent redirects, and we set the host's www redirect to match. Next.js's redirects documentation↗ (opens in a new tab) says permanent: true "will use the 308 status code", which, unlike 301, keeps the original request method. For a search engine the two mean the same thing. Keep them for a long time: Google's site-move guide says "generally at least 1 year."

What must be right on launch day?#

Run these checks on the live address, not the test copy, within minutes of the switch. Most need only a browser and curl.

One mistake in those rows deserves its own paragraph, because nothing on screen gives it away: a build where the production site URL was never set, so every canonical tag, sitemap entry and robots.txt line still names a development address such as localhost. The site looks perfect in a browser while search engines are told its home is somewhere they can't reach. A look at the page source catches it; one setting and a rebuild fix it.

What did we check on launch day for marketlube.in?#

The new site went live at 11:32 IST on 2 October 2026. We wrote the launch checks as a script, so they run the same way after every release; on launch day it reported 24 of 24 passing. What it confirms:

• http and www addresses reach https://marketlube.in through 308 redirects, in at most two hops, with the path kept.
• The home page answers 200 with no X-Robots-Tag, and its canonical points at itself.
• robots.txt answers 200 as plain text, blocks only /api/ and /admin, and names the sitemap.
• The sitemap index lists every sitemap (7 on launch day), each answers 200, and every URL in them sits on https://marketlube.in: 113 URLs on launch day.
• Pages we hold back from search answer with noindex and stay out of the sitemaps.
• The preview copy still answers with noindex, old build files answer 404, and the IndexNow key file is live.

Then the search engines. We submitted all 113 URLs through IndexNow↗ (opens in a new tab), and it was accepted with a 202 response: received, with the ownership key still being checked. IndexNow shares one submission with every participating engine; its list, read on 7 October 2026, names Bing, Yandex, Seznam, Naver, Yep, the Internet Archive and Amazon, and not Google. For Google, the sitemap went into Search Console, which read it successfully, and we requested indexing for 20 key URLs. Bing Webmaster Tools imported the site from Search Console and took the same sitemap and 20 URLs. GA4 and Microsoft Clarity went live at 11:36, loading only after a visitor accepts cookies (our GA4 guide shows the channel set-up). Our own crawl of all 113 URLs that afternoon found every one answering 200, open to indexing and pointing its canonical at itself, with no internal link to a redirect or a 404.

Two things hadn't moved when we looked on launch day, as expected: Search Console had read the sitemap index but not yet the 7 sitemaps inside it, and the home page still showed "Page with redirect" from a crawl made before the switch. We re-ran the script on 7 October 2026: 24 pass, 0 fail, with 154 URLs in the sitemaps now that the blog has grown.

What do you watch in the first 30 days?#

Old addresses showing "Page with redirect" are normal while Google recrawls them. And if only the host changes, skip Search Console's Change of Address tool↗ (opens in a new tab): it is for moving to a different domain, and Google lists "Moving between www and non-www in the same domain" among the moves it doesn't cover. We are keeping the old www property in Search Console for 90 days instead, to watch the old URLs drop out.

Which mistakes cost the most?#

In rough order of damage:

1. Old URLs left to 404, or all sent to the home page. The pages that earned links and rankings lose them.
2. A staging noindex or a blocking robots.txt on the live site. Search engines drop what they are told to drop, and Google notes that noindex only works if robots.txt lets the crawler see it.
3. Canonicals, sitemaps or robots.txt naming the wrong host, often a development address.
4. Temporary redirects used for a permanent move, or chains of several hops.
5. Cutting content that ranked, or rewriting a top page's title and headings so it is about something else.
6. Removing redirects after a few months. Old links can keep sending visitors for years.
7. Moving text behind JavaScript. Our old site was exactly this case, as our guide to generative engine optimisation describes.

The checklist#

If the redesign changes the platform, our guide to website development costs in Kerala covers what the build involves, and our post on website maintenance costs in India covers what keeping it healthy costs afterwards. If the new site takes ad traffic from day one, run its pages through our landing page checklist too.

Frequently asked questions#

Will changing my website affect my Google ranking?#

It can for a few weeks, even when everything is done right: Google says to expect temporary fluctuation during a move. Lasting losses usually trace back to missing redirects, removed content or a noindex left on.

Do I need 301 or 308 redirects?#

Either works for a permanent move: Google lists both as permanent redirects that make the target the canonical page. Next.js sends 308 because it keeps the original request method. Avoid temporary redirects (302 and 307) and JavaScript redirects for pages that have moved for good.

How long does Google take to settle after a redesign?#

For a medium-sized site, Google's guide says a few weeks or more for new URLs to start replacing old ones. Check the Pages and Performance reports weekly for the first month, against the numbers you recorded before launch.

Should I change URLs in a redesign?#

Only when the old ones are genuinely poor, such as long query strings or addresses that no longer describe the page. Every changed URL needs a permanent redirect kept for at least a year, so the cheapest redesign keeps every address that already works.

Do I need Search Console's Change of Address tool?#

Only when you move to a different domain, such as example.com to example.org. Google says not to use it between www and non-www versions of the same domain, for http to https, or for path changes inside a site; redirects and canonical tags handle those.

Relaunching soon?#

The work that protects a site's search traffic happens mostly before launch day, in the URL list and the redirect map. If you're planning a redesign and want it mapped and checked the way we did ours, tell us about your site, or see how a website redesign fits into our web development work and our SEO programme. Or book a redesign consultation with Althameem Ali before you migrate.

Changelog#

• 2026-10-10: The closing paragraph now offers a redesign consultation with Althameem Ali before you migrate.