Direct Ordering or Marketplace Listings: What Belongs on Your Own Site

Your own site and a marketplace listing do different jobs, and the fastest way to waste both is to make the site a worse copy of the listing. A marketplace is built to sell one meal to one guest right now, with discovery, payment and a driver attached. A website is built for everything with a longer lead time or a conversation in it: catering, large orders, tenant and wholesale inquiries, the brand story, and the guest who already knows the name and typed it into a search bar. Most kitchens end up running both, which is the correct answer. What decides whether that works is how clearly the page separates the two paths.

What the website does better than a marketplace listing

The website is better at everything a listing template cannot hold: the reason the concept exists, an order too large for a delivery bag, and any inquiry that needs a person to answer it.

The brand story and the reason the concept exists

A marketplace listing gives a brand a name, a photograph and a menu, in a layout identical to every competitor on the same screen. There is no room to say that the birria recipe came from a family kitchen, that the wings are fried to order rather than held, or that the brand runs out of a commissary shared with three other concepts. Those details do not fit a listing and they are exactly what makes a guest choose one brand over the near identical one below it.

That story is also what a guest searches for later. Someone who liked the food and remembers the name types the name, not the platform. If the only thing that address returns is a marketplace listing surrounded by competitors, the brand handed a warm lead back to the feed.

Catering and large orders

A marketplace listing cannot take a catering order, and trying to force one through it wastes both sides time. A large order needs a lead time, a headcount, a delivery window, a contact, an invoice and usually a conversation about whether the kitchen can hold that volume alongside its normal ticket flow on that shift.

That is a form and a phone number, not a checkout. It also tends to be the highest value inquiry a kitchen receives all week, which makes it worth its own page rather than a line buried under the delivery links. A catering block that states lead time, minimum headcount and what the kitchen can actually produce at volume filters out the inquiries that were never going to work and gives the serious ones enough confidence to submit.

Tenant, wholesale and facility inquiries

Commissary and production kitchens receive a category of inquiry that has nothing to do with meals: a caterer looking for station time, a food truck needing a licensed prep base, a small brand wanting production capacity, a retailer asking about wholesale volume. None of that exists on a delivery platform in any form.

These inquiries are slow, high value and easy to lose. They need a page that says what the facility offers, what the access terms look like in general shape, and who to contact. Routing them to the same inbox that receives order complaints is how they get buried under a Friday night ticket problem.

Repeat guests and the menu narrative

The website is where a kitchen controls the order of the menu, the wording of the descriptions and what gets emphasized. A marketplace sorts by its own logic and applies its own layout. On a brand page, the item the kitchen actually wants to sell can lead, the items that travel best can be grouped, and a description can explain heat level, portion and format in the kitchen own words rather than in a truncated field.

That control matters most for the items that generate support messages. Every question a guest asks about portion size or spice level is a description that failed, and on the website that description can be fixed in minutes.

What the marketplace does better

The marketplace owns discovery, delivery logistics and payment, and those are genuinely hard problems that a website should not try to solve from scratch.

Discovery is the big one. A delivery app is where a hungry guest with no particular brand in mind goes to browse, and a new virtual brand with no audience gets found there long before anyone searches its name. A listing arrives with an existing audience, an existing review mechanism and existing ranking behavior. A new website arrives with none of that.

Delivery logistics is the second. Dispatch, driver assignment, live tracking, the support path when an order goes wrong and the reassignment when a driver cancels are an operational system, not a feature. Kitchens that try to run their own delivery usually discover that the hard part is not the first delivery, it is the one on a Friday night when a driver does not show.

Payment and dispute handling is the third. Card processing, refunds, chargebacks and fraud handling are absorbed by the platform. A direct ordering setup moves some of that back onto the operator, which is a real operational change rather than a settings toggle.

Why “both” is the normal answer

Most kitchens run both because the two surfaces feed each other: the marketplace generates first orders, the website converts the guests who remember the name into catering, repeat and direct business.

The layout problem that follows is real. A page that tries to serve both paths equally often serves neither, because the everyday guest wanting dinner and the office manager planning a lunch for a whole floor are looking for opposite things on the same screen.

The workable pattern is one primary path and one clearly marked alternative, both reachable without scrolling on a phone. The ordering path leads, because it is what most visitors want. The catering and inquiry path sits immediately beside or below it as a distinct block with its own label, not as a link in the footer.

Job to be done: own site or marketplace

