Make One Property Legible Across Pages

Prerequisites: Lectures 1, 2 and 3.

Before this lecture, you should be able to read a ChatGPT answer as an assembled text with retrieval, inference and smoothing inside it. You should also know the four-room habit from Lecture 2 and the category drift problem from Lecture 3, because today we move upstream: before category can be stable, the property itself has to look like one property across public evidence.

On the reception desk there is a small folder with printed confirmations, taxi notes and one old laminated direction sheet. The sheet still says “Via Provinciale 18,” because that was the road name guests used for years. The website now says “Via del Ponte 18.” A booking page says only “near the bridge.” A public map profile has the new address, but an older public profile has the old one and a shortened property name. When ChatGPT is asked about the place, it answers with confidence: correct town, correct general area, wrong street name. Nobody lied. The public evidence simply behaves like three waiters giving directions at once.

This is a composite scenario, but the mess is ordinary. Italian hospitality businesses often keep small historical layers in public: a legal name, a signboard name, an old road name, a translated name, a booking-platform name, maybe a family surname attached in one place and missing in another. Human guests can sometimes solve that with photos and patience. ChatGPT has no patience. It reads repeated public fragments and tries to make one neat identity from them.

The identity room begins before the answer

In Lecture 2 we used the identity room to ask whether the answer is clearly about one property. In this lecture, we ask a harder question: what public material makes that room possible? If a ChatGPT answer names your guesthouse correctly but attaches an old address, the identity room is not completely broken. It is wobbling. Like a key that enters the lock but catches halfway.

Entity consistency is presenting one recognisable property across names, addresses, pages and listings. I use “recognisable” carefully. The goal is not mechanical sameness in every sentence. A homepage may sound warm, a contact page may be dry, a booking page may use shorter wording. But the public evidence should let a system, and a guest, say: yes, this is the same place.

A small hospitality entity has more edges than owners sometimes notice. The visible name on the sign may not match the business registration wording. The phone number may be shared with a sister property. The English homepage may remove “B&B” because the writer thought international guests disliked the abbreviation. A tourism page may use the town name differently from the municipality. None of these details alone is dramatic. Together, they can make ChatGPT assemble a slightly bent identity.

Here is a teaching example. Imagine a property whose website header says “Casa dei Tigli,” whose contact page says “B&B Casa dei Tigli,” whose public map profile says “Casa Tigli Rooms,” and whose old tourism profile says “Hotel Tigli.” The address is mostly the same, except one source uses “località” and another uses a street name added after renumbering. ChatGPT may still recognise the property. But when it writes, “Casa Tigli Rooms is a small hotel near the village road,” you can see how the name room and category room have both absorbed the mess.

The practical question is not “Which version do we personally prefer?” The practical question is: which version should public evidence teach ChatGPT to repeat?

Choose the name guests should meet everywhere

The canonical property name is the preferred guest-facing name used on the site, listings and correction requests. It does not have to be the legal name. It has to be the name you want guests, maps, booking surfaces and AI answers to use when they speak about the property.

This distinction matters in Italy because legal, family and hospitality names often overlap. A guesthouse might be legally tied to a surname, known locally by a shorter name, and sold internationally under a softer English phrase. That can work in human conversation. It becomes fragile when the public web gives each version equal weight.

A recurrent pattern looks like this: the property owner believes the name is obvious because everyone nearby uses it. The website logo shows one version, the page title shows another, and the footer adds the legal form. A booking profile shortens the name to fit a template. A review surface uses the shortened version because guests copy what they saw in confirmation emails. ChatGPT then chooses the version that appears most convenient for the question, not necessarily the one on the front door.

I would not rush to erase all variants. Some variants are useful. The legal name may belong in the footer or privacy page. A historical name may belong in a short note if old guests still search for it. A translated phrase may help English readers understand the type of stay. But variants need hierarchy. The canonical property name should appear in the page title, homepage heading, contact page, About page and listing correction requests. Secondary names should be explained, not left floating like spare keys in a drawer.

A useful sentence on an About or contact page can be plain: “Casa dei Tigli is the guest-facing name of our family-run B&B at Via del Ponte 18; older listings may show the previous road name, Via Provinciale.” That sentence is not elegant. It is better than elegant. It tells the public record how to connect the versions.

There is a risk here. Owners sometimes overcorrect and make the site sound like a registry form. Do not do that. Guests still need warmth. But the core name should be boringly stable. Hospitality prose can have linen, shade, breakfast smells and local memory around it. The name itself should not wander.

Align the address without flattening local reality

NAP consistency is stable use of name, address and phone across public hospitality evidence. The term comes from ordinary local search practice, but in this course we use it as a practical identity check: do the main public surfaces give the same basic contact facts?

For Italian guesthouses and boutique hotels, address consistency can be more delicate than it looks. A property may sit outside the main town but use the better-known town for guest orientation. A rural address may include a “frazione,” “località,” hamlet name, road number or old municipal wording. A road may have been renamed. Some platforms simplify the address because their fields do not like local nuance.

