Website redesign without losing traffic: what to keep and what to check

Website redesign without losing traffic

A website redesign without losing traffic is achievable, but only when the project is treated as a migration rather than a change of appearance. Traffic drops after a relaunch are most often tied to changed URLs without proper redirects, deleted or heavily shortened content, and replaced titles and meta descriptions, not to the new visual design. This article covers what to record before the work starts, which decisions belong before the design stage, and what to watch during the first three months after launch.

In short

• Traffic loss after a redesign is most often tied to changed URLs without correct 301 redirects, to deleted or heavily shortened content, and to replaced titles and meta descriptions, not to the new visual design.
• Google recommends server side permanent redirects (301 or 308) and advises keeping them for at least one year. For medium sized sites it can take a few weeks or more before the new URLs replace the old ones in results.
• If the URLs stay the same, the risk drops sharply. A change of URL structure is worth making only when there is a concrete reason, not for the sake of tidier looking addresses.
• Record a baseline before anything is touched: full URL inventory, rankings, traffic per page, titles and meta descriptions, internal link map.
• Core Web Vitals are measured on real users at the 75th percentile. The thresholds for a good rating are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1.
• Migration errors found at launch are fixed immediately. Only unrelated structural changes get postponed, because they mix effects and make diagnosis impossible.

Table of contents

• Why traffic drops after a redesign
• What exactly gets lost in a redesign
• When a redesign is justified and when it is not
• What to record before touching the site
• When to change the URL structure and when not to
• How redirects are done properly
• Content: what not to delete
• Technical items that break most often
• Speed and Core Web Vitals after a redesign
• What to monitor in the first 90 days
• When traffic recovers
• Common redesign mistakes
• Frequently asked questions

Why traffic drops after a redesign

Traffic drops after a redesign because Google loses the connection between what it already ranked and what it now sees. Ranking is attached to a specific URL and to specific content at that URL. When the URL changes without a redirect, the accumulated value does not transfer on its own. When the content is halved for a cleaner layout, the page no longer answers the same queries.

Design is rarely the cause

A visual change on its own does not cause organic positions to fall. Google evaluates a page on content, structure, real user speed and links. A new look with the same text, the same URLs and the same headings usually passes without disruption. The problem appears when the redesign arrives together with a new CMS, a new menu structure and new, shorter content.

The three levels where the connection breaks

In a migration the connection breaks at three levels. URL level: the old address returns a 404 error or leads to the home page. Content level: the text has been rewritten more briefly and no longer covers the same sub questions. Structural level: internal links to the page disappeared with the old template, leaving the page without any inbound links from its own site.

What exactly gets lost in a redesign

What gets lost in a redesign is concrete and countable, and every item can be checked in advance. The list below is the practical minimum to audit before the new site goes live.

The most expensive loss is content

URLs are fixed in a day. Deleted content takes weeks to rebuild. If the old site had a detailed service page of 1800 words and it is replaced by a visual block and three sentences, the page loses every long tail query it used to appear for. This is why the content review belongs before the design work, not after it.

When a redesign is justified and when it is not

A redesign is justified when the site has a measurable problem that cannot be solved by changing content. Cosmetic fatigue with your own website is not that kind of problem.

Justified reasons

• The site works poorly on mobile and the device data shows it.
• The platform is unsupported or has known security vulnerabilities.
• Required functionality cannot be added: configurator, filters, multiple languages, connection to a stock system.
• Forms and the path to an enquiry are confusing, and the data shows people reach them but do not complete them.
• The site does not meet accessibility requirements that already apply to the business.

Reasons that do not justify a full redesign

• The site looks dated but brings in enquiries.
• A competitor has launched a new website.
• Colours and fonts need changing, which is done within the existing template.
• There are speed complaints caused by heavy images, which can be solved without a new site.

If the site has measurable traffic but needs content and speed improvements, look first at the signs that a website genuinely needs rebuilding before committing to a full replacement. Once the decision for a new site is made, scope and budget are planned together rather than separately: indicative ranges are covered in the guide to website development cost in Bulgaria.

What to record before touching the site

The baseline is a snapshot of the state before migration, and without it there is no way to prove what actually broke. It is recorded on a single day and stored outside the website.

Minimum data set

1. Full list of indexable URLs from the sitemap file and from a crawl of the site.
2. Google Search Console export for the last 12 months: queries, pages, clicks, impressions, positions.
3. Export from the rank tracking tool for the keywords being monitored.
4. Table of title and meta description for every URL.
5. List of the pages with the most inbound external links.
6. Traffic per page from the analytics tool for the last 12 months.
7. A copy of the text content of every important page.

