Help Center SEO When Zendesk Owns Your Rankings

On this page

If your help center lives at yourcompany.zendesk.com, the SEO equity it earns is building authority for zendesk.com, not for you. That subdomain is the vendor’s domain wearing your name in the URL, and the brand string in the address confers no domain ownership in Google’s eyes. So every feature explainer, integration guide, and use-case article that ranks (the support content with real acquisition value) is leaking its compounding SEO value off your property. The fix has two parts: host-map a custom domain as the minimum viable move, and selectively migrate your highest-value, acquisition-oriented content onto your own domain, while leaving genuine operational support content where it sits.

The domain-ownership mechanic

yourcompany.zendesk.com is a subdomain of zendesk.com. The fact that “yourcompany” appears in the hostname does not make it yours; it is a label on the vendor’s domain. Google attributes signals at the domain and host level, and a vendor subdomain is, structurally, the vendor’s. The practical consequence is that when your integration guide earns links and rankings, you are contributing to the vendor’s overall domain strength rather than accumulating your own.

Be careful not to overstate this into “subdomains never build any authority for you.” That is false, and the counterexample is the whole point of the fix: a custom domain you control, or a subdomain on a domain you own, behaves as your property. The problem is specifically the vendor-owned subdomain, where the domain underneath is theirs.

Triage: acquisition content versus retention content

Not every help article deserves to move. Triage by what the content is for.

Acquisition content targets real search demand from people who are not yet customers or who are evaluating: feature explainers, integration and setup guides, use-case walkthroughs, “how to do X” articles that map to genuine query volume. This is the content whose ranking value you want on your domain, because it pulls in prospects and builds your topical authority.

Retention and operational content serves existing customers who are already logged in and looking for account-specific help: billing questions, password resets, plan management, internal account settings. This content rarely targets meaningful external search volume, and its SEO value on your domain is marginal. It can stay on the platform without much loss.

The triage rule prevents the common error of over-migrating: hauling low-value operational pages onto your CMS for no ranking benefit and a lot of maintenance overhead.

There is also a middle category worth naming, because it causes most of the disagreement during triage: content that serves existing customers but happens to rank for external demand anyway. A detailed troubleshooting guide for a feature can be read mostly by current users and still pull in prospects searching the same error before they buy. When a page straddles the line, let the search data settle it rather than the article’s stated purpose.

The deciding test is simple. If the page earns meaningful non-branded impressions from people who are not logged in, treat it as acquisition and move it, even though it doubles as support. The cost of leaving a genuine acquisition asset on the vendor subdomain is the leakage the whole exercise is meant to stop, so when in doubt the bias is to migrate the page that ranks and keep only the pages that no outside searcher ever looks for.

A practical way to run the triage is to pull the help center’s own page-level analytics and any rank data you can get, then sort articles by external search entrances and impressions. The articles bringing in non-logged-in visitors from search are your acquisition candidates; the articles viewed almost entirely by authenticated, existing users are operational. Cross-check against query intent: an article that ranks for a feature or integration term is acquisition even if traffic is currently low, because the demand is real and you are simply not capturing it yet on a domain that benefits you.

Host mapping is the minimum viable fix

Zendesk’s mechanism for serving your help center under your own domain is host mapping. You point a CNAME record from a subdomain you own (for example help.yourcompany.com or support.yourcompany.com) to your Zendesk subdomain, and you enable SSL. Zendesk provides free Let’s Encrypt certificates for host-mapped domains, or you can upload your own. The served hostname becomes your domain rather than the .zendesk.com address.

Host mapping changes the hostname that is served and that users and crawlers see, which is why it is the immediate, low-effort move. State the authority implication cautiously: serving the content under a hostname on your own domain is what lets the content count toward your domain rather than the vendor’s, but verify the current behavior for your setup rather than assuming a guaranteed transfer of historical equity. The content underneath still renders from Zendesk’s infrastructure; what changes is the public hostname.

Full integration is the heavier, stronger option

Host mapping gets the content onto your domain but it still lives in a separate property with the platform’s templates and its own navigation, somewhat siloed from your marketing site. The stronger version is full integration: bringing the high-value articles into your own marketing CMS, where they share your site’s navigation, templates, and internal linking, and where they can be interlinked with your product and content pages.

The tradeoff is effort against payoff. Host mapping is a DNS change and an SSL toggle. Full integration is a content migration and an ongoing editorial commitment. The decision rule: host-map everything for the immediate hostname fix, then fully migrate the specific acquisition articles whose ranking and conversion value justifies living natively in your marketing site.

Migration mechanics, done correctly

When you move an article from the platform to your domain, the mechanics determine whether you keep the equity:

  • Set 301 redirects from the old platform URLs to the new ones so accumulated link signals and rankings follow the page.
  • Understand what canonical can and cannot do here. A canonical tag from the platform page to your domain only behaves correctly if equivalent content genuinely exists at the target. If the content does not yet exist on your domain, you are not canonicalizing, you are migrating, and you need the real page plus the redirect. Never point a canonical at a page that does not exist.
  • Use the migration to improve the content, not merely relocate it. The articles were written as support docs; rewrite them as acquisition content with the depth, context, and search-intent match that ranks. Moving a thin article unchanged just relocates a thin article.

The community-forum variant

The same mechanic, often with higher stakes, applies to a community forum hosted on a vendor subdomain. User-generated content (questions, answers, threads) accumulates enormous long-tail coverage over time, and on a vendor subdomain all of that authority builds for the vendor. Because UGC scales far beyond what your team writes, the leakage can be larger than the help center itself. The fix is identical: host-map the community onto your domain so the long-tail equity accrues to you.

Frequently Asked Questions

Does putting my brand name in the subdomain help my SEO at all?

No. yourcompany.zendesk.com is still a subdomain of zendesk.com; the brand string in the hostname is irrelevant to which domain Google attributes the signals to. Only serving the content under a domain you actually own (via host mapping or migration) changes that.

Should I move my billing and password-reset articles too?

Usually not. Those are retention and operational pages that target little external search volume. Moving them adds maintenance overhead for negligible ranking benefit. Migrate acquisition content; leave operational support on the platform.

Sources

Zendesk Help, “Host mapping: Changing the URL of your help center” (CNAME plus SSL setup): https://support.zendesk.com/hc/en-us/articles/4408838571930
Google Search Central, Consolidate duplicate URLs (canonicalization and redirects): https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls