Restaurants became an eligible category in Google's EEA search units on 18 September. The aggregator unit and the supplier unit had covered hotels, flights, long-distance trains or buses, and products; local businesses are the fifth vertical. Google's changelog spends a single sentence on it — "The aggregator unit and supplier unit now support local business queries" — and Barry Schwartz picked the entry up at Search Engine Roundtable the same day.
Both units exist to satisfy the Digital Markets Act, and both appear only to users inside the EEA.
The two boxes are filled from different places
The aggregator unit carries listings from approved vertical search services, a group Google's documentation defines as online travel agencies, comparison shopping services, metasearch engines and directories. Approval is one condition and supply is the other: "Eligible aggregators that wish to participate must provide data to populate a unit by direct data feed integrations or real-time APIs." Flights and ground transport are served by real-time APIs. Lodging and local business queries are served by a feed.
The supplier unit sits alongside it and belongs to direct providers, which Google's documentation illustrates as "individual hotels or airlines, brick-and-mortar business owners, or providers of services like plumbing". A restaurant is the middle example in that list. A diner inside the EEA searching for somewhere to eat can therefore meet a directory's selection in one box and individual restaurants in the other, assembled by two unrelated mechanisms.
The feed schema has no room for a dish
For local business queries the aggregator documentation points at the Local Point of Interest feed, and that schema is worth reading in full. It carries poi_id, name, telephone, url, location, display_address, up to five images, rating, num_ratings, rating_scale, category, description, and a local_data block holding a price_range.
No field carries a dish name, a dish price or an allergen. A directory can file a complete and valid feed for a restaurant without recording a single thing that is served there. The closest the schema comes to food is a band describing what an average visit costs.
That is defensible design for a format meant to describe plumbers and restaurants with the same fields. It also settles what the aggregator box can be: a proximity and ratings surface, answering the part of the question a diner has usually worked out for themselves.
There is no application form for the supplier unit
What Google asks of a direct provider is close to nothing. The website has to serve users in the EEA, the business has to be a direct provider in an eligible category, and then the documentation is blunt: "You don't need to provide additional data beyond what's accessible through web crawling to appear in this feature." Feeds are permitted but optional — supplier results "can be enhanced with data feeds, if available".
That cuts both ways. No restaurant can apply for a place in the supplier unit, and none can correct its entry by filing something. Whatever Googlebot reads off the site is the entire input.
It puts Restaurant, Menu and MenuItem markup in a position worth stating precisely. Google has not named structured data as an eligibility criterion for this feature, and nothing here claims it is one. It is simply the part of a crawlable page that records what the kitchen sells, at what price, with which dietary flags attached — the material the POI schema has no room to carry.
The United Kingdom sits outside this one
The EEA is the European Union plus Iceland, Liechtenstein and Norway. The United Kingdom is not a member. A restaurant in Dublin or Rotterdam falls inside a search feature a restaurant in Norwich will not be shown, built to satisfy a regulation Britain is no longer governed by.
The field list is still worth reading from outside the EEA. It is the clearest published statement of what a large platform treats as a sufficient description of a local business — a name, a category, a rating, a price band — and Google wrote it to cover plumbing firms and restaurants without varying a field. Schemas built that way tend to outlast the feature they were written for.