Why 12 months and not 3

Twelve months reveal seasonality. If the baseline covers three months and the migration coincides with a normal seasonal dip, that dip will be blamed on the redesign. The reverse is equally true: a seasonal rise can mask a real loss.

Who keeps the data

The data is kept by the site owner, not only by the agency. If the working relationship ends six months later, the baseline still needs to be accessible. This is a practical point best settled before work begins.

When to change the URL structure and when not to

The URL structure is changed only when the current one obstructs something concrete. Every address change is a risk that has to be justified by a benefit larger than that risk.

Justified cases

• URLs contain parameters and identifiers instead of readable words.
• The site moves from one domain to another, or from a subdomain into a folder.
• A second language is introduced and the language versions need clear separation.
• The category structure genuinely changes, not just its labels.

Cases where URLs stay as they are

If the URLs are readable, short and reflect the content, they are kept even through a complete change of design and platform. A good URL is not the one that looks tidy in a presentation, it is the one that already ranks.

Protocol and domain changes

Moving from http to https and switching between the www and non www version are treated as address changes and require redirects, but they do not require the Change of Address tool in Search Console. That tool is intended for moves between domains and subdomains, according to Google's documentation on site moves with URL changes.

How redirects are done properly

Redirects are implemented server side with a 301 or 308 status code, one to one, from each old URL to the exact matching new one. Google recommends server side permanent redirects wherever technically possible.

The one to one rule

Every old URL points to the new URL with the same or the closest matching content. Redirecting all old addresses to the home page in bulk is the most common migration mistake. To a search engine that pattern reads as deleted content, and the old page loses its positions.

Redirect chains

If the site has been migrated once before, old redirects are probably still in place. New ones must not be layered on top of them. Address A pointing to B pointing to C is rewritten so that A points directly to C. Chains slow crawling down and in some configurations they break.

How long they are kept

Redirects are kept for at least one year. Keeping them indefinitely is the practical choice, because external links to old addresses survive long after the migration, and everyone arriving through them is a real visitor.

Pre launch checks

1. Build a two column table, old URL and new URL, covering every indexable page.
2. Verify that each row returns a 301, not a 302, a 307 or a soft error.
3. Verify that no row points to an address that redirects again.
4. Verify that addresses with and without a trailing slash behave the same way.
5. Check what happens to image URLs and downloadable file URLs.

Content: what not to delete

Nothing that generates impressions or holds inbound links gets deleted, even when the clicks are few. Impressions mean Google considers the page relevant to specific queries, and that is a foundation to build on.

How to decide which page stays

Merging rather than deleting

When two pages cover the same topic, the weaker one is merged into the stronger. The unique parts of the weaker page's text move into the stronger page, then the weaker one is redirected. This preserves the content and removes the internal competition between the two.

Headings stay as text

In a redesign, headings are often turned into images or into captions over background blocks. Important information has to remain as HTML text. The same applies to prices, lead times, opening hours and service lists, because they are used both by search engines and by the systems that extract answers.

Technical items that break most often

Post migration technical problems repeat almost identically across projects, which is why they are checked against a list rather than by instinct.

The noindex left over from staging

The staging site is normally closed to search engines. At launch that restriction has to be lifted both in the robots file and in the meta tag. This is the most common and most expensive oversight in a migration, because the site simply vanishes from the index.

Canonical tags pointing at the staging domain

If canonical URLs were hard coded during development, they keep pointing at the staging address after launch. Check one representative of every template type: home page, service page, article, category, product.

The sitemap file

The new sitemap contains only the new URLs, returns valid XML, and is submitted in Search Console once the redirects are live. An old sitemap with old URLs that is still reachable sends a contradictory signal.

Error pages

A non existent URL must return a real 404 or 410 status, not a page with a 200 status that merely looks like an error message. Soft errors accumulate in the indexing report and distract crawling.

Structured data

Before the migration, take an inventory of which structured data types exist on which templates. After the migration, verify that the same types are present, valid and consistent with the visible content. Data for non existent offers, ratings or reviews is never added.

Speed and Core Web Vitals after a redesign

The new site is often slower than the old one, because it carries more images, more fonts and more scripts. Speed is measured with real user data at the 75th percentile, not with a synthetic test on a fast connection.

The thresholds for a good rating

These thresholds and the 75th percentile methodology are set out in Google's official Core Web Vitals documentation. INP replaced the earlier FID metric and has been a stable Core Web Vital since 2024.

