Website redesign: what breaks your search visibility, and how to avoid it.

A redesign rarely fails on design. It fails on search visibility, and you find out six weeks later, when the traffic does not come back. We migrated studjoow.com from WordPress to Next.js in May 2026: 247 URLs, five of which carried 43 % of all clicks on their own. Here is what that migration taught us, and the order to do things in.

What a redesign actually costs you

The risk is arithmetic, not aesthetic. On an established site, traffic concentrates on a handful of pages. In our inventory, five typography pages accounted for 779 clicks out of 1,801, and eleven colour articles added up to 227,354 impressions. Lose those URLs and you lose half the traffic, however good the new site looks.

Three causes, in order of frequency: URLs that change without redirects, temporary redirects that carry no authority, and a technical setup that slows down how fast crawlers can read the site. None of the three is visible to the naked eye.

Step 1: freeze the inventory before touching anything

Before the first mockup, export every URL from Search Console over sixteen months, with clicks, impressions and average position. That export becomes a versioned file in the repository, not an attachment in an email.

Each URL gets one decision and one only: kept as is, redirected to a precise target, or dropped. Our inventory was 247 lines long, and every line carried its target route. Of 146 portfolio pages, thirty were kept; the other 116 redirect with a 301 to a single page, because their traffic did not justify maintaining them.

That file is the contract of the redesign. A URL that is not in it does not exist, and any change to it goes through an explicit review.

Step 2: decide what you abandon

A redesign is also a pruning. The criterion is not attachment to the content, it is clicks over twelve months. A page with zero clicks in a year does not deserve to be carried over, it deserves to be redirected to the page that replaces it.

Own the loss when you decide it. Consolidating a hundred dead pages into one living page beats maintaining a hundred pages nobody reads and Google crawls on your behalf.

Step 3: the three technical traps of migration

The temporary redirect that carries nothing

A 307 redirect is temporary: it does not transfer the authority you built. Hosts sometimes set it by default between the bare domain and the www subdomain. Google then treats the two as separate sites, and the history stays on the wrong side.

Checking it takes one line:

curl -sI https://yoursite.com | grep -i "HTTP\|location"

A 301 or a 308 is fine. A 307 has to be fixed before launch, not after.

The dynamic rendering that kills the cache

On modern frameworks, reading headers or cookies inside a shared component, a site header or a footer, flips the entire site to dynamic rendering. Every crawler visit becomes a server call, and crawling slows down accordingly.

The symptom is readable in the response headers: a cache-control that turns to private, no-cache and a CDN cache that never fills. We lived through it on studjoow.com: a single line of geolocation in the footer had made every page on the site dynamic.

Internal links that no longer say anything

When a whole card is a link, the anchor text becomes the full teaser: several hundred characters, unreadable to a screen reader and meaningless to a search engine. The link should carry the title, and the card stays clickable through a CSS overlay.

Step 4: measure afterwards, with the right indicators

Search Console takes one to two weeks to reflect the migration. That delay is normal and staring at it daily does not shorten it.

What to track, in order: coverage errors, the average position of the ten URLs that carried the traffic before, then field Core Web Vitals. A lab score says nothing about what your visitors actually experience.

Set the baseline before launch. Without a picture of the before, the after is only an impression.

Step 5: replace the redesign with maintenance

A redesign every five years is expensive and frightening, so it gets postponed, so it costs more. A site maintained continuously never enters that cycle: pages evolve one at a time, the technical base follows its versions, and the question of a redesign stops coming up.

That is the model we apply to our own sites and to the ones we operate: continuous updates rather than periodic reconstruction.

How long, and with whom

A properly inventoried redesign takes six to ten weeks for a site of one hundred to three hundred pages, including a full week spent on the URL inventory alone. That is the week everyone wants to skip, and it is the one that decides the outcome.

If you want to see how we run a Next.js redesign, the method is laid out on our Next.js redesign page. If you would rather talk about your own case, the first conversation lasts thirty minutes and costs nothing.