Stitching Your Brand Entity Back Together After a Rebrand
Rebrands and mergers split your knowledge graph entity in two. How to reconcile the fragments with @id, sameAs, Wikidata, and a sequenced cleanup.
What happens to your knowledge panel when the company changes its name? In the messy cases, which are most of them, nothing clean. The old entity keeps living on years of citations, links, and mentions. The new name starts from near zero. Google may show a stale panel or two competing ones, and AI assistants keep recommending a brand that no longer exists while treating the current one as an unknown.
Search engines and answer engines don't store your company as a record you can edit. They store an entity, a node corroborated by thousands of independent signals that agree with each other. A rebrand, a domain migration, or a merger breaks that agreement. Reconciliation is the work of making the signals agree again, and it has a defined toolkit.
How one company becomes two entities
Knowledge graphs build entities from convergence. The same name, the same site, the same executives, and the same addresses appearing across Wikipedia, Wikidata, LinkedIn, Crunchbase, news coverage, and your own structured data give the graph confidence that all these references point at one thing.
A rename cuts the convergence in half. Old coverage points at the old name and the old domain. New coverage points at the new ones, with no machine-readable statement that they share an identity. Each fragment is weaker than the original entity was. Some effects you can watch happen in the wild. Knowledge panels showing the pre-merger logo. Brand queries for the new name returning the competitor instead. An assistant answering "I'm not familiar with that company" about a fifteen-year-old business.
Mergers produce the worst version, three fragments instead of two. Both legacy entities plus the combined company, each with partial evidence.
AI engines forgive more slowly than Google
The split costs you twice, on two different clocks.
| Layer | Where the old name lives | How fast it heals |
|---|---|---|
| Retrieval (Google index, Bing, answer-engine crawls) | Indexed pages and structured data | Weeks to months, follows your cleanup |
| Model weights (what the LLM "knows") | Training data scraped before the rebrand | Only at retrain, often a year or more |
Grounded engines like Perplexity or Google's AI Overviews lean on the retrieval layer, so markup and registry fixes reach them reasonably fast. A model answering from memory is a different matter. It learned your old name from years of text, and no schema change reaches into the weights. The practical consequence. New authoritative coverage that names both identities in the same sentence ("X, formerly Y") is the only signal that survives into the next training run, which makes the press and directory work as important as the markup.
The markup that declares one identity
JSON-LD gives you two instruments for this. A stable @id (microdata calls it itemid) that every page on your site uses for the organization, and a sameAs array pointing at the registries that corroborate you. The strongest sameAs targets are the ones knowledge graphs already trust as identity anchors, Wikidata above all.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://newbrand.com/#organization",
"name": "NewBrand",
"alternateName": "OldBrand",
"url": "https://newbrand.com/",
"sameAs": [
"https://www.wikidata.org/wiki/Q123456",
"https://www.linkedin.com/company/newbrand",
"https://www.crunchbase.com/organization/newbrand"
]
}Three details carry most of the weight here. alternateName keeps the old brand attached to the new entity instead of orphaned. The @id must stay identical across every page and never change again, because it's the URI other systems will use to mean you. And the Wikidata line does more than the rest of the array combined, since Wikidata QIDs are the reconciliation key the major knowledge graphs are built on.
Your Google kgmid, the machine ID behind your knowledge panel, is findable through the Knowledge Graph Search API. You can't write to Google's graph directly, but knowing the ID lets you check whether old and new names resolve to the same node, which is the success metric for this whole exercise.
Registries before markup
Markup asserts an identity. Registries confirm it, and the order matters more than most migration checklists admit.
- Wikidata first. Update the label to the new name, keep the old name as an alias, add the new official website, and cite a press source for the change. Downstream graphs inherit this.
- Then the profiles that knowledge graphs crawl as evidence. LinkedIn, Crunchbase, Google Business Profile, industry registries. Same name, same domain, everywhere.
- Claim the knowledge panel under the new identity and submit corrections against the stale one.
- Only then publish the markup above, so the sameAs targets it points to already say what your site says.
301 redirects from the old domain stay up for years, not months. The graph keeps checking.
The monitoring side is plain. A monthly set of prompts in ChatGPT, Perplexity, and Gemini asking about both names, and a check of whether the panel and the API still show separate nodes. Reconciliation is done when the machines stop needing the old name explained, and that date arrives later than the rebrand party. If you are working through a rename or merger and want the sequence audited against your live entity, that is what my consultancy work is for.