To redesign a website without losing search traffic, record which pages earn visits today, keep each URL or permanently redirect it to its closest new equivalent, carry over the content, titles and internal links that rank, remove staging blocks at launch, and watch Search Console closely for the first weeks.
A redesign changes templates, navigation and often URLs at the same moment. Search engines then have to recrawl and re-understand the site. Google's own guidance on site moves with URL changes describes the process in detail, and this checklist follows it, adding the practical steps teams most often skip.
What can cause a redesign to lose search traffic?
Traffic is usually lost through a small number of avoidable mistakes rather than through the new design itself.
| Cause | What happens | Prevention |
|---|---|---|
| Missing or wrong redirects | Old URLs return errors or land on unrelated pages | One-to-one redirect map, tested before and after launch |
| Content removed or cut down | Pages stop answering the questions they ranked for | Content inventory of pages that earn visits; carry their substance over |
| Staging block left in place | Pages are excluded from search | Launch checklist covering noindex, robots.txt and passwords |
| Internal links changed or lost | Important pages become harder to find and look less important | Compare internal links to key pages before and after |
| Titles and headings rewritten wholesale | Pages lose clear signals about their topic | Keep titles for pages that perform; change deliberately |
| Slower pages | Worse user experience on mobile | Check Core Web Vitals on staging before launch |
What should you record before the redesign starts?
Record every URL on the current site, which pages earn search visits and links, and how each page is built, so you can protect what works and compare after launch.
Pre-redesign checklist
- A full URL inventory. Combine a crawl of the live site, the XML sitemap, a CMS export and analytics landing pages. Google's site-move guidance suggests checking server logs for URLs visited recently, and including embedded resources such as images, videos, PDFs, JavaScript and CSS.
- Top pages from Search Console. Export the Performance report by page and by query for as long a period as you can, so seasonal pages are not missed.
- Linked pages. The Search Console Links report shows which of your pages other sites link to most. These URLs must redirect perfectly.
- On-page elements per URL: title, meta description, main heading, structured data, canonical tag, hreflang if you run several languages.
- Internal links to your most important pages, and how many clicks they sit from the home page.
- Core Web Vitals: the current status in Search Console, so you know whether the new design improves or worsens it.
- Analytics and conversion tracking: every tag and event, so measurement survives the launch.
How should URLs be mapped and redirected?
Keep URLs unchanged wherever you can. Where a URL must change, redirect each old URL with a permanent server-side redirect to the single most relevant new page, never in bulk to the home page.
Google's redirects documentation recommends a permanent server-side redirect whenever possible when a page's URL changes, and names HTTP 301 and 308 as the permanent status codes. Its site-move guidance adds three points that matter in practice:
- Do not redirect many old URLs to one irrelevant destination such as the home page. Google says this can be treated as a soft 404.
- Avoid redirect chains. Point each old URL straight to its final destination rather than through several hops.
- Keep redirects for as long as possible, which Google says is generally at least one year.
URL mapping template
| Old URL | New URL | Status | Reason | Priority |
|---|---|---|---|---|
| /services/web-design | /services/website-design | 301 | Renamed section | High: top landing page |
| /blog/2019/old-guide | /blog/updated-guide | 301 | Merged into newer article | Medium |
| /promo-2021 | none | 410 | Expired offer, no equivalent | Low |
The rows are examples. Where a page is removed and nothing on the new site genuinely replaces it, returning a 404 or 410 status is more honest than redirecting to an unrelated page. Redirect URL variants as well: with and without trailing slash, http and https, www and non-www. Then update internal links, canonical tags and sitemaps to point at the new URLs directly, rather than relying on the redirects.
How to test redirects before launch
Test the redirect map on staging, not on launch day. Load the full old URL list into a crawler in list mode and check four things for every URL: it returns a single permanent redirect, the destination matches the mapping, the destination returns a 200 status, and there is no chain or loop. Check that redirects happen on the server rather than through JavaScript, which Google's redirects documentation advises using only when server-side or meta refresh redirects are not possible. Repeat the test with the URL variants your old site served, and with old URLs that carried query parameters, such as campaign links. Keep the mapping file in version control: it is the record you will need if a page underperforms months later.
What must carry over from the old pages?
Carry over whatever made each successful page useful and understandable: its main content, its title and headings, its links and its structured data. A new design should change how the content looks, not quietly delete it.
| Element | What to check |
|---|---|
| Body content | Pages that earn visits keep the substance that answered people's questions |
| Title and main heading | Kept or improved deliberately, not replaced by template defaults |
| Meta description | Carried over or rewritten page by page |
| Internal links | Key pages are still linked from navigation and related content |
| Structured data | The same schema types are present and valid on the new templates |
| Images | Alt text kept; important image URLs redirected if they change |
| Canonical tags | Each new URL has a self-referencing canonical, as Google's guidance recommends |
| hreflang | Language and regional alternates updated to the new URLs |
How should the staging site be protected, and what changes at launch?
Protect staging with a password, or with noindex if that is not possible, and remove that protection as an explicit, checked step at launch.
Google's robots.txt documentation is clear that robots.txt is not a mechanism for keeping a web page out of Google; it points to noindex or password protection instead. Its noindex documentation adds that the rule only works if the page is not blocked by robots.txt, because a crawler that cannot fetch the page never sees the noindex. Password protection avoids both problems and also keeps unfinished pages away from customers.
Launch-day checklist
- Remove the noindex rules from page templates and from X-Robots-Tag response headers
- Remove password protection from the production site
- Publish the production robots.txt, not the staging version, and check it does not block sections, CSS or JavaScript you need crawled
- Confirm canonical tags point to the production domain, not the staging domain
- Switch on all redirects and test the full old URL list
- Submit the new XML sitemap in Search Console
- Confirm analytics and conversion tracking fire on the new templates
- Use URL Inspection on a sample of key pages to check how Google sees them
What about robots.txt, sitemaps and canonical tags?
Each needs updating to match the new structure. Google's site-move guidance asks you to set up a robots.txt that blocks only what you intend, give each new URL a self-referencing canonical tag, and submit the new sitemap in Search Console.
The guidance also describes what to expect in the Sitemaps report: at first, the sitemap with the new URLs shows few or no indexed pages while the old one shows many, and the balance shifts as Google processes the move. If you are changing domain or subdomain, Google also asks you to submit a Change of Address in Search Console. That tool is not needed for moves within the same domain, for switching between www and non-www, or for moving from http to https.
Should you check Core Web Vitals before launch?
Yes. Redesigns often add large hero images, video, web fonts and extra scripts, and it is far cheaper to fix performance on staging than after launch.
The Core Web Vitals thresholds published on web.dev are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop. On staging you can only run lab tests such as Lighthouse; field data from real users appears in the Search Console Core Web Vitals report after launch, so compare it with the baseline you recorded.
What should you monitor after launch?
Monitor redirects, errors, indexing and performance by page, daily at first and then weekly, and fix problems as they surface rather than waiting for traffic to recover on its own.
First day
- Crawl the full old URL list and confirm each returns a single redirect to the right page, which then returns a 200 status
- Check that no page carries a leftover noindex or staging canonical
First weeks
- Server logs and the Search Console Page indexing report for 404 errors and unexpected exclusions
- The Sitemaps report, watching new URLs move into the index
- The Performance report by page, comparing old and new URLs for the same content
- Search Console's Links report, and outreach to important referring sites asking them to update links to the new URLs, as Google's guidance suggests
First months
- Rankings and clicks for the top pages in your inventory, compared with the same period before launch
- Core Web Vitals field data against your baseline
How long does it take for search traffic to settle after a redesign?
It varies, and anyone promising a figure is guessing. Google's site-move guidance says that for medium-sized websites it can take a few weeks or more for Google to start showing new URLs instead of old ones, and longer for larger sites.
Google also says to expect temporary fluctuation in rankings during a move while it recrawls and reindexes the site. Fluctuation alone is not a reason to reverse changes. A sustained drop on specific pages is a reason to investigate: check their redirects, content, internal links and indexing status first.
When is a full redesign not the right approach?
- The problem is conversion, not appearance. Improving key templates and forms one at a time carries less risk than replacing everything.
- You are also changing domain and platform at the same time. Each change adds risk, and stacking them makes any drop hard to diagnose. Where you can, separate them.
- The site earns most of its traffic from a few stable pages. Redesign around those pages carefully, keeping their URLs and content intact.
- There is no time to build the redirect map properly. Delay the launch rather than ship without it.
Planning a redesign with Timeline Digital
Our website redesign service includes URL mapping, redirects and launch checks as part of the build, and our technical SEO team can audit an existing site before work begins or check a launch after the fact. If the redesign is part of a wider rebuild, see our website design and development services and our UI and UX design work.