Documents and the document editor

Three documents, all drafts

UserGuard generates three documents per site: a cookie policy, an accessibility statement, and a Do Not Sell or Share notice. They live on the site's Documents tab, and each is built from what the product actually knows — the approved cookie inventory, the assessment you recorded, how the opt-out tool is configured — never from a generic template.

All three are drafts for a person to review. Every version carries the same standing warning: it is not legal advice, and publishing it does not make the site compliant with anything. Have counsel read a document before it goes up. UserGuard fills the page with evidence; whether the result is right for your business is a judgment only you and your lawyer can make.

Edit the inputs, watch the page

Each document has one workspace. Edit & preview on its row opens a full-screen editor: your inputs in a rail on the left, and the real generated page on the right, rendered inside a browser frame. This is not a mockup — the editor runs the actual generator on every keystroke, so what you see, cookie tables included, is byte-for-byte what publishing will put at the hosted URL and into every embed.

You never edit the document's HTML by hand. You edit its inputs, and the generator writes the page.

What each document takes

The cookie policy takes three copy fields: the opening line, "What a cookie is", and "Your choices". The scan-date sentence always follows your opening — it is the document's evidence claim, not copy — and the cookie tables come from the approved inventory, not from anything you type here.

The accessibility statement takes your commitment wording, a conformance choice (leaving it blank publishes an honest "not yet assessed", never a claim), how the site was evaluated, known limitations, a response time, and an escalation body.

The Do Not Sell notice takes only its opening paragraph. The definitions, the mechanism, and the rights sections are fixed, because they describe what the law and the control actually do; the link variant, sale categories, and observed recipients come from the Do Not Sell tool and the approved inventory.

The statement and the notice share the privacy contact email; the notice alone also takes a privacy policy URL (https only) to link from the page. Leave the contact blank and drafts print your login email — and warn you that they do. Any copy field left blank falls back to standard wording, and a blank line starts a new paragraph.

Save details is not Publish

Save details stores your inputs and nothing else — the published document is unchanged until you publish. Publish regenerates the document from today's inputs and inventory and replaces the live version, behind a confirm that says exactly what that means: "Replaces v4 everywhere it's embedded." Publishing with unsaved edits saves them first, and visitors get the new version within about two minutes.

The caveat strip

Below the preview, the editor keeps a live answer to one question: what would publishing right now record? These caveats are the generator's own warnings — no completed scan behind the policy, cookies with no written purpose, a conformance claim with no described evaluation, an opt-out control on a site where the script has never been seen running. Fill the relevant field in the rail and the count drops, before anything is published.

Whatever caveats remain when you publish are stored with that version and shown on the Documents tab, so an unfinished draft cannot pass for a finished one after a reload.

Version history: view and restore

Every publish is kept. The Version history group lists each version with its date and, where one was recorded, the caveat count it carried, and a Live stamp on the current one. View puts a stored version's exact page on the stage; Restore re-publishes those bytes as a new version, behind the same two-step every publish gets. Restore v2 on top of v5 and you get a v6 that is byte-for-byte v2 — never a rewritten v2, because consent-era records may name the versions in between. History is never rewritten.

Getting a document onto your site

The cookie policy and the accessibility statement each get a hosted URL you can link to directly. All three can be embedded instead: one doc.js script line, pasted where the document should appear, renders the current version — publish again and the live page updates with no re-pasting. Copy HTML is still offered, last, for a CMS that will not take a script; it is a snapshot and stops updating the moment you paste it.

The Do Not Sell notice is embed-only, on purpose. Its opt-out control writes the opt-out cookie on the domain the page is served from, so a copy hosted on UserGuard's domain would record a choice your site never sees. On that one document, the embed on your own domain is the only honest route.

When to publish again

A published document describes the site as it was at publish time. When the underlying facts drift — you approve new cookies, a scan changes the evidence, the opt-out configuration moves, you reword a section — the live page does not update itself. The editor notices for you: it regenerates the document from today's inputs, compares the result to the live version byte for byte, and stamps the document Draft over v4 whenever they differ. When you see that stamp, open the preview, read what changed, and publish.