Technote

Development workflow Practical

Series Redesigning a site that is already live Part 5 of 8

Do not swap everything at once

A full swap makes every problem appear at the same moment — which means none of them can be attributed. So you switch one template at a time.

When the new design is ready, the temptation is to switch everything on a chosen day. It announces well, and there is no awkward period with two designs side by side. But it carries one cost: when something goes wrong, you cannot tell what caused it.

Suppose traffic wobbles the day after a full swap. The candidates are changed addresses, changed title tags, page speed, internal linking, or simply that week’s seasonality. Because everything moved together, there is no way to eliminate hypotheses one by one.

The unit of rollout is the template

Here is why part one counted templates rather than pages. Switching one template changes every screen it renders, and the changed set is exactly known. That set is also what you then observe.

Rollout order — start where risk is low and learning is high, finish on the home page

The ordering principle is low risk, high learning first. Single posts exist in large numbers, so the full variety of real content shows up immediately, yet they are not the centre of the conversion path. What you learn there — long titles, tables, quotes, image handling — feeds straight into every remaining template.

The home page goes last. It has the most exposure and the least to teach: one screen offers no variety to learn from, while getting it wrong costs the most.

Living with two designs for a while

The price of a gradual rollout is a mixed site for a period. There is a way to soften it: unify the header and footer first. Those two are the strongest cues a visitor uses to recognise where they are, so when they match, differing body layouts still read as one site.

Move the site-wide elements early too — buttons, link colour, body typography. Laying the foundation of the new system first and raising templates onto it one at a time is always quicker than carrying different rules into each template.

You accept a mixed period and get back the ability to know what caused what

What to watch at each step

After switching a template, leave it a few days. Watch three things: are those screens still being indexed, has speed held up, and does the next action people used to take still happen. If all three look fine, move to the next template.

How to observe these and what counts as a normal range is picked up in detail in the post-launch part.

Staged deployment and verification are covered further in the development workflow archive, and staged, no-downtime work is exactly how our optimization program runs.

Next part

Switch templates one by one and you will inevitably meet something: old body content that does not follow the new design. That is the next part.

More on this topic

All technotes

Development workflow Practical

Turning taste arguments into rule checks

"It feels a bit cramped" can be neither argued with nor fixed. Spacing off the scale, colour off the palette, contrast below threshold, missing states — four rules…

Designers 9 min read

Development workflow Practical

Adding an SCSS build, and whether to commit the output

WordPress themes are expected to deploy without a build step, which leads to the opposite conclusion from ordinary application code — and to its own costs.

Developers 7 min read

Development workflow Practical

Running scripts with eval-file, and the argument trap

It runs your own PHP file inside a fully loaded WordPress. Flags starting with -- never reach your script, though, because WP-CLI consumes them first.

Developers 7 min read

₩270,000 · Join the program