Extract recipe data from the provided webpage content and return a single JSON object conforming to the schema.org `Recipe` format.

Schema reference: https://schema.org/Recipe

The input may contain HTML, extracted text, metadata, navigation, advertisements, comments, unrelated page content, or duplicated recipe information. Identify and extract only the actual recipe.

Do not invent, infer, or add information that is not supported by the source. If the source does not contain enough information to identify a usable recipe, return an empty JSON object: `{}`.

## Extraction rules

- Prefer the recipe author’s actual content over surrounding page text, SEO text, advertisements, comments, related-recipe links, or other unrelated page content.
- Remove duplicated content caused by responsive layouts, print views, metadata, repeated page sections, or multiple representations of the same recipe.
- Do not include navigation labels, button text, subscription prompts, promotional text, advertisements, comments, or unrelated commentary.
- Do not treat labels such as `Step 1`, `Step 2`, `Method`, or `Instructions` as separate instruction steps when they contain no cooking action.
- Instruction steps must contain actual instruction text.
- Remove redundant step-number prefixes such as `Step 1:`, `1.`, `01 —`, or similar because step ordering is already represented by the JSON structure.
- Preserve the meaning of useful instruction section headings, but never return them as standalone instruction steps.
- Do not create empty instruction sections or empty instruction steps.
- Preserve the original ordering of ingredients, ingredient sections, and instructions.
- Keep ingredient quantities, units, preparation notes, alternatives, package sizes, and optional markers associated with the correct ingredient.
- Extract preparation time, cooking time, total time, yield, servings, temperatures, ratings, and nutritional information only when explicitly present in the source.
- Prefer explicit values from the main recipe over values inferred from prose, comments, related content, or calculations.
- When several representations of the recipe exist, prefer complete structured recipe data and verify it against the visible recipe content.

## Recipe normalization

Normalize the recipe before returning the JSON.

- Convert US customary measurements to sensible metric measurements.
- Prefer grams, kilograms, millilitres, litres, and degrees Celsius.
- Preserve practical kitchen units such as teaspoons and tablespoons when they are clearer than very small metric quantities.
- Preserve count-based quantities where appropriate, such as `2 eggs`, `1 onion`, `3 cloves garlic`, or `1 can tomatoes`.
- Convert Fahrenheit cooking temperatures to Celsius.
- Round conversions to sensible cooking values.
- Avoid false precision such as `236.588 ml`, `28.3495 g`, or similar values that are impractical in a kitchen.
- Use quantities that are practical to measure using normal kitchen equipment.
- Do not change quantities that are already expressed using sensible metric or practical kitchen units.
- Do not convert culturally meaningful, product-specific, package-based, or count-based units when conversion would make the ingredient less clear.
- Keep all converted quantities internally consistent across ingredients and instructions.
- When a converted quantity also appears in the instructions, use the same normalized value and unit in both places.

## Ingredient formatting and unit normalization

Normalize every string in `recipeIngredient` before returning the JSON.

Ingredient strings should be concise, natural, and suitable for display in a recipe application.

### Preferred unit output

Use these exact abbreviations for metric units:

- milligram → `mg`
- gram → `g`
- kilogram → `kg`
- millilitre or milliliter → `ml`
- litre or liter → `l`

Use these exact abbreviations for common kitchen units:

- teaspoon → `tsp`
- tablespoon → `tbsp`

Use lowercase abbreviations exactly as written.

Do not:

- add periods to unit abbreviations
- pluralize abbreviated units
- output long-form metric unit names when a preferred abbreviation exists
- mix long-form and abbreviated versions of the same unit within one recipe

Examples:

- `200 millilitres whipping cream` → `200 ml whipping cream`
- `390 grams chopped tomatoes` → `390 g chopped tomatoes`
- `1 kilogram potatoes` → `1 kg potatoes`
- `2 tablespoons tomato purée` → `2 tbsp tomato purée`
- `1 teaspoon salt` → `1 tsp salt`
- `500 milligrams saffron` → `500 mg saffron`

### Unit recognition

Recognize and normalize common spelling variants, abbreviations, singular forms, plural forms, and regional variants.

Normalize these forms:

- `mg`, `milligram`, `milligrams` → `mg`
- `g`, `gram`, `grams` → `g`
- `kg`, `kilogram`, `kilograms` → `kg`
- `ml`, `millilitre`, `millilitres`, `milliliter`, `milliliters` → `ml`
- `l`, `litre`, `litres`, `liter`, `liters` → `l`
- `tsp`, `teaspoon`, `teaspoons` → `tsp`
- `tbsp`, `tbs`, `tablespoon`, `tablespoons` → `tbsp`

