How to Turn Your Notion or Confluence Docs Into a Public Help Center

Most teams that need a public help center have already written one. It is sitting in Notion or Confluence right now, spread across forty-odd pages, and the only people who can read it are the people who already know the answers.

So the job is not writing. It is working out which of those pages were always meant for customers, then moving those onto a surface built for strangers. Here is how that actually goes: what Notion and Confluence give you when you publish, where publishing stops being enough, and the order to do the work in so you do not break the links your support team has been pasting into tickets for the last two years.

First, what publishing actually gives you

Worth starting here, because "Notion cannot do public docs" is wrong, and someone will tell you so about ten minutes after you repeat it. Both tools publish to the web. A Notion knowledge base and a Confluence knowledge base can both be read by people who have never logged in. The question is what you get when they are.

Notion

Publishing is per page, and that single fact shapes everything about a Notion help center. Open the page, hit Share, switch to the Publish tab, select Publish. The page goes live on a notion.site URL and updates whenever you edit the original, which is genuinely useful and the main reason people try it.

Three details decide whether it works as a customer-facing site:

• Every subpage comes along. Publishing a parent publishes its children. If your "Help" page has a child called "Pricing experiments Q3," that is now on the internet.
• Indexing is a toggle, and it is slow. Under Search engine indexing, switch on Discoverable on the web. Notion's own documentation says sites can take up to four weeks to be indexed and start appearing in search results.
• Your domain and your search are add-ons. Free workspaces get one notion.site domain. Putting the docs on a domain you already own means buying the Sites add-on on a paid plan, and search on a published site is a paid-plan feature as well.

There is also no password protection on published pages. Published means published.

Confluence

Opening up a Confluence knowledge base takes two switches, and they are usually held by two different people. A site admin goes to Security > Anonymous access and ticks Use Confluence. Only then can a space admin grant anonymous access to an individual space.

Once they do, anonymous visitors see everything in that space unless a specific page carries its own restriction, and restrictions cascade down to child pages. Atlassian is refreshingly blunt about what follows: content shared with anonymous users will show up in Google searches. It is also all or nothing. There is no way to share a space with some anonymous people and not others.

The word doing the work in both products is anonymous. Your customers are not a permission level, they are the audience. That difference in framing is where the friction starts.

Where it stops being enough

None of what follows means these are bad tools. It means they are internal tools with a public setting, which is a different thing from a public product.

1. The default runs the wrong way. In a wiki, everything in scope is visible unless someone restricted it. In a help center, nothing is visible until someone published it. Those two defaults fail in opposite directions. The wiki version fails toward accidentally public, and it fails quietly, because nobody gets an alert when an internal page inherits its parent's visibility.

2. Search assumes the reader speaks your language. Workspace search is tuned for people who know the project codename, the acronym, and roughly where the page lives. Your customer knows none of that. They type "card declined" and your article is titled "Payment Processing Failure States." Internal search leans on structure the reader cannot see, and customer search has to lean on synonyms and phrasing instead.

3. You cannot tell whether an article worked. Page views tell you a page was opened, not that a question got answered. The reports that actually change what you write next are the search terms people typed, the searches that returned nothing, and the per-article thumbs down. The zero-result search list in particular is the closest thing to a free content backlog, and neither wiki keeps one for you.

4. It only helps people who leave your product to find it. A published docs site is a destination. The question, though, gets asked inside your app, at the moment someone is stuck on a screen. Docs that cannot be surfaced in that moment get read by the people who were already determined enough to go looking.

Three signs you have already outgrown it

Plenty of teams publish a wiki space and are fine for years. These are the signals that you are not one of them.

Support pastes the same link, then explains it anyway. If the standard reply is a wiki URL followed by two paragraphs of translation, the content is right and the surface is wrong. The article was written for a colleague and it is being handed to a customer.

Someone has asked "wait, can customers see this?" more than once. That question is a symptom, not a one-off. It means the boundary between internal and public runs through a permissions setting rather than through the structure, and nobody is fully sure where it sits today.

You cannot say which article gets read the most. Not "cannot say precisely," but cannot say at all without opening pages and guessing. Once documentation is a real support channel, running it without numbers is the same as running a support queue without a ticket count.

The move, in six steps

Roughly a week of real work for a mid-sized doc set, most of it in steps one and two.

Step 1: Sort by audience, not by topic

Export a list of every page in the space or workspace and mark each one customer, internal, or both. Not "is this good," just "who is it for." The customer list always comes out shorter than people expect, and that is the useful part: you now know the real size of the job instead of guessing at it.

The both pile is where the judgment goes. A page explaining how a feature works is usually two documents wearing a trench coat: a customer explanation, and an internal note about why it behaves that way. Split them now, while you still remember which half is which.

Step 2: Rewrite for someone who does not work at your company

Internal docs are full of load-bearing context nobody wrote down. Strip out the @mentions, the Jira links, the "ask Marco if it errors," the team acronyms, and the screenshots of the admin panel your customers cannot open.

