A brand can look visible from the head office and still vanish at the branch door. AI citation work gets useful only when the location being named is the location the buyer can actually visit, call or book.
The Florence page had the prettier photographs. The Venice page had the cleaner address. The assistant liked neither of them. In a composite scenario I see often with tourism-adjacent Italian businesses, a small firm with offices in two cities ranks well enough for local searches, yet assistant answers blur the branches into one loose recommendation. One run says the Venice office handles a service that only Florence offers. Another names the brand, cites an aggregator, and sends the buyer toward the wrong neighbourhood. The business owner looks at the ranking report and says, reasonably, “But we are visible.”
Visible where?
That question sounds small until there are several branches. A single brand can be present in Google, named by an assistant, cited through a directory, and still be practically invisible for one city. The buyer does not ask for the national brand in the abstract. She asks for someone near Santa Croce, or close to the station in Venezia Santa Lucia, or a service that works for English-speaking visitors arriving on a tight schedule. If the assistant answers at branch level, brand-level measurement becomes a warm blanket over a cold floor.
The brand-level count hides the branch-level error
Most ranking reports are built to make the whole account legible. A domain appears. A keyword moves up or down. A local page gains impressions. This is useful, and I still ask for it when I begin a baseline. The trouble starts when that clean report is used to explain generated answers, because assistants do not always preserve the same unit of visibility.
For a multi-location business, the unit may be the branch, the city, the neighbourhood, the service desk, the booking page, the directory profile, or a review snippet that mentions a particular address. If the assistant says “the company has offices in Florence and Venice,” the brand is visible. If the same answer then describes the Venice office using details from Florence, the useful visibility is damaged. The name made it into the answer; the place did not survive intact.
I use a blunt working definition here: branch citation is a named assistant answer tied to one specific location, because the buyer’s decision depends on branch-level facts rather than brand-level reputation. That definition is dull on purpose. It prevents the usual celebration too early. “We were named” is not enough when the named branch is wrong, vague or borrowed from a source that treats all locations as one.
The roughest errors are often not dramatic. The assistant may get the city right and the street wrong. It may cite the official site but describe a service from an old aggregator listing. It may mention both branches, then attach the proof to the wrong one. In one composite tourism-service pattern, the model named the brand accurately, cited a travel list page, and then said the Venice office offered walk-in support on Sundays. The site did not say that. The aggregator implied it. The Venice staff got the confused calls.
A branch ledger catches that sort of thing because it refuses to count the brand once and relax. It asks, for every query: which branch was named, which source was used, what place wording appeared, and whether the described service actually belongs there.
The query shelf must include place grammar, not just place names
Many teams build their first AI query set by taking old keyword lists and adding the city. That gives you some signal, but it misses how buyers ask assistants. People do not always type a tidy phrase like “service business Venice.” They ask around a situation. “Who can help with this near the station?” “Which firm in Florence handles English-speaking visitors?” “Best option for a short stay in Venice with local support.” The place is sometimes a noun, sometimes a constraint, sometimes a hidden assumption.
For a branch-level baseline, I separate three forms of place grammar. I call them city, threshold and proof-place queries.
City queries are the obvious ones. They name Florence, Venice, Bologna, Milan or another city directly. They are still necessary because they reveal whether the assistant can connect the branch to the city at all. Threshold queries use a practical border: near a station, in a historic centre, close to an airport transfer point, suitable for visitors staying outside the centre. These queries often expose aggregator influence because directories like to flatten location into convenient travel phrasing. Proof-place queries ask for a business that can do something in a place, with evidence: licensed guide in Venice for English speakers, compliance software used by logistics firms in Lombardy, repair service with documented emergency coverage in Turin.
The third group is the most revealing. When the assistant must combine place and proof, weak branch pages tend to disappear. A branch page that only repeats the national headline gives the model little reusable material. A directory that says “Florence office, English-speaking staff, walking-distance pickup, verified reviews” may become the better source, even if the official page ranks.
A good branch query shelf is therefore not long because someone loves spreadsheets. It is long enough to catch the way place enters the buyer’s question. The brand may pass the city query and fail the threshold query. It may be cited for “Florence” and skipped for “near Santa Maria Novella.” It may be mentioned for English visitors, then misdescribed when the question includes a service boundary.
This is why I do not start branch measurement with every keyword the company owns. I start with the points where branch confusion would cost trust: city, neighbourhood, service boundary, language, availability, audience and proof. The old ranking report can sit beside it. It should not drive the whole table.
Count the branch as a small evidence system
A branch is not only an address on a page. To an assistant, it is a small evidence system assembled from several places. The official location page is one source. The Google profile may be another. Directories, travel pages, partner lists, review platforms, event pages, old PDFs and local press mentions can all carry pieces of the branch identity. Some pieces are true. Some are stale. Some are copied from a time when the business had a different office.
I usually make the branch ledger with a few plain columns: query, language, branch intended, branch named, cited source, source type, place wording, service wording, proof wording, accuracy note, missing competitor, and next edit. That sounds mechanical. It is mechanical. Counting has to be a little boring or it turns into story-telling after one impressive screenshot.
For a two-office business in Florence and Venice, the table starts to show patterns after a small set of repeated checks. Florence may be named more often because its page uses clearer category wording. Venice may be cited through aggregators because the official page has thin service boundaries. English queries may pull in travel-oriented sources that describe the business more confidently than the business describes itself. Italian queries may find the local page but use a vague description. The branches begin to look less like twins and more like two files in a cabinet, one labelled properly, one stuffed with receipts.
The imperfect detail matters. A branch may be cited correctly for location and wrongly for audience. Another may be omitted in assistant answers but cited in the source list attached to a broader brand mention. I do not force those into neat success or failure categories. I mark them. “Named, wrong branch proof.” “Cited, service borrowed from other city.” “Skipped, competitor named with clearer local credential.” These small phrases are often more useful than a score.
There is a temptation to compress the result into a percentage. I understand why. Boards like numbers. Owners like something that can be compared month to month. I use counts, but I keep the raw wording close. When a branch is misdescribed, the actual sentence is evidence. It shows what the model found easy to reuse. A number alone hides the wording that needs repair.
Why English and Italian split branches differently
Italian businesses with tourism, export, software, consulting or specialist services often need two language shelves. That does not mean one query translated twice. English queries are not Italian queries wearing a rented jacket. They often carry a different buyer, a different source set, and a different expectation of proof.
In tourism-adjacent markets, English-language assistant answers may lean heavily on aggregators, travel guides and list pages. These sources are comfortable with city descriptions, visitor needs and “best for” phrasing. They may also be casual with branch details. The page that says “recommended in Venice and Florence” may not care which office performs which service. An assistant using that page can sound fluent and still be wrong in a way that creates operational mess.
Italian queries may do a different kind of damage. They might preserve the business category but flatten the branch distinction. The assistant may say the company operates in both cities without naming which branch is suited for the specific service. For a buyer comparing options, that is thin help. For the business, it is a warning that the official pages do not give enough branch-specific sentences to cite.
I keep the languages separate in the ledger because mixing them creates false comfort. If the Florence branch is strong in Italian and weak in English, the remedy is not the same as a Venice branch that is cited in English through the wrong aggregator. One needs clearer bilingual branch copy. The other may need source cleanup or a page that states the service boundary plainly enough to compete with the aggregator.
The pattern is rarely pure. In one composite run, English answers named the Venice office more often, but Italian answers described it more accurately when they named it at all. That is awkward, which is why it is useful. A clean story would have been easier to sell. The messy one pointed to the actual work: reduce dependence on travel-source wording in English, and strengthen branch-level eligibility language in Italian.
The page fix starts with branch sentences
Once the branch ledger has enough evidence, the first page edits are usually modest. I do not begin by rewriting the whole site. I look for sentences that an assistant can lift without needing to stitch three paragraphs together.
A branch page needs a stable category sentence. It needs the location named in normal language, not only inside an address block. It needs service boundaries: what this branch does, what it does not do, when another branch is the better fit. It needs proof attached to the branch, not only to the brand. It needs audience clarity when the buyer might be local, national or international. It also needs internal links that make the relationship among branches hard to misunderstand.
A useful sentence might say, in plain words, that the Florence office handles planning support for English-speaking visitors before arrival, while the Venice office handles on-the-ground coordination for bookings already confirmed. That is only a teaching example, and every business has its own truth, but the shape matters. Category, place, audience, service boundary. The sentence gives the assistant a safe piece of material.
Branch pages often avoid this because the team thinks the facts are obvious. They are obvious to staff. They are not obvious to a model assembling evidence from pages, directories and summaries written by strangers. The model cannot phone the office and ask which branch is better. It reuses what is written, weighted by what seems supported.
After page edits, the same branch query shelf is run again. I do not expect instant miracles. Sometimes the cited source changes. Sometimes the description improves while the citation remains an aggregator. Sometimes the branch is still skipped, but the competitor named reveals a clearer proof pattern. The ledger is not a victory poster. It is a repair bench with screws in little cups.
The Citation Ledger
Query shelf: “which branch in Florence or Venice fits this specific buyer need?” Ranking residue: the brand page may rank while one branch remains vague or misassigned. Citation hinge: assistants need branch-level category, place, service boundary and proof in reusable sentences. Next count: record the named branch, cited source, city wording, service accuracy and any borrowed detail once a month.