Skip to main content
NestBoard

← Journal

Importing recipes from any cooking site

NestBoard · 2026-05-18

How it actually works

When you paste a recipe URL into NestBoard's meal planner, we try not to send it to an LLM to "extract" the ingredients and steps. First we read the structured data that's already there.

Most major cooking sites embed schema.org/Recipe markup in every recipe page. Bon Appétit, NYT Cooking, AllRecipes, BBC Good Food, individual food blogs running WordPress. It's invisible to you, but it's sitting in the HTML: the ingredient list, the instructions, cook time, yield, everything.

We parse that structured data, pull out the fields we need, and show you the recipe. On that path there is no round-trip to a language model, so no waiting and no hallucination risk.

What works well

Food blogs using plugins like WP Recipe Maker or Tasty Recipes are perfect. The metadata is clean and consistent.

Recipe aggregators like AllRecipes and Food Network work beautifully. They've been publishing schema.org data for years.

Even smaller independent sites often use the same WordPress plugins, so they work just as well as the big names.

What doesn't work

Restaurant menus don't publish recipe metadata. They're not recipes, they're listings. If you want to save "pad thai from the place on 5th," use "+ New recipe" and type it in, or ask Robin for a version of it in chat and then say "save this to my recipe box."

Some older or minimal food blogs skip the structured data entirely, and some block a direct fetch. When that happens we fall back to reading the page's plain text and having a model pull the recipe out of it. That path is slower and less certain, so check the result before you cook from it. It also means the URL you pasted goes to Jina AI's reader service, which is listed on our subprocessors page with exactly what it receives. Only the public recipe URL you chose to import goes with it. Nothing about your account or your household does.

And sometimes a site has the schema.org tags but fills them badly. Missing units, ingredients buried in the instructions, that kind of thing. We can't fix bad data. When a page has no recipe data we can read, or its recipe is missing the ingredients or the steps, you get a clear message and nothing is saved, so a broken page never leaves a half-empty recipe in your collection.

Why we like this approach

It's fast. There's no API call to wait on, no token budget to manage.

It's honest about which path you got. When the structured data is there, what lands in your recipe box is exactly what the publisher wrote, not a model's reconstruction of it.

And it respects the work that recipe publishers have already done. They've marked up their content in a standard format specifically so tools like ours can use it. We're just reading what they intended to share.

This is the same philosophy we take with Robin: we're clear about what it reads and what it doesn't. We'd rather give you a reliable tool with known boundaries than promise magic and deliver guesswork.

If you've found a recipe site that should work but doesn't, the Feedback button goes to a person, and the link that failed is the useful thing to send. On a phone it sits under More, and on a computer or tablet at the bottom of the left sidebar.