For most restaurants with a reasonably stable menu and a reliable way to update their website, showing prices is the more useful choice. Guests can decide whether a meal fits their budget before they call or visit. The decision gets harder when your team cannot keep the site current or when the price shown online differs from the price a guest pays through an ordering channel.
Start with a simple question: can someone on your team check and change published prices whenever the menu changes? If the answer is no, fix that process before adding a full priced menu. An informational site does not need to take orders, but guests can still reasonably expect its menu to reflect what they will find at the restaurant.
Assess guest needs and your ability to update
Think about how people use your site. A family choosing a place for dinner may want to estimate the cost before leaving home. A diner planning a work lunch may need to compare options quickly. Someone looking at a catering menu may need enough detail to know whether to request a quote. A menu without prices leaves each of them with another step.
Ask your front-of-house team what callers and walk-ins commonly ask. Does the team spend time reading prices over the phone? Are guests surprised by the bill? Those observations can help you decide where published prices would be most useful. You do not need to publish every possible custom order to make the main menu more helpful.
Then check your update capacity. The owner or manager can identify how often the regular menu changes and who approves the new prices. The person responsible for the website can explain how edits are made, how long they take, and whether the restaurant controls the login. If an outside provider makes changes, ask about turnaround times, charges, and what happens when the usual contact is unavailable.
Look at the format as well. A downloadable menu may be easy to create, but a replacement file still needs to be uploaded and checked on a phone. A web page with editable menu items may be easier to revise item by item; confirm that in the system you actually use. For either format, a clear menu label and readable prices matter more than the format alone.
A partial menu can be a reasonable middle ground. You might publish the regular food and drink list with prices while asking guests to contact you for custom catering. Make the boundary clear so visitors know which items are priced and where to get details for the rest. A general statement such as “prices subject to change” should not replace a working update process.
Compare informational and ordering prices
Before publishing, list every place a guest can see a price: the informational website, a direct ordering page, any third-party ordering pages, and the menu used in the restaurant. They may be managed by different people or systems. Decide which price belongs in each place and how a guest will understand any difference.
Hypothetical example: A restaurant lists a sandwich for $14 on its informational site and sells that same standard sandwich for $16 on an ordering channel. The $2 difference is the difference between the two listed item prices, not a calculation of profit or the guest's final total. The comparison excludes optional additions, taxes, delivery charges, and other possible checkout fees. It is not an estimate of the restaurant's fixed costs, variable costs, or exception costs.
If the informational site is meant to show the dine-in price, label it accordingly and direct guests to the relevant ordering page for ordering prices and the final checkout total. Check whether the two listings describe the same portion and included sides before treating them as equivalent. A visitor who sees $14 on one page and $16 on another without context may assume one of them is wrong.
If you use online ordering, ask whether its menu and the informational menu are managed together or edited separately. Do not assume that changing one updates the other. Also ask how modifiers, unavailable items, and channel-specific prices appear to guests. If the systems are separate, include both in the update checklist.
Be careful with ranges and starting prices. “From” can help when a dish has genuinely different sizes or additions, but tell guests what the starting price buys. For a custom package, explain what is included in the quoted price rather than placing an unexplained number next to the name.
Use a menu price publication decision matrix
The matrix below turns the main trade-off into an action. Start with the row that best describes your current setup, then confirm who will maintain it. These are decision guides, not promises that one format will suit every restaurant.
| Current situation | Practical choice | Check before publishing |
|---|---|---|
| Regular menu is stable; staff can edit the site | Publish item prices for the regular menu | Assign an owner and check the live page after each change |
| Regular menu is stable; website changes require an outside provider | Publish prices if update turnaround is dependable | Agree on the request method, cost, backup contact, and timing |
| Some offerings are standard; others are custom | Price the standard items and explain how to request a custom quote | Clearly separate priced items from quote-only offerings |
| Prices cannot currently be kept accurate | Resolve access and ownership first; consider an unpriced menu in the meantime | Give guests a way to ask for current prices and set a date to revisit |
The last row is a temporary operating choice, not an instruction to hide prices indefinitely. If guests must call, give them a working phone number and make sure the team answering has the current menu. Revisit the decision once someone can reliably edit the site or arrange timely changes.
When evaluating a restaurant website builder comparison, focus on that operating job. Can a staff member find and edit the menu without rebuilding the page? Can they preview changes on mobile? What happens to an older menu file or a link saved by a guest? Ask for a demonstration using a representative menu, rather than judging only the initial design.
Assign ownership and rehearse a change
Give each part of the process a named owner, even if one person handles several roles. The manager approves the item and price. The website editor makes the change. A second person, or the editor using a separate check, compares the live page with the approved menu. Front-of-house staff receive the update so they can answer questions consistently.
Write down the trigger: a menu change is not complete when a new price is approved; it is complete when the relevant guest-facing menus have been checked. Keep a short record of the approved change, the pages or files affected, the person responsible, and the date checked. Include the restaurant's ordering channels in that list when they need a separate edit.
Practice before relying on the process. In a preview or other nonpublic version, have the assigned editor change a sample item, then have a colleague check the name, price, description, and mobile display against an approved sample. Confirm that the editor knows how to undo the practice change. This is a simulated check: it should not create a real payment, send a guest message, or dispatch a courier.
A successful practice check shows that the people involved can handle that sample in the practice environment. It does not prove that an outside provider will meet a future deadline or that every live menu is current. For a live change, follow the normal approval process and inspect the actual guest-facing pages after publication.
Access is part of ownership. Make sure more than one authorized person knows how to reach the website provider or account, without sharing credentials in an insecure way. Review who controls the domain as well; the domain ownership guide covers questions to ask before a provider relationship changes.
Review disclosures and take the next step
Menu presentation can raise questions beyond the update workflow. Ask qualified counsel what disclosures or pricing rules apply to your restaurant, location, and sales channels. Bring examples of the actual pages, including dine-in prices, ordering prices, starting prices, fees, and any statements about changes. Ask where a disclosure needs to appear and whether a proposed label is clear for the way you sell.
Separately, ask your website or ordering provider for an operational quote for any setup, edits, or ongoing service you need. Identify what the quote includes and what could be charged separately. Your adviser can help with contract or tax questions; the provider should explain the practical process for getting a price change onto the site.
Next, choose a row in the matrix and walk through one menu change with the person who would own it. If you are reviewing a new restaurant website, ask Fleksa about availability in the US, menu editing, and how the site would connect to your existing ordering setup.
Frequently asked questions
Should an informational restaurant website include prices?
Usually, yes, if the restaurant can keep them accurate. If editing access or turnaround is unreliable, address that first and give guests a clear way to request current prices.
What if ordering prices differ from dine-in prices?
Label the prices by context and direct guests to the relevant ordering page for its current prices and checkout total. Check that the items being compared have the same portions and included sides.
Who should update menu prices on the website?
Assign an editor and an approver, plus someone to check the live result. If a provider makes edits, agree on a request process, turnaround, and backup contact.