Job to be done	Own site	Marketplace listing
Guest browsing for dinner with no brand in mind	Weak, there is nothing to browse	Strong, this is what the app is for
Guest who already knows the brand name	Strong, the name should land somewhere you control	Weak, lands beside competitors
Explaining the concept and who cooks it	Strong, unlimited room	Weak, a short blurb field
Catering and large orders with lead time	Strong, form plus phone plus stated terms	Not supported in any useful form
Tenant, wholesale or facility inquiries	Strong, this is the only surface for it	Not supported
Delivery dispatch, tracking and driver support	Weak, an operational system to build	Strong, included
Payment, refunds and chargebacks	Adds operational load to the kitchen	Strong, absorbed by the platform
Controlling the order and wording of the menu	Strong, full control	Weak, the platform sets the layout
Presenting several brands from one facility	Strong, one hub plus a page per brand	Weak, each listing is isolated
Capturing a guest you can contact again	Possible with a direct path	Generally not, the guest belongs to the platform

The table is also a page plan. Anything in the left column that reads “strong” deserves visible space on the site. Anything in the right column that reads “strong” deserves a clear, tested outbound link and nothing more.

Menu drift, and how to prevent it

Menu drift is the most common quiet failure on a kitchen website, and it happens because price changes get made during a shift on whichever surface is in front of somebody.

The sequence is always the same. A cost goes up, so the price is corrected on the busiest platform on a Tuesday. The second platform gets updated the following week. The third is forgotten. The website, which nobody has opened in two months, still shows the original price. Now four surfaces disagree, and the guest who notices is holding a screenshot.

The procedure

1. Name one source of truth and write down where it lives. A single menu document, owned by one person, with prices, descriptions, modifiers and availability. Not a design file, not a printed sheet, not a platform dashboard.
2. Give it an owner. One named person approves a menu change. Without that, every surface accumulates its own version of the truth.
3. Set a cadence for pushing changes to every surface. Whether that is weekly or monthly matters less than it being fixed, because an ad hoc cadence means the surface nobody uses daily never gets updated.
4. Audit item by item. Open the website menu and each platform storefront side by side and compare name, price, description and availability. Record the date of the audit.
5. Fix the source first, then the surfaces. A correction made directly on a platform and not in the source document will be overwritten at the next push, which is how a fixed price silently reverts.
6. Note what is intentionally different. Some kitchens deliberately price differently across surfaces. That is a decision, not drift, and writing it down stops the next audit from “correcting” it.

Reduce the number of places the menu lives

The cheapest way to prevent drift is to have fewer copies. If the website menu can be a link to the ordering surface for the everyday items, with the site carrying only the catering menu and the brand narrative, then there is one fewer copy to keep in sync. That is a legitimate design choice and not a lazy one, particularly for a brand with a menu that changes weekly.

Where a full menu does live on the site, it should be structured content that one person can edit in place, not text baked into an image. A menu inside a graphic cannot be updated in five minutes, cannot be read by a search engine and cannot be read aloud by a screen reader.

When a platform changes a store URL

Ordering links break without warning, and nothing on the website announces it. A platform can reorganize its storefront addresses, a location can be re-onboarded under a new identifier, a brand can be renamed on one app and not another. The button on the site still looks correct. It now lands on a marketplace search page, and guests bounce there rather than hunting for the brand.

The mitigation is procedural. Keep the same grid a launch uses: rows for brands, columns for kitchens, cells for platforms, with the date each link was last verified. Re-test on a fixed schedule and after any change to a storefront, a brand name or a location.

On the website side, point buttons at the platform canonical storefront address rather than at a shortened or campaign tagged variant when there is a choice, because the short link is the layer most likely to be retired. Where the site itself uses redirects, for instance a friendly address that forwards to a long platform link, use a permanent redirect for a move that is permanent. Both MDN and Google Search Central document the distinction between permanent and temporary redirects, and Google treats a permanent redirect as the strong signal that a destination has moved for good.

If the same ordering page is reachable at more than one address on the site, for instance with and without a tracking parameter, a canonical tag tells search engines which version is the real one. Google Search Central covers that consolidation directly, and it is a small piece of housekeeping that prevents a brand competing with a duplicate of itself.

Presenting several platforms without a wall of buttons

Lead with one path, then present the rest compactly. A column of six identically sized buttons is a decision the guest has no basis for making, and hesitation costs more orders than any individual platform choice.

Choose a primary

