Recipe Schema: The Markup Behind Recipe Rich Results

Recipe schema is the schema.org Recipe type, written as a block of JSON-LD in a page's source code, and it is the reason a food page can show a photo, a star rating, a cook time, and a calorie count directly inside a Google search result instead of just a blue link. Search engines cannot reliably read "preheat the oven to 220C for 35 minutes" out of free-form prose and know which number is the temperature and which is the time; Recipe schema hands that structure over explicitly, property by property.

That said, Recipe schema fails silently far more often than it fails loudly. A JSON-LD block can be syntactically perfect, pass a generic validator with a green checkmark, and still never earn a rich result, because Google's actual eligibility rules for this type are narrower than schema.org's base specification permits. This piece works through the properties that matter, the specific ways the time, nutrition, and image fields break in practice, and where the recipe-card plugins that generate most of this markup automatically tend to get it right or wrong.

What Recipe Schema Actually Marks Up

Recipe schema is a JSON-LD object with "@type": "Recipe", almost always placed inside a script tag with type application/ld+json, either in the page head or lower in the body. It is a distinct vocabulary from the generic structured data used for articles or products; a Recipe object has properties like recipeIngredient and cookTime that a NewsArticle or Product object has no equivalent for, so a general structured-data pass on a site does not automatically cover recipe pages correctly.

The markup is read in more than one place. Google uses it to build the standard recipe rich result and the recipe carousel on mobile search and Google Images. Bing parses the same schema.org vocabulary for its own recipe features. A growing number of recipe apps, shopping-list tools, and voice assistants also read this structured block directly rather than scraping the visible prose, since it is far less ambiguous than "a pinch of salt" parsed out of a paragraph.

A common structural mistake is putting more than one Recipe object on a single page without a clear primary one, which happens most often on roundup pages describing five different dishes. Schema.org technically allows several Recipe entities on one URL, but Google's rich result is built around one page representing one recipe, so a roundup with five Recipe blocks usually wins a rich result for none of them. Giving each recipe its own dedicated page is the more reliable pattern.

The Properties Google Actually Requires

Google's structured data guidelines for Recipe list a short set of strictly required properties, and image sits at the top of it: without at least one qualifying image, the page is not eligible for a recipe rich result at all, regardless of how complete everything else is. Name is the other required property, and a Recipe object without one defeats the point of the markup, since there is nothing for the headline to display.

Everything past that short required list falls into recommended, and recommended is doing more work than the label suggests. Each recommended property gates one specific visible element of the card, so skipping it does not just leave a gap in the data, it removes a piece of the result:

• author: attributed authorship, used in some result variants and by aggregators
• datePublished: freshness signal for the recipe's first publication
• description: supporting text some surfaces show under the recipe name
• prepTime, cookTime, totalTime: the time badge shown directly on the card
• recipeYield: the serving count shown alongside the card
• recipeCategory and recipeCuisine: classification used for filtering in carousels
• recipeIngredient: the ingredient list some assistants and apps pull directly
• recipeInstructions: the step-by-step method, structured or as plain text
• nutrition: the calorie figure shown on the card, and the fuller nutrition panel
• aggregateRating and review: the star rating shown next to the photo
• video: the video badge on the thumbnail, when a matching video exists

A page can validate cleanly with only image and name present and still show a bare rich result with no stars, no time, and no calories, simply because nothing recommended was filled in. The gap between valid and fully populated is exactly where most Recipe markup underperforms.

Time Properties: The Most Common Validation Failure

The single most frequent validation error on Recipe pages is a malformed duration value. Schema.org's Duration type, which prepTime, cookTime, and totalTime all use, expects the ISO 8601 format: PT30M for thirty minutes, PT1H15M for an hour and fifteen, PT2H for two hours flat. Writing "30 minutes," "30 mins," or a clock-style "00:30:00" instead is not a nuance Google's parser tolerates; it treats the value as invalid and drops the time badge entirely, even though the number is perfectly readable to a person.

A quieter failure is a missing "PT" or "P" prefix, or a lone number with a unit letter but no duration marker, such as "30M" instead of "PT30M." This passes a casual glance because it looks close enough, but the parser reads the leading character as structural, not decorative, and rejects anything that does not start with it.

The three time properties are also frequently inconsistent in ways that throw no error but look wrong on inspection: a totalTime shorter than prepTime plus cookTime, or a totalTime left blank while the other two are filled in. The validator will not flag the arithmetic, and Google's guidelines expect either totalTime or both prepTime and cookTime, so a page that fills in only one of the three can lose the time badge without any obvious error.

Nutrition, Images, and Other Validation Failures

