A fix that hid a real problem somewhere else
Every false positive you have ever reported to a tool gets fixed the same way: somebody adds a condition. The part nobody sees is what that condition does to every other site the check runs on — because the usual way to stop a rule being wrong about you is to make it quieter about everyone, and quiet is indistinguishable from correct.
The navigation label that became a company name
A preprint archive's logo is a link, and that link's accessible name is "archive home". Good accessibility practice: it tells a screen-reader user where the link goes.
A check that works out what a site calls itself reads four sources, and one of them is that accessible name. It has a salvage step that strips navigation words, because plenty of real logo labels look like "[Company] homepage" and the company is what you want. So "home" came off, and "archive" was recorded as one of two names the organisation uses for itself.
It is not a name. It is the section the link points to, with the word "home" removed by a step that was working exactly as designed.
The rule that fixed it, and why it is about the domain
A link's accessible name is the weakest of the four identity sources. Structured data and
og:site_name are declarations — a site saying who it is. A link name is a
description of a destination. So the weak source was made to corroborate against the one
identity signal a site cannot easily fake: its own domain.
Across crawled sites the pattern held cleanly — every genuine residue resembles the domain, and only the navigation label does not:
| What the logo link was called | Resembles the domain? |
|---|---|
| The company's name, plainly | Yes |
| The company's name plus a description of itself | Yes |
| A health service's initials plus "homepage" | Yes |
| "archive home", on an archive whose name is not "archive" | No |
And then the fix broke a site it had never seen
This is the half worth publishing.
The first version of that fix required corroboration from every residue. It is the obvious reading of the rule and it is wrong, because a test in the suite asserts the opposite case: a logo naming one institution, on a site titled after a completely different one, on a domain resembling neither. That is a real disagreement, and it is precisely what this check exists to find.
Demanding corroboration everywhere made the logo source incapable of ever being the odd one out. One site's false positive had been traded for another site's false negative — and a false negative makes no noise at all. Nobody writes in to say a tool failed to tell them something.
The narrower condition
What separates the two cases is not the name. It is whether the salvage had to run at all.
- An accessible name that was already a plain name — the company, and nothing else — is a declaration in everything but format. It is read as before, corroborated or not.
- One that needed a navigation word stripped off it was a description of a destination, and what remains is as likely to be the section as the company. That residue has to resemble the domain before it counts.
The general form: when a guard is about to silence a whole source, ask what made this case suspicious, and condition on that instead of on the source. The suspicious thing here was never "logo links are unreliable" — it was "this string only became a name because we edited it".
What the rule costs, stated plainly
A company whose domain does not contain its name — a rebrand still living on the old host — loses this one source, and only when a navigation word had to be removed to find the name. Its declarations are untouched, so the name is still seen. That is the trade, it was taken deliberately, and it is the kind of thing a tool should tell you rather than leave you to discover.
The other half of not being silly about names
A related guard, worth knowing because it changes how you read any "second brand" finding: a name seen once across dozens of signals is a single odd page, not a second identity. A delicatessen that puts its tagline in one page title is not announcing a new company, and reporting it as one is the sort of confident nonsense that costs a report its credibility.
Declared identity is exempt: structured data or og:site_name counts at a single
occurrence, because saying it once is still saying it.
Reading this on your own report
- When a tool names a "second brand" you do not recognise, find where it came from. A navigation label, a tagline and a section heading all look like names once they are out of context.
- Check how many times it appears. Once, in a site's worth of signals, is a page rather than a policy.
- Check your declarations first. Your structured data and
og:site_nameare what you have actually claimed; everything else is inference. - Do not rewrite a link's accessible name to satisfy a finding — it is there for a reason, and the harm in that is a page of its own →.
When the finding is real
Two genuinely different names for one organisation, across titles and declarations, is worth fixing — it splits the signals that tell a search engine and an assistant that all these pages belong to one entity. The point of the guards above is that this finding only means something when it is rare, and a check that produces it on ordinary sites has made it mean nothing.
The fixes that make it worse
- Changing your accessible names so a tool stops guessing. They describe destinations for people who cannot see the logo. That is not negotiable against a report.
- Adding your company name into every navigation label. Now every link says the same thing and none of them says where it goes.
- Removing the odd title rather than the inconsistency. If two real names exist, picking one is the fix; deleting the page that revealed it is not.
What this means for any tool you trust
When you report a false positive and it gets fixed, the honest question to ask is what the fix cost. A condition that makes a rule quieter about you probably made it quieter about somebody else too. The only reason the regression above was caught is that a test existed asserting the opposite case — a site where that source should disagree with the rest. Reasoning would not have caught it; the suite did.
Where this sits in an audit
The registered check is brand.name_consistency, which compares the names your site
uses for itself. For four other ways it got that wrong — including why rewriting a logo link's
accessible name is the wrong repair — see
what your site says you are called
→. For the wider lane, see brand consistency
→.
Common questions
Why did an audit report my navigation label as a company name?
Because a logo link's accessible name describes where the link goes, and a step that strips navigation words can leave a section name behind. What remains is as likely to be the section as the company.
How should a tool decide whether a logo link name is a real brand name?
By whether it had to edit the string to get one. A name that was already plain is close to a declaration; one left over after a navigation word was stripped should have to resemble the domain before it counts.
Can fixing a false positive cause a false negative?
Yes, and it is the common outcome, because the easy fix is to make a rule quieter. A false negative is silent — nobody writes in to report that a tool failed to tell them something — so only a test asserting the opposite case catches it.
An audit says my site uses two brand names. Should I believe it?
Check where the second one came from and how often it appears. A tagline or a section label appearing once across a whole site is a page, not an identity. What you declared in structured data or og:site_name is the part you actually claimed.
Should I rename my logo link so it matches my company name?
No. That name exists so someone using a screen reader knows where the link goes. Put the company name in your declarations instead, where a tool should be reading it from anyway.