Judge a restaurant website change by whether more guests complete the task it was meant to help them finish. If you change the ordering button, measure completed orders among the people who had a reasonable chance to use it—not just button clicks. Then check whether the change caused errors or made the task harder for some guests.
Choose those measures before the change goes live. A short written plan keeps a busy shift, a promotion, or an attractive-looking traffic spike from turning into the wrong decision. You do not need to measure every part of your site; you need a clear answer about one change.
Define one guest task and its outcome
Start with a sentence: “We are changing the menu page’s order button so more guests who visit that page complete an order.” The guest task is ordering. The change is the button. The desired outcome is a completed order, not a visit to the checkout page.
Pick one primary measure that matches that sentence. For this example, use completed orders divided by eligible visits to the menu page. An eligible visit is a visit that reaches the page while ordering is available and is not an internal staff or practice visit. Decide how the analytics system identifies a visit and applies those exclusions before comparing results.
Other tasks need different outcomes. For a reservation change, the outcome might be a confirmed reservation divided by eligible visits to the reservation page. For a directions change, an owner might measure clicks to directions, but that is only a request for directions—not proof that someone arrived at the restaurant. Choose the strongest observable outcome you can measure without pretending it proves more than it does.
Write down both parts of the rate. “More orders” can simply mean more traffic. A higher completion rate means a larger share of the measured visits ended in an order, although it still does not prove the change caused the difference. Also decide whether repeat visits from one person count separately. If the tool cannot reliably identify people across visits or devices, report visits rather than calling them unique guests.
The owner should supply the business goal and decide which guest task matters. A manager can flag service hours, menu changes, and promotions that may affect the comparison. Whoever manages the website or analytics should explain how visits and completions are counted, including whether a guest moves to a separate ordering page. The ordering provider should confirm what records a completed order and whether the measurement can follow the guest across that handoff.
If the records cannot be joined reliably, do not quietly divide one unrelated count by another. Ask whether a shared visit identifier or another consistent method is available. Otherwise, use a narrower measure, such as clicks from the menu to ordering, and label it as a step toward an order rather than a completed order.
Set error and accessibility guardrails
A higher completion rate is useful only if the experience remains workable. Before launch, list the problems that would stop you from keeping the change. For an order-button test, guardrails could include a broken link, a guest being sent to the wrong ordering location, or a keyboard user being unable to reach or activate the button.
Check the path on a phone and a larger screen. Can a guest find the button, read its label, and understand what happens next? Can they move through the page with a keyboard and see which control has focus? Ask someone familiar with screen-reader use to check whether the button has a meaningful name. These practical checks help find barriers; they are not a certification of accessibility.
Use a safe practice environment for simulated checks. A simulated order must not take a real card payment, send a guest message, or dispatch a courier. If the system cannot prevent those actions, stop the simulation before the triggering step and ask the provider for a safe way to check the rest. A live service pilot is different: real guests may place real orders, so staff need to monitor the normal order flow and know how to revert the change.
Track errors as counts and, where possible, as rates with a clear denominator. For example, compare ordering-link errors per eligible menu-page visit, not an error count from one busy day against a count from a quiet day. Ask the provider what the error log actually captures. A drop in recorded errors may mean the tracking changed, rather than the experience improved.
Set an action rule in advance. A broken ordering link or a newly blocked keyboard path should trigger a fix or rollback regardless of the conversion result. For less severe issues, decide who will review them and how quickly. A faster path for some guests is not a good trade if others cannot use it.
Compare groups without confusing traffic with the change
If your tools support it, compare a control version and a changed version at the same time. Assign eligible visits randomly, keep the assignment consistent where the tool allows, and send each version a similar mix of traffic. Ask how the system handles repeat visits and guests who switch devices. Avoid changing the menu, price, or checkout process for only one group during the test.
If you cannot run a randomized comparison, compare similar periods before and after the change. Match days of the week, ordering hours, and promotion conditions as closely as practical. Record holidays, weather disruptions, local events, advertising changes, and outages. These comparisons are easier to run but more exposed to outside influences.
Consider this hypothetical plan for a menu-page order button. The restaurant uses concurrent groups, with the same ordering hours and offer for both. Each eligible visit is counted once in its assigned group; the ordering system records completed orders. The table shows the primary outcome and two guardrails.
| Measure | Current button | Changed button | How to read it |
|---|---|---|---|
| Completed orders / eligible visits | 80 / 400 = 20% | 100 / 400 = 25% | Five percentage points higher for the changed button. |
| Recorded link errors / eligible visits | 4 / 400 = 1% | 12 / 400 = 3% | Errors also rose; investigate before keeping the change. |
| Keyboard path | Button reached and activated in a simulated check | Button not reachable in a simulated check | The changed version fails the stated stop rule. |
The changed button has 20 more completed orders in these measured visits, but it also has eight more recorded link errors and fails the keyboard check. Under the stated rule, the owner should fix or roll back the change rather than keep it on the strength of the order rate. The simulated keyboard check is separate from the live order counts and must not trigger a real order.
Even if the guardrails had passed, 400 visits per group would not by itself establish that the change caused the difference or that the result will hold next month. Random variation and measurement problems remain possible. If results are close, gather more comparable data rather than treating the higher number as a guaranteed winner.
Make and record the decision
Before starting, write down the version being changed, eligible population, primary outcome, guardrails, comparison method, planned test period, and person responsible for the decision. Set the period around normal operating patterns, including the days that matter to the restaurant. Avoid repeatedly stopping the test as soon as a favorable number appears.
At the end, record the numerator and denominator for each group or period, not just the percentages. Note missing data, tracking changes, unexpected closures, and any difference in promotions. Review mobile and desktop results where the counts are large enough to be useful, but avoid declaring a winner from a handful of visits in one subgroup.
Use three decision labels: keep, revise and retest, or revert. Keep a change when the primary result is convincingly useful for the restaurant, the measurement is trustworthy, and the guardrails pass. Revise and retest when the direction looks promising but an error, accessibility barrier, or measurement gap needs attention. Revert when a stop rule is breached and the problem cannot be corrected promptly.
Also record what the test did not answer. An order-completion rate does not measure whether orders were profitable, whether guests enjoyed their meals, or whether they returned. If a provider charges for a change, ask for a written quote and compare the operating cost with the benefit you can reasonably observe; do not treat extra orders as pure profit.
For a broader buying decision, use the restaurant website builder comparison alongside these task measures. Ask how a restaurant website connects to online ordering, who can edit the button, and what completion and error data you can access.
Next step: Use the checklist above on one current guest task, then ask Fleksa about its website setup and verified US availability. Bring your proposed outcome, denominator, guardrails, and questions about the ordering handoff.
Frequently asked questions
Should I measure clicks or completed orders?
Use completed orders when ordering is the task and you can measure the handoff reliably. Button clicks are useful as a supporting step, but they do not show that an order was completed.
How long should a restaurant website test run?
Plan around comparable operating days and expected traffic. A quiet site may need more time to produce a useful comparison. If conditions change or counts remain small, document the uncertainty rather than forcing a decision from a fixed deadline.
What if the new version converts better but causes errors?
Follow the guardrail you set before launch. Investigate and fix the errors, or revert if a stop rule is breached. Retest the corrected version before assuming the higher conversion rate is worth keeping.
