Why your restaurant is not showing in Swiggy search
Swiggy publishes more about how it ranks restaurants than any other platform restaurant operators deal with, and the detail comes from two unusual places: its own engineering blog and its regulatory filings as a listed company. Its ranking team has written that “no one algorithm wins across all cities” and that this is why different rankers go to production in different cities. That single sentence reframes the question. There is no Swiggy ranking to be missing from, there is a ranking in your city, and it may not be the same one running two states away.
What does Swiggy publish about how its restaurant feed is ranked?
Swiggy names the surface first. Its engineering team writes that “For the vast majority of our customers, exploring food options on Swiggy starts at what we call the Listing page”, and that the team’s core aim is to “present our current customers with the most relevant feed of restaurants and help with discovery for our potential customers.” That is the object a restaurant is competing inside, and Swiggy calls it the Listing page rather than search.
On the mechanism, an earlier generation of the ranker is described plainly: “our utility is a function of 3 attributes: a customer preference score, a restaurant similarity score, and a restaurant (popularity) score”, and “For a given restaurant-customer tuple, the above score is what ranks the list of restaurants the customer sees.” Swiggy adds that the score is then modified further “to, for example, reflect real-time conditions (like SLAs, whether the systems are under stress due to inclement weather, etc.), and/or add additional constraints like diversity.”
Does the Swiggy feed differ from one city to the next?
Swiggy says it does, and says why. Describing how competing rankers are evaluated, its team writes that “no one algorithm wins across all cities”, and that the evaluation setup “helps us roll to production whatever works best in a given city.” Swiggy also keeps a control group, holding out “a small fraction of traffic where the feed ranking is solely based on the popularity of restaurants (baseline).”
For a chain operating in several Indian cities, this is the most consequential thing on the page. A visibility playbook that worked in one city has no guaranteed transfer to another, because the ranking that produced the result may not be running there. It also means a brand-level Swiggy visibility report, averaged across cities, is averaging over different systems. Reading such an average and concluding anything about a specific city is a category error, and it is one that gets made in almost every national review deck.
Which restaurant attributes does Swiggy name as ranking features?
Several, and it names them in the context of dish search rather than the feed, which is a distinction worth keeping. Describing the inputs to its dish ranking model, Swiggy lists “Restaurant Input: Concatenation of restaurant embedding, average of restaurant cuisine embeddings and features like rating, preparation time, cost for two and SLA”, alongside “Popularity Input” built from daily and monthly orders and “Distance-Time input” built from “normalized last-mile distance and max delivery time”.
Swiggy also explains the reasoning behind the distance term: “One of the most important factors which a user will consider when ordering food is the delivery time. In general, restaurants nearer to a customer’s location are more preferred compared to the ones that are farther.” So rating and preparation time are named as model features by Swiggy itself, which is a much stronger footing than the same claim would have anywhere else on this list. It is still a statement about one model on one surface, not a universal weight, and it should be quoted as what it is.
Is the Swiggy feed personalised for each customer?
Explicitly so. Swiggy’s ranking team writes that it is “building Deep Learning models for a personalized ranking of restaurants”, and defines relevance in per-session terms: “a restaurant is ‘relevant’ if a customer would order from it in a given session.” It goes further on memory: “we want the output prediction to be higher for a restaurant that was recently ordered from, by the customer”, and notes that “Memorizing individual preferences is important because customers expect a healthy balance of reordering from their favorite restaurants, and exploring new ones.”
Swiggy also states that relevance is not the only objective. “While relevance is the primary objective of all our ranking models, we also care about other important business objectives like delivery experience”, with the worked example that “A faraway restaurant may be very relevant for a customer, however recommending it may have a negative impact on the delivery experience.” A restaurant can therefore be highly relevant to a customer and still be held back, and that trade-off is Swiggy’s decision, not a signal about the restaurant.
What are Swiggy’s paid placements called and how are they billed?
The customer sees the word “Promoted”. Swiggy’s engineering blog labels an illustration of its ad placements “Promoted restaurant on Swiggy Food Page and Promoted Brands on Instamart Page”, and names the product: “Swiggy Ads platform supports ads of restaurant partners and various FMCG/non-FMCG brand partners across its different business verticals (Food, Instamart, Meat).”
The billing is stated in Swiggy’s regulatory filing rather than in marketing material, which makes it about as reliable as such a statement gets: “Advertisement revenue is generated from the sponsored listing fees paid by partner merchants and brands. Advertisement revenue is recognized when a consumer engages with the sponsored listing based on the number of clicks. There are certain contracts, where, in addition to the clicks, the Group sells online advertisements which are usually run over a contracted period of time.” Swiggy’s annual report adds scale, describing “a self-serve tool now used by over 65% of transacting restaurant partners”. A majority of transacting partners buying placement is the competitive context every unsponsored listing sits in.
Does being unserviceable remove a restaurant from Swiggy entirely?
On the advertising path Swiggy states the gate directly: “When a customer logs into the app, the ranking algorithm provides a ‘relevance score’ for each of the ad partners which are serviceable to the customer. These relevance scores are then used to rank the restaurants.” Serviceability comes first, ranking second, and a restaurant that is not serviceable to that customer never reaches the scoring step at all.
Swiggy also describes what its ads system counts as failure: “Reward is defined as +1 when a user clicks on a restaurant and 0 if the restaurant made an impression and did not receive a click.” A listing that appears and is not clicked is training data arguing against itself. That is the strongest available argument for keeping a Swiggy card in good order, and it is a rare case where a platform has written down the loop rather than leaving operators to guess at it.
What can a Swiggy operator measure against all this?
The city, the point, the hour, and whether the cards above yours said “Promoted”. Swiggy has published enough that a chain can form real hypotheses rather than folk theories, and the honest use of that material is to test it locally rather than to assume it. Because Swiggy says the deployed ranker varies by city, the unit of analysis has to be the city, and a national average will hide exactly the variation Swiggy has told you to expect.
The published material also has a limit worth stating. Engineering posts describe systems at the time of writing, and a ranking team that experiments continuously will have moved on. What does not go stale is the position a customer sees at a given address on a given day. Kitchain (kitchain.co) records that position, per point and per platform, together with the competitor names above it, which is the only reading that stays true regardless of which ranker is live in that city. Our platform overview is at https://kitchain.co/aggregators/swiggy/.