Ask your website provider for a list of every optional analytics tool and third-party script, what each one does, and exactly when it loads. Then ask how the site behaves when a guest accepts, rejects, changes, or withdraws a choice. A banner alone does not tell you whether those choices are respected.
The buying decision is about control as much as appearance. You need to know who can change a script, whether the ordering flow uses a separate consent setup, and how you can check the result after an update. The answers should be specific enough to test, not just a promise that the site has a cookie notice.
Inventory the tools behind your website
Start with a list of the services that run when someone visits your site. Ask the website provider to include tools it installs, tools you or an agency added, and services loaded by other vendors. A script is code that can run in a visitor's browser; a cookie is one way a site or service can store information there. A consent review needs to look beyond cookies alone.
For each tool, ask for its name, supplier, purpose, pages where it runs, and the information it stores or sends. Ask whether it loads another service in turn. A marketing tag, for example, may introduce additional code that does not appear in the page editor.
Organize the list by purpose rather than by the person who bought the tool. Possible categories include site operation, optional analytics, advertising, and embedded content. The correct treatment of a particular tool depends on its behavior and the rules that apply to your business; do not assume a label settles that question.
Also identify the owner of each change. Your website provider might control the page template, an agency might manage analytics, and an ordering vendor might control a linked checkout. Ask each one who can add, remove, or pause its tools and who will tell you when the list changes.
Follow the guest journey beyond the home page. If your site links to online ordering on another domain or opens a separate ordering page, ask whether that destination has its own scripts and consent choices. A visitor's selection on the restaurant site should not be assumed to control a separate service. Ask how the two are connected and what a guest sees when moving between them.
Map each guest choice to script behavior
Before comparing providers, write down the behavior you want and ask each provider to explain how it would implement it. The table below is a practical starting point for optional analytics and other optional third-party tools. Have counsel review the choices and wording for your circumstances.
| Guest action | Behavior to discuss | Evidence to request |
|---|---|---|
| No choice yet | Optional tools wait until the relevant choice is made. | A fresh-visit demonstration showing which requests and storage appear. |
| Reject optional tools | Optional tools remain inactive while the guest browses. | A repeatable check across the home page, menu, and ordering entry point. |
| Accept a category | Only tools assigned to the accepted category can start. | A category-to-tool list and a demonstration of the resulting behavior. |
| Withdraw a choice | Optional activity stops going forward; the provider explains what happens to existing storage. | A demonstration plus an explanation of any data already sent to third parties. |
Ask what “inactive” means in the provider's setup. Does the optional script wait to download, or does it download but hold back certain actions? Does the browser contact the third party before the guest chooses? Does the tool create storage on the device? These are different behaviors, so ask the provider to show each one rather than relying on a single on/off label.
Also ask whether guests can accept and reject optional categories with comparable ease, and where they can reopen their settings later. If an embedded map or video is optional, find out what appears before the guest enables it. A useful fallback might be a street address or a link, but confirm what the provider can actually configure.
Hypothetical example: A neighborhood restaurant wants visit analytics and an embedded map on its menu page. Its owner asks for analytics to start only after the guest accepts that category, and for the map to remain inactive until the guest enables it. The provider can demonstrate both behaviors, but the map setting is separate from analytics. The owner should check that the labels explain those choices and that rejecting analytics does not prevent a guest from reading the menu.
There is a trade-off: when optional analytics does not run, the restaurant may see fewer visits in its reports. That is a measurement limit to understand before buying, not a reason to assume that every visitor has agreed to tracking.
Test the full choice cycle on representative devices
Use a staging site or another safe practice environment where possible. Choose at least a phone and a desktop browser that resemble what guests use. Start each independent check in a fresh browser profile or after clearing the relevant site data. A private window can help create a fresh session, but it is not a complete substitute for checking normal browsing and returning visits.
Ask a technically capable provider or agency to share its screen and show browser storage and network requests. The owner does not have to interpret every request alone. The useful question is whether the visible behavior matches the tool list and the guest's selection.
- Before a choice: Open the home page and menu. Record which listed services receive requests and what storage appears before touching the banner.
- Reject: Reject optional categories. Navigate between pages and reload. Check whether the listed optional tools remain inactive and whether the choice persists as the provider says it should.
- Accept selectively: Start a fresh session, accept one category, and leave another off. Compare the requests and storage with the category-to-tool list.
- Change and withdraw: Reopen settings, change the selection, and check what stops. Ask how existing cookies or other local storage are handled and whether previously transmitted data remains with a third party.
- Return: Close and reopen the browser, then revisit. Check whether the saved choice and the available settings behave as described.
- Follow the journey: Open the ordering entry point and inspect any separate domain or embedded service. Confirm what the guest is asked and which provider controls each step.
For practice, stop before submitting an order or other guest information. Do not use a real card payment, send a guest message, or dispatch a courier. If a provider wants to demonstrate a live service pilot, agree separately on its scope and safeguards; a simulation is not proof of every live transaction path.
Keep a short record of the device, browser, date, pages visited, choice made, and observed result. Repeat the relevant checks after a template change, a new marketing tool, or an ordering integration update. Testing two devices will not cover every browser or future release, but it gives you a repeatable way to catch mismatches and ask for a fix.
Set ownership and review requirements before signing
Ask for a written description of the consent setup as part of the quote or implementation scope. It should identify who maintains the tool inventory, who assigns categories, who can change banner text, and who fixes a mismatch between a guest's selection and a script's behavior. If an agency and a website provider both have access, name the person responsible for coordinating them.
Get practical answers to these questions:
- Can we remove or pause an optional tool without rebuilding the site? Who has access to do it?
- What happens when an agency adds a new tag or an embedded service changes its own scripts?
- Where can a returning guest find and change their settings?
- Does the ordering page use the same choices, a separate notice, or another arrangement?
- What does the setup cost to configure and maintain, including changes and troubleshooting? Which work is outside the quote?
A low initial quote may leave the restaurant paying separately whenever a tag changes or a vendor needs to investigate. Compare the quoted setup and ongoing support together, and ask about exception work such as a third-party script behaving unexpectedly. Get the scope in writing rather than assuming every future change is included.
Consent requirements and appropriate wording depend on your circumstances. Ask qualified counsel to review the categories, notice, guest choices, retention practices, and any agreements with service providers. The technical provider should then explain how the approved choices are put into practice. A legal review and a behavior check answer different questions; plan for both.
If you are also comparing site ownership and control, the domain ownership guide covers a related decision. For a broader shortlist, use the restaurant website builder comparison alongside this checklist.
Next step: Send the checklist and your current tool list to your provider, then request a walkthrough of each choice. If you are evaluating a new restaurant website, ask Fleksa about verified US availability and how the consent and third-party script setup would work for your site.
Frequently asked questions
Does a cookie banner stop optional analytics by itself?
Not necessarily. Ask the provider to demonstrate what loads before a choice and after rejection. The banner's appearance and the underlying script behavior need to be checked separately.
What should happen when a guest withdraws consent?
Ask how optional activity stops going forward, how existing browser storage is handled, and what happens to information already sent to a third party. Have counsel review the required approach for your business.
Should I check a separate online ordering page?
Yes. A linked or embedded ordering service may have its own scripts and settings. Ask who controls them and whether the guest's choice on your main site carries over.
