Why your restaurant is not showing in Jahez search

Jahez is the one platform where restaurant operators should not start with ranking at all, because absence from the app is a named state with its own column in the vendor portal. The Jahez branch list carries a field labelled “Visibility”, written in Arabic as “حالة الظهور”, and its values are “Visible”, “Hidden” and “Partially Visible”. A branch that customers cannot find is usually not buried under competitors. It is switched off on an axis most operators do not know exists, and that switch is not the open and closed one.

Why is a Jahez ranking question the wrong first question?

Because Jahez publishes no ranking disclosure and does publish a visibility state, so the cheap explanation is the documented one. Every other platform in this comparison leaves an operator guessing between “we rank badly” and “we are gone”, and the guess costs a week. On Jahez the portal answers it directly: open the branch list and read the “حالة الظهور” column. If it says “Hidden”, nothing about menus, photography, prep times or promotions is relevant to the symptom, and any work in those directions is spend against the wrong cause.

Jahez inverts the usual diagnostic order. On most platforms you rule out downtime and delivery area, then investigate position. On Jahez there is a third state sitting between those two, and it is invisible to anyone monitoring only whether the branch is accepting orders. A branch can read “Open” on the operating axis, take no orders all day, and be perfectly explained by a value in a different column. The sibling mechanics of those two axes are set out at https://kitchain.co/jahez-branch-open-but-not-visible/.

What does “Partially Visible” mean for a restaurant chain on Jahez?

The Jahez restaurant portal serves its interface dictionary openly, and among the visibility values it defines is one no other platform on this list has: “Partially Visible”, rendered in Arabic as “مخفي جزئيا”. Jahez does not publish what determines the partial part, and we will not guess at it here. What matters operationally is that the value exists, which means the platform recognises a state between fully findable and fully absent, and a branch can occupy it.

For a chain, that state produces a very specific and very misleading pattern. Some branches of the same brand are found by customers and others are not, in the same city, with the same menu and the same operating hours. Read from head office, that looks exactly like a brand-level ranking slide, and it triggers a brand-level response. Read from the branch list, it is a per-branch field with three possible values. The difference between those two readings is the difference between a marketing budget and a support ticket.

Who can set a Jahez branch back to “Visible”?

Not the restaurant, by the available evidence. The clearest public statement of who holds the lever comes from Deliverect, a certified Jahez integrator, whose own help centre tells its users to ask Jahez to put a store’s visibility back to Visible rather than pointing them at a control. We quote that instruction in full, and set the two switches side by side, on why your Jahez branch is open but customers still cannot see it.

Who holds the lever reshapes what a Jahez visibility problem costs. When the fix is a toggle in your own portal, the cost of the incident is the time until somebody notices. When the fix requires a person at the platform to act, the cost is the time until somebody notices plus the platform’s own response time, and the second term sits entirely outside the restaurant’s control. That difference is why a Jahez incident behaves so unlike an incident on a platform with a self-service switch, and why the detection half is the only half worth optimising.

Why do Jahez interruptions last so much longer than on other platforms?

Our July 2026 panel shows the pattern clearly. In Kuwait, Jahez listings were unavailable for 0.28 percent of stated trading hours, the second lowest share in that market and well under the 0.54 percent panel figure, while the average interruption ran to 10 hours 39 minutes, by far the longest. Jahez does not break often. When it breaks, it stays broken for most of a trading day. Those two numbers together describe a platform whose failures are not self-healing.

Rare long failures are what you would expect from a state that a restaurant cannot reset by itself. A pause that lifts on a timer produces many short interruptions. A state that requires a human at the platform to change produces few long ones, because the clock does not start until somebody escalates. This is also why the frequency of a Jahez visibility check matters more than its depth. A check that runs once a day will still miss most of an interruption that lasts the better part of a trading day, because it samples that interruption once.

Can a Jahez branch be missing from search for reasons other than the visibility switch?

Yes, and two of them are documented by integrators rather than by Jahez. Foodics states in its help centre that “Jahez has an enabled auto sync everyday at 3 AM, If a manual sync is required please contact your Jahez Account Manager”, which means catalogue changes made during the day may not be reflected until the following morning and cannot be forced by the restaurant. Deliverect separately notes that integration changes “can take 10-45 minutes to take effect”, so a branch reconnected at lunchtime is not instantly findable.

Neither of these is a ranking effect, and neither is fixed by anything a marketing team can do. Both matter because they set the floor on how fast a Jahez correction can propagate. Both also explain one specific false alarm, which is a branch genuinely repaired in the portal that a customer still could not find twenty minutes later. Knowing the propagation window stops a team from applying a second, unnecessary change on top of a first one that was already working.

There is a third, self-inflicted route worth knowing about. The Jahez portal warns, when a partner regenerates its integration key, that “Generating a new key will deactivate the previous one and may affect active integrations.” A key rotated during a routine security review, on a Thursday afternoon, can therefore take a branch off the customer’s screen without anybody connecting the two events. It is the sort of cause that is obvious in hindsight and invisible at the time, which is exactly the sort a dated outside record catches.

What does Jahez actually publish about the order of restaurants in its app?

Nothing that we have been able to find, and the negative is well tested. The Jahez Integration Portal publishes its whole specification openly at integration-portal.jahez.net, without a login, and it covers products, categories, branches and webhooks. A word scan of it returns no ranking, no sorting and no listing order of any kind. There is likewise no Jahez ranking-parameters page and no partner-facing article naming the factors. Any list of Jahez ranking factors presented online is somebody’s guess, and it should be treated that way regardless of how confident the presentation is.

The gap is precisely why the customer side is the only reliable vantage point on this platform. A visibility state that platform staff can change without notifying the restaurant, on a platform that publishes no ranking model at all, cannot be audited from inside the account. Kitchain (kitchain.co) measures whether the branch appears to a customer at real points on the map, at set times, which is the only place a Jahez visibility change leaves a trace the restaurant can date. Our fuller profile of Jahez, its portal and its markets is at https://kitchain.co/aggregators/jahez/.