A favicon reminded me that a redesign never truly starts from zero

The new website was still showing an old colour

A few days after publishing a redesign, I noticed the favicon in the browser tab. It was the intended icon, but it still carried the colours of the previous brand. The new identity was present throughout the website. In that small space, however, the old one had survived.

It did not prevent a page from opening, slow the website down or block any function. That is precisely why this kind of detail can go unnoticed while checks are focused on the more consequential parts of a project.

I corrected it. I could have considered the episode closed within a few minutes because its technical impact was minimal. It seemed more useful to consider what the favicon represented: not a problem in the new code, but a trace of the previous project that had remained during the transition.

It was a small error. It was still an error, and being small did not make it invisible to the brand.

Rebuilding everything does not mean starting from nothing

When I create a new website, I can define its structure, files, images, metadata and behaviour from the beginning. That does not make the work automatically perfect, but the boundary is created with the project and every element has a deliberate place.

In my work, a redesign is not a matter of changing a few colours on top of the existing website. It means redesigning and rebuilding the website with the same method I use for a new project. The difference is that a history already exists: an active domain, content, files, icons, indexed results, brand assets and sometimes configurations accumulated over years.

Some elements need to be retained. Others need to be transformed. Others should disappear. The challenge is not only to produce what comes next correctly, but to recognise everything that belonged to the previous version and decide what should happen to it.

A favicon does not determine website quality. It is part of its consistency

I do not want to give a favicon an importance it does not have. The old colours did not compromise the website’s security, SEO, responsiveness or usability. They did not erase the work that had been completed or change how the pages functioned.

A favicon does, however, appear in the browser tab, bookmarks and other places where a website is recognised in very little space. It is a detail, but it is also a signature. If it preserves the old brand while everything else presents the new one, the story is not entirely consistent.

That is why I distinguish severity from correctness. Not every error carries the same weight, and treating them as equivalent would be misleading. A security issue demands a different priority from a colour left inside an icon. But the second still needs to be acknowledged and corrected rather than hidden behind the fact that the website works.

Aiming for 100 does not mean claiming to be infallible

For the websites I build, I aim for the highest possible result in performance, accessibility, best practices and SEO. Security, responsiveness and usability are part of the project from the beginning. These are concrete objectives supported by specific checks and tools.

A Lighthouse score measures certain conditions at a specific moment. It does not check whether a favicon colour matches the brand, know every intention behind the project or certify the absence of every possible human imperfection. Confusing a measured result with a universal guarantee would make that number less serious, not more authoritative.

For me, aiming for 100 means not knowingly accepting an avoidable problem. It also means continuing to observe after publication, because the real website lives across browsers, devices and journeys that no single check can exhaust.

Rigour is not claiming that nothing can ever be missed. It is refusing to ignore what emerges.

Publication is not when I stop looking

During development, checks are intended to stop known problems from reaching the public website. After publication, the context changes: the website loads from its final destination, encounters real browser caches, histories and behaviour, and reveals details that may have had less prominence within the production workflow.

That must not become an excuse to publish without checking. It is why I consider post-publication review part of the work, rather than an optional activity performed only when someone reports a problem.

The favicon with the old colours added a very simple question to the way I review a redesign: are there still signs of the previous identity in less visible parts of the project? Not only on the main pages, but also in the elements that accompany the website and make it recognisable.

A useful process does not exist because the person doing the work cannot make a mistake. It exists because relying only on attention in the moment is not enough when a project contains many parts and a history that needs to be migrated.