Do not solve this by pretending local nuance does not exist. If guests need the hamlet name to arrive, keep it. If the formal postal address differs from the route description, explain both. The error is not local complexity. The error is leaving different versions unexplained across surfaces.

A composite scenario: a family guesthouse near a small Umbrian town uses the formal address on the contact page, a landmark-based direction on the homepage and an old road reference on a tourism profile. The map pin is correct, but ChatGPT says the property is “on the main road into town,” which makes guests expect traffic and walking access. In reality, it is on a side road above the bridge. The answer has not invented from nothing. It has taken a loose direction phrase and treated it like an address.

The repair begins with a contact page that acts like a quiet anchor. Put the canonical property name, full current address, phone, town, province and one practical location note in the same place. If there is an old road name, say it is old. If the property is outside the town centre, say that without embarrassment. If car access matters, state it. If walking access is possible only by a steep path, do not let “near the centre” do all the work.

Then check the public surfaces you can edit or request edits for. The exact same address format is not always possible, because platforms have their own fields. But the same identity should be unmistakable. Same canonical name. Same current street or locality. Same phone where it is public. Same town relationship. One property, not a trail of cousins.

Core pages should confirm each other

A property website can accidentally behave like several small websites stitched together. The homepage says one thing because it was revised for bookings. The About page carries older family wording. The rooms page was translated by someone else. The contact page is accurate but thin. ChatGPT does not know which page carries the owner’s current intention. It sees public text and tries to reconcile it.

For entity consistency, the core pages should confirm each other. I mean the homepage, About page, rooms or accommodation page, services page and contact or location page. They do not need to repeat the same paragraph. That would be unpleasant to read. But they should repeat the same identity facts: canonical property name, property type, town or area, address where appropriate and the basic shape of the stay.

A teaching example: the homepage says, “Casa Riva is a family-run guesthouse in the hills outside the town.” The About page says, “Our six-room B&B has welcomed travellers since the family renovated the old house.” The contact page says, “Casa Riva, Via dei Castagni 4, outside the historic centre, private parking by reservation.” The service page says breakfast is served in season and does not imply a restaurant. These pages have different jobs, but they hold the same entity together.

Now compare the weaker version. The homepage says “boutique stay near the old town.” The About page says “family rooms in our historic house.” The contact page gives only a map embed. The English page says “small hotel.” A tourism profile uses an old name. In that situation, ChatGPT has to decide which version is the spine. The assistant may choose a fluent phrase over the accurate one because the accurate one was never made visible enough.

A good page set gives the model fewer excuses to smooth. It also gives staff fewer explanations to make by email. The same repair serves both AI visibility and human hospitality, which is one reason I trust it. When an action helps only the machine and makes the guest experience worse, I distrust it.

What to inspect before changing anything

Before editing public pages, collect the identity evidence you already have. Start with the ChatGPT answer, but do not let it boss you around. Mark the name, address, property type and any old or alternate wording. Then open your homepage, contact page, About page, main booking profile, public map profile and two or three major public profiles. Read only the identity layer first. Ignore adjectives for the moment.

Ask where the canonical property name appears. Ask whether the address is current. Ask whether an old road name appears without explanation. Ask whether the phone number belongs to this property alone or to a shared office. Ask whether the English pages preserve the same identity or quietly turn the property into another kind of stay. Keep this inspection small. Owners sometimes use a broad audit as a way to avoid making one precise correction.

A simple identity repair often has three moves. First, state the canonical property name clearly on controlled pages. Second, place the current address and any necessary local explanation on the contact or location page. Third, request corrections on the strongest mismatched public profiles. The order matters. If your own pages are vague, a corrected outside profile has less to lean on.

There are cases where ambiguity is legitimate. A property may have changed name and still receive searches for the old name. A family may operate two nearby structures with related wording. A rural address may be known locally by a landmark more than by the street number. Do not hide that. Write the bridge between old and new, formal and practical, Italian and English. ChatGPT handles bridges better than holes.

One compact definition for this lecture is worth keeping: entity consistency is public identity evidence that lets ChatGPT connect one property name, address and page set to the same real hospitality business. It is a working definition, not a perfection test. Perfect sameness is rare. Clear connection is the goal.

The work may feel too humble for a course about AI. A name in a heading. An address line. A corrected old profile. A sentence explaining a former road name. But this is where many AI mistakes begin. The answer does not start in the answer. It starts in the fragments the answer is allowed to collect.

What to remember

Entity consistency is presenting one recognisable property across names, addresses, pages and listings. In practice, this means your public evidence should make one hospitality entity easy to connect.

The canonical property name is the preferred guest-facing name used on the site, listings and correction requests. Choose it deliberately, then give secondary names a clear explanation.

NAP consistency is stable use of name, address and phone across public hospitality evidence. For Italian properties, stable does not mean flattening local address nuance; it means explaining it consistently.

Four rooms of Italian hospitality visibility are the name room, the category room, the place room and the promise room, because ChatGPT must recognise who the property is, what kind of property it is, where it belongs and which promises public evidence can support.

A small identity repair often beats a grand rewrite: clarify the name, anchor the address, and correct the public surfaces that make the property look split.