Ask your provider for a private preview that you can open on your own phone and computer before the website goes public. Review it with the restaurant’s real menu, hours, contact details, and ordering or reservation paths in place. Record each problem by page and screen state, then retest the corrected version before approving publication.
The best preview method is one that lets the right people see enough of the site to make a decision without exposing the draft to guests. A password-protected link may work for a small review group; a provider-led screen share can help when access is restricted. Ask what each method lets you test before choosing.
Choose a private preview and control access
Start by asking the provider how you will view the draft. A link you can open independently gives you time to check pages on different devices and revisit them after service. A screen share is useful for walking through questions together, but it may not show how the site behaves on your own phone or connection. Screenshots can document a design, but they cannot replace a working preview for links, forms, and navigation.
Ask whether the preview is protected by a password or individual accounts, who can open it, and when access expires. If a shared password is used, agree on who receives it and how it will be changed or removed after review. Also ask whether the preview can appear in search results or be reached through a public link. Treat the address as private until the provider explains its protections.
Agree on the scope of the draft. Is it a complete copy of the intended site, or a design with some unfinished connections? A preview may show the menu correctly while an ordering button still points to a placeholder. That can be acceptable for an early design review, but it is not enough to approve the guest journey.
The owner or manager should supply the current menu, prices, hours, location, contact details, and any approved photos. The provider should explain how to access the draft, which parts work, and how to report changes. If another person manages ordering or reservations, give that person a defined review task rather than sending a link without context.
Ask these questions before the review starts:
- Can reviewers open the preview on their own devices without publishing it?
- What protects the preview, and can access be removed after review?
- Which pages and connections are ready to test, and which are placeholders?
- Will changes made in the preview carry over to the live site?
- How will the final version and intended publication time be confirmed?
If a provider offers only a screen share, request a separate device check or another way to inspect the working draft. Decide whether that limitation leaves any important guest action untested. You can also use a restaurant website builder comparison to frame questions about editing and control before choosing a provider.
Check real content and guest paths on two screens
Begin with a phone, where small text, crowded buttons, and long menus are easy to spot. Then check a desktop or laptop. Use the browser and devices your team has available; one phone and one computer will not represent every guest, but they will expose different layout problems.
Read the site as a guest would. Can you find today’s hours, the address, and the menu without knowing where the provider placed them? Check spelling, prices, item descriptions, and any stated dietary information against the restaurant’s approved material. Look for outdated holiday hours and photos that suggest items you no longer serve.
Open navigation links and buttons. On mobile, check whether text remains readable, buttons are easy to tap, and important content is visible without awkward sideways scrolling. On desktop, check whether wide layouts leave content stranded or hide the next action. Review more than the home page: a guest may arrive directly at the menu, contact page, or ordering page.
Hypothetical example: A neighborhood restaurant wants guests to see its dinner menu, place pickup orders, and find parking information. Its manager opens the preview on a phone and laptop. The menu is accurate on both, but the pickup button on the phone opens a placeholder. The parking note appears on the contact page, but the address is an old location. The manager records both issues rather than approving the site because the home page looks good.
For online ordering and reservations, ask the provider for a safe way to inspect the path. A simulated check can cover the button, destination, menu display, and form fields without completing a transaction. It must not charge a real card, send a guest message, or dispatch a courier. If a connection cannot be exercised safely in preview, record it as untested and agree on a separate live-service check after publication.
A live-service pilot is different from a simulation: it uses the published service and can affect real operations. Agree in advance on who runs it, what real actions it may trigger, and how staff will monitor them. Do not treat a preview click as proof that a live order or reservation will reach the right place.
Use a worksheet to record each page and state
Keep feedback in one shared list. Give each issue a location, the device and state in which it appeared, the expected result, and a status. “The site looks wrong” is hard to act on; “the pickup button opens a placeholder on the mobile menu page” gives the provider a starting point.
The worksheet below continues the hypothetical restaurant example. The first two rows show the initial findings; the third records a check that passed. A pass applies only to the device and state reviewed, not every possible configuration.
| Page and state | Device and finding | Expected result | Status |
|---|---|---|---|
| Menu; pickup button tapped | Phone; placeholder opens | Open the intended pickup ordering destination | Fix, then retest |
| Contact; address visible | Laptop; old address shown | Show the approved current address | Fix, then retest |
| Menu; dinner items displayed | Phone and laptop; details match approved menu | Show current items and prices | Passed on both devices |
Use one row per issue when different people may need to fix it. Add a screenshot to your shared records if the provider accepts attachments, but still write the page and action in words. Include the browser if relevant and note whether the issue happens every time or only under particular conditions.
Separate corrections from preferences. An incorrect address or a dead ordering link can stop a guest from reaching you or buying. A preferred photo crop may be worth changing, but it should not obscure an unresolved functional problem. Agree on which items must be fixed before publication and which can wait, with an owner and expected follow-up for each deferred item.
Keep a copy of the approved source material alongside the worksheet. If the menu changes during the review, mark which version the provider should use. That prevents a correct earlier draft from being mistaken for the current one.
Retest the corrected version before approval
When the provider says changes are ready, ask for the updated preview link or confirmation that the existing link now shows the new version. Reopen every fixed item on the device where it failed. For the hypothetical pickup button, that means tapping it again on the phone and checking its destination, not just reading a message that says it was fixed.
Then check nearby content and navigation. A change to a menu page can affect its spacing or move a button. If the address was corrected, look at any other page where the address appears. Mark a row passed only after the expected result appears; otherwise, return it to the provider with the new finding.
Before giving approval, review the remaining open items and decide explicitly whether each can wait. Confirm which version will be published, who will make it public, and when the owner expects to check the live site. Ask about access to the domain and future edits as well; the guide to restaurant website domain ownership covers questions worth settling with the provider.
After publication, open the public address on a phone and computer. Check the key pages and links again, because a private preview and a live site are different environments. Use the agreed live-service pilot for any ordering or reservation connection that could not be safely checked in preview, and have staff ready to monitor the outcome.
Use the worksheet on your current draft, then ask Fleksa how a private review would work for its restaurant website and whether the relevant setup is available in the US.
Frequently asked questions
Is a screenshot enough to approve a restaurant website?
A screenshot can help review a layout or document a problem, but it cannot show whether navigation, forms, and buttons work. Ask for a working preview or a way to check those actions separately.
Who should review the private preview?
The owner or manager should check business details and the overall guest experience. Ask whoever handles the menu, orders, or reservations to review the relevant pages and connections too.
Can I test an order before the site goes live?
Ask for a simulated path that does not charge a card, send a guest message, or dispatch a courier. If the full connection cannot be safely checked in preview, plan a separate, controlled live-service check after publication.
