---
title: "How to Choose Between help., docs. and support. Subdomains"
canonical: https://supportpages.io/guides/help-vs-docs-vs-support-subdomain
updated: 2026-08-13
---

Chosen one of `help.`, `docs.` or `support.` for a reason you can defend in a review, and you will have reserved the other two. The names are not interchangeable: each one makes a different promise about what is behind it, and readers act on that promise before the page loads.

## Before you start

Know who the content is for. Two audiences exist and they behave differently: people using your product's interface, who arrive with a task and want steps; and people building against your product, who arrive with a question about an endpoint and want a reference. Most naming arguments are really disagreements about which of those the site is for, conducted without either party saying so.

## Steps

1. **Write down the primary audience in one sentence.**
   "People using the app who are stuck" or "developers integrating with the API". If the sentence contains "and", you have two sites and the naming question changes shape.

2. **Match the word to that audience.**
   `docs.` reads as technical reference and is what developers look for by habit. `help.` reads as end-user assistance with steps and screenshots. `support.` reads as a route to a human.

3. **Check what `support.` will actually be used for.**
   Many companies eventually want `support.` to host a contact form, ticket portal or status information. If you have any chance of wanting that, keeping the name free is worth more than using it for articles.

4. **Check what the word implies about the answer.**
   A reader who lands on `support.` and finds only articles feels deflected. The same articles under `help.` read as the intended answer rather than an obstacle before a human. This is the strongest practical argument between the three.

5. **Check your own in-product language.**
   If every link in your interface says "Help", `docs.` creates a small mismatch at every one of them. Matching the site name to the button label removes a category of confusion for free.

6. **Decide whether you will need two sites eventually.**
   A product with both an interface and an API usually ends up with `help.` and `docs.` serving different audiences. Deciding that now means you name the first one correctly instead of taking the general name and having nothing left for the second.

7. **Reserve the other two and point them at your choice.**
   Configure the unused names as redirects. People type them, link to them from memory, and guess at them - a redirect converts each of those into an arrival rather than a browser error.

8. **Write the decision down where the next person will find it.**
   Two lines in an internal wiki naming what you chose and why. The rename discussion recurs every time someone new joins, and a written reason ends it in a minute.

![Three subdomain choices and the expectation each sets: reference, tasks, or contact.](/images/guides/figures/help-vs-docs-vs-support-subdomain.webp)

*The word sets the expectation before the page loads.*

## Common mistakes

**Using `support.` for self-service articles while also using it for ticketing.** The same hostname then means two different things, and the navigation has to work for both, which usually means it works well for neither.

**Splitting related articles across two hostnames.** Once billing articles are under `help.` and API authentication is under `docs.`, questions that touch both - API rate limits on a paid plan, say - have no home, and site search on either hostname finds half the answer.

**Choosing `kb.` or `wiki.`.** Both are internal vocabulary. Readers do not search for a knowledge base; they search for help with a problem, and a wiki signals unmaintained content whether or not that is fair.

**Renaming after the articles have accumulated links.** It is a full migration with redirects, a fresh Search Console property, and an index that takes weeks to settle. Correct at the start, expensive later.

**Picking on aesthetics.** The shortest or best-looking name loses to the one your readers already type. Where your existing site search or ticket data shows the word customers use, that data outranks the taste of everyone in the room.

## When this stops scaling

This decision does not decay. A hostname chosen well in year one is still correct in year five, and unlike almost everything else in a help centre it needs no maintenance. There is no honest threshold at which this guide's method stops working, so there is nothing here to escalate to a tool.

What does change is the number of surfaces. Products accumulate them: a status page, an API reference, a community forum, a changelog, a developer portal. Each arrival re-opens the naming question, and the answers drift apart because they are made years apart by different people.

The thing that keeps that coherent is not a naming rule but the record from step eight - one page listing every hostname you own, what it serves, and what it is reserved for. Teams that keep it end up with a legible set of subdomains. Teams that do not end up with `docs.`, `developers.`, `api-docs.` and `help.` all live, three of them stale, and no one willing to be the person who deletes one.