301 redirects and site redesigns: keeping your SEO intact

Redesigning a site often means changing its URL structure. Without a redirect plan, every address that disappears takes the SEO it had accumulated with it and sends visitors to an error page. This is not a cosmetic concern: a poorly set redirect turns into lost traffic from the crawler’s very first passes. This guide covers choosing HTTP status codes, building the plan, canonicalisation, server-side implementation and post-launch checks.

#What a redirect carries, and what an error destroys

A permanent redirect tells the browser and the search engine that the content has definitively moved. The engine then transfers most of the old URL’s ranking signal to the new one and updates its index. Conversely, a URL removed without a redirect returns a 404: the external links that pointed to it become dead ends, and the signal they carried vanishes. A successful redesign preserves the mapping between each useful old address and its destination.

The transfer is not instantaneous. The engine has to revisit the old URL, register the redirect, then re-evaluate the destination. That delay, from a few days to a few weeks depending on crawl frequency, is why a temporary drop in traffic after a switch is nothing unusual — provided the redirects are correct.

#301, 302, 307, 308: choosing the right code

The HTTP code is not a detail. It tells the engine whether the change is permanent and whether it should transfer the signal. Picking the wrong code means either keeping the old URL in the index or losing the transfer.

For a redesign the rule is simple: 301 for pages, 308 when the HTTP method must be preserved. Reserve the 302 for genuinely temporary situations, since it does not invite the engine to update its index.

#Building the redirect plan before the switch

The plan is prepared during the redesign, never after. It is a mapping table between each old URL and its destination, built from three cross-referenced sources: the export of indexed URLs from Search Console, the list of most-visited pages, and known inbound links. Each valuable old URL gets a destination on an equivalent page — not systematically the home page, which dilutes the signal.

Redirecting every old page to the home page is not a redirect plan: it is signal loss dressed up as a solution.

Some cases deserve special attention. URLs with parameters (filters, sorting, campaign tracking) are not redirected one by one: a rule on the path, keeping or dropping the parameters according to their role, works better. Pagination pages, archives and image URLs also change during a redesign and belong in the plan. Finally, editorial continuity matters as much as technical continuity: a page that carried structured data must find equivalent markup on its destination, otherwise the rich results disappear until the engine re-evaluates the new page.

#Canonicalisation: forcing a single version of each URL

A redesign is the right moment to consolidate duplicate entry points. As long as http:// and https://, the with- and without-www versions, or the trailing-slash variants all answer with a 200, the engine sees several URLs for one piece of content and has to decide for itself which to index. You force the choice with a permanent redirect to a single, canonical form. Under nginx, the idiomatic practice uses dedicated redirect blocks rather than conditional tests:

# HTTP to HTTPS: all cleartext traffic goes to the secure version
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# Non-www to the canonical www version
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

The same principle applies to the trailing slash: pick a convention, keep it everywhere, and redirect the other form with a 301. What matters is consistency, not the choice itself.

#Implementing it server-side

The redirect belongs at the web-server level, ahead of the application, so it stays fast and code-independent. Under nginx, an exact match is declared with return 301, a full pattern with rewrite:

server {
    listen 443 ssl;
    server_name www.example.com;

    # Exact redirect, old page to new
    location = /old-section/article {
        return 301 /new-section/article/;
    }

    # Full-pattern redirect to a new tree
    location /blog/ {
        rewrite ^/blog/(.*)$ /articles/$1 permanent;
    }
}

The result is checked in the HTTP response: the code must be 301 and the Location header must point to the final URL, in a single step.

GET /old-section/article HTTP/1.1
Host: www.example.com

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-section/article/

A command-line check is enough to confirm the behaviour without opening a browser:

curl -sI https://www.example.com/old-section/article \
  | grep -i -E '^(HTTP|location)'

This logic holds whatever the hosting, including a self-hosted stack where the web server is directly accessible.

#Avoiding chains and loops

#Checking after go-live

The switch is not the end of the job. In the days that follow, three checks are due: submit the new sitemap to Search Console and watch indexing coverage, track traffic to spot a page that slips, and read the server logs for 404s still being served. The monitoring dashboard that cross-references analytics and Search Console makes those signals readable at a glance. A spike of 404s in the logs almost always flags an old URL forgotten in the plan; it is fixed by adding the missing redirect, without waiting for the engine to notice the error.

#What to remember

A redesign preserves its SEO when the redirect plan is prepared before the switch, backed by real indexing and traffic data, set as direct 301s server-side, then checked after go-live. The HTTP code is chosen according to the nature of the change, duplicate entry points are consolidated to a canonical URL, destinations stay relevant page by page, and chains and loops are eliminated up front. Nothing spectacular: method, applied at the right time.

Further reading: the Google Search Central documentation on redirects and their effect on crawling and indexing.