## Opening the project settings workspace
To work with project-level settings in Atloria, start by opening the project you want to manage from the main project area. These settings are meant for people who can administer that specific project, so you should have **Project Administrator** access or an equivalent permission level that allows you to change configuration. If you can open the project but do not see a **Settings** option in the project navigation, your access level may be limited to content work rather than project administration.

1. Open the target project from your project list or dashboard.
2. In the project navigation, select **Settings**.
3. Review the settings groups available on that screen before making changes.

[SCREENSHOT: Project navigation with the Settings option highlighted]

It helps to separate project settings from the Admin workspace. The Admin area is used for broader organization-wide tasks such as user access, analytics, and security review. Project settings only affect the documentation workspace you currently have open. If you need help with organization-wide controls, use [Using the Admin Workspace](doc:using-the-admin-workspace) or [Managing Organization and Admin Settings](doc:managing-organization-and-admin-settings).

In this guide, you will work across three main groups of options:

- **General project configuration** for the project’s core details
- **Website options** for branding and public presentation
- **Public delivery controls** for access and release behavior

Some changes appear right away after you save them, especially updates tied to project labels and administrative views. Other changes may not be visible on the published documentation site until the next publish action, site refresh, or content sync. When you update website-facing settings, always plan to verify the live result after saving so you can tell whether the change was immediate or still waiting on a publish-related step.

## Configuring core project details
The first settings area to review is the project’s core information. These details help your team identify the workspace inside Atloria and can also affect how the project is labeled in project lists, headers, and other internal views. Open the general project settings section and look for fields related to the project name, description, and identifying label.

1. In **Settings**, open the general project details section.
2. Update the **Project Name** so it matches the documentation set your team recognizes.
3. Edit the internal description if your team uses it to explain the project’s purpose, audience, or scope.
4. Review the project identifier or slug field if Atloria shows one for distinguishing the workspace.
5. Set the default language, locale, or regional options if those controls are available.
6. Click **Save**.

[SCREENSHOT: General project settings with name, description, identifier, and language options]

These fields usually serve different purposes, so it is worth checking each one carefully:

| Setting | What it affects |
|---|---|
| **Project Name** | How the project appears in headers, lists, and internal navigation |
| **Description** | Internal context for contributors and administrators |
| **Identifier / Slug** | A distinct label used to separate this project from others |
| **Default Language / Locale** | Dates, labels, and region-specific presentation |

If Atloria includes visibility defaults for contributors, review who can view draft content and who can manage configuration. Keep in mind that these are project-level working rules, not public website settings. They shape how your internal team works inside the project.

After saving, return to the project header or project list and confirm that the updated name and other visible metadata appear as expected. If the project title changes immediately in the workspace but not on the public site, that usually means the internal project record updated right away while the website-facing view still needs a publish-related refresh.

## Setting up website identity and public presentation
Once the core project details are in place, move to the website settings area to control how the documentation appears to readers outside your editing team. This is where you define the public-facing identity of the project rather than the internal workspace label used by contributors.

1. In the project **Settings** screen, open the website-related section.
2. Enter the **Site Title** that should appear to readers on the published documentation site.
3. Add or update the **Public Description** so visitors understand what the documentation covers.
4. Review any branding text fields shown in the website settings panel.
5. Upload or replace website assets such as the logo, favicon, or other brand images.
6. Save your changes before moving to URL or homepage options.

[SCREENSHOT: Website settings panel showing site title, public description, and branding assets]

Use the internal project name and the public site title deliberately. In many teams, they are similar, but they do not always need to match. For example, the internal project name may help contributors distinguish workspaces, while the public site title should be clear to customers, partners, or other readers.

Next, review the delivery location for the site. If Atloria shows a **Public URL**, **Custom Domain**, or **Site Path** field, confirm that it points to the address where this documentation should be available. Be careful when changing these values, because they affect where readers will find the site.

You should also check homepage or landing-page options. If Atloria lets you choose which page, collection, or navigation entry acts as the public starting point, make sure the selected content is the one you want visitors to see first. This is especially important if your project contains multiple sections or audience-specific content paths.

After saving, the branding and identity changes may be visible in previews right away, while domain or delivery changes may take longer to appear depending on how the site is published.

## Controlling navigation, indexing, and reader-facing options
Website settings are not limited to branding. They also shape how readers move through your documentation and what information is visible around the content itself. In the website options area, look for controls related to navigation, search, indexing, and page details.

1. Open the navigation and reader experience section inside **Settings**.
2. Decide whether sections, categories, or the page tree should appear in the website menu.
3. Review search-related options and save the choices that match how discoverable the site should be.
4. Check reader-facing options such as footer links, support references, or update details shown on pages.
5. Save the changes and preview the site menu.

[SCREENSHOT: Website options for navigation, search, and page display settings]

These options usually affect the published reading experience in several ways:

- **Navigation visibility** controls whether readers can browse by section or rely on direct links and search.
- **Search and indexing settings** affect whether pages can be found inside the documentation site and, where allowed, by external search engines.
- **Footer and support references** give readers extra context or a way to continue their journey.
- **Update metadata visibility** determines whether published pages show information such as recent update details.

This part of the settings screen changes how the site feels to readers without changing how your team writes and edits content inside Atloria. Your page structure, authoring workflow, and review process stay the same; what changes is how much of that structure is exposed on the public-facing site.

If your team is planning audience-specific navigation or more advanced content organization, keep those broader decisions aligned with your project structure. For related planning guidance, see [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation) and [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences).

