Munchable has a hand-written recipe library: 38 recipes, each checked against seven gut conditions by the same rules engine that runs on a barcode in the app. Every recipe is a public page. Every page ranks for its own long tail.
The obvious next move, and the one every programmatic SEO guide would tell you to make, is seven collection pages: low FODMAP recipes, reflux recipes, lactose free recipes, and so on. Seven head terms, seven internal hubs, seven URLs built from data we already have.
We did not build them. The reason is a distribution, and I think it generalises.
Here is what the seven lists would have contained. 37 of the 38 recipes suit low FODMAP. 30 suit reflux. The thinnest condition still has 30.
Those are not seven collections. They are one collection, printed seven times with a different heading, with most pages sharing over 80 percent of their items with every sibling. Google is quite good at noticing that, and the outcome is not seven ranking pages, it is a set of near-duplicates splitting the same internal link equity and spending crawl budget re-reading lists it has already seen.
Does this list diverge from its siblings enough that a reader who has seen one would learn something from the second?
At 37 out of 38, no. The comment in the index page records the condition for revisiting it:
That is a real plan rather than a no. When the library is 300 recipes and low FODMAP holds 210 of them while gastroparesis holds 60, the pages are different pages and they get built.
So the recipe index is grouped by meal: breakfast, lunch, dinner, snack. A recipe can carry more than one meal type, but a breakfast list and a dinner list genuinely differ, which is the whole property the condition lists lacked.
The condition-shaped linking still happens, just not through seven thin hubs. Each of the seven condition guides links to the recipes it clears, and each recipe page links back to the guides it suits. The hub already existed and already ranks for the head term; it did not need a near-copy of itself.
Every recipe page has a "Who this suits" block. Nobody types those lines. Each page is built by running the production engine against the recipe, once per condition:
toProduct(recipe) converts a recipe into the same shape a scanned product has, so the recipe goes through the same code path as a jar of pasta sauce. There is no second "recipe checker" that can disagree with the scanner. The engine is a package that both the marketing site and the mobile app import, so a recipe cannot say one thing on the web and another thing on somebody's phone.
sensitivity: 'high' is the more interesting decision. Lactose sensitivity is a user setting, and a public page has no user. We read the claim at the strictest setting the app offers, so the published line can never be softer than the answer the app would give the person who acts on it. A page that says "suits lactose intolerance" to a visitor whose app would later say "caution" is worse than no page.
The app filters the recipe library to the reader's profile and then shows no verdicts at all. The web pages label everything. That asymmetry was deliberate, and the comment that explains it is the part of this I would most want to keep:
In the app a reader has a profile, so the library is filtered for them and a verdict on top of that would be the app arguing with a decision it already made. A web visitor has no profile: "suits a low FODMAP pattern" is an index label rather than a judgement about them, and it is also the thing they searched for.
Same data, same engine, opposite presentation, because the reader's context is different. It is worth asking of any shared component whether the thing you are reusing is the data or the interface.
With 37 of 38 recipes clearing low FODMAP, most recipes suit six or seven conditions, and enumerating them produces a card that is five lines of condition names and no recipe. So the line is generated by rule:
Inverting near misses is the good bit. "Every condition except gastroparesis" is shorter than naming the other six and more useful, because the exception is exactly what a reader with gastroparesis is scanning for.