Renaming, re-homing, archiving, and deleting a site

Where these controls live

All four controls live on the site's Settings tab: the domain in the Install panel, beside the verification it resets; the name under Name and organization; archiving and deleting in the last card. They are not equals, and the page does not present them as equals. A rename changes a label. A domain change moves your evidence to a new address. Archiving stops the meter. Deleting destroys the record. If you remember one thing: when a client relationship ends, archive. Delete only when you mean to unmake the evidence.

Renaming is cosmetic

The site name is a label for you and your team, nowhere else. Renaming changes nothing but that label: not the domain, not the site key, not the snippet on the page, not the bill, and not one scan or consent record. Rename freely.

Moving a site to a new domain

When a client rebrands, or a site graduates from a staging domain to the real one, change the site's domain instead of deleting the site and adding a new one. The delete-and-re-add route throws away the consent log. Changing the domain keeps it.

Your history is attached to the site, not to the domain, so consent records, scan history, and the cookie inventory stay put and stay continuous. The snippet keeps working too — it is keyed by the site key, which does not change — as long as that same snippet is installed on the new domain. You can paste a full URL into the domain field; UserGuard stores the bare hostname. One rule: an account cannot hold the same domain twice.

Two things need your attention afterward:

• Install verification resets. Verification was a statement about the old domain, so the site shows as not installed until the script is seen answering from the new domain — then the Live, Quiet, and Silent health states described in Installing the UserGuard snippet resume from there.
• Published documents go stale. Generated documents are frozen HTML, and they name the old domain in their text. They do not rewrite themselves. Your published documents still name the old domain until you publish them again from the Documents tab — a cookie policy that names a domain the site no longer uses is the first thing to fix after the change.

Archiving: the bill stops, the record stays

Archiving is the answer to "we no longer work with this client." It stops everything that costs you money or attention, and keeps everything the site ever recorded.

What stops:

• Billing. Your bill counts live sites, and an archived site is not one. The subscription adjusts when you archive, prorated mid-cycle rather than waiting for the next invoice — and because volume pricing follows the live count, the per-site rate can move too.
• Scheduled scans. The scheduler never touches an archived site.
• Attention items. An archived site stops asking for review, and it leaves the default sites list. An Archived filter shows it when you want it.

What does not stop: the script. An archived site keeps serving its published banner, and consent keeps being recorded. Archiving is a statement about your account, not about the visitor's page — the app says exactly this once a site is archived. If you want the banner gone, remove the snippet from the page too.

Archiving is reversible. Restore the site and billing picks it back up; nothing was lost in between.

Deleting is permanent, and it takes the consent log

Deleting a site destroys everything recorded for it: the scans and their page-by-page evidence, the cookie inventory, the published banner configurations, the generated documents, and the consent log. There is no undo and no recovery window.

Most of that list can be rebuilt — a rescan will find your cookies again. The consent log cannot. A consent record is the proof that a specific visitor was asked and what they answered, and once it is gone, nothing can reconstruct it. That is why the confirmation asks you to type the site's domain rather than a stock word: typing "DELETE" is a reflex, but typing the domain means you looked at which site this is.

Keeping that log does not make you compliant by itself — nothing does — but deleting it closes the question of what the site did while it ran. How long you should retain consent records after a relationship ends is a question for your counsel; archiving exists so the answer never has to be "we deleted them." It stops the billing just as well, which is why the app offers it first.

Who can do which

Renaming a site, like changing its domain and archiving it, takes an admin. Deleting is owner-only. The ladder follows the consequences: a rename or an archive is undone in a click, and unmaking the evidence is a decision the account owner makes.