June 9, 2026 · 8 min read · Data

Why Michelin tier dominates restaurant ranking, and the cities where it matters.

A 4.5-star unrated diner is not a credible answer to "best restaurants in Paris." A one-star Michelin bistro almost always is. Our /v1/restaurants endpoint encodes this preference directly: Michelin tier first, rating second. Here's the rationale and the cities where it changes everything.

The ordering, made explicit

Restaurant ranking on /v1/restaurants applies the following primary sort, ties broken by user rating:

  1. 3 Stars (worth a special journey)
  2. 2 Stars (worth a detour)
  3. 1 Star (a very good restaurant in its category)
  4. Bib Gourmand (good quality, good value)
  5. Selected (Michelin Guide listing without a star)
  6. No Michelin presence — fall back to crowdsourced rating

The reason is simple: Michelin is one of the few global signals that's editorially curated, doesn't decay quickly, and is independent of how Instagrammable a venue is. A four-and-a-half star burger joint in a tourist district might be excellent. It might also have 8,000 reviews from people who eat one meal in the city and rate everything five stars. The Michelin selectors visited anonymously, paid for their meal, and are not optimizing for engagement.

Where Michelin coverage is dense

Michelin coverage is geographically uneven. Roughly:

Where Michelin doesn't exist

For most of the world, Michelin tier is null and the ranking falls through to user rating. The Guide simply doesn't operate in:

In these regions, your AI travel agent has to lean on rating, review volume, cuisine signals, and editorial provenance. The API still returns a coherent ordering — it just can't lead with stars.

What a top-8 query looks like in London

GET /v1/restaurants?city_id=london&limit=8

[
  { "name": "Restaurant Gordon Ramsay",   "tier": "3 Stars",      "neighborhood": "Chelsea" },
  { "name": "The Ledbury",                "tier": "3 Stars",      "neighborhood": "Notting Hill" },
  { "name": "Hélène Darroze at Connaught","tier": "3 Stars",      "neighborhood": "Mayfair" },
  { "name": "CORE by Clare Smyth",        "tier": "3 Stars",      "neighborhood": "Notting Hill" },
  { "name": "Alain Ducasse at Dorchester","tier": "3 Stars",      "neighborhood": "Mayfair" },
  { "name": "Sketch (Lecture Room)",      "tier": "3 Stars",      "neighborhood": "Mayfair" },
  { "name": "Story",                      "tier": "3 Stars",      "neighborhood": "Bermondsey" },
  { "name": "Da Terra",                   "tier": "2 Stars",      "neighborhood": "Bethnal Green" }
]

The same query in Tokyo skews even higher — there are enough 3-star venues to fill a top-8 with room to spare. In Bangkok it's a healthy mix of 1- and 2-star plus a couple of Bib Gourmand surprises. In São Paulo the top is one or two starred venues followed immediately by the highest-rated rated-only entries.

Why we don't blend the two signals

A common engineering instinct is to combine Michelin and rating into a weighted score. We tried it. It produces results that feel arbitrary: a 4.6-star unrated venue can leapfrog a Bib Gourmand, which is wrong if your user is asking the canonical "where should I eat" question. The strict tier-first ordering loses some local color but is reliably correct for the question travel apps actually answer.

If you want a more democratic ranking — say, for a city listicle — call /v1/restaurants with sort=rating instead. The Michelin field is still on every row, so you can re-rank client-side however you want.

Sign up — free See India coverage →