You have 12 shops, but to the AI you are 12 separate and weak entities — none with enough authority to be recommended with confidence. One query cites one location, the next you disappear entirely, while a competitor with a single well-structured shop beats you on every answer. The authority you've built across the whole network scatters instead of adding up. There is a way to stitch everything back together under a single recognizable identity — and the change is noticeable within a few months.
You have 12 artisan gelato shops across Emilia and Romagna. When someone opens Perplexity and asks “the best artisan gelato shops in the region”, the AI might cite one of your locations — the one in Rimini, or the one on the Cesenatico seafront. Then, in another query (“reliable artisan gelato chains in Italy”), you don’t show up at all. You fragment into 12 weak entities instead of presenting yourself as a single strong brand.
It’s not a content problem. It’s an entity architecture problem. And in the next few minutes I’ll explain why this happens, what the research on the topic documents, and how to stitch the brand back together in the eyes of AI models.
What an AI model sees when it looks at a chain with 12 locations
The starting point is to understand that, to an AI model, each location is by default a separate entity. If your Rimini gelato shop has its own page, its own Google Business Profile listing, its own reviews, and the Ferrara location has its own, the AI engine treats them as two distinct objects. Until someone tells it clearly, it won’t merge them.
In the world of statistical research this problem has a precise name. Binette and Steorts, in a 2020 paper that reviews the entire discipline, frame it like this:
“Before such questions can be answered, databases must be cleaned and integrated in a systematic and accurate way, commonly known as record linkage, de-duplication, or entity resolution.”
Translated: before answering any question about a set of data, the system must clean it, integrate it, and decide which records refer to the same entity. The technical name for this operation is entity resolution (or record linkage).
The practical consequence for you is simple: if you don’t do the work of declaring “these 12 locations are the same chain”, the AI model will do it by approximation, badly, or it won’t do it at all. And the authority you earn in Rimini stays in Rimini.
Why entity resolution is a hard problem even for those with enormous resources
The authors of the same paper are clear that this is not a negligible detail:
“Furthermore, entity resolution is not only a crucial task for social science and industrial applications, but is also a challenging statistical and computational problem itself.”
In other words: unifying entities is a statistically difficult problem. Even the big platforms get it wrong. From this follows a principle that applies to your chain: the easier you make it, the higher the probability that the AI engine recognizes you as a single brand.
The mechanism you need to build is a hierarchical entity architecture: a parent page that represents the chain, linked to 12 child pages that represent the locations. Each location points to the parent, the parent lists all the locations.
If you’ve already read the piece on how AI engines build authority maps around an entity, it will be clear why this structure isn’t optional: without the central glue, the authority built by each location stays isolated.
A different brand name at every location.
The 10-minute test to see whether you’re fragmented
Before restructuring anything, check how you appear today. Two quick checks.
Check 1 — Google Rich Results Test. Open the Rich Results Test, paste the URL of the chain’s homepage. Look for the word “Organization” in the detected schema. If it’s not there, the engine has no explicit signal saying “this is a parent company”. If it is there, check whether it contains the `department` or `subOrganization` field with your locations listed. In 90% of the cases I see, there’s nothing.
Check 2 — direct queries to the AI engines. Open ChatGPT, Perplexity and Gemini, one by one. Ask: “How many shops does [brand name] have?” and “In which cities is [brand name] present?”. Binary threshold: if across the three engines none of them can answer with the correct number, you’re fragmented. If one out of three gets there, you have the outline of a parent entity but a weak one.
In the research world, Binette and Steorts describe the set of techniques used to stitch entities back together like this:
“We review clustering approaches to entity resolution, semi- and fully supervised methods, and canonicalization, which are being used throughout industry and academia in applications such as human rights, official statistics, medicine, citation networks, among others.”
The key word here is canonicalization: deciding on a canonical, official form in which the entity is represented. For your chain it means something precise: you need ONE canonical brand page, not 12 pages that behave like 12 different brands.
Decide on the canonical brand name and write it identically everywhere: website, GBP, social, invoices.
The case study: what happened to a chain of 12 gelato shops
Let me tell you about a real intervention, anonymized. A chain of artisan gelato shops, 12 locations spread across Emilia and Romagna, operational base near Rimini. Strong product, good reviews for each location, but one problem: to the AI they didn’t exist as a single brand.
Before the intervention (measurement on a set of 25 test queries spanning “best artisan gelato shops [region]”, “artisan gelato chains Italy”, “reliable gelato shops Romagna Riviera”): the brand was cited 3 times out of 25, always referring to a single location, never as a chain. On ChatGPT and Perplexity no engine could say how many locations it had. An indicative test, not a study, but the pattern was clear.
Intervention over 6 weeks:
- The parent page “/chi-siamo” rewritten as the canonical brand page, with a complete `Organization` schema and a `department` array listing all 12 locations with address and URL.
- Every single location page rewritten with a `Store` schema that includes `parentOrganization` pointed at the parent.
- A Wikidata entry created for the parent brand, with the `has part` property toward the locations (where each location already had a local identifier).
- Google Business Profile: alignment of the exact brand name across all 12 listings (previously there were variants like “Gelateria X – Rimini Centro” vs “X Gelato Rimini”).
- Internal links: every location page links to the parent with the anchor “[brand name] chain”; the parent lists all locations with a city-specific anchor.
After 6 months, on the same set of 25 queries: the brand was cited 11 times out of 25, and in 7 of those citations the AI explicitly used the word “chain” or “network of gelato shops”. ChatGPT and Perplexity answered correctly about the number of locations. Gemini still got the count wrong but recognized the brand as a single entity. It’s not a magic result — it’s the result of having done the work the engine doesn’t do on its own.
An honest limitation: small sample, 25 queries, a single case study. Real analysis, with a representative sample and a control, requires professional tools. But the mechanism is consistent with what the paper documents: if you declare canonicalization, the system uses it.
The mistakes I see most often in multi-location chains
Four recurring patterns, in order of frequency.
A different brand name at every location. “Gelateria X — Rimini”, “X Gelato Cesenatico”, “X — Riccione Centro”. To the AI these are three brands. The canonical name must be identical everywhere, the city goes in the address field, not in the name.
Parent page missing or anonymous. Many chains have only the location pages and a weak “/contatti”. The canonical brand page as a company is missing. Without a parent, there’s no glue.
Local schema without `parentOrganization`. The locations have their `LocalBusiness` schema done well, but they don’t declare whom they belong to. It’s like having 12 children with no surname.
Google Business Profile without consistency. Varied names, different categories, disconnected descriptions. Google’s Knowledge Graph relies heavily on the GBP, and from there it filters through to the AI models that use that source as an anchor.
What to do concretely, in order
- Decide on the canonical brand name and write it identically everywhere: website, GBP, social, invoices.
- Create (or rewrite) the parent page as the company page, not as a generic “about us”.
- Implement an `Organization` schema on the parent, with `department` or `subOrganization` listing all the locations.
- On every location page add a `LocalBusiness` schema (or `Store`, `Restaurant` depending on the case) with `parentOrganization` toward the parent.
- Verify it all with the Rich Results Test.
- Open a brand entry on Wikidata linking the locations as parts of the organization.
- Align the names across the 12 Google Business Profile listings.
- After 3 months, repeat the 25-query test and compare with the baseline.
Parent entity and visibility in AI answers
The common thread across my articles is always the same: visibility in AI answers is built by making it easy for the engine to recognize you. For a multi-location chain this means something concrete: declaring the parent entity. It’s not a magic factor — it only works if the locations already have their own content and authority — but without it the authority of the locations never adds up.
In this series, in the upcoming articles I’ll explain how to manage specific vertical entities (multi-partner professional firms, e-commerce with several owned brands), how to build the Wikidata entry without getting rejected, and how to tie the brand entity to the company’s key people — a topic that connects directly to the piece on author entity recognition that I left you in the previous nodes.
The gelato chain from the case study isn’t the most cited in Italy today. But when Perplexity talks about artisan gelato in Romagna it knows it exists, it knows how many locations it has, and it knows where to send anyone who asks. It’s the starting point, not the destination.
