The migration went clean. Every URL 301s to its new home, the new name is on every page, the logo changed everywhere, Google reindexed the new domain inside a few weeks. By the standard of a normal SEO migration, it was a success, and your agency has the redirect map to prove it.
Then a prospect mentions on a call that they asked ChatGPT about you and it described you under the old name, with the old positioning, next to the old competitors. You check, and it is true across half the engines. The rename that was supposed to be done in a weekend is somehow still not done in the place your buyers now start.
This is not a botched migration. It is a migration that fixed the layer it was designed to fix and never touched the layer that decides what an AI engine calls you. Those are different systems, and the redirect that satisfies Google does almost nothing for the one that matters here.
A redirect moves a page. It does not move a reputation
A 301 is an instruction to a crawler about where a URL now lives. It is a plumbing fix, and for Google’s link graph it is close to sufficient, because Google is largely resolving addresses.
An answer engine is not resolving an address. It is answering “what is this company” by assembling a description from everything published about you, and almost none of that lives on your domain. It lives in the review profiles, the comparison posts, the analyst notes, the podcast show-notes, the conference bios, the old news coverage, the Wikipedia line if you have one. Every one of those still says the old name. Your redirect did not reach a single one of them, because you do not own any of them.
So after a rebrand you are in a very specific and lopsided situation. The old name is corroborated across hundreds of third-party pages built up over years. The new name is corroborated almost nowhere, because it is new. To an engine weighing what to call you, that is not a close call. The overwhelming weight of the record still points at the old identity, and your own site, the one place that fully reflects the new name, is the weakest input it has. You changed the one source the engine trusts least and left untouched the hundreds it trusts more.
That is why it feels stuck. You are not waiting for a cache to clear. You are outvoted.
Schema is the floor here, not the fix
The standard advice for this is technical, and it is not wrong, it is just badly incomplete. Add an alternateName property, get your Wikidata entry to link the old and new names, update your Organization markup. Do all of it. It is the floor, and skipping it is a real mistake.
But understand what that markup does and does not do. It helps an engine that has already found both names connect them as the same entity. It is a disambiguation aid. It does not go out and change the hundreds of pages that only carry the old name, and it does not add weight to the new name in the sources the engine actually reads. Markup is you talking about you, which is the least-trusted signal there is, and a rename is precisely the moment you are asking the engine to believe something about yourself that the rest of the web still contradicts.
The real work is a re-corroboration project, and it looks nothing like a technical migration. It is finding the third-party pages that carry the most weight for your category, the ones the engine actually leans on, and getting the highest-leverage of them to reflect the new name. It is getting a fresh piece of independent coverage that uses the new name as the primary and mentions the old one as former. It is making sure that anywhere the two names appear together, they appear as the same company, so the engine has permission to merge them rather than treating them as two entities, one of which went quiet.
None of that is a redirect. All of it is the thing that actually moves the answer.
The old name is not a bug to delete. It is a bridge to keep, for a while
There is a tempting instinct to scrub the old name everywhere, to make the break clean. Resist it during the transition, because the old name is doing load-bearing work.
For a period after the rename, the old name is the only identity most of the record recognizes, which means it is the thread that lets an engine connect the mass of existing corroboration to the new entity. If you erase every trace of it before the new name has accumulated its own weight, you do not accelerate the transition. You sever the link between your history and your present, and you risk the engine treating the new name as a brand-new company with no track record, which is a worse position than being called by the old name.
The move is to keep the two explicitly joined everywhere you can, for as long as it takes the new name to stand on its own. Formerly known as. The company previously called. Same product, new name. You are not hiding the old name, you are using it as a bridge, and you take the bridge down only after the far side can bear the load.
What I got wrong
I ran a rebrand like a migration once, and I was proud of the migration.
We did the technical side genuinely well. Clean redirect map, no orphaned URLs, new name deployed consistently across the whole site, schema updated, Wikidata edited to link the names. Google transitioned nicely and the organic traffic held. By every metric I was measuring, the rebrand had gone through.
Months later the client was still being introduced by AI engines under the old name, and I had no good answer for why, because I had been looking at the wrong scoreboard the whole time. When I finally went and audited what the engines were actually citing for the company, it was obvious and it was humbling. They were pulling from a review site, two comparison articles, and an analyst page, and every one of those still said the old name, because nothing we had done touched them. I had spent the budget making our own property perfect and had not sent a single email to the handful of pages that were actually writing the answer.
The fix, once I saw it, was small and slow and unglamorous, which is the pattern by now. We identified the specific third-party pages carrying the most weight, reached out, and got the most important ones updated to the new name with the old one noted as former. We landed one piece of fresh independent coverage under the new name. Within a couple of refresh cycles the engines started leading with the new name and referring to the old one as previous. The technical migration I was proud of had been necessary and nowhere near sufficient.
The lesson I kept is that a rebrand is not a migration with a new logo. It is an entity-transition problem, and the entity does not live on your site.
What to actually do after a rename
Do the technical migration properly, because it is the floor. Redirects, consistent new name on-site, updated Organization schema, alternateName linking the old and new, Wikidata edited to connect them. None of this is optional and none of this is sufficient.
Then do the part that actually moves the answer. Audit which sources the engines are currently citing for you, because those specific pages are writing your name whether you like it or not. Get the highest-leverage of them updated to the new name. Earn at least one piece of fresh independent coverage under the new identity. Keep the old and new names explicitly joined everywhere during the transition so the engine can carry your history across, and only retire the old name once the new one has its own corroboration.
And expect it to be uneven and slow. Retrieval engines will pick up the corrected pages within crawl cycles while memory-default engines lag for months, so you will see the new name appear in some engines long before others. That split is normal, not a sign the work failed.
If you have a rebrand or a migration behind you and the engines have not caught up, or one coming and you want to plan the source layer before the announcement, that is the work we do and the method we use.