Website privacy and cookies, in plain words

What a cookie is and why banners exist

A cookie is a small piece of text a website stores in a visitor's browser and reads back later. Some are useful, like remembering a login. Some follow a person from site to site so that advertising can be aimed at them.

Consent banners exist because rules in many places say a site must ask before it sets the second kind. A banner on a site that sets no such cookie is a habit, not a requirement. Which rules apply to you depends on where your visitors are, and that is a question for your lawyer, not this page.

The words matter here. A cookie is not the same as a server log, and a form is not the same as tracking. Knowing which is which is most of the privacy conversation.

Counting visits on the server, with no cookie added

You still want to know how many people visited and how many filled in the form. Website Builder Studio counts page views and conversions on the server, as the page is served, rather than by planting a script in the visitor's browser.

So a site straight from the builder adds no analytics script and no cookie. Nothing follows the visitor anywhere. You see your counts on your dashboard, and the in-app assistant can read them with you.

A conversion here means a visitor did the thing the page asked for, such as sending the form. It is counted the same way, on the server, with nothing left in the browser.

Your own Google Analytics 4 tag, loaded only after consent

If you want Google Analytics 4 as well, paste your measurement ID into one field. On sites that show a cookie banner, the tag loads only after a visitor accepts. Until then, nothing from Google runs on the page.

The same goes for a Google Search Console verification token: one field, and it is there for Google to read. Neither is required. The server-side count works without them.

Testing two versions without a cookie

A/B testing usually means a cookie, so the visitor keeps seeing the same version. The builder does it without one. A second version of a site with a different headline, lede and answer capsule, with a stable split per visitor and nothing stored in their browser.

That matters here because it is the one feature most people assume must add a cookie, and it does not.

What a form collects and where it goes

The contact form is the main place your site gathers personal information: a name, a way to reach the person, and what they wrote. That is data you are responsible for, and your privacy policy should say what you do with it.

Each submission is delivered where you chose, your CRM, chat, phone or inbox, and every delivery is signed so your end can check it. The lead is also on your Leads screen, where you can edit its status and note. Ask for as little as the conversation needs.

A newsletter opt-in box, if you add one, starts unticked. A visitor joins your list only by choosing to.

Your privacy policy publishes exactly as you gave it

You write your privacy policy, or your lawyer does. You upload it, and it publishes word for word. The builder does not write legal pages and does not edit yours, so nothing appears in your policy that you did not put there.

The policy should match what the site actually does. If you add Google Analytics 4, say so. If you add a newsletter box, say what you send. Nothing on this page is legal advice about what your policy must contain.

What is yours to decide

Each of those is a switch or a page you control. The builder's own default is to add nothing to a visitor's browser. Every page still passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards. Each one is written from a conversation about your business rather than from a template.

• Whether to show a cookie banner at all
• Whether to add your own analytics tag
• What the form asks for
• What your privacy policy says
• Whether Google may use your content to train its AI, which does not affect search indexing