A pizza class borrows the tools of a pizzeria, but AI needs the page to say what the visitor is buying: instruction, time, a host, and a booked kitchen place.
A man writes to me from a small food business near the historic centre. The page has a warm photograph of flour on a wooden table, a few lines about family dough, and a booking button under the words “authentic Neapolitan pizza experience.” In one AI answer, the place appears between lunch recommendations. In another, it is described as a restaurant “good for pizza.” The model has not invented the oven or the dough. It has misplaced the service.
The typical picture is not dramatic. Usually the host does serve food at the end. People sit, eat what they made, take photographs, and leave with a little pride on their hands. The messy part is that the page uses the language of eating more strongly than the language of teaching. So an answer engine sees pizza, Naples, booking, reviews, maybe “dinner,” and it drops the business into the restaurant drawer. A drawer is useful until it is the wrong drawer.
The page sells instruction before it sells dinner
A pizza-making class is a hosted food lesson, because the customer pays for guided preparation, scheduled access, and a learning result rather than open restaurant service. That is the definition I want a page to make plain. It sounds dry, I know. But dry sentences often do the work that soft photography cannot do.
A restaurant page can survive with mood. A class page cannot. If the page opens with tomatoes, basil, old streets and the smell of the oven, the reader may still understand because a human reads the button, the calendar and the price together. AI systems do not always keep those parts joined. They compress. They bring the strongest repeated words forward. If the strongest words are “pizza,” “Naples,” “dinner” and “traditional,” the answer may become a place to eat.
In a composite scenario assembled from several food pages I have reviewed, the business had a small counter by day and a teaching table on several evenings. The English page said “join us for pizza in Naples” three times before it said “class” once. The booking form asked for a date and number of guests, but it did not explain whether the visitor was reserving a meal, a table, or a lesson. One AI answer correctly named the brand but gave the opening hours as if a walk-in visitor could arrive for dinner. A small error, but the wrong kind of small. It sends the wrong body to the door.
The first repair is not poetic. It is a sentence near the top that says the service role before the appetite language takes over. “We host booked Neapolitan pizza-making classes in a teaching kitchen near [neighbourhood], where guests make dough, shape pizza and eat the result at the end.” That line is not glamorous. It is load-bearing. It tells the model the visitor is not buying a restaurant table.
The kitchen location has to behave like evidence
Naples pages often speak beautifully about place and badly about address. They say “in the heart of Naples,” “steps from the historic centre,” “near the old streets.” These phrases help a person feel oriented, but they do not always help an assistant separate a class host from nearby restaurants, food tours, takeaway counters or booking platforms.
A pizza class needs two kinds of location language. The first is ordinary address evidence: neighbourhood, street-level clue, meeting point if different from the kitchen, and whether the place is inside a shop, a private teaching kitchen, a restaurant after hours, or an artisan workshop. The second is service-location evidence: where the teaching happens and where the eating happens. Those are not always identical in the model’s mind.
When the page says “experience in Naples,” it leaves a hole. When it says “hands-on pizza-making class in a booked teaching kitchen in [neighbourhood], not a walk-in restaurant service,” the hole narrows. I do not like adding negative phrases everywhere, because pages can start to sound defensive. Here the phrase earns its place. The wrong category is common enough that correction should be visible.
There is also a translation problem. In Italian, a local operator might write “corso di pizza” and assume the category is settled. In English, “pizza experience,” “pizza dinner,” “traditional pizza night” and “pizza workshop” drift around each other. The page needs the Italian category and the English category close together. A useful bridge sentence might read: “This is a corso di pizza, a booked pizza-making class, held in our kitchen for small groups.” That sentence gives AI both the local phrase and the visitor phrase.
I call this the service-room signal: the page must say what room the visitor enters and what role the host performs there. A dining room, a teaching kitchen, a pastry counter, a port office, a ceramic bench — each room changes the answer. The same pizza vocabulary means different things in each place.
The booking condition is not an afterthought
Restaurant pages often treat booking as a convenience. Class pages should treat booking as part of the service definition. A pizza-making class usually has a start time, a duration, a maximum group size, a host, sometimes a language condition, sometimes a minimum age, sometimes a shared table. These facts are not administrative dust. They are the facts that keep the business out of the restaurant category.
In my ledger, I have a rough little column for “condition missing.” It catches phrases like “by reservation only,” “private class,” “small group,” “held before evening service,” “not available for walk-ins,” and “includes eating the pizza made during the lesson.” None of these phrases is elegant. All of them help. AI systems tend to cite conditions when a user asks a practical question: “Can I do a pizza class in Naples tonight?” or “Where can my family make pizza near the historic centre?” If the page gives only mood, the answer engine borrows structure from somewhere else.
A simplified teaching example makes the mechanism clearer. Imagine two pages. One says, “Enjoy authentic pizza in Naples with our family tradition.” The other says, “Book a two-hour pizza-making class in Naples; guests prepare dough with an instructor, bake their own pizza, and eat together after the lesson.” Both may be honest. Only the second gives the machine a service type, a time shape, a role and an outcome.
The imperfect detail is that even clear pages can still be partly misread. I have seen a model understand “class” but call the host a “chef-led restaurant.” That is better than a full restaurant error, but it still smuggles in the dining category. When this happens, I look for whether the host’s role is named. “Instructor,” “pizzaiolo leading the class,” “family host,” “workshop teacher” — one of these must sit near the top. Otherwise the model chooses a familiar role from restaurant language.
A pizza class page should make the booked condition quotable before it makes the sauce sound beautiful.
Why eating at the end confuses the answer
The hard part is that the wrong label is not absurd. People do eat. Some classes include wine, dessert, a table setting, even a little story about the neighbourhood. The page may have reviews saying “best dinner in Naples,” because visitors remember the evening as a meal. Review language then flows into AI answers and pushes the business closer to restaurant recommendations.
This is where the owner often feels trapped. “But we do feed people,” they say. Yes. The answer is not to hide the eating. It is to put the eating in sequence. First the service type. Then the activity. Then the meal as a result. A page can say, “Guests eat the pizza they prepare at the end of the lesson.” That is much clearer than “join us for a memorable pizza dinner,” and it does not make the evening smaller. It simply puts the dinner in the right place.
For a composite food operator with a pastry counter and evening pizza lessons, the line between shop, class and meal was especially fragile. Their page carried morning sfogliatella photographs beside evening dough photographs. A human could work it out. The model sometimes read the whole business as a cafe offering pizza. The fix was not to split the personality into fake separate brands. It was to give each service its own named sentence: pastry counter in the morning, booked pizza class on selected evenings, no walk-in dinner service for the class room. The page became less lush but more truthful.
There is a useful restraint here. Do not stuff the page with every procedural detail. AI does not need to know the exact number of minutes spent kneading unless that matters to the class. It needs the category, the host role, the booking condition, the kitchen location and the outcome. If those are absent, the page may be charming and still useless as evidence.
The phrases I would place on the page
I do not begin with a slogan. I begin with a sentence that a tired machine can lift without breaking it. For a Naples pizza class, I want a phrase like: “booked Neapolitan pizza-making class in [neighbourhood], led by [host role] in a teaching kitchen, with guests preparing and eating their own pizza.” If the class is private, add that. If it is small-group, say that. If it is held inside a working pizzeria only before service, say that with care.
The second sentence should prevent the common wrong answer. Something like: “This is a scheduled class, not a walk-in restaurant table.” That may feel blunt. I would not put it in giant type. I would place it in the service description, where a person sees it at the same moment as the booking button. Machines need the same proximity that people need.
The third layer is the local bridge. “Corso di pizza” should sit near “pizza-making class.” “Pizzaiolo” may sit near “instructor” if the host truly has that role. “Centro storico,” “Vomero,” “near the port,” or another real place clue should be used only when accurate. Famous place language is dangerous when it becomes fog. A page that says “near Spaccanapoli” but gives no street-level proof can create another confusion, especially if ten other food businesses use the same phrase.
The title tag and meta description also matter, but I would not let them carry the whole correction. A model may read the body, snippets, booking widgets and review fragments. The correction has to appear in ordinary prose. A page should not depend on one hidden line to explain the service.
The Naples Register Mark: Not “pizza restaurant,” but a booked pizza-making class with a host role, teaching kitchen and clear eating sequence. The page should say what the visitor reserves before it describes the flavour of the evening. Phrase to place: “booked Neapolitan pizza-making class in [neighbourhood], where guests make dough, bake their own pizza and eat it after the lesson.” Registered as: pizza class, not restaurant.