Site permissions
What each role can do when managing a site's structure, settings, and publishing
Your role on a site determines what you can do when working with it — from browsing its content to changing its structure, settings, and publishing. This page covers what each role unlocks for managing a site. For how a member ends up with a given role on a site, see permissions and inheritance.
What each role unlocks on a site
Each role includes everything the roles below it can do.
Admin
Everything: site settings, publishing, members, billing, integrations
Creator
Restructure the site: add, publish, rename, reorder, and delete sections and variants
Reviewer
Merge change requests — publishing their content to the live site
Editor
Edit page content in change requests, submit them for review, add draft sections and variants
Commenter
Read content and leave comments
Reader
Read-only access
Admin — full control
Admin is required for anything that affects the site as a whole rather than a single piece of its content:
Site settings — title, visibility, custom domain, default section or variant.
Publishing and unpublishing the site.
Site-wide branding and customization, as opposed to a single variant's override.
Managing members and teams on the site, including role overrides.
Installing and configuring integrations, including MCP servers.
Managing redirects, share links, and the site's private-site authentication.
Configuring the AI assistant, its knowledge sources, and feedback channels.
Site billing and plan.
If an action changes something every reader or every editor is affected by — not just one page or one section — it requires admin permissions.
Organization admins always have site Admin on every site in the organization, regardless of any per-site role settings. There's no way to give an org admin a lower role on a specific site.
Creator — shaping the site
Creator unlocks control over the site's structure — the sections, section groups, and variants that make up its table of contents:
Add a section, variant, or group directly as published content, not just drafts.
Publish a draft that an editor created, or turn published content back into a draft.
Rename, reorder, and move sections, groups, and variants.
Delete a section or variant.
Customize an individual variant's branding overrides, such as its title.
In short, a creator can fully rebuild how a site is organized without needing site-wide administrative access.
Reviewer — merging content changes
Reviewer adds one capability on top of Editor: merging change requests, which publishes their content straight to the live site. This makes Reviewer the first role that can actually change published content, even though it can't touch the site's structure or settings.
Merge access is defined per space, not per site — it's the same Reviewer role, applied to whichever spaces make up the site. A member only needs Reviewer to merge; they don't need to be the one who opened the change request.
Editor — day-to-day content work
Editor is the entry point for making changes. An editor can:
Edit page content by submitting a change request, the same as in any space. This doesn't go live immediately — the change stays as a proposal until someone with Reviewer access or above merges it.
Add a new section or variant to the site's structure — but only as a draft. Draft content isn't visible on the published site until someone with Creator access or above publishes it.
Resolve findings surfaced by GitBook's AI content-quality scans.
An editor cannot merge their own or anyone else's change request — that requires Reviewer access or above.
Letting editors add draft structure — without letting them publish it — means a writer can stage a new section or variant for review without accidentally changing what readers see.
Commenter — browsing and commenting
Commenter includes Reader access and adds the ability to leave comments. Neither role can change site content or settings.
Reader — browsing
Reader access lets you open a site in the dashboard, browse its structure, and read published content.
Where to manage this
A site's members, their roles, and its default permission level are managed from Site settings → Members, by anyone with Admin access to the site. See permissions and inheritance for how that default, team access, and direct member overrides combine to decide a member's role.
Last updated
Was this helpful?