Pause routine changes to menus, prices, hours, photos, page copy, promotions, and ordering links while you test a replacement restaurant website. Allow urgent corrections, but record them and check whether they need to appear on both the current site and the replacement. A freeze should protect the version being tested, not stop you from correcting information guests rely on.
The aim is to avoid a familiar problem: a menu passes review on Monday, someone changes a price on Tuesday, and the new site launches on Friday with the old price. A short freeze window and a shared exception log make that change visible.
Set the freeze window and exceptions
Start the freeze when the replacement site is ready for final content checks. End it after launch verification, not simply when the new site becomes visible. Agree on the intended window with the person building the site before announcing it to staff. Leave time for a correction and a recheck if something important fails.
Ask the people closest to each type of information for their expected changes. The kitchen or menu manager can flag planned item and price updates. The manager who handles staffing can confirm regular and holiday hours. Whoever manages promotions can identify offers about to start or expire. The website provider can explain how long publishing and correcting changes usually take.
Use those inputs to make a practical cutoff. If a menu change is already scheduled for the middle of testing, either move it before the freeze or plan it as a documented exception. Do not quietly defer a closure notice or an unsafe allergen correction just to preserve the schedule.
Separate changes into three groups:
- Pause: optional photo swaps, rewritten descriptions, new promotions, layout preferences, and routine page additions.
- Consider as exceptions: a price correction, a broken ordering link, an inaccurate hour, or an item that is no longer available.
- Escalate immediately: information that could cause a guest to make a materially wrong decision, such as an incorrect allergen statement or an unexpected closure.
Agree who can approve an exception and who can publish it. Those may be different people. Set a single place for requests, such as a shared document, rather than relying on a chain of texts. Include the live site, replacement site, and any separately managed ordering menu in the discussion: changing one does not necessarily update the others.
If you are still choosing a setup, the restaurant website builder comparison can help frame questions about editing access and the connection between the site and ordering. Ask the provider which content is shared and which must be changed separately.
Record urgent changes in both versions
For every approved exception, record the requested change, its reason, where it must appear, who will make it, and how it will be checked. Add a status for each affected version. “Done” is too vague if the current site has been fixed but the replacement still needs an update.
Hypothetical example: A restaurant freezes its replacement site on Tuesday for a planned Friday launch. On Wednesday, its manager learns that the restaurant must close at 8 p.m. on Saturday rather than 10 p.m. The current site and the replacement site both show the old hours. A separate ordering page also displays hours.
The manager approves the correction as an exception. The person with access updates the current site and checks the published page. The builder updates the replacement and supplies a preview for review. The manager also checks the ordering page and arranges a correction if it shows the old closing time. The log below shows how to keep those tasks distinct.
| Change | Reason and decision | Locations and status | Recheck |
|---|---|---|---|
| Saturday closing time: 10 p.m. to 8 p.m. | Urgent guest-facing correction; approved by manager | Current site: updated. Replacement preview: updated. Ordering page: correction requested. | Manager checks each location; ordering page remains open until corrected. |
| Replace dining-room photo | Optional refresh; deferred | Neither site changed during freeze | Revisit after launch verification. |
The exception is not complete until each applicable location has been checked. If the ordering page cannot be corrected before launch, decide whether to delay the launch or use another approved, accurate way to direct guests. Record the decision and its owner rather than assuming the discrepancy will resolve itself.
Use the same process for a menu price or unavailable dish. Confirm the intended wording and effective time, then compare the website menu with the ordering menu. A correction on the old site alone can be overwritten in practice if the replacement goes live with stale content. Conversely, fixing only the replacement leaves current visitors with the wrong information until launch.
Not every source of restaurant information is controlled by the website provider. Keep a separate note of other places where guests may see hours or menus, and assign someone to check them. The freeze log can point to that work without pretending that publishing the website updates every listing.
Recheck menu, hours, and links before release
Test the exact version intended for launch after all approved exceptions have been applied. Use a phone as well as a computer, and ask someone other than the person who entered the change to compare the page with the approved information. Look for missing details as well as incorrect ones.
- Menu: Check item names, descriptions, prices, availability, and any statements guests need to make an informed choice. Compare the displayed menu with the ordering menu where both are used.
- Hours and contact details: Check regular hours, known exceptions, address, and phone number. Confirm that tap-to-call and directions links lead to the intended destination.
- Guest actions: Follow ordering and reservation links through to the intended page. Check that the destination belongs to the restaurant and displays the expected information.
- Navigation: Open important pages from the main menu and from prominent buttons. Check that text and buttons are readable and usable on a small screen.
- Exceptions: Revisit every open log entry. Confirm that the correction appears in each applicable place and that the person responsible has marked the check complete.
For the hypothetical Saturday-hours change, the reviewer should compare the approved 8 p.m. closing time against the replacement preview and ordering page, not merely check that an hours section exists. After launch, the reviewer should repeat that comparison on the public site. If the preview and public page differ, keep the exception open and ask the provider to investigate.
A preview check has limits: it shows the version and connections available in that environment, not necessarily what guests will see after the domain points to the new site. A link check also does not prove that an order or reservation can be completed. For practice, use a simulated or non-submitting path agreed with the provider. Do not place a real card payment, send a guest message, or dispatch a courier as part of a practice scenario.
If you use online ordering, ask the provider how to verify the connection safely and what a live-service pilot would involve. A live pilot is a separate, deliberate decision with staff prepared to handle real activity; it is not the same as clicking through a preview. For domain-related checks, the domain ownership guide covers questions to ask about access and control.
End the freeze after launch verification
Once the replacement is public, check the live pages again using the restaurant's normal website address. Confirm the key menu, hours, contact, ordering, and reservation destinations. Review the exception log alongside the live site, including any changes made shortly before release. Mark each item complete only after the relevant public or ordering location has been checked.
Give the team a clear release message: the freeze has ended, routine edits can resume, and the normal editing contact or process applies. Move deferred requests out of the exception log into the regular work queue so they do not disappear. Keep the completed log for reference if a discrepancy appears later.
If an important check fails, keep the affected change open and agree on an immediate response with the provider. That may mean correcting the public page, directing guests to accurate information, or delaying a planned promotion. Assign someone to recheck the fix and tell staff what guests may see in the meantime. A launch can require follow-up; the freeze process makes that follow-up easier to track, but it cannot guarantee an uninterrupted transition.
Before your next launch, use this checklist to assess who can edit each location and how exceptions will be published. Then ask Fleksa about its restaurant website and verify US availability for your intended setup.
Frequently asked questions
How long should a website content freeze last?
Set it around the time needed for final checks, corrections, and public verification. Agree on the window with the provider and restaurant staff rather than choosing a fixed number of days without considering planned changes.
Can we correct a menu price during the freeze?
Yes. Approve it as an exception, identify every affected website and ordering location, and check each published or previewed correction. Keep the entry open until all applicable locations are verified.
Does the freeze end when the new site goes live?
Not automatically. Recheck the public site and important guest links first, resolve or assign any open exceptions, and then tell the team when routine editing can resume.
