We built and maintain the public record for the Council on Local Relations, a client of ours. It has one approved seal. When we audited where that seal appears, we found older versions of it live in a lot of places. This is what we found, what we changed, and what we put in place so it does not drift again.
What we found
Wherever we looked, something other than the approved seal was showing.
- The header seal on the main pages of the site was an older hand-drawn version.
- The site icon, the favicon target and the logo in the page data were a traced rhino.
- Across all 43 places, the SVG files, favicons and apple-touch icons were an older generation of the seal.
- The Deer Park share cards had the old rhino drawn into the image itself.
- The Substack email banner showed a rhino that looked more like a horse.
None of it was dramatic on its own. Together it meant the same organisation looked slightly different depending on where you met it.
What we built
First we built a proper set of headers and banners from the one approved seal file. Our build script scales the seal and never redraws it, and it refuses to run unless the source file matches the approved fingerprint.
The set covers:
- email banners at 1100×220, 2200×440 and 1200×300;
- a Substack header at 2400×600;
- a dark-background variant;
- a 1456×816 cover for every Substack package, with the seal small and whole in a corner so it survives the 1.91:1 share crop.
Each one shows the whole seal with clear space around it and the wordmark beside it.
What it took
The swap itself was 495 files. In plain terms:
- the header seal, the site icon, the favicon target and the page-data logo, all on the main site;
- every seal, favicon and apple-touch file across all 43 places;
- the Deer Park share cards, 63 live and 149 in staging, where we repainted only the 52px mark box with the approved seal and changed nothing else on the card;
- 873 files in our staging copies, so old versions could not be redeployed from there;
- the dashboard folder the place pages were originally generated from, where we also retired the script that composed the old seal.
We kept every file name. That meant none of the roughly 2,300 pages that reference those files had to be edited. We also copied the originals to a backup folder outside every web folder, so anything can be rolled back.
Afterward we checked from outside. The header seal, the favicon target, a Pasadena seal, an LA seal, and Deer Park's apple-touch icon and share card all match the approved file. Our check now reads 533 marks and 0 failing across every live site of the client.
We also checked the places that did not need a fix: the Facebook avatars for both pages, the social scheduler channel avatars, our email templates and campaigns, the card and reel templates, and the brand kit. All clean.
The part that matters most: the check
A clean-up lasts until the next deploy. So we added a gate.
Any file named like a seal, rhino, logo, favicon, apple-touch icon or wordmark has its fingerprint compared against an approved list. If it is not on the list, it fails. We compare fingerprints rather than names because the retired seal file and the approved one share a file name. A name check would have passed both.
We tested the gate before trusting it. A wrong file with the right name fails. A renamed copy of a wrong file fails. The gate now runs on every staged file at deploy, and our brand-kit process refuses any logo that is not on the list.
One honest caveat: the list includes our own five UMS logos exactly as they are served today, so the gate does not block our site. Whoever owns our brand kit still needs to confirm those against the kit of record.
What is still open
- There is no rhino-only mark in the approved set. Every former rhino icon now shows the whole seal. It is correct, but at 16 px it reads as a disc. Making a rhino-only mark would be a new brand asset, and that is the client's decision.
- Several town sites have no share image, so the share link returns a 404. That is not a seal problem, but we noted it.
- The Substack email banner still needs a login to replace, so it is handled as a separate task.
- There is no reversed version of the approved seal. The reversed file is the same file as the light one, as it was before.
What you can take from this
Your logo is almost certainly in more places than you remember, and some of them are old copies.
Make a list of every place it appears: website header, browser tab icon, share image, social avatars, email banner, invoices, directory profiles. Open each one and look. Keep a single approved file in a single folder. When you update it, replace the files in place under the same names, so the pages that use them do not need editing.
And if you have more than one person or tool touching your site, compare logo files by content, not by name. The old version and the new one can look identical in a folder listing.