Pick the primary path deliberately. That might be the direct ordering path where one exists, the platform that guests in the area already use, or the platform the kitchen has the best economics on. Give it the weight: a full width button, the clearest label, the first position.

Group the rest

Put the remaining platforms in a single compact row with a short line above them, something as plain as “also available on”. Small consistent buttons or wordmarks, one line, no competing colors. The guest who has a preferred app will find it, and the guest who does not will take the primary.

Group by kitchen before platform

When a brand is produced in more than one facility, the first choice a guest makes is location, not platform, because a guest can tell which address is nearer to them and cannot tell which storefront belongs to which kitchen. Label each group with the neighborhood or the area it serves rather than the internal facility name. The ghost kitchens page and the delivery platform page design page both go further into how those blocks get laid out when several brands and several kitchens are involved.

Say what the guest gets

A short line under the ordering block earns its space: delivery area, typical prep time in the kitchen own terms, and whether pickup is possible. If the facility is delivery only with no counter, say so plainly. Google Business Profile guidance draws the same line for profiles, distinguishing a business that serves customers at its address from a service-area business that delivers only, and a guest who drives to a commissary expecting a pickup window is a guest the page failed.

The direct ordering question

Direct ordering is worth wiring when guests already search for the brand by name, and it is premature when they do not.

Fees, described honestly

Marketplace ordering carries a commission on each order, and direct ordering does not carry that same commission but is not free either. There is a processing cost, usually a platform or tool cost, and the marketing cost of generating the demand that the marketplace was previously generating for you. The correct comparison is not commission against zero. It is commission against the total cost of getting the same guest to order without the marketplace. Run that comparison against your own numbers rather than against a published figure from someone else operation.

Who owns the guest

This is often the more important half of the decision. On a marketplace, the guest relationship generally belongs to the platform. The kitchen sees an order, not a person it can contact again. With a direct path, the kitchen holds the order history and the contact details, subject to whatever privacy obligations apply, which makes a repeat purchase something the kitchen can influence rather than wait for.

For a brand with a real following, that ownership compounds. For a brand nobody is searching for yet, it is ownership of an audience that does not exist. Sequence matters more than preference here.

What changes on the line

Direct orders arrive differently, and the line has to be ready for that before the button goes live. A direct order may print on a different device, may not carry the same modifier formatting, and may not be batched into the same flow the expediter uses for platform tickets. Delivery has to be solved, whether through a third party dispatch service or the kitchen own drivers. Support moves too: when a direct order goes wrong, the guest calls the kitchen, not a platform support queue, usually during service.

Test the whole path before launch, not just the link. Place a real order, confirm the ticket reaches the station in a form the line can read, confirm the modifiers survive, confirm the confirmation reaches the guest, and confirm somebody on shift knows what to do when the first one arrives.

A short decision procedure

For an operator deciding what the site should do this quarter:

1. Write down where orders actually come from today, by brand and by platform.
2. Write down every inquiry received in the last month that a marketplace could not have handled. Catering, wholesale, tenant, press, complaints.
3. Give the website the second list. That is what it is for.
4. Give the marketplace the first list, and make the links to it obvious, correct and recently tested.
5. Add a direct path only when there is name demand to convert, and only after the line has been walked through what a direct ticket does to the shift.
6. Put a date in the calendar for the menu audit and the link re-test. Both of them fail silently, which is exactly why they need a date.

The structural side of that, how many pages, how brands are separated and where the ordering blocks sit, is covered in more depth in the ghost kitchen website structure guide.

Where this stops being a website question

Platform agreements, commission terms, tax treatment, food safety, allergen disclosure and licensing are outside the scope of a website build, and nothing here should be read as advice on any of them. Which platforms a kitchen signs with and what those contracts contain is a decision for the operator and a qualified advisor. What a menu has to disclose belongs to the relevant state or local health authority. Where a page decision touches that territory, such as how an item is described or what an allergen note says, confirm the wording with the appropriate authority before it goes live.

The useful way to think about it is division of labor on a busy shift. The marketplace is the line: high volume, fast, standardized, very good at the thing it does all day. The website is the pass: it is where the order is checked, where the unusual ticket gets handled, where somebody can answer a question, and where the kitchen decides what leaves the building under its name. Neither one replaces the other, and a kitchen that staffs only one of them notices the gap on the first large order that does not fit a delivery bag. If you want the split walked through against your own brand list and platform mix, contact is the place to start.