Recipe schema: what it is and how to check yours

Recipe schema markup gives the facts on your recipe page a labeled, machine-readable form. The dish’s name, ingredient quantities, photograph and yield have counterparts that services such as Google can read as structured data. Those counterparts should describe the recipe you published—not a second version assembled to satisfy a test.

Checking your markup means answering three separate questions: Is Recipe data present? Does it agree with the visible recipe? Does it meet Google’s requirements? A tool can help with the first and third. The second needs your attention to the recipe itself.

Together, these checks help establish eligibility for recipe rich results: enhanced search presentations that can include an image or other details beyond a standard link. Eligibility is not a promise that Google will show one.

Find the Recipe data on your published page

Open the recipe as a reader would, then submit its full published URL to Google’s Rich Results Test. Choose the URL test rather than pasting a code sample: you want to inspect what your website actually supplies.

When the test finishes, look for Recipe among the detected structured-data types. Open that group and expand the individual recipe item to inspect its properties—the named fields holding the recipe facts—and any reported issues. As Google’s test help explains, clicking an issue’s description opens the corresponding location in the rendered source code. You can use that view to locate the affected field without needing to understand the whole page’s code.

If the tool cannot fetch the page, resolve that access problem before concluding that markup is missing. The test cannot use your login to reach private content. And if it finds another type of structured data but no Recipe item, that other type does not establish that recipe data is present. Check any reported parsing problems, then the recipe’s structured-data settings.

Keep the visible recipe open beside the results. A detected item is the beginning of the comparison, not its conclusion.

Compare the recipe facts, not just the test status

Suppose a page called Lemon Yogurt Dip lists these ingredients:

• 200 g plain yogurt
• 1 tablespoon lemon juice
• 1/4 teaspoon salt

It says the dip serves four and shows a photograph of the finished dish.

Now suppose the page’s generated Recipe data contains the fragment below. For this example, neither image nor description appears anywhere in the complete Recipe object; they have not merely been left out of the excerpt.

This is an illustrative comparison, not a tested dish, a deployment template or a captured validation result.

{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Lemon Yogurt Dip",
  "recipeYield": "4",
  "recipeIngredient": [
    "200 g plain yogurt",
    "1 teaspoon lemon juice",
    "1/4 teaspoon salt"
  ]
}

This format is called JSON-LD, one of the supported ways to put structured data on a page. A property is a label such as recipeYield; its value is the fact beside it, here "4". That serving count agrees with the visible recipe. The recipeIngredient property holds the ingredient list—but one entry does not agree.

The page asks for a tablespoon of lemon juice; the markup says a teaspoon. Both are readable ingredient entries. Only one represents this published recipe. A tool’s ability to read an ingredient field does not prove that the quantity inside it is accurate, so correct the markup to say 1 tablespoon lemon juice.

The photograph presents a different problem. A person can see the finished dip, but the Recipe object has no image property identifying it. Google lists that property as required. The fix is to connect the finished-dish photograph to the recipe’s generated image data, not merely to confirm that a photograph appears somewhere on the page.

The missing description is different again. Google recommends a short summary of the dish, but its absence is not the same eligibility failure as a missing required image. Add a truthful summary that also appears on the page; do not invent extra claims to fill the field.

These are three selected findings, not a complete audit. On your own page, continue through the name, ingredients, instructions, times and yield. If nutrition or ratings are supplied, compare those too. Correcting the dip’s three findings would not establish that every other requirement had been met.

What “required” and “recommended” actually mean

Schema.org supplies the vocabulary—the labels used to describe recipes and other things. Google specifies which of those labels matter to its search features. Its structured-data introduction makes that distinction explicit: use Google’s documentation as the authority for Google Search behavior, rather than treating every available Schema.org field as a search requirement.

Google’s Recipe guidance lists name and image as required properties. The image must depict the completed dish, and its URL must be accessible to Google and eligible for indexing—what the documentation calls “crawlable and indexable.” A photograph that only you can access does not meet that condition. Required properties are necessary for eligibility, but the page must also follow the relevant structured-data guidelines.

Ingredients and instructions appear among Google’s recommended properties. That classification is about search markup, not what makes a useful recipe. A cook still needs to know what goes into the dip and what to do with it. “Recommended” is not a reason to omit known, useful facts.

Nor does it mean a field is optional in every circumstance. If you supply nutrition per serving, Google requires recipeYield with the number of servings. An item count can be an additional yield, but it should not replace that serving count. Suppose a recipe makes 12 biscuits and defines a serving as two biscuits: per-serving nutrition needs the six-serving count, not just “12 biscuits.” The page and its data should make the same serving definition clear.

Times have a related rule: Google says to use totalTime, or a combination of both prepTime and cookTime. If you are supplying time data, choose the supported arrangement that reflects the recipe rather than inventing a missing duration.

The aim is accurate information, not the largest possible object. Nutrition figures, ratings and other facts should never be manufactured to satisfy recommendations.

Fix the source, then check the published result

If you use a CMS—the system where you edit your website—start with the recipe’s editing fields. Check the saved ingredient list, yield and selected photograph. Then look at the relevant search settings or recipe-plugin controls. You may not have, or need, access to edit the page’s code directly.

If you are choosing publishing software, compare recipe website builders with this requirement in mind: how will the facts you enter become Recipe data, and where will you correct them?

First settle any uncertainty in the recipe itself. If one part of the page says a tablespoon and another says a teaspoon, the validator cannot decide which you intended. Resolve the quantity and write a complete recipe before encoding its facts.

If the saved fields are correct but the generated data is wrong, send the person maintaining the integration a precise report. Include the page URL, affected property, expected value and observed value. For a separate, hypothetical soup, that report might read:

My soup page says “Serves 4,” and the recipe editor also says four. Google's Rich Results Test still shows recipeYield as six after I publish. Here's the public recipe address and the test result. Can you check where the old value is coming from?

That gives the maintainer a specific discrepancy to trace rather than a general request to “fix the schema.”

Publish the correction, rerun the URL test and compare the recipe facts again. Checking only the editor would miss an output problem; checking only the test status would miss a readable but wrong quantity. When you update an existing recipe, keep the visible content, generated data and any update information aligned with what actually changed.

Valid markup, but no rich result?

A valid test result does not prove that the page has been indexed or that Google will display an enhanced result. Google’s test help explicitly says that neither a preview’s exact appearance nor any particular enhanced presentation is guaranteed.

Use Search Console’s URL Inspection tool to check Google’s indexed version separately from the live page.

Once your markup accurately describes the page and meets the relevant requirements, a missing rich result is not a reason to keep adding fields. Move to the broader question of how Google finds your recipe pages, rather than adding unsupported nutrition, ratings or recipe details in pursuit of a search appearance you cannot guarantee.

← Back to the blog