Nutrition information is its own nested object, NutritionInformation, and its calories property is a Text value, not a bare number. Writing the raw number 270 instead of the string "270 calories" is a common source of a card that omits the figure or shows it without a legible unit. These values are also almost always estimates from an ingredient database rather than a lab-measured fact, and should be framed that way.

Image requirements are stricter than most authors expect. Google looks for images meeting a minimum resolution and specific aspect ratios: square (1x1), standard (4x3), and widescreen (16x9), because the card and the carousel crop the source image differently depending on where it displays. A single image at one ratio forces an awkward, off-center crop; an array of URLs already covering the three ratios lets Google pick a properly composed one instead.

recipeInstructions accepts three shapes: a single block of text, an array of text strings, or a list of HowToStep objects, each with its own text property. All three validate, but only HowToStep preserves the steps as discrete units, which is what lets some surfaces expand or number them in a preview rather than showing one dense paragraph. Fifteen genuinely distinct steps marked up as a single string still validates and still loses that benefit.

Beyond the technical schema, Google's policies require marked-up data to match what a visitor actually sees. A Recipe object claiming a 4.8 rating from 340 reviews on a page with no visible reviews at all is a mismatch the guidelines treat as a violation independent of technical validity, and it can cost the page its structured data eligibility site-wide, not just on that one page.

How the Recipe Rich Result and Carousel Actually Use This Data

The standard recipe rich result is a card combining the qualifying image, the star rating when aggregateRating is present, the total time when totalTime is present, and the calorie count when nutrition.calories is present. Each visible element maps to a specific property; there is no separate toggle to enable the rich result, it is simply built from whichever qualifying properties exist.

The recipe carousel is a more prominent, swipeable presentation of the same eligibility, appearing mainly on mobile search and inside Google Images and Discover. It is not a feature a site opts into separately: any page eligible for the standard rich result is a candidate for the carousel, and which pages surface in it depends on the same markup completeness plus factors outside the page's control, such as the query and device.

Video works the same way: when the video property points to a genuine VideoObject actually present and playable on the page, the result can show a video badge on the card. A video property pointing to a URL not embedded anywhere visible on the page repeats the mismatch problem above, and Google's spam policies specifically call out recipe markup added to content that is not genuinely the page's primary subject, such as attaching a full Recipe object to every dish mentioned in passing on an unrelated roundup article.

None of this is a guarantee. Full eligibility only makes a page a candidate; Google decides at query time whether to render any rich result at all, and a technically perfect Recipe object can still show as a plain blue link if it decides not to display the enhanced treatment for that search.

Do Recipe-Card Plugins Get This Right?

Most WordPress food sites do not hand-write this JSON-LD; a recipe-card plugin such as WP Recipe Maker or Tasty Recipes, or the recipe block built into an SEO plugin like Yoast or Rank Math, generates it from the fields an author fills into a form. This removes the most common hand-authoring mistake almost entirely: current versions convert a friendly "30 minutes" field into the correct PT30M duration automatically, so that error rarely originates from plugin-generated markup at all.

A few things are still worth checking manually. Star ratings are the biggest one: several recipe-card plugins ship a five-star voting widget, enabled by default, that feeds aggregateRating directly, and a newly published page can end up with a rating built from a handful of early test clicks rather than a meaningful sample of reader feedback. A few unrepresentative votes can produce a rating that reads as more established than it is, so checking the actual vote count before trusting the star display is worth the few seconds it takes.

Nutrition data from these plugins is almost always a computed estimate from an ingredient database, not a verified figure from a lab or a packaging label. That is a reasonable approximation, but should not be described as more precise than it is, and swapping an ingredient after publishing can leave a stale figure attached to a recipe that has quietly changed.

Roundup formats reproduce the multi-recipe problem described earlier: a recipe-card block in each entry of a "12 dinners" post generates a separate Recipe object per entry, all on the same URL, with no signal about which one that page represents. Finally, since some themes and plugins inject the card or its JSON-LD with JavaScript, view-source alone is not always reliable; check the actual rendered page instead, since a script failing to execute removes the schema along with the visible card.

Testing and Reading the Results

Google's Rich Results Test and the URL Inspection tool in Search Console both parse a live URL and report Recipe eligibility directly, and the distinction between the two severities they report matters. An error means a required property is missing or malformed and the page is not eligible for any recipe rich result at all until it is fixed. A warning means a recommended property is missing or malformed; the page can still show a rich result, just a sparser one missing whatever that property would have supplied, such as the calorie figure or the time badge.

Reading the report as a checklist against the recommended-property list above, rather than stopping once the eligible status turns green, is the difference between a recipe page that technically passes and one that actually earns the full card in the search result.