Documents and the document editor

The three documents

UserGuard generates three documents per site: a cookie policy, an accessibility statement, and a Do Not Sell or Share notice. You'll find them on the site's Documents tab. Each one is built from what the product knows about your site (the approved cookie inventory, the assessment you recorded, how the opt-out tool is configured), and none of them comes from a generic template.

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

How the editor works

Each document has one workspace. Edit & preview on its row opens a full-screen editor, with your inputs in a rail on the left and the generated page on the right, rendered inside a browser frame. 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, because it's the document's evidence claim and doesn't count as copy. The cookie tables come from the approved inventory, and nothing you type here changes them.

The accessibility statement takes your commitment wording, a conformance choice (if you leave it blank, it publishes "not yet assessed" and makes no 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 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. Only the notice takes a privacy policy URL (https only) to link from the page. If you leave the contact blank, 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.

Is Save details the same as Publish?

No. Save details stores your inputs and nothing else, and the published document stays the same until you publish. Publish regenerates the document from today's inputs and inventory and replaces the live version, after a confirmation that says exactly what that means: "Replaces v4 everywhere it's embedded." If you publish with unsaved edits, they're saved first, and visitors get the new version within about two minutes.

The caveat strip

Below the preview, the editor shows you what publishing right now would 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, or an opt-out control on a site where the script has never been seen running. When you fill the relevant field in the rail, the count drops, before anything is published.

Any caveats that remain when you publish are stored with that version and shown on the Documents tab, so an unfinished draft can't 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, with a Live stamp on the current one. View shows a stored version's exact page in the preview area. Restore this version re-publishes those bytes as a new version, with the same two-step confirmation every publish gets. If you restore v2 on top of v5, you get a v6 that's byte-for-byte v2. We never rewrite v2 itself or anything else in the history, because consent-era records may name the versions in between.

How do you get 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. You paste one doc.js script line where the document should appear, and it renders the current version. When you publish again, the live page updates with no re-pasting. Copy HTML is still offered, last, for a CMS that won't take a script. It's a snapshot and stops updating the moment you paste it.

The Do Not Sell notice is embed-only. 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. For this one document, the embed on your own domain is the only route that works.

When to publish again

A published document describes the site as it was at publish time. The live page doesn't update itself when the underlying facts change, for example when you approve new cookies, a scan changes the evidence, you change the opt-out configuration, or you reword a section. The editor catches this 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.