Then retitle everything as the question the reader would ask. "Payment Processing Failure States" becomes "Why was my card declined?" This one pass does more for findability than anything you will do in step six, because it aligns the title with the words people actually search.

Step 3: Flatten the page tree into categories and articles

Wikis nest, because nesting mirrors how teams think. Help centers stay flat, because flat mirrors how strangers browse. Aim for categories at the top, articles inside them, and nothing buried three levels deep. If an article only makes sense after reading two parents, it is not an article yet.

A working rule: if you need more than a dozen categories, the categories are too specific and you are rebuilding the page tree with new names. Group by the job the reader is doing (getting set up, billing, troubleshooting) rather than by the part of the product that owns the feature, because readers do not know your org chart.

This is also the moment to decide what a "page" is. Wiki pages sprawl, because there was never a cost to adding one more section. A help article answers one question and links to its neighbours instead.

Step 4: Get the content out

Both exports have a catch worth knowing before you start.

In Notion, export from the ••• menu on any page and choose Markdown & CSV, HTML, or PDF. The catch is Include subpages, which is a Business and Enterprise option. On lower plans you are exporting page by page, so budget for that or copy the tree manually.

In Confluence, a single page exports only to Word or PDF, neither of which you want. The format you want, HTML, lives at the space level: Space settings > General > Export space, which also offers PDF, CSV, and XML. That export is space-admin only, and you only get the content you personally have permission to see, so have the right person run it.

If the doc set is large or the formatting is fiddly, most help center vendors will do this part for you. Ours is included on Growth and Catalyst annual plans, and there is more detail on done-for-you migration if that is the route you take.

Step 5: Put it on your own domain, then redirect

Publish to a subdomain you control, help.yourcompany.com or similar, before you announce anything. Two reasons: the SEO value accrues to your domain rather than a platform's, and you can move vendors later without reprinting every link.

Then redirect the old URLs. Those notion.site links are in shipped emails, onboarding sequences, and two years of support replies. Keep a spreadsheet mapping every old URL to its new home as you go, because reconstructing it afterwards is miserable.

Match the look of your product while you are here. Customers should not feel handed off to a different company halfway through a support question, which is most of the reason we rebuilt our own template editor around design changes that do not need a developer.

Step 6: Turn on the feedback loop

Now the part the wiki could not do. Switch on per-article helpfulness voting, and check the search report weekly, especially the searches that returned nothing. Every zero-result search is a customer telling you exactly what to write next, in their own words.

If you add AI answers on top, ground them in your published articles rather than a general model, so a wrong answer is a content bug you can fix rather than a mystery. On our plans that is included on Catalyst at $179/mo, and a $29/mo add-on on Bootstrap and Growth, $24/mo billed annually.

What stays exactly where it is

Keep the wiki. This is a split by audience, not a migration off a tool you like.

Confluence sitting next to Jira, with the runbooks and the architecture decisions and the incident write-ups, is doing a job a help center should not try to take. Notion holding specs, meeting notes, and the half-finished thinking is the same story. Both are good at the messy internal middle, and a help center is deliberately bad at it, because everything in a help center is finished and public by definition.

What changes is that customer-facing content stops living as a special case of internal content. If you want the longer version of how to keep the internal side healthy after the split, we wrote that up in our guide to building an internal knowledge base.

And if you are weighing whether to move at all, the honest comparisons are here: HelpCenter.io and Notion side by side, and HelpCenter.io and Confluence side by side. Both name the cases where staying put is the right call.

Frequently asked questions

Can you use Notion as a public knowledge base?

Yes, with limits. Publishing a page makes it and all of its subpages public on a notion.site URL, and you can toggle on search engine indexing. Using your own domain and adding search to the published site are paid add-ons, there is no password protection, and you get page views rather than article-level search and helpfulness data.

Can people without an account see Confluence pages?

Only if two things are switched on. A site admin has to enable anonymous access under Security, then a space admin has to grant it for that specific space. After that, anonymous visitors can see everything in the space except pages carrying their own restrictions, and Atlassian notes that content will show up in Google searches.

Will a public Notion or Confluence page rank on Google?

It can be indexed, which is not the same as ranking. Notion requires the indexing toggle and says it can take up to four weeks to appear, and Confluence's anonymous spaces are indexable by default once public. What neither gives you is the per-article control that ranking usually needs: titles and meta descriptions written per page, a clean URL structure on your own domain, and a sitemap you manage.

How do I move the content without breaking existing links?

Map before you move. Build a spreadsheet of every published URL and its destination as you migrate, then set up redirects from the old addresses before you switch anything off. Support replies, onboarding emails, and in-product links tend to outlive the pages they point at.

Do I have to stop using Notion or Confluence?

No, and most teams should not. The split that works is customer-facing content in a help center, internal knowledge in the wiki. Keeping Confluence next to Jira or Notion for specs costs you nothing once the public docs have moved somewhere built for the public.