What degrades the score on a new site

• A large hero image or video without predefined dimensions.
• Fonts that load late and cause text to shift.
• Scroll animations that block the main thread.
• Consent banners that appear with a delay and push content around.
• Tracking scripts added sequentially without prioritisation.

A closer look at how these metrics feel to an actual visitor is covered in the article on Core Web Vitals from the real user's perspective.

What to monitor in the first 90 days

In the first 90 days there are two distinct kinds of intervention. Errors caused by the migration itself, such as missing redirects, a leftover noindex or broken canonical tags, are fixed the moment they are spotted. Unrelated structural changes are postponed, because they mix effects and make it impossible to tell which intervention caused what.

The first 48 hours

1. Confirm the indexing restriction has been removed.
2. Test 20 to 30 representative redirects live.
3. Submit the new sitemap in Search Console.
4. Confirm the analytics code and goals fire on every template.
5. Test the forms: send a real enquiry and confirm the message arrives.

The first two weeks

• Indexing report: watch for new 404s and soft errors appearing.
• Growth in indexed new URLs and decline of the old ones.
• Real user speed data, which starts accumulating after launch.
• Structured data report: new warnings and errors.

Month two to month three

Compare traffic per page against the baseline for the same period the previous year. Work page by page, not on the total. The overall figure can look stable while specific important pages have lost half their visibility.

For ongoing monitoring of availability and site health after launch, an automated check is useful, which is what the website monitoring service provides.

When traffic recovers

In a correctly executed migration, fluctuations last weeks rather than months. Google notes that for medium sized sites it can take a few weeks or more before the new URLs replace the old ones in results, and longer for larger sites.

Normal behaviour

It is normal for positions to fluctuate during the first two to four weeks, for old URLs to gradually disappear from results and for new ones to take their place. Impressions may dip temporarily and then return.

When it is no longer normal

• A noticeable drop that persists beyond six weeks with no sign of recovery. A threshold in the region of 30 per cent is a practical rule of thumb from migration work, not a Google standard.
• An indexed page count that does not approach the number of URLs in the sitemap.
• Specific pages that do not appear at all when searching for their own URL.
• A large number of soft errors in the indexing report.

What to check first on a lasting drop

1. Indexability: robots meta tag, robots file, HTTP headers.
2. Canonical tags across every template type.
3. Redirects: missing, chained, or pointing to the home page.
4. Amount of text compared to the old site, page by page.
5. Internal links: pages left without a single inbound link.

If the drop is not migration related and the site simply never ranked, the causes are different and are checked in a different order. That case is covered separately in the article on why a website is not ranking in Google.

Common redesign mistakes

Everything at once

New design, new platform, new structure, new content and a new domain on the same day. When something breaks, there is no way to establish which of the five caused it. Where possible, changes are split into stages with a few weeks between them.

Launching on a Friday

A migration goes live early in the week and early in the working day, when someone is available to react. A problem spotted on Friday evening sits unresolved for three days, and search engines crawl the broken version throughout.

Design produced without the text

When the design is approved with placeholder text, the real content later does not fit and gets cut. The working order is the reverse: first decide what the page has to say, then design how it looks.

Deleting the old site

The old site is archived together with its database and kept for at least a year. When there is a dispute about what a given page said, the archive is the only reliable source.

No named owner

If nobody is specifically responsible for the migration work, it gets split between designer, developer and marketing, and as a result nobody does it. Responsibility is assigned by name before the start. On projects where website development and the subsequent SEO optimization go to the same provider, that ownership is clear by default, because the same team is accountable for the outcome after launch.

Skipping the other language versions

On a site with two language versions, redirects and language annotations are checked separately for each. A correctly migrated English version and a broken second language still counts as a broken migration.

Frequently asked questions

Will traffic drop if I keep all the URLs?

With unchanged URLs, unchanged content and unchanged headings the risk is small. Short lived fluctuations are possible due to recrawling and speed changes, but a structural drop is not expected. Compare the amount of text per page before and after launch, because cutting content is a more common cause of decline than the design change itself.

How far ahead should a migration be prepared?

Preparation starts when the scope is defined, not in the final week. The baseline, the redirect map and the decisions about which pages survive are made before the design work, because they determine how many pages the new site will have and what content those pages must hold.

Can a redesign increase traffic?

It can, when it solves a real problem: better mobile behaviour, a faster site, a clearer structure and more detailed content. The growth comes from those changes, not from the new appearance on its own. If the content stays the same, the best realistic outcome is holding current levels.