Faceted Recipe Search Starts at Ingestion

A good recipe search experience is not built by throwing recipe text into a search engine and adding filters later. It starts at ingestion, where cuisine, diet, ingredients, timing, nutrition, equipment, and source confidence become explicit fields that a product can filter, rank, and explain.

Keyword search is only the first layer

Keyword search helps users find "chicken tacos" or "banana bread," but most recipe products quickly need more precise controls:

• vegetarian weeknight dinners
• gluten-free recipes under 30 minutes
• high-protein breakfasts with oats
• pantry recipes that use chickpeas
• low-sodium meals without shellfish
• recipes that work with an air fryer

Those are not just text queries. They combine full-text relevance with structured constraints. If the source recipe only stores a title, a paragraph, and free-text ingredient lines, every filter becomes a guess.

Public recipe markup shows the minimum useful vocabulary

Schema.org's Recipe type is a useful starting point because it names common recipe fields: ingredients, instructions, yield, cuisine, category, diet suitability, nutrition, time, images, and aggregate rating. Google's recipe structured data documentation uses the same general vocabulary for search presentation, including cooking time, nutrition, recipe category, cuisine, keywords, ingredients, and instructions.

That matters because the public web has already converged on a rough recipe vocabulary. But product search needs stronger guarantees than markup alone provides. A field being present in markup does not mean it is normalized, complete, safe to filter on, or consistent across suppliers.

Treat public markup as an interoperability layer. Treat your internal API schema as the product contract.

Facets need normalized fields, not labels

Search systems can filter on fields only when those fields are intentionally modeled. Algolia's faceting guide describes facets as attributes used to refine search results. Meilisearch's filtering documentation similarly requires fields to be configured as filterable before they can be used in filter expressions.

For recipe apps, that means ingestion should produce stable values like these:

{
  "title": "Chickpea and Spinach Curry",
  "cuisines": ["indian-inspired"],
  "mealTypes": ["dinner"],
  "dietaryFlags": ["vegetarian", "dairy-free"],
  "totalTimeMinutes": 35,
  "ingredients": [
    { "id": "chickpeas", "display": "canned chickpeas" },
    { "id": "spinach", "display": "baby spinach" }
  ],
  "nutritionPerServing": {
    "proteinGrams": 18,
    "sodiumMilligrams": 620
  }
}

The important part is not the exact field names. The important part is that facets use controlled IDs and numeric values, while display copy remains free to be human-friendly.

Build a facet contract before indexing

A practical recipe search contract should define which fields are filterable, searchable, sortable, and display-only.

Field	Search role	Why it matters
title	searchable	Supports natural queries and autocomplete.
ingredientIds	filterable, searchable	Enables pantry search and exclusion filters.
dietaryFlags	filterable	Powers vegetarian, vegan, gluten-free, allergen, and religious-diet flows.
totalTimeMinutes	filterable, sortable	Supports weeknight and quick-meal filters.
nutritionPerServing	filterable, sortable	Enables macro and nutrient-aware products.
cuisines and mealTypes	filterable	Makes browsing and personalization possible.
equipmentIds	filterable	Helps appliance-led experiences such as air fryer or slow cooker apps.
sourceConfidence	ranking signal	Lets the product prefer complete, verified recipes over weak ingested records.

This contract should live upstream of the search index. If a field is important enough for users to filter by, it is important enough to validate when recipes enter the system.

AI-generated recipes need the same facets

AI recipe generation makes this more important, not less. A generated recipe that returns only prose cannot participate in the same product experience as catalog recipes. It cannot reliably appear in diet-filtered search, meal plans, grocery lists, nutrition dashboards, or pantry results without another extraction pass.

The better approach is to require generated recipes to return the same schema as retrieved recipes. The search index should not need to know whether a recipe came from a catalog, an editorial workflow, a partner feed, or an AI generation endpoint. It should receive one normalized object shape.

Validate facets as product behavior

Facet bugs are product bugs. If a recipe marked dairy-free contains butter, the issue is not just data quality; it can damage trust. If a recipe says it takes 25 minutes but includes an overnight marinade in the instructions, the time filter is misleading. If a "contains peanuts" exclusion depends on keyword matching alone, it will miss aliases and branded products.

Add validation checks at ingestion:

• Require controlled IDs for ingredients, cuisines, diets, equipment, and meal types.
• Store both normalized values and original source text.
• Keep confidence or provenance fields for inferred facets.
• Validate numeric ranges for time, servings, and nutrition.
• Separate positive claims from unknown values. glutenFree: false and glutenFree: null are different product states.
• Re-run facet extraction when a recipe, ingredient taxonomy, or nutrition source changes.

What builders should do differently

Before choosing a search provider, write the recipe object you want users to experience. Then decide which fields need full-text search, exact filtering, range filtering, sorting, ranking, and display.

A search index can only refine the data it receives. The durable engineering work is the ingestion layer: turning recipes into normalized product data with stable ingredient entities, dietary flags, time fields, nutrition values, equipment, cuisine, and provenance.

Recipe API is designed around that idea. Recipes expose structured ingredients, dietary flags, timing, nutrition, equipment, and consistent generated-recipe output so teams can build search and planning features without inventing a cleanup layer first.

Sources

• Schema.org Recipe
• Google recipe structured data
• Algolia faceting guide
• Meilisearch filtering and sorting documentation