### Count-based and descriptive units

Preserve concise count-based or descriptive units as words when they are appropriate, including:

- egg
- onion
- clove
- can
- jar
- bottle
- package
- packet
- sachet
- cube
- bunch
- bundle
- sprig
- slice
- piece
- stick
- pinch
- dash

Use natural singular or plural grammar for these units.

Examples:

- `4 cloves garlic`
- `2 cans chopped tomatoes`
- `1 bunch parsley`
- `3 slices bread`
- `1 pinch salt`

Do not rewrite natural count-based ingredients into artificial units such as `4 units garlic cloves`.

### Practical conversions

Preserve teaspoons and tablespoons when they remain practical and clear.

Examples:

- `1 tbsp olive oil` should remain `1 tbsp olive oil`
- `2 tsp paprika` should remain `2 tsp paprika`
- Do not convert `1 tsp salt` into `5 ml salt`
- Do not convert `2 tbsp oil` into `30 ml oil` unless the source or recipe context clearly benefits from metric volume

For larger US customary quantities, convert to sensible metric units.

Examples:

- `1 cup water` → approximately `240 ml water`
- `2 cups flour` → a sensible weight in grams only when the ingredient and conversion are unambiguous
- `1 lb potatoes` → approximately `450 g potatoes`
- `8 oz cream cheese` → approximately `225 g cream cheese`

Do not perform weight-to-volume or volume-to-weight conversions when ingredient density is uncertain.

### Fractions and ranges

- Preserve practical fractions for teaspoons and tablespoons when they are clear, such as `½ tsp` or `1½ tbsp`.
- Decimal quantities may be used when they improve consistency, such as `0.5 kg`.
- For converted metric values, prefer practical rounded numbers.
- Preserve quantity ranges when the source gives a meaningful range, such as `2–3 tbsp water`.
- Do not collapse a meaningful ingredient range unless the target schema requires a single value.
- Do not create false precision when converting fractions.

### Ingredient text

- Keep ingredient preparation notes associated with the ingredient.
- Preserve meaningful qualifiers that define the ingredient, such as `smoked paprika`, `dark soy sauce`, `full-fat coconut milk`, or `self-raising flour`.
- Preserve optional markers and serving notes, such as `optional`, `for garnish`, `for serving`, or `to taste`.
- Do not move preparation notes into separate ingredients.
- Do not split one source ingredient into several ingredient strings.
- Do not merge separate source ingredients.
- Preserve the original ingredient ordering.

Examples:

- `400 g tomatoes, drained`
- `2 tbsp olive oil, plus extra for frying`
- `1 large onion, finely chopped`
- `½ tsp red pepper flakes, optional`
- `salt and freshly ground black pepper, to taste`

## Instruction normalization

Normalize `recipeInstructions` before returning the JSON.

### Required behavior

- Every final `HowToStep` must contain at least one concrete action that a cook can perform.
- Never return a `HowToStep` whose text consists only of a title, label, section heading, phase name, or step number.
- Standalone headings must not appear as separate instruction entries.
- Do not create separate steps merely to preserve the source page’s visual structure.
- Do not preserve heading punctuation such as trailing colons.
- The final instruction list must contain only meaningful cooking actions.
- Preserve the original cooking order.

Examples of forbidden heading-only steps include:

- `Season Chicken`
- `Sear the Chicken`
- `Sauté Garlic`
- `Add Lemon and Spices`
- `Bake the Chicken`
- `Garnish and Serve`
- `To serve`
- `Serving`
- `For serving`
- `Make the sauce`
- `Prepare the filling`
- `Method`
- `Instructions`
- `Step 1`

### Heading handling

When a heading is immediately followed by an instruction:

- Omit the heading if the following instruction is clear without it.
- Merge the heading naturally into the following instruction if it adds useful context.
- Never return the heading as its own `HowToStep`.

Examples:

Input:

`Season Chicken:`

`Pat the chicken thighs dry, then season with salt and pepper.`

Output:

`Pat the chicken thighs dry, then season with salt and pepper.`

Input:

`Make the sauce:`

`Add the garlic, lemon juice, and stock to the pan.`

Output:

`To make the sauce, add the garlic, lemon juice, and stock to the pan.`

Input:

`Garnish and Serve:`

`Top with parsley and lemon slices, then serve.`

Output:

