Embed a Zendesk Help Center in Your Website

Four ways to embed a Zendesk help center in a website. Three of them are fine. One quietly costs you the SEO value of everything you wrote.

Start free trial All guides

Decide what embedding a Zendesk help center in your website should do

The question hides three different goals, and the right answer depends entirely on which one you have.

You want the help centre to live on your domain. That's host mapping, not embedding, and it is usually the correct answer.

You want help content inside your product. That is the widget or the API, depending on how much control you need.

You want one specific article on one specific marketing page. That's the API, or honestly, a link.

People say "embed" for all three. Sorting out which one you mean saves a lot of wasted work.

Host mapping, the answer most people need

Zendesk lets you serve the help centre from your own subdomain, something like support.yourcompany.com, with a CNAME pointing at Zendesk and a certificate handled for you. Check the current docs for the setup steps, since the SSL side has changed over the years.

This is not embedding, and it beats embedding on nearly every axis. The content stays on your domain for branding and for search engines. Zendesk still renders it, so search, breadcrumbs, article voting and the request form all keep working. Nothing to maintain.

If your reason for embedding was "our help centre is on a Zendesk URL and that looks bad", stop here. This solves it.

The iframe route to embed a Zendesk help center in a website

You can drop the help centre, or a single article, into an iframe on your page. It takes about four minutes and it's the option that causes the most regret.

Search engines do not credit iframed content to the host page. The article is indexed at its Zendesk URL, if at all. All that documentation you wrote earns you nothing on your own domain.

Navigation breaks. Links inside the frame either trap the user in a small box or escape it awkwardly.

Mobile is bad. Nested scrolling on a phone is genuinely unpleasant.

Deep linking is gone. You cannot send someone a URL for the thing they're looking at.

There is one honest use for it: an internal tool, on an internal page, where nobody is searching and nobody is on a phone. Otherwise pick something else.

The API route

Zendesk exposes help centre content through its API. You fetch articles, sections and categories as JSON and render them in your own pages with your own markup.

This is the option with real upside. The content is genuinely on your site, in your HTML, indexable, styled by your design system, and free to sit anywhere in your information architecture. A docs page that reads as part of your product rather than as a bolted-on subdomain is worth something.

The costs are equally real. You are now building and maintaining a rendering layer: caching, images, internal links between articles, search, and a plan for what happens when the API is slow. You also need to decide whether the Zendesk-hosted copy stays public, because if it does you have the same article at two URLs and want a canonical pointing at one of them.

Do this when help content is a serious acquisition channel and you have engineering time to keep it alive. Do not do it to avoid a subdomain.

The widget route

The Zendesk widget puts search and article previews in a launcher on your existing pages, without changing your page structure at all. Contextual help inside a product, in other words.

It's the right tool when the goal is deflection at the point of confusion: someone stuck on your pricing page or mid-setup, who wants an answer without leaving what they are doing. It contributes nothing to SEO, because it is JavaScript-rendered chrome rather than page content, and that's fine. That was never its job.

Widget and host mapping together is the combination most companies end up with, and it is a good one. See the web widget guide for the configuration side.

The SEO summary

Host mapping. Content on your domain, indexed normally, zero maintenance. Best default.

API rendering. Best possible SEO outcome, real engineering cost, watch for duplicate URLs.

Widget. No SEO effect either way, excellent for in-product deflection.

Iframe. No SEO benefit to your domain, plus usability problems. Internal use only.

FAQ

Frequently asked questions

Iframe, API or host mapping: which is best for SEO?

Host mapping. Putting the Zendesk help center on own domain keeps the SEO value with you. A Zendesk help center iframe hands it to Zendesk's domain, and a Zendesk knowledge base API embed keeps it only if you render the content server-side.

Can I embed a Zendesk help center in my website on my own domain?

Yes. Host mapping serves it from a subdomain you control, using a CNAME record. It is the standard approach and is almost always better than embedding.

Does embedding Zendesk articles in an iframe hurt SEO?

It does not help it. Search engines attribute iframed content to its own URL rather than to the page hosting the frame, so the article earns nothing for your domain.

Can I pull Zendesk articles into my own site with the API?

Yes, the help centre API returns articles, sections and categories. You render them yourself, which gives full control and full maintenance responsibility.

Will I have duplicate content if I render articles on my site?

You can, if the Zendesk-hosted copy stays public. Decide which URL is canonical and point the other at it, or restrict the Zendesk copy.

Which embedding method is best for in-product help?

The widget. It surfaces search and articles where the user is stuck without moving them off the page, which is exactly what contextual help should do.