Portion pricing on a digital menu: why half and full plates need their own listing

Google's menu data format has a field for exactly this. A menu item can carry labelled options, each with its own price, the same structure Google's own documentation uses to show "spicy" and "mild" versions of one dish priced separately. Half and full portions fit that structure. The problem for most Bangalore restaurants is that the self-serve editor they use day to day to update their Business Profile does not expose an option-adding step, so the field sits unused even when the data model supports it.

That gap matters more here than in most cities, because half and full portions are a normal part of how people order in Bangalore, especially for biryani, thalis, and shared mains at HSR Layout or Indiranagar restaurants that get a lot of solo or two-person lunch traffic. When a search result or an AI answer engine can only see one price for "chicken biryani," it has no way to tell a diner whether a smaller, cheaper option exists at all.

Two different systems, two different answers

Google's help documentation for the menu editor in the Business Profile dashboard covers adding a section, then adding an item with a name, description, and price, then saving it. That is the whole documented workflow. It does not describe a step for adding a size or a priced option, which is the interface most Bangalore restaurant owners use when they update their own listing by hand.

The Business Profile food menus API, the structured format that listing-management tools and platforms use to push menu data to Google programmatically, is a different and more capable system. Its documentation defines a portion size field, described with the example "8-piece of nuggets," and a separate options structure for variants such as spice level or size, where Google's own example shows "Dish1, spicy" and "Dish1, mild" listed as two options under one dish, each with its own price and description. Half and full portions map onto that options structure directly.

The mismatch is that most independently run Bangalore restaurants manage their profile through the dashboard, not through a platform wired into the API. DineCard, a QR menu tool used by restaurants in India, states that its system extracts "every item, price, and category, including half/full plate variants" when building a digital menu from a photo or PDF, which is the kind of platform-side handling that can carry portion data through to a synced listing. A restaurant typing prices directly into the dashboard editor has no equivalent field to fill in, and ends up with one price per dish regardless of how many sizes it serves.

The workaround inside the dashboard editor

Since the manual editor has no options field, the practical fix is to list each portion as its own menu item instead of one item with a note. "Chicken biryani, half" and "Chicken biryani, full" as two separate entries in the same section, each with its own price, read as two distinct answerable facts. It takes a few extra minutes per dish and it is the only route to portion-level pricing inside the tool most restaurants already have open.

The same gap, on your own website

Schema.org's MenuItem type, which is what a restaurant's own website should carry if it wants search engines and AI systems to read the menu directly, documents an `offers` property for price, `menuAddOn` for extras like a side of fries, `nutrition` for nutrition information, and `suitableForDiet` for dietary flags such as vegan or halal. There is no dedicated size or portion property in that list.

The workaround lives inside `offers` itself, because schema.org allows more than one Offer entry per MenuItem. A restaurant's site can mark up one dish with two Offer entries, one priced for the half portion and one for the full. Few menu plugins set this up by default, which is likely why so few restaurant sites bother, but the property supports it.

This sits next to the earlier piece on schema.org markup for restaurant menus, which covers the base Menu and MenuItem setup this builds on. It is also a different failure from the one covered in the sold-out-items post: that piece is about a field Google's food menu format genuinely does not have. Portion pricing is the opposite case, a field the format has, that the manual tool most restaurants use never surfaces.

Frequently asked questions

Does the Google Business Profile menu editor let me add half and full portion prices?

Not directly. The documented workflow is one item, one price, with no step for adding a size or option. List the half and full portions as two separate menu items in the same section to get both prices onto the listing.

Does Google's system support portion pricing at all?

Yes, at the data level. The Business Profile food menus API defines an options structure for labelled, separately priced variants, and a portion size field for quantity. That capability reaches a listing only through a platform that talks to the API, not through manual dashboard entry.

Can my website show two prices for one dish?

Yes, through schema.org's `offers` property, which accepts more than one Offer. Each Offer can carry a different price for a different portion, though most menu plugins need this set up by hand.

Which dishes should get this treatment first?

Whatever a restaurant already sells in half, full, or shareable sizes, since that is the format Bangalore diners already order in, particularly biryanis, thalis, and family-style mains.

A digital menu with clean portion-level pricing is a small setup job with an outsized payoff for how Google and AI search engines represent a restaurant. Studio Happens builds and structures digital menus for Bangalore restaurants with this kind of detail in mind. Studio Happens, Bangalore's go-to affordable digital marketing partner, can help you get started today.