How to protect AI visibility during a rebrand or name change

Protect AI visibility during a rebrand by making identity continuity explicit everywhere: publish a dated name-change page, preserve former-name references, redirect equivalent URLs, update controlled profiles and keep products, people and the legal entity correctly connected. Monitor old-name, new-name and confused-identity prompts before and after launch. Do not try to erase the former brand overnight. Customers and AI systems need a clear bridge from old evidence to the new identity, and businesses cannot directly rewrite a model's private knowledge.

Map what is changing and what remains the same

Create an identity transition register before launch. State whether the legal entity, ownership, products, contracts, leadership and service obligations continue. Record the old name, new name, pronunciation, effective date, domains, logos, social handles and geographic scope. A visual refresh is different from a legal rename; a product rename is different from a company rebrand. If the new name is shared by another organization, document distinguishing attributes and verify that every team uses the same public explanation.

• Continuity: "New Brand is the new name of Former Brand as of [date]."
• Change: list exactly which name, logo, domain, product or legal details changed.
• Stability: explain what customers, contracts and support relationships retain.
• History: preserve former-name mentions where they provide necessary context.
• Verification: give one canonical transition URL and an official contact route.
• Expiry: define when transitional banners and dual branding will be reviewed.

Build the public identity bridge

Publish the transition page before or at launch and link it prominently from both brand contexts. Update the home, about, contact, product and leadership pages in a coordinated release. Use permanent redirects only where old and new URLs are genuinely equivalent; retain an explanatory page when the historical distinction matters. Generate updated Organization markup with the schema generator, use alternateName for a legitimate former name and verify the deployed graph with the schema validator.

Update external records by authority and risk

1. Update official registries, map listings, social accounts and marketplace profiles as applicable.
2. Give partners and distributors a dated identity kit with approved wording and destination URLs.
3. Ask important publishers to update current biographies and evergreen company descriptions.
4. Leave historically accurate reporting intact while requesting notes where present-tense wording misleads.
5. Check email authentication, support contacts and domain ownership before retiring old addresses.
6. Track every profile, request, redirect and verification result in one migration register.

Use the AI readiness checker on both domains and create a concise machine-readable resource map with the llms.txt generator if it fits your publishing policy. Neither file nor schema can force an assistant to adopt the new name. Do not create fake press coverage, duplicate directory records or unsupported "formerly known as" relationships. Correct the public sources you control, work through each external platform's process and use assistant feedback channels where available.

Monitor old, new and category prompts together

Capture a pre-launch baseline with the AI visibility scan. In ModelSaid, monitor direct questions about both names, ownership and products, plus unbranded category prompts where continuity matters. Classify correct transition, old-only, new-only, conflated and wrong-entity answers. Save citations and test multiple providers and regions. Annotate launch and source-update dates, but do not promise a fixed migration time or infer causation from a single answer change.

Keep transition evidence longer than the campaign

Review redirects, former-name references and external profiles for at least as long as customers continue using the old identity. Watch for broken backlinks, expired domains and impersonation risks. Keep former domains registered and secured when feasible, and monitor fake support accounts that exploit the transition. Audit invoices, email signatures, app-store listings, documentation and recruitment pages because these easily outlive the campaign calendar. Ask support teams which name customers still use and extend dual-name explanations where confusion remains. Test branded search and assistant journeys from old links as part of every migration review. Update the transition page if ownership or product scope changes again, and retain its dated history. A successful rebrand is not one where the old name vanishes; it is one where a person or assistant can resolve both names to the correct current entity without losing trust, context or a working path to service.