After a Rebrand, Why AI Assistants Keep Using the Old Name

"How long until ChatGPT forgets our old name?" It is the question almost every company asks after a rebrand, and it rests on a wrong picture. An AI assistant does not forget anything on a timetable. There is no expiry date on the old name, no queue in which the new one waits its turn, and no clock inside the model counting the months since the announcement. The useful question is a different one: which of the two channels an assistant answers from is still carrying the old name, and in which language.

After a rebrand, a merger or an acquisition, the old name survives in AI answers for two separate reasons. One lives inside the model and changes only when the model is replaced. The other lives on the web and changes as fast as other people update their pages. Treating them as one problem is why so many post-rebrand checks produce confusing results.

Two channels, two answers

An assistant knows about a company in two ways. The first is model memory: what the model absorbed from text during training, fixed on the day training stopped. The second is retrieval: pages the assistant fetches from the web while it writes the answer.

The two can disagree, and after a rebrand they usually do. Memory holds the name the company had before the training cutoff. Retrieval holds whatever the pages found today say, which may be the new name, the old one, or both. Which channel answers depends on the question, the assistant and, in some cases, on nothing more than the particular run.

OpenAI's own documentation describes this for its web search tool: the model "can choose to search the web or not based on the content of the input prompt" (OpenAI, web search guide). The same question about your company can therefore come back from memory one day and from search the next. One answer uses the old name, the other the new one, and neither is a malfunction.

What the model remembers, and for how long

Every model has a training cutoff, and the providers publish it. Anthropic lists two dates for each Claude model: a reliable knowledge cutoff, "the date through which the model's knowledge is most extensive and reliable", and a broader training data cutoff. For Claude Haiku 4.5 those are February 2025 and July 2025 (Anthropic, model page). OpenAI gives gpt-5-mini a knowledge cutoff of 31 May 2024 (OpenAI, model page).

The second fact matters more than the first. Models stay in service long after their cutoff. Claude Haiku 4.5 was released in October 2025, eight months after its reliable cutoff, and was still available through the API in October 2026. Any company that changed its name in that window exists in that model's memory only under the old name. Nothing about the model will change that. Only a new model, trained on later text, can.

A newer model does not settle the matter either. Training data is text, and text accumulates slowly. A name used for twenty years appears in catalogues, trade press, tender documents and forum threads going back decades. A name used for six months appears on your own site and a handful of pages that have caught up. A model trained after the rebrand may well have seen the new name and still treat the old one as the stronger association. It is not stubbornness. The old name simply has more text behind it.

So the old name in model memory has no fixed lifespan. It fades as successive model versions are trained on a web where the new name has grown and the old one has stopped growing. That takes model generations, not weeks, and nobody outside the providers knows when the next one ships.

Why web search does not clean it up

Retrieval looks like the cure, since it reads today's web. It is only as current as the pages it finds, though, and most pages about a company are not written by the company.

For a typical B2B exporter, those pages include:

• Distributor and reseller catalogues, often maintained once a year and in several languages.
• B2B directories and trade fair exhibitor lists, which keep last year's entry until somebody edits it.
• PDF datasheets and certificates issued under the old name and still hosted on dozens of sites.
• Press coverage and case studies from before the change, which nobody will rewrite.
• Registry and credit-check pages, which may show both names with dates, or only one.

Then there is the question itself. A buyer who has known you for ten years types the old name. A search for the old name returns pages with the old name. If your redirects work, the assistant may also land on your new site and write "formerly known as". If they do not, it may describe a company that, as far as the visible web is concerned, still exists unchanged.

The good outcome after a rebrand is not an answer that has erased the old name. It is an answer that connects the two: X, now Y. That sentence is what you want an assistant to be able to write, and what you should check for.

Rebrand, merger, acquisition: three different problems

"Name change" covers situations that fail in different ways in AI answers.

A pure rebrand

Same company, same legal entity, new name. The risk is mostly lag: the assistant names you correctly but under the old name, or gives both without explaining the link. This is the mildest case.

A merger

Two companies become one. Here the assistant may keep describing them as two separate businesses, which is what its training data says they were. In a category question it can list both, side by side, as alternatives. A buyer reads that as two competitors where there is now one supplier. Worse, the description of one may borrow details from the other, a cousin of the problem described in our piece on namesakes, except that this time both names really are yours.

