Rename site admin and site configuration to Administration and Advanced configuration

docs/admin/access-control/batch-changes.mdx

@@ -1,6 +1,6 @@
 # Access control for Batch Changes
 
-Granular controls for who can access [Batch Changes](/batch-changes/) can be configured by site admins by tuning the roles assigned to users and the permissions granted to those roles. This page describes the permission types available for Batch Changes, and whether they are granted by default to the **User** [system role](/admin/access-control#system-roles). All permissions are granted to the **Site Administrator** system role by default.
+Granular controls for who can access [Batch Changes](/batch-changes/) can be configured by administrators by tuning the roles assigned to users and the permissions granted to those roles. This page describes the permission types available for Batch Changes, and whether they are granted by default to the **User** [system role](/admin/access-control#system-roles). All permissions are granted to the **Administrator** system role by default.
 
 | Name                        | Description                                                                                                                                                                                                                                             | Granted to **User** by default? |
 | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------------------: |
@@ -9,9 +9,9 @@ Granular controls for who can access [Batch Changes](/batch-changes/) can be con
 | `batch_changes:agent_read`  | <ul><li>User can view [agentic batch changes](/agentic-batch-changes/), including agents, their conversations, and results.</li><li>Requires `batch_changes:read` as well.</li></ul>                                                                    |                ✓                |
 | `batch_changes:agent_write` | <ul><li>User can create, run, and modify [agentic batch changes](/agentic-batch-changes/).</li><li>Requires `batch_changes:write` as well.</li></ul>                                                                                                    |                ✓                |
 
-These permissions gate access to the Batch Changes feature as a whole. Within a batch change, what a user can see and do is further limited by the batch change's [permission levels](/batch-changes/permissions-in-batch-changes#permission-levels-for-batch-changes) and by their [repository permissions](/batch-changes/permissions-in-batch-changes#repository-permissions-for-batch-changes). Merging changesets can additionally be restricted to site admins with the `batchChanges.restrictMergeToAdmins` [site configuration](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) property.
+These permissions gate access to the Batch Changes feature as a whole. Within a batch change, what a user can see and do is further limited by the batch change's [permission levels](/batch-changes/permissions-in-batch-changes#permission-levels-for-batch-changes) and by their [repository permissions](/batch-changes/permissions-in-batch-changes#repository-permissions-for-batch-changes). Merging changesets can additionally be restricted to administrators with the `batchChanges.restrictMergeToAdmins` [advanced configuration](/batch-changes/permissions-in-batch-changes#restricting-merges-to-site-admins) property.
 
 <Callout type="note">
-	The site configuration property `batchChanges.restrictToAdmins` is deprecated and has no effect.
-	To restrict Batch Changes to site admins, remove the `batch_changes:read` and `batch_changes:write` permissions from the **User** role instead.
+	The advanced configuration property `batchChanges.restrictToAdmins` is deprecated and has no effect.
+	To restrict Batch Changes to administrators, remove the `batch_changes:read` and `batch_changes:write` permissions from the **User** role instead.
 </Callout>

docs/admin/access-control/index.mdx

@@ -7,7 +7,7 @@
 
 <Callout type="note">
 	This page refers to in-product permissions, which determine who can, for
-	example, create a batch change, or who is a site admin. This is *not* the
+	example, create a batch change, or who is an administrator. This is *not* the
 	same as [repository permissions](/admin/permissions/), which enforces the
 	same repository access on Sourcegraph as your code host.
 </Callout>
@@ -18,13 +18,13 @@ Sourcegraph uses [Role-Based Access Control (RBAC)](https://en.wikipedia.org/wik
 
 ![Role management page](https://sourcegraphstatic.com/docs/images/administration/access_control/managing_roles_permissions_dark.png)
 
-Site admins can control which features each type of user has access to by creating custom roles and assigning permissions to them. You can see all available roles and create new ones under **Site admin > Users & auth > Roles**.
+Administrators can control which features each type of user has access to by creating custom roles and assigning permissions to them. You can see all available roles and create new ones under **Administration > Users & auth > Roles**.
 
 ### System roles
 
 Every Sourcegraph instance ships with two built-in system roles:
 
--   **Site Administrator**: This role is granted to any user who is promoted to site admin. It always has all features and permissions of Sourcegraph granted to it and the set of permissions cannot be modified.
+-   **Administrator**: This role is granted to any user who is promoted to administrator. It always has all features and permissions of Sourcegraph granted to it and the set of permissions cannot be modified.
 -   **User:** This role is granted to every user of the Sourcegraph instance and cannot be unassigned. By default, it has all features and permissions of Sourcegraph granted to it, but _the set of permissions can be modified_.
 
 ### Creating a new role and assigning it permissions
@@ -33,7 +33,7 @@ To create a new role, click the **+ Create role** button. Give the role a unique
 
 ### Editing permissions for an existing role
 
-> NOTE: The **Site Administrator** role cannot be modified.
+> NOTE: The **Administrator** role cannot be modified.
 
 To edit the permissions granted to a role, click the role to expand it, then select the new set of permissions you want to grant to it. Then click **Update** to save your changes.
 
@@ -55,9 +55,9 @@ To delete a role, click the **Delete** button on it. You will be prompted to con
 	Built-in system roles cannot be assigned this way.
 </Callout>
 
-Site admins can manage which roles are assigned to which users from **Site admin > Users & auth > Users**. To view or edit a user's roles, click the triple dots to open the context menu for that user, then click **Manage roles**. This will open a modal dialog where you can see the user's current roles, assign new ones, or unassign current ones. You can type in the input field to search roles by name. Click **Update** to save any changes, or **Cancel** to discard. Note that system roles cannot be revoked or assigned via this modal.
+Administrators can manage which roles are assigned to which users from **Administration > Users & auth > Users**. To view or edit a user's roles, click the triple dots to open the context menu for that user, then click **Manage roles**. This will open a modal dialog where you can see the user's current roles, assign new ones, or unassign current ones. You can type in the input field to search roles by name. Click **Update** to save any changes, or **Cancel** to discard. Note that system roles cannot be revoked or assigned via this modal.
 
-To assign the **Site Administrator** system role to a user, open the same context menu from the triple dots, then click **Promote to site admin**. To unassign the **Site Administrator** role, open the same context menu from the triple dots, then click **Revoke site admin**.
+To assign the **Administrator** system role to a user, open the same context menu from the triple dots, then click **Promote to administrator**. To unassign the **Administrator** role, open the same context menu from the triple dots, then click **Revoke administrator**.
 
 The **User** system role is automatically assigned to all users and cannot be revoked.
 

docs/admin/audit-log.mdx

@@ -60,7 +60,7 @@ The audit log captures a wide range of security-relevant events including:
 -   **Authentication Events** - Login attempts, access token usage, password changes, and sign-out events
 -   **Authorization Events** - Permission changes, role modifications, and access control updates
 -   **User Management** - User creation, modification, deletion, and email verification
--   **Configuration Changes** - Site configuration updates, external service modifications
+-   **Configuration Changes** - Advanced configuration updates, external service modifications
 -   **Repository Access** - Repository access events and gitserver requests
 -   **API Usage** - GraphQL requests and outbound API calls
 -   **Code Host Integration** - External service configuration and webhook events
@@ -105,11 +105,11 @@ Below is a comprehensive list of currently audited entities and their associated
 
 ### Target audience
 
-Security specialists. We expect these to ingest the logs into their SIEM tools and define alert policies as they see fit. Site admins are currently not the target audience, but we'll likely offer an easy-to-use in-app audit log.
+Security specialists. We expect these to ingest the logs into their SIEM tools and define alert policies as they see fit. Administrators are currently not the target audience, but we'll likely offer an easy-to-use in-app audit log.
 
 ## Configuring
 
-The audit log is currently configured using the site config. Here's the corresponding entry:
+The audit log is currently configured using the advanced configuration. Here's the corresponding entry:
 
 ```
   "log": {
@@ -219,7 +219,7 @@ The `audit.actor` node carries ID of the user who performed the action (`actorUI
 
 1. Grab the user ID from the audit log
 1. Base64 [encode](https://www.base64encode.org) the ID with a "User:" prefix. For example, for Actor with ID 71 use `User:71`, which encodes to `VXNlcjo3MQ==`
-1. Navigate to Site Admin -> API Console and run the query below
+1. Navigate to Administration -> API Console and run the query below
 1. Find the corresponding user by searching the query results for the encoded ID from above
 
 GraphQL query:

docs/admin/auth/builtin.mdx

@@ -1,24 +1,24 @@
 # Builtin password authentication
 
-The [`builtin` auth provider](/admin/config/site-config#builtin-password-authentication) manages user accounts inside Sourcegraph. It supports user signup, login, and password reset. This is the simplest provider type to set up, and is the default auth provider on a fresh installation for the first user so they can create an account and become site admin.
+The [`builtin` auth provider](/admin/config/site-config#builtin-password-authentication) manages user accounts inside Sourcegraph. It supports user signup, login, and password reset. This is the simplest provider type to set up, and is the default auth provider on a fresh installation for the first user so they can create an account and become administrator.
 
 Use this auth provider, if you have no organizational requirements to use a SSO provider.
 
 When enabled, users will be able to login using username/password combinations from the login screen.
 
-Signup can either be allowed to all users, the site admin can provision accounts, or new users can request an account.
+Signup can either be allowed to all users, the administrator can provision accounts, or new users can request an account.
 
 ![Login form for builtin authentication](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/auth/login_signup.png)
 
 <Callout type="note">
 	If Sourcegraph is running on a free license all users will be created as
-	site admins. Learn more about license settings on our [pricing
+	administrators. Learn more about license settings on our [pricing
 	page](https://about.sourcegraph.com/pricing).
 </Callout>
 
 ## Enabling this authentication provider
 
-Add the following section to your site configuration:
+Add the following section to your advanced configuration:
 
 ```json
 {
@@ -63,19 +63,19 @@ When `allowSignup` is not set, or set to `false`, users will see a request accou
 	configurations.
 </Callout>
 
-New users can submit a form and site admins will see the request in the navbar on the instance, where they can approve or reject the requests.
+New users can submit a form and administrators will see the request in the navbar on the instance, where they can approve or reject the requests.
 
 ![List of pending access requests for admin to approve](https://storage.googleapis.com/sourcegraph-assets/docs/images/admin/auth/pending-access-requests.png)
 
 ## Disable account requests from users
 
-The account request feature can be disabled by setting `"auth.accessRequest": { "enabled": false }`. When disabled, new user accounts can only be created by the site admin manually.
+The account request feature can be disabled by setting `"auth.accessRequest": { "enabled": false }`. When disabled, new user accounts can only be created by the administrator manually.
 
 ## Creating builtin authentication users
 
 Users can be created for builtin password authentication in several ways:
 
--   through the site admin page `/site-admin/users/new`
+-   through the Administration page `/site-admin/users/new`
 -   through users [signing up](#allow-all-new-users-to-sign-up-to-your-sourcegraph-instance)
 -   through the `createUser` mutation in the GraphQL API
 -   through [`src users create`](/cli/references/users/create)
@@ -84,9 +84,9 @@ When [SMTP is enabled](/self-hosted/email), special behaviours apply to whether
 
 ## Account lockout
 
-Password reset links expire after 4 hours by default - this can be configured in site configuration with the [`auth.passwordResetLinkExpiry`](/admin/config/site-config#auth-passwordResetLinkExpiry) field.
+Password reset links expire after 4 hours by default - this can be configured in advanced configuration with the [`auth.passwordResetLinkExpiry`](/admin/config/site-config#auth-passwordResetLinkExpiry) field.
 
-Account will be locked out for 30 minutes after 5 consecutive failed sign-in attempts within one hour for the builtin authentication provider. The threshold and duration of lockout and consecutive periods can be customized via `"auth.lockout"` in the site configuration:
+Account will be locked out for 30 minutes after 5 consecutive failed sign-in attempts within one hour for the builtin authentication provider. The threshold and duration of lockout and consecutive periods can be customized via `"auth.lockout"` in the advanced configuration:
 
 ```json
 {
@@ -102,7 +102,7 @@ Account will be locked out for 30 minutes after 5 consecutive failed sign-in att
 }
 ```
 
-To enabled self-serve account unlock through emails, add the following lines to your site configuration:
+To enabled self-serve account unlock through emails, add the following lines to your advanced configuration:
 
 ```json
 {