## Managing publication and access behavior
After you finish the visual and navigation settings, review how the documentation site should be exposed to readers. In Atloria, publication and access controls determine whether the website is openly available, limited to certain readers, or kept out of view until the content is ready.

1. In the project **Settings** area, open the publication or access section.
2. Choose whether the website should be **public**, **restricted**, or **hidden**.
3. Review controls that exclude drafts, unpublished pages, or internal-only content from the website.
4. Check whether audience-based access, sign-in requirements, or password-style protection is available for this project.
5. Click **Save** and test the result in a browser window.

[SCREENSHOT: Publication and access settings showing visibility choices and content exclusion options]

A useful way to think about these choices is:

| Access mode | What readers experience |
|---|---|
| **Public** | Visitors can open the published documentation without special access |
| **Restricted** | Only approved or signed-in readers can view the site or certain content |
| **Hidden** | The site is not meant for general viewing until release is ready |

Also review what content is allowed to appear on the website. If Atloria provides options to exclude drafts, unpublished pages, or internal-only sections, use them carefully before release. These controls help separate active team work from reader-ready documentation.

If your project uses audience access rules, those settings can further shape who sees what after publication. This is especially important when one project serves multiple reader groups. For deeper guidance on audience behavior, use [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Version Visibility and Reader Access](doc:managing-version-visibility-and-reader-access).

Once saved, compare the site in two ways: as a signed-in team member and as a visitor who is not signed in. That side-by-side check is the quickest way to confirm whether the selected access mode is behaving as intended.

## Verifying the website configuration
After saving project and website settings, take time to verify the result before sharing the documentation link with others. A quick review inside the project is not enough on its own. You should check both the preview and the published site experience.

1. Open the project’s website preview if it is available from the settings or project area.
2. Confirm the **Site Title**, logo, homepage, and navigation match the values you saved.
3. Open the public URL or custom domain in a separate browser tab.
4. Test the site again in an anonymous or private browser window.
5. Check search behavior, menu visibility, and page access for both signed-in and anonymous viewing.
6. If something looks wrong, return to **Settings**, adjust the option, and save again.

[SCREENSHOT: Published documentation preview with title, logo, navigation, and homepage visible]

During verification, focus on the details readers notice first:

- The correct project is loading at the expected public address
- The homepage opens to the intended landing page
- Navigation shows the right sections and hides anything that should stay out of view
- Search behaves as expected for published content
- Restricted material is not visible to anonymous visitors

If a change does not appear right away, the issue may not be the setting itself. In Atloria, some website updates can wait for a republish, a content sync, a cache refresh, or domain propagation before they become visible everywhere. If the project workspace shows the new values but the live site still shows older ones, test again after the next publish-related update.

For a broader release check before sharing documentation externally, pair this review with [Publishing a Project from Setup to Public Release](doc:publishing-a-project-from-setup-to-public-release).

## Overview
Project settings in Atloria bring together the controls that define how a documentation workspace is identified internally and how it appears when published to readers. The most important distinction to keep in mind is that some options are for your team’s day-to-day work inside the project, while others shape the public documentation site.

The project settings workspace typically covers three practical areas:

- **Core project details** such as the project name, description, and identifying labels
- **Website options** such as site title, branding assets, homepage choice, and navigation behavior
- **Publication and access controls** such as whether the site is public, restricted, or hidden

These settings matter because they affect both contributor experience and reader experience. A clear project name helps your team find the right workspace. A well-defined site title and homepage help readers understand where they are as soon as the documentation opens. Navigation, search, and indexing settings influence how easily visitors can browse or discover content. Access controls help make sure unfinished or internal material does not appear before you are ready.

You should also expect different timing for different changes. Internal labels often update immediately in project lists and headers after you click **Save**. Website-facing changes may appear in preview first and then reach the live site after a publish step or refresh cycle.

If you are still getting familiar with project navigation before changing settings, review [Working with Project Lists and Dashboards](doc:working-with-project-lists-and-dashboards) and [Managing Project Administration from the Project Home](doc:managing-project-administration-from-the-project-home). The next step in this project settings sequence is [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls).

## Prerequisites
Before you change project settings in Atloria, make sure the project and your access are ready for administrative updates. These checks help you avoid saving changes in the wrong workspace or expecting public results before the project is prepared.

- You can sign in to Atloria and open the correct project from your dashboard or project list.
- Your account has **Project Administrator** access, or another permission level that allows changes in the project **Settings** area.
- The project already exists and has enough setup completed for website-related options to make sense, such as a defined documentation structure or homepage content.
- You know whether you are changing internal project details, public website presentation, or release visibility.
- You have the branding materials you plan to use, such as the logo or favicon, if those upload options are available in the website settings.
- You know which public address, custom domain, or site path the project should use, if Atloria shows those fields.
- You are ready to test the result in both a signed-in session and an anonymous browser window after saving.

A few preparation steps are especially helpful before editing:

- Confirm the exact project name and public site title your team wants to use.
- Decide which page or section should act as the homepage.
- Agree on whether the site should be public, restricted, or hidden during setup.
- Identify any drafts or internal-only content that must stay off the published site.

If you still need to create the project or finish onboarding, start with [Creating Projects and Completing Onboarding](doc:creating-projects-and-completing-onboarding) or [Choosing Between Manual and Connected Project Setup](doc:choosing-between-manual-and-connected-project-setup). The next document in this sequence is [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls).