# General settings (/en/docs/platform/websites/general-settings)



**Settings** > **General** holds the website's name and URL plus the two destructive actions. You need the website **Manager** role to edit the details and **Admin** to reset or delete.

## Website details [#website-details]

**Name** is the label used in lists, breadcrumbs, and alert notifications. Renaming is safe and affects nothing but display.

**URL** is the site's public address. Changing it does not move your reporting endpoint or invalidate anything already collected, so correcting a typo carries no risk.

Select **Save changes** when you are done.

## Reset reports [#reset-reports]

Deletes every stored report for this website.

<Callout type="error" title="Reset reports cannot be undone">
  There is no export step and no recovery. Export anything you need first, from the CSV export on any report page or from the PCI DSS evidence pack.
</Callout>

The important detail: **resetting does not reset usage.** Reports you already ingested this period still count against your monthly quota. Resetting frees storage and clears the dashboards, not your allowance, so it is not a way to recover from an overage.

Reasonable uses are clearing test data before going live, or removing a burst of noise that makes the dashboards unreadable after you fix its cause. If your goal is to stop the noise rather than hide it, [ingestion filters](/en/docs/platform/websites/reporting-settings) are the right tool.

What survives a reset: your PCI DSS review decisions and their audit ledger. Those live separately from report storage, which is what keeps evidence meaningful after the underlying reports age out.

## Delete website [#delete-website]

Permanently deletes the website, its configuration, and its reports.

<Callout type="error" title="Delete website cannot be undone">
  Everything goes: settings, ingestion filters, alert channels and rules, PCI DSS scope and script review, access grants, and reports. Recreating a site with the same name and URL does not bring any of it back.
</Callout>

Deleting also releases the reporting endpoint. If the site had a custom subdomain, that hostname enters the 90-day quarantine before anyone can claim it again, including you. For more information, refer to [Custom subdomain](/en/docs/platform/websites/custom-subdomain).

Before deleting, consider whether you actually want one of the softer options:

* **To stop collecting but keep the history**, remove the headers from your site. The website stays, its reports stay, and nothing new arrives.
* **To stop a runaway site from consuming quota**, set a website report limit instead. For more information, refer to [Usage and limits](/en/docs/platform/websites/usage-and-limits).
* **To hand a site to a different team**, change its access grants rather than deleting and recreating. For more information, refer to [Access control](/en/docs/platform/websites/access-control).

Deletion is recorded in the workspace audit log, including who did it and when. For more information, refer to [Audit logs](/en/docs/platform/security/audit-log).

## Next steps [#next-steps]

* [Access control](/en/docs/platform/websites/access-control)
* [Usage and limits](/en/docs/platform/websites/usage-and-limits)
* [Websites overview](/en/docs/platform/websites)