An acquisition that keeps the brand

The acquired name survives as a product line or a division. The assistant may present it as an independent company, give the old ownership, or attach the old contact details. Nothing here is technically wrong from the model's point of view: it is describing the world as it was.

Each case needs its own questions when you measure. A prompt set built for a pure rebrand will not show you the merger problem, because it never asks the assistant to list the suppliers in a category.

How this differs from launching something new

We have written about why assistants do not know your new product. The mechanics overlap, but the situation is the reverse. A new product starts with an empty memory: the model has nothing, so retrieval is the only route in. A new name starts with a full memory of the wrong thing.

Empty is easier to fix than wrong. When memory is empty, a retrieved page has no competition inside the model. When memory holds the old name, a retrieved page that mentions the new name has to win against everything the model already associates with the old one. That is why rebrand answers so often come out mixed: half from memory, half from search, stitched together in one paragraph.

What to measure after a rebrand

A rebrand changes the thing being measured, so the measurement has to change too. Four groups of questions cover most of it.

• Old-name questions. What a long-standing customer would ask: "What does old name make?" Does the answer mention the new name? Does it say the two are the same company?
• New-name questions. What a new prospect would ask. Does the assistant recognise the new name at all, or does it treat it as an unknown company?
• Category questions with no name. "Which manufacturers of your product supply your market?" Which name appears, if any? After a merger, do both old names appear as separate entries?
• Source checks. Where an assistant cites pages, which ones carry the old name? These are the pages worth chasing first.

Run each group in every language you sell in. A rebrand reaches the English-language web through your own site and press release fairly quickly. It reaches an Italian distributor's catalogue or a German trade directory when somebody there gets round to it. The old name usually lasts longest in the markets you pay least attention to.

Run them on each assistant separately, too. Perplexity is built around search and cites the pages it reads, so it tends to reflect the current web. ChatGPT and Claude decide case by case, so they mix memory and search. Comparing them is the quickest way to see which channel is behind.

Ideally, start before the announcement. A baseline taken under the old name tells you what "normal" looked like, so that a drop after the change can be read as lag rather than as loss of visibility. Repeating the same prompt set on a schedule is the part that is tedious by hand, and it is what PSentry does: 2 scans a month across ChatGPT, Claude, Gemini and Perplexity, with a score per language and the sources the assistants cite. It measures which name the assistants use. It does not make them switch, and nothing can promise that.

What you can change on the web

You cannot touch model memory. You can make sure that whenever retrieval runs, it finds pages that connect the two names.

Redirects that last. If the domain changes, the old one should redirect page by page, not just to the new homepage. Google's guidance on site moves says to keep the redirects for at least 180 days, and longer if traffic still arrives through them, and its Change of Address tool forwards signals for 180 days (Google Search Central Help). That is about Google Search. AI retrieval reads the same web, so a broken redirect is broken for both.

One plain sentence on your own site. An about page that says, in words, "Y was called X until 2026" gives a retrieved page the link an assistant needs. Put it in every language version, not only in English.

Structured data, used honestly. Schema.org has no property for a former name. The closest is alternateName, defined only as "an alias for the item", alongside legalName and sameAs (schema.org). Listing the old name as an alternate name tells machines that both strings point at one organisation. It does not carry a date, so the plain sentence above is still needed.

The pages other people own. Distributor catalogues, directories, exhibitor lists, certificate registries. Make a list, by language, of the pages that still use the old name, starting with the ones assistants actually cite. This is slow work, and it is the work that changes what retrieval finds.

None of this guarantees that an assistant will use the new name. It removes the reasons a search-based answer would not.

Questions that come up after a name change

Should we stop using the old name completely?

Not on your own site, at least not at first. A page that never mentions the old name gives retrieval nothing to connect a buyer's old-name question to. Mention it, once, with the date of the change.

Can we ask OpenAI or Anthropic to update the name?

There is no form for this. What a model learned in training changes only with a new model. What it finds through search changes with the web.

The assistant says the old company closed down. What happened?

Usually a registry or news page about the legal change, read without the context that the business continues under a new name. Check which source the answer cites and whether your own pages say clearly that the company continues.

How long should we keep tracking the old name?

Until it stops appearing in answers in every language you sell in, which is a measurement, not a date. Expect the markets you neglected to be the last.