Website Redesign Without Losing SEO: Baseline, Redirect Map and Launch Checklist

Why a redesign loses rankings (and when it doesn't)

A new look does not lower rankings. Search engines rank URLs by their content, links and technical signals, and colors, fonts and layout carry almost none of that. Rankings drop because a redesign usually changes more than the look: URLs get renamed, text gets trimmed to make room for white space, the menu is rebuilt, and a new template ships with a leftover noindex tag.

That gives you a short list of things to protect. Each row below is something a redesign commonly touches and the SEO signal that goes with it.

So the goal is not to avoid redesigning. It is to keep the same URLs, content and links wherever a page already earns traffic, and to prove that after launch instead of assuming it.

What to record before you change anything

You cannot tell whether the launch hurt you without a before picture, and once the old site is overwritten you cannot rebuild it. Take these snapshots while the old site is still live.

• A full crawl of the live site. Export URL, status code, title, meta description, H1, canonical, indexability, word count and internal inlinks for every page.
• Search Console performance data. Export clicks, impressions and queries by page. Search Console only keeps up to 16 months, so export now rather than later.
• Pages that have external backlinks. These URLs carry links you cannot easily win back, so they are the last ones you should break.
• Your sitemap, robots.txt and structured data types as they are today.
• The pages that produce conversions in your analytics, whether or not they get organic traffic.

Then sort every URL into three tiers. This one step drives most of the later decisions.

Decide first: keep every URL or change some

The safest redirect is the one you never need. If the redesign is visual only, keeping the URL structure means there is nothing to redirect and the work is a content and markup parity check. Change URLs only when there is a clear reason, such as a messy folder structure or a platform that forces a new pattern.

Google's documentation on site moves with URL changes describes the Change of Address tool as being for domain or subdomain changes only. It is not needed for HTTP to HTTPS, www to non-www, or path changes inside the same domain.

One practical rule: avoid shipping a redesign, a new CMS, new URLs and a rewritten content strategy in one launch. If traffic drops, you will not be able to say which change caused it. Split them across releases when the schedule allows.

How to build the 301 redirect map

Start from every old URL you can find: the crawl, the sitemaps, server logs and analytics landing pages. Then give each one a destination. These rules keep the map clean:

• Use permanent, server-side redirects. Google says permanent redirects (301 and 308) signal that the target should become the canonical URL, while temporary ones (302, 303, 307) do not. It also says server-side redirects have the best chance of being interpreted correctly, as covered in its guide to redirects and Google Search.
• Redirect to the closest equivalent page. A service page should land on its new service page. Sending hundreds of old URLs to the homepage gives users and crawlers nothing relevant, and Search Console tends to report such redirects as soft 404s.
• Keep it to one hop. If an old URL goes A to B and B was later moved to C, point A straight to C.
• Cover the variants. Trailing slash, uppercase, www, and URLs with tracking parameters that attracted links.
• Leave the redirects in place. Google's site move guidance is to keep them as long as possible, generally at least a year.

On nginx, a map block keeps the rules in one plain file instead of hundreds of location blocks:

# http context
map $uri $redirect_target {
    default '';
    include /etc/nginx/redirects.map;
}

server {
    # ...
    if ($redirect_target) {
        return 301 $redirect_target;
    }
}

# /etc/nginx/redirects.map, one rule per line
# /old-services/web-design/   /services/website-design/;
# /blog/2019/seo-tips/        /blog/seo-tips/;

A map is only useful if it works, so test it before launch. This script reads a CSV of old_url,expected_url pairs (absolute URLs, no header row) and flags any rule that takes more than one hop, starts with a temporary redirect, fails to end on a 200, or lands somewhere other than the page you meant:

import csv
import sys
from urllib.parse import urljoin

import requests

REDIRECT_CODES = (301, 302, 303, 307, 308)


def trace(url, max_hops=6):
    chain = []
    for _ in range(max_hops):
        r = requests.get(url, allow_redirects=False, timeout=15)
        if r.status_code not in REDIRECT_CODES:
            return chain, r.status_code, url
        chain.append(r.status_code)
        url = urljoin(url, r.headers['Location'])
    return chain, None, url


def problems(old, expected):
    chain, status, final = trace(old)
    found = []
    if len(chain) != 1:
        found.append(f'{len(chain)} hops')
    if chain and chain[0] not in (301, 308):
        found.append(f'first hop is {chain[0]}')
    if status != 200:
        found.append(f'ends on status {status}')
    if final.rstrip('/') != expected.rstrip('/'):
        found.append(f'lands on {final}')
    return found


with open(sys.argv[1], newline='') as f:
    for old, expected in csv.reader(f):
        issues = problems(old, expected)
        if issues:
            print(old, '->', ', '.join(issues))

Run it against staging first, then again against production on launch day. Doing this by hand across several hundred URLs is where most mistakes creep in. If the redesign is also a rebuild on a new CMS, treat the URL map as a deliverable of the build itself, which is how we approach business website projects at Netalith.

Keep what ranks: content, links and markup parity

For every Tier A page, compare the new version to the old crawl before launch. The point is to find what the design changed without anyone intending it.

Tabs and accordions are fine as long as the text is in the HTML when the page loads. Text that is fetched only after a user action may never be seen by a crawler. Check performance on the new templates as well, because a design with heavier images and scripts can make pages slower than the ones it replaced.

Launch-day traps that cost the most traffic

These are small configuration mistakes with large effects. Most come from settings that were correct on staging and wrong on production.

Make a pre-launch rehearsal part of the plan. Crawl staging with the same crawler settings as the baseline crawl, diff the two exports, and fix every Tier A difference before the switch. Launch early in the week and outside your busiest sales period, so there are working days to react.

The first 90 days: what to watch and when to roll back

Some movement after launch is normal. Google's site move documentation says to expect temporary ranking fluctuation during a move, and that for small and medium sites most pages are picked up within a few weeks. Fluctuation that settles is expected. A Tier A page returning 404 or noindex is a bug that needs a fix today.

A workable rule for rolling back: if the new site is broken at the infrastructure level (blocked, noindexed, mass 404s) fix or revert immediately. If it is a ranking dip with correct technical signals, do not revert. Keep comparing against the baseline, because reverting resets the clock and you lose the change you launched for.

Get the redirect map and launch checklist reviewed

The expensive redesign mistakes are all visible before launch: a redirect map with chains, a staging directive still in place, a Tier A page with half its content missing. A second pair of eyes on those three things costs far less than a month of lost traffic. If you want one before you switch, request a free quote and tell us a redesign is on the way.