How to Do SEO During a Website Redesign
On this page
A redesign can lose traffic through defects you can check for before and after launch, such as URLs that changed without a redirect, pages removed while they still earned links, unmatched URLs redirected to the home page, and staging settings that reached production. Treat the redesign as a software release. Take a baseline before anything changes, give every existing URL an explicit fate, check the launch against a short list, decide your rollback triggers in advance, and compare the result with the baseline for weeks.
Take a baseline first
You can’t judge a launch without a “before.” Capture it while the old site is still live:
- Top pages and queries from the Search Console Performance report, over a period long enough to cover weekly swings.
- Pages with links from other sites, from the Links report and any backlink tool you use.
- A full URL list from a crawl of the current site and from your CMS. Search Console’s example lists are samples, not an inventory.
Store the export where you can compare against it after launch. This list is also where your redirect map starts.
Give every URL a fate
Build a row-per-URL map, and give each old URL one of these outcomes:
| Fate | When |
|---|---|
| Unchanged | The URL survives the redesign |
| Permanent redirect to its equivalent | The page moved |
| Permanent redirect to the page it merged into | Several pages became one, and the content came along |
| Permanent redirect to the closest relevant page | No equivalent exists, but a closely related page does |
| 404 or 410 | The page has no replacement, no links you want to keep and no traffic |
Google’s documentation on redirects says the indexing pipeline uses a permanent redirect as a signal that the target should be canonical. Its site move guide warns against redirecting many old URLs to one irrelevant destination, such as the home page, because it can confuse users and might be treated as a soft 404. The same reasoning applies to sending every old blog post to the blog index.
When pages merge, carry their content into the merged page. A redirect to a page that no longer covers what the old one answered sends visitors to the wrong answer. Before removing a page, check the baseline: if it still earns links or traffic, keep it or redirect it to its closest real counterpart.
Check the launch
A staging site should be kept private with a password. Google’s guide to controlling what you share says private content needs password protection so only authorized users can access it. What matters at launch is that none of staging’s protections come along. In the first hour, check each template on production:
- No leftover
noindex. Google’s page on blocking indexing describes two ways to set it: a<meta>tag and anX-Robots-TagHTTP response header. Check both. The header doesn’t show in the page source. - The production robots.txt, not a staging version that disallows everything.
- No authentication on production. A login left over from staging answers crawlers with an error instead of the page.
- Canonical tags on the production hostname. A build that hardcoded canonicals to the staging host points every live page at a host that is password-protected or gone.
- Redirects by response. Request a sample of old URLs from each URL pattern and confirm a single permanent redirect to a live page.
Run a live test in the URL Inspection tool on one URL per template to see what Google receives.
Decide rollback triggers in advance
Write down, before launch, what forces a rollback or an immediate fix:
- the site is down, or a whole template or section is failing, beyond the threshold your team set before launch
- redirects are failing across a URL pattern
- a
noindexor a site-wide robots.txt block is live on production
And what doesn’t: small visual differences, and ranking movement while Google recrawls. The site move guide says that with any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes it. Deciding this in advance helps keep a real failure from being ignored and normal movement from triggering a panic.
Compare with the baseline
For the following weeks, compare indexed pages, impressions, positions and clicks for the pages in your baseline. Look for sustained differences, not day-to-day movement. A page that falls and stays down after its redirect and launch checks are clean needs its own investigation, starting with its content and links.
Ask your agency for the artifacts
“We’re handling SEO” can mean meta titles and a sitemap. Before launch, ask for three things:
- the redirect map, one row per existing URL, with a fate for each
- written confirmation that production gets its own robots.txt, no
noindexand no staging login - the rollback plan with its triggers
If those don’t exist, you have no evidence the SEO part of the redesign has been done.
Frequently asked questions
Can I redirect all my old URLs to the new home page to be safe?
No. Google’s site move guide says redirecting many old URLs to an irrelevant page such as the home page can confuse users and might be treated as a soft 404. Give each old URL its own fate.
Traffic dropped after launch even though the redesign looked fine. What should I check first?
Check production for a leftover noindex in both the meta tag and the X-Robots-Tag header, the robots.txt file, and any login left from staging. Then confirm that old URLs from each pattern return one permanent redirect to a live page.
How long should I monitor after launch?
For weeks, against the baseline. Google says ranking can fluctuate while it recrawls and reindexes a significantly changed site, so judge sustained differences, not the first days.