Updated September 2026. Originally published April 2024.
Between July and August 2026 I roughly doubled the traffic on two websites I own and operate.
One is Diets Meal Plan, which went from 10,274 sessions to 16,928, with revenue up 53 percent. The other is TechnoWifi, which went from 4,326 sessions to 11,032, with revenue up 283 percent and revenue per thousand sessions up 50 percent.
Both of them were redesigned. New theme, new layout, new colours, plugins stripped out, Core Web Vitals and schema rebuilt.
The redesign was the last thing I did.
Before any of it, the content was fixed. Thin and aged pages rewritten, duplicated angles consolidated, material removed that should never have been published, and every piece reviewed and updated by the author accountable for it. Author and trust signals rebuilt. Only once that was true did I touch the theme.
That order is the argument of this article, and in 2024 I could assert it but not demonstrate it. A redesign is not forbidden. It is just almost never the first thing, and when it is the first thing it is usually being used to avoid finding out what is actually wrong.
The question to ask first
Somebody calls a meeting. The navigation is wrong, the colours are tired, the homepage does not pop. A redesign is proposed, and it feels like progress because it is visible.
Ask why.
You will get one of four answers. Not enough leads or conversions. SEO traffic is low. Not enough engagement. The site is too slow. In more than a decade of being in these meetings I have never heard a fifth.
Every one of those four can be tested before anyone touches a design file, and three of them usually turn out to have nothing to do with the design at all.
Not enough conversions
First separate the count from the rate, because people say conversions when they mean one or the other and the two demand opposite responses.
Suppose you need 400 conversions a day and you are getting 12, from 100 visitors. That is a 12 percent conversion rate. Your designer is doing excellent work. You do not have a design problem, you have a traffic problem, and redesigning the page will make it worse by resetting a page that is already performing.
If you do have the traffic and the rate is poor, then the analysis is real work: where people enter, where they leave, which step loses them, and whether the traffic arriving was ever capable of converting in the first place. That last question is the one people skip, and I have written about why it matters more than the page does in the piece on keyword research and intent.
SEO traffic is low
This is the fastest one to settle. Open Search Console and check three things.
- Are the pages actually indexed
- Do they pass mobile usability
- Is anything on them misleading, hidden, or doing something the page does not admit to
If those are clean, your ranking problem is not a design problem. It is a content problem, an intent problem, or an authority problem, and a new template will not touch any of them.
A better design can help rankings indirectly, through the behaviour it produces. But search engines are not scoring your colour palette, and rebuilding the site to fix rankings is one of the most expensive ways to avoid rewriting your content.
Not enough engagement
Engagement is where raw data gets consumed without being processed.
Bounce rate is the usual offender. A high bounce rate means nothing on its own. If every page carries a form and your conversion rate is healthy, a high bounce rate may simply mean people got what they came for and acted. If the page exists to send people deeper and they leave instead, the same number is a real signal.
The number is identical. Only the intent of the page makes it good or bad. Any metric you read without knowing what the page was for will mislead you, reliably.
The site is too slow
It is not the button colour and it is not the hero image.
Check field data, not lab scores. Unoptimised images and oversized media are the common cause, and interaction delay is the one that gets missed because it does not show up in a synthetic test the way it shows up for a real person on a real phone.
Both are fixable without touching the design. Compression, correct formats and dimensions, lazy loading, and cutting the scripts that block interaction. A redesign that carries the same scripts forward will be exactly as slow, which I have watched happen.
Then the part that actually is design
Once you have ruled out the other three, there is real design work to do, and it starts further back than most redesigns do.
Your business model dictates the structure. The structure dictates the navigation.
You did not build a business to hang a website on. The site should be the clearest available representation of what the business actually does and who it is for. A beautiful site that does not reflect the model is decoration.
Most companies also load the home page with the wrong job. They try to make it close, with buy now and book a demo and get the guide competing for the same attention. The home page is rarely where closing happens. Its actual jobs are narrower:
- Orient the visitor and route them to the page that fits them
- Deliver the value proposition at prospect level, before any product detail
- Identify the business clearly enough that machines can describe it correctly
That third one has grown in importance and I will come back to it.
What changed: navigation should be first person now
In 2024 I argued for solution-focused navigation, where you organise around what you solve rather than who you serve. I said persona-based navigation adds a step to the prospect’s thinking, and I gave the example of a CMO who already knows what they need and should not have to hunt for an enterprise button.
I now build persona-focused navigation, and the reason is not a change of taste.
Solution-focused navigation was an accommodation for crawlers. It existed because search engines needed structural help to understand what a site was about. Grouping by problem, with clean hierarchies and predictable paths, made a site legible to a machine that could only infer meaning from structure and links.
That machine no longer needs the help. Engines and language models now understand what a site does from the content itself, from entities, from context, from how the whole property hangs together. They are not depending on your menu to work out that you sell managed IT to small companies.
Which frees the navigation to do the only job it was ever supposed to do, which is serve the person reading it.
And people arrive in the first person now
Here is the part that decided it for me.
Prompting has changed how buyers articulate need. When somebody types into a model, they do not write a keyword. They write a sentence about themselves. I run a forty person practice and my IT provider keeps missing tickets. I am a marketing lead at a mid-size manufacturer and I need to prove pipeline contribution.
Situation first, in the first person, then the need.
That is the same unit I described as a parent intent in the keyword research article, and it is written in the first person there too, because that is how it arrives.
So my 2024 objection has been answered by the thing that changed. I said visitors do not self-identify as enterprise or small business. They increasingly do, because the interface they now use for research asks them to describe themselves before it will help them. Navigation that lets them recognise themselves is matching how they already think, rather than adding a step.
One caveat, because this is easy to do badly. Persona-focused only works if the personas are real distinctions that change what you offer, and if they are named in the buyer’s own words rather than your internal segmentation. Enterprise, mid-market and SMB are your words. A forty person practice is theirs.
What a redesign quietly destroys
If you have concluded that you genuinely do need to rebuild, this is the part that decides whether the new site keeps what the old one earned.
Almost every redesign that loses traffic loses it here, and almost none of it is visible in the new design.
- URLs change and redirects are incomplete. Every old address needs to land on its closest equivalent, one hop, no chains. Map it before launch, not after the rankings drop.
- Internal links break silently. Links inside body content point at old paths. They still resolve through redirects, so nobody notices, and the structure you spent years building is now held together by redirect hops.
- Crawl depth increases. New templates bury pages that used to be two clicks from the home page. Anything past three clicks is telling a crawler it does not matter, whatever you intended.
- Titles and H1s collide. Template defaults overwrite carefully differentiated pages with the same pattern, and suddenly forty pages are competing with each other.
- Images break or lose their alt text. Media survives the migration, the references do not.
- Structured data disappears. The old theme or plugin was emitting it. The new one is not, or is emitting an invalid version, and nobody checks because nothing looks wrong on screen.
- Author and trust signals are dropped. Bylines, author pages, the profile links that connect a person to their work elsewhere. These are slow to build and instant to lose.
Every one of those is invisible to the people approving the design, and every one of them is why the traffic chart falls the week after launch. I have written about how the structural side of this should be built in the piece on internal linking.
The order I actually worked in
Back to the two sites, because the sequence is the transferable part and it has more steps in it than people expect.
1. Inventory and classify before touching anything
Pull every URL the site publishes and every URL that gets impressions, and put them in one list. Sitemap on one side, Search Console export on the other. The gap between those two lists is already telling you something.
Then classify every page into one of four outcomes: keep, rewrite, merge, or delete. Not by feel. By whether the page earns impressions, whether it says something no other page on the site says, and whether it is still true.
Almost nobody does this first, and it is the step that makes every later step cheap. You cannot decide a template, a navigation, or a redirect map until you know what is actually going to exist.
2. Decide what dies
Deletion is the step people cannot bring themselves to take, and it is frequently the one that moves the number.
Thin pages, pages built for a term nobody searches, near duplicates written by three different people over four years, and content that has aged into being wrong. Merging two weak pages into one good one usually beats improving both.
Every deletion and every merge creates a redirect obligation, so the map starts being built here, not at launch.
3. Rewrite in batches, against hard gates
Rewrites happen in batches, and each batch has to pass checks before it ships. Minimum depth, no duplicated headings across the set, title and description within their limits, and a similarity check across the batch so that twenty pages on related topics do not come out reading like each other.
That last one matters more than it sounds. The failure mode of producing content at volume is not that any single page is bad. It is that the set becomes homogeneous, and homogeneity is exactly what quality systems are built to detect.
4. Put a name against every page
Then accountability. Every piece reviewed and updated by the author responsible for it, not signed off in bulk.
Around that: author profiles that are actually filled in, bylines that resolve to a real person, profile links connecting that person to their work elsewhere, one identity rather than four half-built ones, and the editorial and legal pages that tell a reader who is behind the site. On anything touching health, money or safety, the review and the disclosure are not optional.
This is slow, it looks like nothing on a dashboard, and it is the part that decides whether the site is treated as a publisher or as a page farm.
5. Rebuild the structure and the internal links
Now the pages can be organised, because you finally know what they are.
Clusters and hierarchy, depth from the home page kept shallow, links placed contextually in passes rather than stuffed in one sweep, and a full audit for links that point at nothing or travel through a redirect to get where they are going.
6. Structured data
Schema after the content, not before, because schema describes what is on the page and the page keeps changing until now.
The work here is mostly removal and repair rather than addition: invalid properties, duplicate blocks emitted by two plugins at once, markup describing things the page does not contain. Broken structured data is worse than none, and it is invisible on screen, so it survives for years unless someone goes looking.
7. Then the rebuild
Theme, layout, colour, navigation. Plugins removed rather than added. Core Web Vitals, with field data rather than lab scores.
By this point the design decisions are easy, because everything upstream has already answered them. You know what pages exist, how they cluster, who they are for and how they connect. The template is the last variable rather than the first.
8. Migrate without losing what you earned
The redirect map that has been accumulating since step two now gets finished and tested. Internal links updated to their final destinations rather than left to resolve through redirects. Titles and headings checked for template defaults overwriting them. Images and their alt text verified. Sitemap and robots rebuilt and resubmitted.
Then caches purged in the right order, and the live site verified rather than assumed.
9. Watch it for longer than feels necessary
Indexing recovery is not instant and it is not linear. Pages return in an order you do not control, and the first two weeks will tempt you into a second round of changes that you cannot then attribute.
Hold still and record what you did. The discipline is the same as in testing: if you change five things while measuring, you have learned nothing about any of them.
Why this order and not another
Each step removes a variable from the one after it.
Classification makes deletion decidable. Deletion makes the rewrite smaller. The rewrite makes the structure knowable. The structure makes the linking precise. The content and structure together make the schema accurate. All of it together makes the design decisions obvious.
Run it backwards and every step is guesswork built on the previous guess. A redesign on top of unfixed content is a faster route to bad content, with the added disadvantage that the budget is now spent and everyone believes the problem was addressed.
Fix the content first. Make it accountable. Then make it fast, clean and legible.
I am also not going to claim one month proves a method. Two properties over one month, during ongoing work, is a direction rather than a conclusion, and several of these steps were running at once on each site. What it does show is that the sequence survived contact with two very different properties.
If you are about to redesign
- Ask why, and make them answer in a number. If the answer is not one of the four, it is an opinion wearing a project.
- Separate count from rate. A traffic problem and a conversion problem look identical in a meeting and need opposite responses.
- Rule out the technical causes first. Indexing, mobile, speed. They are cheap to check and they explain more than people expect.
- Let the business model set the structure. Not the org chart, and not whoever has the strongest opinion in the room.
- Write the navigation in your buyer’s first person. Their description of themselves, not your segmentation.
- Build the redirect map and the internal link audit before launch. Not as a post-launch fix, because by then the loss has already been recorded.
- Do the content before the theme. Every time. A rebuild on top of unfixed content preserves the problem and spends the budget.
- Keep the evidence. Whatever you change, record what it was before, so that the next person to call a redesign meeting has something to argue with.
The best outcome of a redesign meeting is usually that the redesign gets postponed, somebody goes and fixes the content, and by the time the rebuild happens it is a finishing step rather than a rescue attempt.
This article was substantially rewritten in September 2026. The original April 2024 version argued for solution-focused navigation. That was correct for a period when search engines relied on site structure to understand a site, and it no longer holds, for the reasons set out above. The diagnostic framework from the original is retained and expanded. The working order, the section on what a redesign destroys, and the results from the two properties are new. Diets Meal Plan and TechnoWifi are sites I own and operate; the figures are taken from their own analytics for August 2026 compared with July 2026, during a period when several kinds of work were running at once.