`Top with parsley and lemon slices, then serve.`

### Step consolidation

- Merge adjacent fragments when one contains only a heading and the next contains the actual instruction.
- Merge very short preparatory actions into the following instruction when they are directly related and doing so improves readability.
- Do not split a coherent cooking action into multiple steps merely because the source uses separate visual blocks.
- Do not over-merge unrelated cooking actions into excessively long steps.
- Prefer a concise sequence of meaningful steps over many tiny fragments.
- The final instruction list should normally contain fewer steps than the raw source when the source separates headings from their instructions.

### Temperature and unit consistency

- Use Celsius in instructions.
- When the source gives both Fahrenheit and Celsius, retain only the sensible Celsius value unless both are needed for clarity.
- Use normalized unit abbreviations consistently in instructions when quantities are repeated.
- Do not use long-form metric unit names in instructions when the preferred abbreviation is clearer.

Examples:

- `Bake at 375°F (190°C)` → `Bake at 190°C`
- `Add 200 millilitres cream` → `Add 200 ml cream`
- `Stir in 2 tablespoons olive oil` → `Stir in 2 tbsp olive oil`

### Final instruction validation

Before returning the JSON, inspect every instruction step.

For each step, verify:

1. It contains a concrete action a cook can perform.
2. It contains more than only a heading, label, phase name, or step number.
3. It does not duplicate information already represented by another step.
4. It is not empty or whitespace-only.
5. It is not merely explanatory text without an actionable instruction.
6. Its quantities, units, and temperatures use the same normalized forms as the ingredients.

If a step fails these checks, merge it with the appropriate adjacent step or remove it.

## Language rules

- If the source recipe is not in English, translate all recipe text into English.
- Translate the title, description, ingredient names, ingredient notes, section headings, instructions, yield text, and relevant recipe metadata.
- Preserve proper nouns, brand names, geographical names, and culturally specific dish names when translating them would make the recipe less precise or less recognizable.
- Use clear, natural cooking English rather than literal word-for-word translation.
- After translation, apply all unit normalization and abbreviation rules to the translated recipe.
- Do not leave untranslated unit names when a preferred English abbreviation exists.

## Image rules

- If the source contains a clear primary image of the finished recipe, include it in the `image` field.
- Prefer the main recipe hero image or the highest-quality image that clearly depicts the completed dish.
- Ignore logos, author portraits, advertisements, icons, social media images, decorative backgrounds, unrelated gallery images, and tracking pixels.
- Prefer image URLs found in recipe structured data, Open Graph metadata, Twitter Card metadata, or the main recipe content.
- When multiple versions of the same image are available, choose the largest practical image rather than a thumbnail or low-resolution preview.
- If the source provides an image array, select the best single primary image for the finished dish rather than returning multiple images.
- The `image` field must contain either:
  - an absolute URL string, for example: `"https://example.com/images/recipe.jpg"`
  - or an `ImageObject` containing an absolute `url` property, for example: `{ "@type": "ImageObject", "url": "https://example.com/images/recipe.jpg" }`
- Use only the `image` field.
- Do not use `thumbnail`, `thumbnailUrl`, `contentUrl`, or other image fields.
- Do not use relative URLs unless they can be resolved unambiguously against the webpage URL.
- Do not use embedded base64 data, data URIs, blob URLs, local file paths, or temporary browser-generated URLs.
- Do not invent, rewrite, guess, or repair an image URL.
- If no suitable recipe image is present, omit the `image` field.

## Final validation

Before returning the JSON, verify all of the following:

1. The output is a single valid schema.org `Recipe` JSON object.
2. Every ingredient from the source is represented once and in the original order.
3. Every recognized metric or kitchen unit uses the preferred abbreviation.
4. No ingredient uses long-form metric units such as `grams`, `millilitres`, or `kilograms`.
5. Ingredient quantities are practical and do not contain false precision.
6. Instruction quantities and temperatures are consistent with the normalized ingredients.
7. No instruction step consists only of a heading, label, or step number.
8. The image, when present, is a valid absolute URL or an `ImageObject` with an absolute `url`.
9. Unsupported fields are omitted rather than guessed.
10. No information has been invented.

Correct any violations before returning the final JSON.

## Output rules

- Return only the final JSON object.
- Do not include Markdown, explanations, comments, warnings, or code fences.
- Ensure the JSON is valid and syntactically complete.
- Omit unsupported optional fields rather than guessing their values.
- Use an empty object only when no usable recipe can be extracted.