How to Customize Your Zendesk Help Center

Most projects to customize a Zendesk help center start with the theme and should start with the structure. Here's how to customize a Zendesk help center without doing the work twice.

Start free trial All guides

How to customize a Zendesk help center, in order

The reason projects go badly is sequence, not skill. Teams pick fonts before they know what the categories are, then rebuild the home page when the structure changes.

1. Structure. Categories, sections, what belongs where. No code, high impact, and everything downstream depends on it.

2. Content. Enough articles that the help centre answers the top twenty questions. A beautiful empty help centre helps nobody.

3. Settings. Logo, colours, fonts, hero image, the layout toggles. Half an hour, no developer.

4. Permissions and segments. Who sees what, which requires deciding what is public.

5. Theme edits. Templates, CSS, custom blocks. Only now, and only for things the settings cannot reach.

6. JavaScript. Last, sparingly, and with a reason you can say out loud.

Most teams should stop at step four and be genuinely finished.

What you can change with no code at all

More than people assume. The theme settings panel covers brand colours, logo, fonts, the home page hero image and a set of layout toggles that vary by theme.

Beyond appearance, the whole information architecture is configuration: creating and reordering categories and sections, moving articles, promoting articles so they pin to the top of a list, setting which sections appear on the home page, and controlling visibility with user segments.

You can also switch on or off community, the request form, article comments and article voting. Each of those is a real product decision dressed as a checkbox. Comments on articles, for example, quietly turn your help centre into a support channel that nobody is assigned to monitor.

Article voting is worth turning on and actually reading. A thumbs-down with no comment tells you little on its own, but a ranked list of your worst-rated articles is the cheapest content backlog you'll ever get, and it costs you one toggle.

What needs theme edits

Anything that changes structure rather than skin. Adding a section to the home page that isn't in the theme. Changing what appears on an article page. Custom navigation. A different search results layout. Adding structured data markup.

That means Handlebars templates, CSS and sometimes JavaScript, which means either a developer or a marketplace theme that already does what you want. It also means you now own a copy of the theme, with the upgrade consequences described in the Copenhagen theme guide.

One rule that pays for itself: anything a non-developer will want to change later should be exposed as a theme setting rather than hard-coded. Every value you leave in a template is a future ticket for whoever inherits it.

The changes that actually move numbers

Most customisation is decoration. Pleasant, and it doesn't change your ticket volume. Four things do.

Search that dominates the page. People come to search, not to browse. If the search box is small, below the fold, or competing with a hero image, you have made the primary action secondary.

Article readability. Sensible line length, real font size, a table of contents on anything long. Deflection depends on people finishing the article.

A visible route to a human. Hiding the contact link raises ticket volume, because frustrated customers write angrier tickets through worse channels. Make the request form easy to find and shape it well.

Speed. Every heavy font, hero video and tracking script is a customer who left before the answer rendered.

None of those four are design decisions in the sense a designer means. They are product decisions that happen to be made in a theme editor, and they are worth arguing about.

Things to decide before you start

Three questions that change everything downstream, and are painful to reverse.

One help centre or several? Multibrand gives each brand its own help centre, its own theme and its own content. It also multiplies the maintenance by the number of brands, forever.

One language or many? Localisation shapes structure, because translated articles hang off the source article. Decide early, since retrofitting is worse than planning for it.

Public or gated? Anything behind a login is invisible to search engines. That is correct for internal documentation and a serious cost for customer-facing content.

Answer those, then start at step one. Fonts can wait.

FAQ

Frequently asked questions

How much Zendesk Guide customization needs code?

Less than you'd think. Zendesk help center customization through theme settings covers colours, logo, fonts and home page blocks, and to edit a Zendesk help center layout beyond that you edit templates.

How do you customize a Zendesk help center without a developer?

Yes, for colours, fonts, logo, hero image, structure, permissions and the layout toggles your theme exposes. Changing page structure means editing templates, and that needs a developer.

What should I change first?

Structure and content, before anything visual. Categories and sections decide how everything renders, and changing them after a theme build means redoing work.

Does customising the help center improve deflection?

Some changes do. Prominent search, readable articles and fast pages measurably help. Colours, icons and hero imagery do not move ticket volume.

Can I have different help centres for different brands?

Yes, multibrand gives each brand its own help centre and theme. Budget for the maintenance, since every article decision now happens more than once.