---
title: "How to Set Up Help on Your Own Domain"
canonical: https://supportpages.io/guides/set-up-help-on-your-own-domain
updated: 2026-08-13
---

Your help centre answering on a hostname you control, over HTTPS with a valid certificate, with the vendor URL redirecting rather than competing. The DNS part takes ten minutes. The part that goes wrong is what happens to the old URL.

## Before you start

You need access to the DNS zone for your domain, admin access to your help centre tool, and confirmation that the tool supports custom domains on your plan - some charge for it, and finding out after you have announced the change is a poor sequence. Check also whether the tool issues certificates automatically or expects you to supply one, because that decides half the steps below.

![A DNS chain: your subdomain points at the host, which provisions a certificate and serves the help centre.](/images/guides/figures/set-up-help-on-your-own-domain.webp)

*One CNAME. The certificate is the part that happens without you.*

## Steps

1. **Pick the hostname before touching DNS.**
   A subdomain of your main domain, chosen once. Changing it later means a second migration with a second set of redirects, and each migration loses a little of whatever the pages have accumulated.

2. **Check whether your tool needs a CNAME or an A record.**
   Most managed help centres want a CNAME pointing at their edge hostname. This is why an apex domain rarely works: a CNAME at the apex conflicts with the zone's own records, so apex hosting requires ALIAS or ANAME support from your DNS provider, or fixed A records from the vendor.

3. **Check your CAA records before requesting a certificate.**
   If your zone has CAA records naming particular certificate authorities, and your help centre provider uses a different one, issuance fails with an error that rarely names the real cause. Add the provider's authority to the CAA set, or remove the restriction.

4. **Add the DNS record with a short TTL.**
   Five minutes while you are working, raised afterwards. A 24-hour TTL on a record you are about to correct is a day of waiting for each mistake.

5. **Register the hostname in the help centre tool and wait for the certificate.**
   Issuance usually takes a few minutes and depends on the DNS record resolving first. If it stalls, check propagation from an external resolver rather than from your own machine, which may have cached the old answer.

6. **Force HTTPS and check for mixed content.**
   Load an article with images and inspect the console. Absolute `http://` image URLs stored in old article bodies are the usual culprit, and they will show a broken padlock on exactly the pages customers read most.

7. **Redirect the vendor URL to the new hostname.**
   If the tool offers this, enable it. If it does not, set the canonical tag on the vendor pages to the new hostname. Leaving both live and indexed splits every ranking signal each page has between two copies of itself.

8. **Update every link you control.**
   In-app help, email templates, support macros, the main site's footer and navigation. This is the step that takes the longest and the one that determines whether the old hostname actually goes quiet.

9. **Add the new hostname as a Search Console property and submit the sitemap.**
   It is a separate property from your main site even though it is a subdomain, so it needs its own verification, its own sitemap submission and its own coverage report.

## Common mistakes

**Pointing an apex domain at a CNAME.** It either fails outright or breaks your MX and TXT records, taking email down with it. Use a subdomain unless your DNS provider explicitly supports ALIAS records.

**Leaving the vendor URL indexed.** Two copies of every article compete with each other, and the vendor URL is usually the one with the older, stronger link profile - so search results keep sending people to the copy you were trying to retire.

**Forgetting robots.txt on the new hostname.** A subdomain serves its own robots.txt, not your main site's. If the help centre tool serves a restrictive default, your articles stay out of the index until you notice.

**Testing propagation from one machine.** Local and ISP resolvers cache aggressively. Check from an external resolver before concluding the record is wrong and changing it again.

**Announcing the new URL before the certificate is issued.** The window between DNS resolving and the certificate being ready shows every visitor a browser security warning, which is the least recoverable first impression available.

## When this stops scaling

For one help centre this is a one-afternoon job that stays done. Certificates renew automatically with any competent provider, and the DNS record needs no further attention.

The threshold is plurality. A second product line, a documentation site alongside the help centre, or a set of locale-specific hostnames turns one record into a set, each with its own certificate lifecycle, its own Search Console property and its own robots and sitemap files. At around four hostnames the failure mode changes from configuration to attention: something expires or drifts and nobody notices, because no single person is watching all of them.

The other limit is anything requiring per-customer hostnames - white-labelled documentation, or partners hosting your help content on their own domains. That needs certificate issuance as an automated service rather than a manual step, which is a different class of problem from what you have configured above.

[SupportPages](https://supportpages.io) issues and renews certificates per custom hostname as part of hosting the help centre, which is worth knowing if you are looking at your third certificate renewal calendar entry. For a single hostname, what you have set up here is entirely sufficient.