Every knowledge base starts with a simple question that is easy to skip: who is supposed to read this? A help center for customers should be easy to find, ideally through search engines. A wiki with internal processes, price calculations or client-specific setups should not be. Many teams only notice the difference after something sensitive went public, or after customers couldn't find answers that were locked away for no reason.
In this guide, we at eniston walk through the four access models we see most often: a public help center, password-protected client documentation, an IP-restricted internal wiki and a login-only team knowledge base. For each one, we explain when it fits, what to watch out for and how to set it up. If you're still at the very beginning, our guide on how to create a knowledge base covers purpose, structure and launch first.
Before you change a single setting, write down who reads what. Most organizations have more than one audience:
Prospects and customers who want answers before and after they buy.
Clients who need documentation that is specific to their project or contract.
Employees who need internal processes, policies and onboarding material.
Partners or contractors who need a limited part of the internal knowledge.
Then sort your content by one question: what would happen if a stranger read this article? If the answer is "nothing, and they might even become a customer," it belongs in a public knowledge base. If the answer is "it would be awkward, confusing or a risk," it belongs behind some kind of restriction.
This usually shows that you don't need one knowledge base with complicated rules, but two or three separate ones, each with a clear audience. That is easier to maintain and harder to get wrong.
A public knowledge base is open to everyone: the classic help center with setup guides, FAQs and troubleshooting articles.
Your content helps people use your product or service.
You want customers to solve problems on their own instead of opening a ticket.
You want your articles to be found through search engines, because prospects often search for a problem before they search for a vendor.
Public means public. Screenshots can show customer names, email addresses or internal URLs. Example data can look a lot like real data. Before an article goes live, check every image and code sample, not just the text.
Also think about search engines. A public help center usually benefits from being indexed. A knowledge base that is technically open but meant for a small group, for example a staging version or an archive, often shouldn't appear in search results at all.
By default, anyone with the link can view the categories and articles of an eniston workspace, so a public knowledge base needs no extra configuration. In the SEO settings, you can set a meta description for the workspace homepage and for each category. If a workspace should stay out of search results, you can block bots from crawling it. eniston then adds noindex, nofollow and noarchive to the meta robots tag. Keep in mind that this only keeps a workspace out of search engines. It does not stop anyone who has the link.
For good public articles, our knowledge base article templates give you a copy-and-paste starting point for how-to guides, troubleshooting pages and FAQs.
A password is the simplest way to share documentation with a defined group of people who don't have, and don't need, an account. Agencies use this for client handbooks, consultants for project documentation.
The readers are outside your organization.
You don't want to manage individual accounts for them.
Everyone in the group may see the same content.
A shared password is shared. People forward it, write it into a chat or keep using it after a project ends. Treat it as a way to keep content out of public view, not as strong protection for sensitive data. Change the password when a project or contract ends, and don't put information behind it that would cause real harm if it leaked.
eniston lets you set a simple password for an entire workspace and for individual categories. Both work the same way, and you can combine them. That gives you two useful patterns:
One password per workspace, for example one workspace per client, each with its own password and, if you like, its own custom domain.
One public workspace with protected categories, for example a public help center with a "Partners" or "Premium customers" category behind a category password.
You can also pass the password in the URL by adding ?pw=YOUR-PASSWORD to the link, so readers open the content directly without typing anything. If readers shouldn't see the actual password, use the pwe parameter with an encrypted version instead. The restricting access article explains how to create it. This is practical for links inside your own app or client portal. Just remember that anyone who has such a link can open the content, so share it as carefully as the password itself.
If you run documentation for several clients, our playbook on how agencies can run a separate help center for every client goes deeper into workspaces, branding and handover.
An IP restriction allows or blocks access based on where a visitor connects from. If your team works from an office network or connects through a company VPN, the knowledge base only opens for people on that network.
Your team connects through a fixed set of IP addresses, such as an office connection or a VPN.
You want internal content to be available without a login prompt.
The content is internal, but not so sensitive that it requires individual accounts.
IP restrictions depend on your network setup. If people work from home without a VPN, or your provider changes your IP address, access breaks. Document which addresses are allowed and who is responsible for updating them. If you work remotely a lot, our post on what remote work means for knowledge management covers the bigger picture.
eniston offers two IP options per workspace, described in our help center under restricting access:
IP whitelist: blocks all IP addresses and only allows the ones you add.
IP blacklist: allows everyone and blocks specific IP addresses.
You can add multiple addresses separated by commas. Note that eniston currently supports IPv4 addresses only, so check with whoever manages your network before you rely on it.
The strictest model requires every reader to have their own account. Nobody gets in without an invitation, and you can remove one person without affecting anyone else.
The content is confidential, for example internal processes, HR policies or client details.
You need to know exactly who has access.
People join and leave regularly, and access should follow that.
Every reader needs an invitation, so plan who sends them and who removes people when they leave. With per-user pricing, this model also tends to get expensive quickly, because readers who only open the wiki once a month count as seats. We explain the math in per-user pricing for knowledge base software.
With frontend authentication enabled, only members of your team can access the workspace, and you invite each of them yourself. Assign the Read-only role to people who should read but not edit. Editors, Extended Editors and Admins get more rights step by step, as described in roles and permissions. Team features are available on our Business plan. Because we don't charge per user, adding more readers doesn't change the price.
This model is a good fit for onboarding. Our guide to an internal knowledge base for onboarding shows a "Start here" structure that works well behind a login.
Most organizations end up with more than one model, and that's fine. A few rules keep it manageable:
One audience per workspace. Instead of mixing public and internal content and hiding parts of it, give each audience its own workspace. Each eniston workspace can have its own team, custom domain and settings.
Use category passwords for exceptions, not as a structure. One protected category in a public help center is fine. Ten of them with different passwords is a sign you need a separate workspace.
Name things clearly. A reader should always know whether they're in the public help center or the internal wiki. A different logo, color or domain, such as help.yourcompany.com and wiki.yourcompany.com, prevents mistakes on both sides.
Link from private to public, rarely the other way around. Internal articles can point to public ones. A public article that links into a protected area only frustrates readers who can't open it.
Review access regularly. Once a quarter, check who is on the team, which passwords are in use and which IP addresses are allowed.
Before you publish or share a restricted knowledge base, go through this list:
Open the knowledge base in a private browser window and confirm what an outside visitor actually sees.
Check screenshots, attachments and code samples for personal data or internal details.
Decide whether search engines should index the workspace, and adjust the SEO settings accordingly.
Write down which passwords and IP addresses are in use, and who can change them.
Use the least access that works: Read-only for readers, editor roles only for people who write.
If you handle personal data, review your data processing agreement and hosting location. Our GDPR checklist for EU teams covers what to ask.
There is no single right answer to "public or private." A public help center helps customers and gets found. Password protection works for client documentation without accounts. An IP restriction suits teams on a fixed network, and a login-only knowledge base is the right choice for confidential internal content. The key is to decide per audience, give each audience its own space and review access regularly.
If you'd like to try these options on your own content, start your free 30-day trial. No payment information is required. Our plans are flat, with no per-user fees: Plus at €8 per month with 2 workspaces and Business at €28 per month with 10 workspaces (excl. VAT). Our servers are located in Germany. See pricing for details.
Our knowledge base software offers a great variety of features to manage your knowledge articles. Try eniston for free for 30 days. No credit card required.
