A support inbox tells you what a help center should say. The same question arrives on Monday, again on Thursday, and again the week after, and each time someone writes the answer out by hand. A help center is that answer written once, at an address you can send people to, and found by the customer before they write in at all.
Building one on HubSpot is mostly decisions rather than code. Where do the articles live. How are they grouped. What does the search do with the words a customer types, which are rarely the words you used. What happens when the search finds nothing. This post works through those, then shows how Help Center Pro handles each one on a single HubSpot page.
Strip away the design and the job is small.
Everything below serves one of those.
HubSpot gives you a few places to put support content, and the choice sets what the thing can do for the rest of its life.
A blog. Each article becomes its own URL with its own title and meta description, which is what you want if the articles are meant to be found in Google. The cost is that a blog is built for reverse-chronological reading. Grouping articles into topics, ordering them for a beginner, and searching across them are all things you add on afterwards.
A HubDB table. Rows become dynamic pages. This is the flexible option and the expensive one: someone has to build the templates, and every edit after that happens in a table rather than where the rest of your site is edited. Content people tend to stop editing it.
One page. The help center is a page such as /help, and the categories, articles and search all live inside it. Nothing to model, nothing to template, and the person who writes the answers edits them in the page editor. The trade is that the articles are not separate URLs, which matters for search rankings and which we come back to at the end.
For most companies the question answers itself: if the support content exists so that existing customers stop having to email you, one page is enough. If it exists to bring in new traffic from Google, it belongs on a blog.
The temptation is to map the product and write an article per feature. That produces a shelf of documentation nobody reads. Start from the inbox instead.
A short list of well-chosen articles beats a long one written to fill a structure.
Categories are the browsing route, so they have to match how a customer would describe their own problem. Group by the job being done — billing, account and security, integrations — rather than by which of your teams owns the answer. Internal org charts leak into category names and confuse everyone outside the building.
Keep the list short enough to scan in one go. A category with two articles in it should be folded into a neighbour; a category with thirty needs sections inside it. Put an article count on each card so the customer can see where the depth is before clicking.
A couple of rows earn their place above the categories. A get started row, in order, for people on day one, and a popular articles list for everyone else. The popular list is the highest-traffic real estate on the page, so it is worth curating by hand rather than leaving it to an algorithm.
If a topic is really a set of short questions rather than articles, it belongs in an accordion instead. That pattern has its own module — FAQ Pro — and mixing the two shapes on one page tends to read better than forcing everything into full articles.
Search is where most help centers quietly fail, because the box works and the results are wrong. A search that only matches exact strings sends people to your inbox with the words "I looked, there was nothing there".
It has to cope with:
Show results grouped by category, with the matched words marked, so the customer can judge relevance without opening anything. And wire up the keyboard: / or Ctrl K to focus the box, arrows to move, Enter to open. Anyone who works in software all day expects it.
An article is read by someone who is halfway through something else, so it is built for skipping rather than reading.
An empty result is the most important screen in the whole help center, and the one that usually gets a shrug emoji and nothing else.
It should say plainly that nothing matched the words they used, offer the popular articles as a fallback, and put the route to a human directly underneath. The form itself belongs on the screen they are already on, rather than behind a link to a contact page in the footer.
The detail worth building: carry their search term into the form. If somebody searched "cancel my plan" and got nothing, the message field should already say "cancel my plan" when the form opens. The question arrives with the enquiry, the customer retypes nothing, and your support team learns which article is missing.
A help center that reports nothing is a help center you improve by guessing. A couple of numbers are worth having from the first day it is live.
Every search term, with its result count. Push a search event to the data layer and it lands in Google Tag Manager with whatever analytics you already run. Sorted by frequency, the terms with a result count of zero are your content plan, in priority order, written by your customers.
Every helpful vote. An article with a run of "no" votes is either wrong, out of date, or answering a different question from the one its title promises.
Neither needs a database. Both are events fired from the page.
Help Center Pro is a HubSpot module that turns one page into the whole thing: a home view with a search hero and category cards, a view per category, a view per article, and a results view per search. Categories, articles, screenshots, videos and every word on screen are fields on the module, so the help center is written and published in the page editor beside the rest of your site. It reads no HubDB table, needs no blog, and runs on any HubSpot plan that can hold a page.
Against the decisions above:
invoice = bill, receipt. Press / or Ctrl K from anywhere on the page.The layouts are fields too, which is why the same module suits a product help center, a shop's questions, developer documentation with a command palette and articles in a side panel, or a small business with a tab per topic. Fonts and the accent colour come from your theme settings, and every colour, size, radius and label is a field, so it can be restyled and translated in full.
Every article lives on one page. Each one has its own link to share and its own address to bookmark, but to a search engine the help center is a single URL. Your articles will not rank in Google as pages of their own, and there is no configuration that changes that.
So the decision is about who the content is for. If it exists so that customers who are already on your site stop having to email you, one page is the right shape and the rankings are irrelevant. If the articles are meant to bring in search traffic — a guide per long-tail question, each one its own entry in Google — put them on a blog, where every post is a URL with its own title and meta description, and keep the help center for the answers people need while they are in the middle of something. Plenty of companies run both.
The live help center, with the search, the articles and every setup shown above, runs at nopethemes.com/help-center-pro. The module is on the HubSpot Marketplace, and the details sit on the Help Center Pro page. It pairs with Resource Library Pro when the same site also hands out downloads, and the rest of the catalogue is on HubSpot modules.
Every theme and module we sell comes with email support, including help fitting it to your brand — write to hello@studionope.com.