Site Structure
Site Structure gives you one place to see and manage how your Higher Logic Vanilla (Vanilla) community is organized.
Instead of managing Categories, subcommunities, Knowledge Bases, and Language Settings on separate pages, you can see how they fit together in a connected hierarchy. You can make changes in context, review them before they affect members, and apply related changes together as a Site Structure Plan.
Site Structure is useful for both simple and complex communities. A single-language community can use it to organize Categories and permission-gated areas. A multilingual community can also use it to plan how static languages, AI Languages, and subcommunities should work together.
NOTE: Site Structure is available across all plans and does not require a feature flag. Existing plan entitlements and quantity limits still apply to features such as Knowledge Bases and subcommunities.
In this article
- Understand the Site Structure hierarchy
- Understand the global area and subcommunities
- Navigate a large structure
- Manage Categories and subcommunities
- Manage permissions with Permission Sets
- Review layouts and Style Guides
- Choose a language structure
- Review and apply your changes
Understand the Site Structure hierarchy
The Site Structure page shows your configured languages, subcommunities, Knowledge Bases, Categories, and subcategories in one hierarchy.
Use the counts and labels shown for each branch to understand what it contains. Expand a branch to see the content organized beneath it, or collapse the hierarchy for a higher-level view.
Understand the global area and subcommunities
Your community has one global content area. That global area uses either your community's default static language or AI Languages.
Every separately navigable area outside the global community must be a subcommunity. This includes additional static-language experiences and separate regional, regulatory, partner, developer, or other audience destinations.
IMPORTANT: Adding a non-default static language does not create a destination that members can navigate to. For example, if English is the default static language and you want members to visit a separate French experience, create a French-language subcommunity.
Navigate a large structure
Site Structure includes several ways to work with a large hierarchy:
- Use Expand All and Collapse All to switch between a detailed hierarchy and its highest structural levels.
- Select Focus to view one language, subcommunity, or Category branch. Use the breadcrumb to confirm your location, and select Clear to return to the full hierarchy.
- Select View to open an area on the community front end and confirm its member-facing destination.
Manage Categories
You can add and edit Categories directly where they belong in the Site Structure hierarchy.
Depending on the Category type and the features enabled in your community, its settings can include allowed post types, event creation, default idea status, visibility options, guest preview, and custom permissions.
The Category actions menu can also include:
- Merge — Combine the selected Category with another Category.
- Move — Move the Category to another location in the hierarchy without recreating it.
- Delete — Permanently delete the Category and the content identified in the warning.
- Manage Layouts — Review inherited and overridden layout assignments.
- Focus — View only the selected branch.
- View — Open the member-facing destination.
IMPORTANT: Delete is not a merge action. It can permanently delete the Category, its nested Categories, discussions, and comments. Review the content summary and warning before adding the deletion to your plan.
Add a subcommunity
You can create a subcommunity directly in the appropriate language or structural branch.
- Select Edit.
- Locate the branch where you want to add the subcommunity.
- Select Add Subcommunity.
- Configure the available settings, such as its name, URL code, description, language, Home Page, community content, default idea status, and permissions.
- Save the subcommunity.
- Review the new subcommunity under Pending Operations.
NOTE: You do not have to create a separate Nested Category first and then associate it with the subcommunity. Existing plan entitlements and quantity limits still apply.
IMPORTANT: Use a subcommunity whenever members need a separately navigable destination outside the global community. A configured non-default static language does not create that destination by itself.
Manage permissions with Permission Sets
By default, a Category or subcommunity uses its inherited or global permissions. Enable Custom Permissions when the area needs different access rules.
The Social Groups Category is an exception to category-level permissions. In Site Structure, its Access section displays an informational message instead of editable permissions. Access to Social Groups content is managed by group membership, Group Settings, and the groups.moderate permission.
Permission Sets let you assign roles to practical access levels without configuring every individual permission separately. The available out-of-the-box sets can include:
- Read Only
- Comment Only
- Contributor
- Category Moderator
- Category Admin
Each Permission Set shows the permissions it includes. Assign the appropriate roles to each set, or select Add Permission Set to create a set for a more specialized access model.
TIP: Permission Sets are useful for areas such as partner communities, customer councils, private feedback spaces, and moderated programs. Site Structure keeps these restricted areas visible in the administrative hierarchy without changing who can access them.
Manage layouts
Select Manage Layouts for a Category or structural area to review its layout assignments.
The Assignment Source shows whether a layout is inherited from a broader default or explicitly overridden for the selected area. Depending on the context, tabs can also show default and language-specific assignments.
TIP: Check whether a layout is inherited before creating an override. The correct layout might already be applied through a broader site, language, or subcommunity default.
Review applied Style Guides
The Applied Style Guides view shows the Style Guides currently in use across the community. Use it to confirm whether a guide is the site default or is assigned to a specific language or subcommunity.
Continue to use the Style Guides page to create, copy, edit, and apply Style Guides.
Choose a language structure
Use Manage Languages to choose how the global community and its subcommunities should handle languages.
The available structures are:
Single Static Language
Use your community's default static language in the global area. This is best for a community that is manually managed in one language and does not need AI translation.
If members need a separate destination in another static language, create a subcommunity for that language.
Static Subcommunity Languages
Keep the default static language in the global area and use separate, manually translated subcommunities for other language destinations.
This is best when different language or regional communities need independent editorial control, different information, or content that should not be automatically translated.
IMPORTANT: Adding the languages is only the first step. Create a subcommunity for each additional language destination, and then add or move its Categories and Knowledge Bases into that subcommunity.
AI Languages
Make the global area the AI Languages community. Existing subcommunities included in the migration are removed, and their Categories and Knowledge Bases are moved into the global AI Languages area.
This is best when the goal is one shared community structure that members can experience across supported AI languages.
IMPORTANT: This is a structural consolidation, not just a translation setting. Review the migration warning carefully before continuing.
AI Languages and subcommunities
Use AI Languages for the global area while keeping selected subcommunities as separate static-language or AI-translated destinations.
This is best when the main community should use AI translation but some regions, audiences, regulatory experiences, or Knowledge Bases still need their own destination.
For each existing subcommunity, you can:
- Keep as Static Language Subcommunity — Keep the subcommunity separate and manually translated.
- Move Categories to AI Languages — Move its community Categories to the global AI Languages area while keeping the subcommunity and its Knowledge Bases in place. The retained subcommunity can become a Knowledge-Base-only destination.
- Move All Content to AI Languages — Move its Categories and Knowledge Bases to the global AI Languages area and remove the now-empty subcommunity.
- Set Subcommunity to AI Translation — Keep the subcommunity as a separate destination and use AI translation for its content.
NOTE: Choosing a language structure does not enable AI Translations or change the number of languages available to your community. See AI Translations for availability, enablement, supported content, and data-handling information.
Merge equivalent Categories during migration
When Categories from several existing subcommunities move into the global AI Languages area, you can organize equivalent Categories into merge sets.
Suggested merges are a starting point, not an automatic decision. Confirm that the Categories represent the same topic, choose which Category's settings should be retained, and keep Categories separate when similar names hide meaningful regional, regulatory, audience, or workflow differences.
Translate historical content
When historical translation is included in your approved migration scope, you can select eligible admin-generated and user-generated content to translate.
Review the content types, translated and untranslated counts, and the selected time range for user-generated content before applying the plan. The exact inventory depends on your community's configuration, and completion time depends on the amount of content selected and the size and history of the community.
IMPORTANT: Historical content is not translated automatically. AI-processing preferences and the data-handling guidance in the AI Translations article continue to apply.
[Product/CSM confirmation required before publication: reconcile Site Structure historical-content selection with the current paid SOW guidance in AI Translations.]
Review and apply your changes
Changes made in edit mode are added to a draft plan and listed under Pending Operations. They do not affect members until you apply the plan.
Before applying the plan:
- Review the plan name.
- Open Pending Operations.
- Review each operation and its details.
- Confirm the content location, permissions, language handling, layouts, and member navigation.
- Apply the plan.
IMPORTANT: Some operations depend on earlier operations and are completed in order. Large plans, especially plans that include translation, can take time to finish.
See Site Structure Plans to learn how to review, apply, and monitor a plan.
Related articles