The moment a second help center becomes necessary is usually obvious. A company ships a second product with a different user base. An agency takes on a client that needs documentation. A team separates its internal SOPs from its public support site. The need is clear. What is less clear is how to run two help centers without paying the overhead of two separate tools, two separate logins, and two separate maintenance systems.
HelpSite's Multiple Sites feature lets you run several help centers from a single account and dashboard. Each site has its own branding, its own content, its own custom domain, and its own access controls, while the login, billing, and dashboard stay shared.
This post covers who needs multiple help centers, what you can configure per site, and how teams typically structure them.
Who actually needs more than one help center?
The answer is broader than most teams expect. The most common situations:
SaaS teams with multiple products. When two products share enough of a customer base that combining their documentation causes confusion, separate help centers clean up navigation and reduce the chance a customer reads an article written for the wrong product. Each site covers its own features, its own pricing, and its own onboarding flow.
Agencies managing client documentation. An agency running support portals for five clients needs each portal to look like it belongs to that client. HelpSite's Multiple Sites feature supports custom domains and per-site branding, so each client's portal carries their own identity. Cloning an existing site speeds up new client launches.
Teams separating internal and external docs. A public help center for customers and a private internal knowledge base for the support team serve different audiences with different needs. Keeping them separate means internal process notes, pricing guidance, and escalation paths never accidentally appear in customer-facing search results. Each site has its own privacy setting, so the internal one can stay invite-only while the public one is open to everyone.
Companies with more than one team. When every department shares one internal knowledge base, a search for "refund" turns up billing procedures, sales scripts, and engineering notes all at once. Giving each team its own private site keeps search results to the documentation that team actually uses. One company running HelpSite this way gives its dispatch team (dispatchers, dispatch leads, and ops leads) a single shared knowledge base, while billing, account management, sales, and development each have their own. Each team searches only its own docs, and nobody has to scroll past another department's processes to find theirs.
Product teams with different user segments. An enterprise product with both an end-user and an admin audience sometimes needs different documentation organized for different starting points. A separate site for each audience lets both groups navigate to answers without having to filter past content written for someone else.
What can you configure separately per site?
Each help center in HelpSite runs independently on the content and presentation side, while sharing the same account and dashboard on the management side.
Branding and themes. Each site has its own logo, color scheme, and theme settings. An agency portal looks like it belongs to the client. A second product's help center matches that product's visual identity, not the company's primary brand.
Custom domains. You can assign a custom domain to each site so it lives at a URL that fits its audience — help.yourproduct.com for one, support.yourclient.com for another. Sites without a custom domain use a HelpSite subdomain.
Access controls. Each site has its own privacy setting: public, public but hidden from search engines, private to users you invite by email, protected by a shared password, or behind your own SSO. Your customer-facing help center is public. Your internal SOP library is invite-only.
Content. Articles, categories, and structure are entirely separate per site. There is no shared content pool between them. If two products share a process that generates the same documentation, that article exists in both sites as separate items you manage independently.
AI Chatbot. HelpSite's AI Chatbot is grounded in each site's own articles, so a chatbot on your first product's help center answers from that product's content only. Customers using the second product's site get answers from that site's articles. The sources stay scoped correctly without any configuration between sites.
"I have now created 7 HelpSites. The ease and intuitiveness of building a content-rich site is not obvious until you dig in and start creating."
Bradley U., Chief Content Creator, Marketing and Advertising
How does cloning a site work?
When a second help center needs a similar structure to an existing one, you can duplicate the first site rather than building from scratch. The duplicate is an exact copy of the original, categories and articles included, which you then modify for the new site's audience.
This is particularly useful for agencies. A new client portal starts as a clone of an existing one, the content is updated for that client's product, the branding is changed, the domain is set, and the portal is ready. The alternative is building each portal from zero, which scales poorly across a client list.
For product teams, cloning is useful when a new product shares onboarding structure with an existing one. You copy the structure, update the articles that differ, and leave shared concepts in place as a starting point to edit rather than recreate.
What does the management overhead actually look like?
Each site shows up in the same dashboard, and you switch between them from one place. There is no separate login, no separate billing, and no separate tool for the second site. Everything that applies to managing one HelpSite applies to managing five.
Analytics is per site, so you can see search data, content gaps, and article performance separately for each help center. What customers of your first product search for does not get mixed into the data for your second product.
On plans that include Assignments, they work per site too. A content update request goes to the person responsible for that site's documentation without crossing into another site's queue.
What to do this week based on your role
SaaS founder adding a second product: Before creating a second site from scratch, check whether your first product's help center structure maps to what the second product needs. If the category hierarchy is similar, clone it, update the content, set the branding, and assign a custom domain. The first draft of the second help center will take an afternoon to complete.
Agency managing client documentation: Create a template site with your standard portal structure — getting started, account management, billing, troubleshooting. Clone it for each new client, swap in their branding and domain, and update the content. Each new client portal starts complete rather than blank.
CS lead separating internal and external docs: Create a second site for internal documentation and set it to private or invite-only. Move internal process notes, escalation paths, and pricing guidance there. The public help center becomes cleaner. The internal site becomes searchable without worrying about what customers might find.
Ops or department lead with several teams: List the teams that search your internal knowledge base and note which articles each one actually uses. Any team whose documentation barely overlaps with the others is a candidate for its own private site. Invite that team's members and put their articles there.
Product manager with multiple user segments: Create separate sites for end users and admins if they currently share one site with significant navigation friction. Set the access controls appropriately and use the AI KB Generator to draft the articles specific to each audience from your existing content.
"The look of the knowledge base out of the box is surprisingly good."
Andrew M., Digital Marketer, E-Learning
Frequently asked questions
Can I manage multiple help centers from one HelpSite account?
Yes. HelpSite lets you create and manage multiple help centers from a single dashboard, each with its own branding, content, domain, and access settings. You switch between sites from one place without separate logins or tools.
Can each help center have its own domain?
Yes. You can assign a custom domain to each site, or use a HelpSite subdomain. Custom domains let each help center feel native to its product or brand rather than pointing to a shared address.
Can I keep one help center public and another private?
Yes. Access is controlled per site. You can make one site public, another invite-only, and a third password-protected within the same account. Internal documentation stays separate from customer-facing content.
How does cloning a site work?
Duplicating a site creates an exact copy of it, categories and articles included. You update the content, branding, and domain for the new site from that starting point. It is useful for agencies launching new client portals or product teams creating a second help center with a similar structure to the first.
Does the AI Chatbot stay scoped to each site's content?
Yes. HelpSite's AI Chatbot answers from the articles in its own site. A chatbot on your first help center uses only that site's content. The second site's chatbot uses only that site's articles. There is no cross-contamination between sites.
Is Multiple Sites available on all HelpSite plans?
Yes. Every plan lets you run more than one help center, and the number of sites grows with the plan. See the pricing page for current limits.
Final thoughts
The reason most teams run all their documentation in one place is that managing two sites used to mean two of everything: two tools, two logins, two billing relationships. One account that handles multiple sites removes that reason.
If your team is already navigating around a single help center that serves too many audiences, the question is how quickly you can set the second one up.