How to Protect SEO During a Redesign or Migration: A 301 Plan

Redesigning a website usually starts with excitement: new design, new platform, faster pages. Two weeks after launch, though, a call sometimes comes in: “We redesigned the site and customers from Google dropped by half.”

A common cause isn't the design but the addresses. The URLs of pages on the old site changed and nobody planned for redirecting old addresses to new ones. Google goes to the old addresses, finds error pages, and rankings built over years can disappear.

The good news: most of this problem is preventable. Below we lay out, step by step, the plan we follow for a redesign or domain migration.

Why does traffic drop after a redesign?

One common reason is old URLs returning 404 errors. If a page at “/hizmetlerimiz/kombi-bakimi.html” on the old site becomes “/kombi-bakimi” on the new one with no redirect in between, the address Google knows no longer works. That page's rankings, the value of links it earned from other sites and the visitors it received can all vanish at once.

But that's not the only reason. Others we often see:

• Content shortened on the new site: an 800-word text on the old service page cut to 3 lines in the new design
• Page titles and meta descriptions lost, or identical across all pages
• A “noindex” tag or robots.txt block added during development and forgotten at launch
• Changed internal link structure, with important pages dropped from the menu
• A change of domain, http/https or www preference without redirects
• Structured data (schema) not added to the new site

Most of these can be caught with a plan before launch. If you want to judge whether your site really needs a redesign, see our post on when to redesign a website.

Building an inventory of old URLs

The first step is listing every address on the old site. Not only pages in the menu, but every address Google knows and other sites link to.

Combine the list from several sources:

• Search Console's Performance report: export every page with impressions or clicks over the longest period the report offers
• Search Console's Pages report: the list of indexed pages
• The old site's sitemap (sitemap.xml)
• A full crawl with a crawler tool; free versions of some crawlers can be enough for small sites, so check current limits on the tool's own site
• The landing pages report in Google Analytics
• Search Console's Links report: the pages external sites link to most

Merge these into one table and remove duplicates. Next to each address, note its clicks over the last 12 months and any external links it has. Those two columns show which pages are most critical.

Don't forget images and PDFs. A PDF catalog that gets traffic from Google Images or links from other sites needs redirecting too if it moved to a different address.

On a small company site this list usually stays at a few dozen addresses. On a site that has blogged or run an online store for years, it can be thousands.

The redirect mapping table

With the inventory ready, write each old address's counterpart on the new site next to it. This table is the most important document of the migration.

Four columns are enough: old URL, new URL, redirect type and notes. Most rows will be 301, a permanent redirect. A 301 tells Google “this page has permanently moved here” and helps pass the old page's signals to the new one. Don't use 302, the temporary redirect, for this.

A few rules for mapping.

Redirect each old page to the new page closest in content. The old “boiler maintenance” page should go to the new “boiler maintenance” page, not the services list or the homepage.

Avoid redirecting in bulk to the homepage. Pointing hundreds of old addresses to the homepage looks like an easy fix, but Google usually treats them as “soft 404s” and value may not pass. Users who land on the homepage instead of the page they wanted get lost too.

For pages with no real counterpart on the new site, there are two options. If a similar page exists, redirect there. If not and the page has been permanently removed, let it return 410 (gone) or 404. For old pages with no traffic or links, that's generally not a problem.

Avoid redirect chains. If the old site already holds redirects from a previous redesign, you can end up with a chain from A to B to C. Update them to go straight from A to C.

If the domain is also changing, make sure every page on the old domain redirects to its counterpart on the new one. In that case you also need Search Console's Change of Address tool.

Preserving metadata and content

Redirects protect addresses, but addresses alone don't decide rankings. Google looks at page content. If content is lost in the new design, even correct redirects may not fully preserve rankings.

For the most critical pages in the mapping table, put the old and new versions side by side. Is the page title and meta description kept or improved? Does the H1 cover the same topic? Does the main text contain the same information, or was it cut for the sake of design? Was alt text carried over? Are structured data, canonical tags and any language tags correct?

Designers often suggest shortening text because the page looks cleaner. Before deciding, check in Search Console which searches that text brings traffic from. If it does, find a way to keep it: tabs, an expandable FAQ, or a section lower on the page.

Internal links are part of content too. A service page linked from many pages on the old site but only from the menu on the new one may lose importance in Google's eyes.

Launch day checklist

However good the plan, launch day is when mistakes often happen. Run these checks in order:

• Was the noindex tag left over from development removed? Check the source code of a few pages.
• Does robots.txt contain a rule blocking the whole site?
• Do redirects work? Open the 20 to 30 most critical addresses from the mapping table one by one, then test the full list in bulk with a crawler. Every old address should go via 301, in a single hop, to the correct new address.
• Do redirects from http to https and to your preferred www version work?
• Was a new sitemap generated and submitted to Search Console?
• Do Google Analytics and Tag Manager code run on the new site? Are key events like form submissions coming through?
• Do contact forms actually send email? Make a test submission.
• Is the new site's property verified in Search Console? If the domain changed, was the Change of Address tool used?

We recommend launching early in the week. A problem on a site launched Friday evening can go unnoticed all weekend.

Monitoring for the first 4 weeks

Some traffic fluctuation in the first weeks after launch is normal. Google needs time to crawl new addresses and process redirects. What matters is telling normal fluctuation from the sign of a problem.

In week one, check Search Console's Pages report and 404 errors daily. Addresses missed in the mapping table surface here; assess each new 404 and add a redirect if needed. Look at server errors (5xx) too.

In week two, compare impressions and clicks for the most critical pages in the Performance report with the weeks before the migration. Old addresses' impressions should fall while new addresses' rise. If new addresses get no impressions at all, check indexing with the URL Inspection tool.

In weeks three and four, look at the overall traffic trend and key events. Are form submissions and calls approaching their old levels? If there's still a clear drop, identify which pages lost out and review them again for content and redirects. We explained how to track broken links and 404 errors regularly in a separate post.

Don't rush to remove redirects. Google's documentation recommends keeping them in place for a long time, at least a year; considering links from external sites, keeping them permanently if possible is safest.

When getting quotes for a redesign, ask your agency whether this plan is in scope. The redirect plan is the invisible half of the design that protects your traffic.