Our logo was the old domain, set in type: what a rebrand actually costs in code, redirects and brand strings

The blocker that stopped a rebrand for two weeks was not the redirects, the legal texts or the SSL certificate. It was that the logo was the domain name, set in type. There was no mark to keep and no wordmark to re-letter. Change the domain and the logo becomes a picture of an address that no longer exists.

I run a Swiss trade directory as one of my own projects, and this week I moved it onto a new brand and a new domain. Not for a client, so nobody to blame and nowhere to hide. Here is what a rebrand actually consists of once you stop thinking of it as a design exercise.

The plan said nineteen files. There were thirty-one.

The migration plan, written two weeks earlier, listed nineteen Python files carrying the old domain as a hardcoded string. The actual sweep found thirty-one. Not because the earlier count was careless, but because a domain literal is the kind of thing that gets copy-pasted into a new generator script on a Tuesday afternoon and never thought about again.

The fix was to stop hardcoding it at all: one configuration file holding the site URL, and — this turned out to matter — a separate entry for the FTP document root. Those two had been the same string for years, so they had quietly become the same concept. They are not. During a migration the public address changes before the deployment target does, and a codebase that conflates them cannot represent the intermediate state where the site is served from one place under a different name.

The verification was the dull part and the part that made it safe. Grep for the old domain across the tree, expect zero hits, compile everything, then regenerate the entire site and diff the output against the previous build. Byte-identical. That is the only assertion worth making before a migration: nothing changed except the thing I meant to change.

The redirect map was easier than the brand sweep

The redirects were 1,176 URLs and a pure host swap, which is the least interesting kind of migration and by far the best kind to have. Google's site move documentation wants one-to-one permanent redirects from every old URL to its closest new equivalent, kept in place for at least a year, plus the Change of Address tool in Search Console once the new property is verified. A blanket redirect to the homepage is where people throw away their rankings, and it is always tempting because it is one line of configuration.

The plan had also over-estimated one section — the magazine was 38 URLs plus 72 dated posts, not the "200+" I had written down. Worth checking, because a wrong count is how a two-day job gets scheduled as a two-hour one, or the reverse.

The brand sweep was the fiddly half: 22 brand phrases across 15 files — page generators, email sender names, print layouts, theme templates. And one rule I had to hold firmly the whole way through: the old brand name was also a keyword. The trade term people actually search for appears in headings and copy all over the site and must not move an inch. A find-and-replace that treats a brand string and a search term as the same string will strip the site's organic relevance while making everything look tidy.

The legal texts I did not touch at all, pending a lawyer's answer. Old brand name, still live, deliberately. A rebrand that silently rewrites its own terms and conditions is not a rebrand, it is a problem for later.

Renée Mauborgne, in Blue Ocean Shift: "A brand, in short, is the result of what you do. It's not an isolated, independent factor." Which is why the expensive part of this week was never the logo. It was the thirty-one files, the eleven hundred redirects and the sender name on the automated emails.

What made the wordmark blocker solvable

I did not start a new identity. I sampled the colours out of the existing logo, kept the existing signet tile, and set the new name in the typeface the site already uses, with the three parts of the name carrying three tones from that palette. Fifteen minutes of decisions, because all the decisions had already been made — the design system was already reverse-engineered from the live site, so there was a documented palette and type ramp to build from rather than a taste argument.

Then everything that is only changeable in the live system went onto a separate checklist with current-state and target-state columns: WordPress site title, SEO title suffix, logos, favicon, analytics property, payment product descriptors. These are the items that no sweep of the codebase will ever find, because they live in a database or someone else's dashboard, and they are the ones that survive the cutover as embarrassing leftovers if nobody writes them down.

And the print pipeline got a dry run — one magazine issue rendered to PDF, twelve pages, zero occurrences of the old brand. Checking the generated artefact rather than the generator is the same instinct as diffing the site output: assert on what actually ships, not on what the code intends to ship.

The uncomfortable finding

Nothing had happened in the two weeks since the plan was written. The SSL certificate for the new domain was still broken. The repository was still sitting on an unrelated feature branch. Every blocker on the list was untouched.

The plan had been perfectly good and completely inert, which is a failure mode I have run into before in a different costume: a written intention with no dated owner does not execute itself, and a fortnight is long enough for that to be invisible. The thing that moved it this week was not a better plan. It was a cutover date, a list of items only Remco can do — certificate, mailboxes, search console, the lawyer's letter — and the acceptance that the codebase work could all be done in parallel, on a branch, deploying nothing.

That last part is the actual technique. Everything I built this week is staged: refactor, redirect map, brand sweep, new logos, the migrated prospectus, all committed and none of it live. The cutover is then a small number of switches rather than a week of work performed under time pressure on a production site.

A rebrand looks like a design project and behaves like a data migration. Budget it that way.

Sources & further reading

External
Site moves with URL changes — Google Search Central
Change of Address tool — Search Console Help

Related posts
The brand book didn't exist
The work was deciding what not to index
2,390 ways to say 29 things
I scheduled a weekly check that could never run