Key Takeaways:
yourdomain.com/help inherits your domain's authority; Google treats a subdomain more like a separate site.Knowledge base SEO is the practice of optimizing help center articles so they rank in search engines and get cited by AI assistants. It spans four layers: article content that answers real customer questions, navigable site structure, technical setup, and measurement. The same work is sometimes called help center SEO or documentation SEO.
Blog posts compete for broad topics against every publisher in your space. Help center articles target narrow product questions that only you can answer, asked by people using or evaluating your product.
Each help center article targets one specific long-tail question. "How do I connect Slack to [product]" has near-zero competition, because only you can answer it. Google has nothing better to rank.
The visitors those articles attract are worth more than blog traffic. Someone searching a setup question is either a customer or an evaluator mid-trial.
The effect compounds. Every recurring question you document becomes a permanent search asset that answers customers before they open a ticket. A support team that publishes one article per week builds 52 ranking pages a year without a content team.
The topic list for your knowledge base already exists. It is sitting in your inbox. Recurring ticket patterns are long-tail queries that customers type into Google and ChatGPT almost verbatim.
The manual method takes an afternoon:
This ordering guarantees demand. Every article maps to a question real customers asked, in the words they used. You never write documentation nobody searches for.
The automated version runs continuously. Helply is a B2B support platform that turns every recurring ticket pattern into a drafted knowledge base article. It flags the questions no article covers, and a human approves each draft before it publishes.
Proposify's customer experience team sees Helply resolve 30 to 35% of conversations. Every seat is free, and the AI is included at $1 per ticket.
The fundamentals below decide whether an article ranks. Most help centers get them half right and stay invisible.
Each article answers exactly one question, and the title is that question as the customer phrases it. "How do I connect Slack" beats "Slack integration overview" because it matches the query word for word. Your ticket subject lines and help center search logs are the keyword research.
Keep URLs short and readable: /help/connect-slack, not /help/article-4471-slack-integration-setup-guide. The Google SEO Starter Guide recommends descriptive URLs: they tell users and crawlers what the page contains.
Put the complete short answer directly under the title. Steps, screenshots, and edge cases come after. A reader who needs only the answer leaves satisfied in ten seconds.
That opening block is also the unit machines extract. Google lifts it into featured snippets, and LLMs quote it when answering product questions. An article that buries its answer under three paragraphs of preamble loses both.
For example, take an article titled "How do I change my billing email?" It should open: "Go to Settings, then Billing, then Contacts. Change the address in the Billing email field and select Save. The change applies to your next invoice." The complete answer runs 25 words.
Structure every article the same way. One H2 or H3 per sub-question, numbered lists for sequential steps, and short paragraphs of three sentences or fewer.
Give every screenshot descriptive alt text that says what the image shows. "Billing settings page with the billing email field highlighted" works; "screenshot-4.png" tells machines nothing.
Link related articles in the order customers need them: setup links to troubleshooting, troubleshooting links to limits and pricing behavior. Link from your highest-traffic articles to new ones so authority flows to pages Google has not discovered yet.
Then link the help center itself from your main site navigation and footer. A help center with no inbound links from the main site starts every ranking battle from zero.
Use this knowledge base article template as the skeleton for every article:
Title: [The question, as the customer phrases it][40 to 60 word direct answer. Complete enough to act on alone.]## Before You Start[Prerequisites, permissions, plan requirements. One line each.]## Steps1. [One action per step, starting with a verb.]2. [Include a screenshot when the UI is ambiguous.]## If It Doesn't Work[The two or three most common failure causes, with fixes.]## Related Articles[Three links, in the order a reader would need them next.]
How you structure the knowledge base decides whether authority concentrates or scatters. The rules are short:
Write category pages as real hub pages. A category page with an intro paragraph and grouped article links can rank for the broader query. Its articles rank for the specifics, and a bare list of links ranks for nothing.
Choose a subfolder when you can. Subfolders like yourdomain.com/help sit inside your main domain. Backlinko's head of organic growth says subdirectories "tend to rank faster because they inherit domain authority more directly."
Google treats subdomains more like separate sites that must earn authority on their own.
Your platform may decide for you. Zendesk Guide defaults to a zendesk.com subdomain, and Intercom Articles publishes to intercom.help by default.
A subdomain help center can still rank well, as Zapier proves. The trade-off is a slower ramp and separate Search Console handling.
| Subfolder (/help) | Subdomain (help.) | |
|---|---|---|
| Authority | Inherits the main domain directly | Treated largely as a separate site |
| Speed to rank | Faster ramp | Slower; can perform well long term |
| Platform support | Needs platform or reverse-proxy support | Default on Zendesk Guide and Intercom |
| Search Console | Same property as your site | Separate property, or use a Domain property |
| When to choose | Whenever technically possible | When the platform forces it |
The decision rule: use a subfolder if your platform supports it or a reverse proxy can put it there. Do not replatform your entire support stack over this alone. And never split articles across both, because you will compete with yourself.
Not everything in a help center belongs in Google. Index every public product article. Noindex internal-only articles, thin stubs under 50 words, and auto-generated tag or search-results pages.
Point a canonical tag at the primary version wherever the same answer exists in two places. Then give the knowledge base its own XML sitemap and submit it in Google Search Console. That lets you inspect help center indexation separately from the marketing site.
Schema markup is structured data that tells machines what a page is. For knowledge bases, three types matter. Use Article schema on every article, FAQPage schema only on true FAQ pages, and HowTo on step-by-step guides.
A minimal working example for an article:
{"@context": "https://schema.org","@type": "TechArticle","headline": "How do I connect Slack?","datePublished": "2026-08-01","dateModified": "2026-08-07","author": { "@type": "Organization", "name": "Helply" },"publisher": { "@type": "Organization", "name": "Helply" }}
Schema earned a second job in 2026. Rich results still matter, but structured data now also tells LLMs what a page covers and when it changed. Fresh dateModified values signal maintained documentation to both audiences.
FAQ SEO and article SEO solve different problems. A question with a one-paragraph answer and no steps belongs on an FAQ page marked up with FAQPage schema. A question that needs steps, screenshots, or troubleshooting deserves its own article.
The failure mode is stuffing full procedures into FAQ entries. The answer becomes too long to extract, and the page competes with the article that covers the same ground.
Support questions are moving from the search box to the chat window. When a customer asks ChatGPT or Perplexity how to do something in your product, the assistant answers from whatever documentation it can retrieve. Your help center is the raw material, but only if the machines can reach it and parse it.
Four moves cover it:
Stale documentation fails the fourth check most often. An AI-native knowledge base closes that loop by keeping articles current as the product changes, instead of waiting for a quarterly documentation sprint.
Track three numbers monthly, and stop tracking individual keyword ranks for help articles.
/help/ or open the subdomain's property, then chart clicks over time.Together they answer one question: is the help center resolving demand that used to become tickets?
These four help centers show the tactics above working in production.
Slack (slack.com/help) runs its entire help center in a subfolder of the main domain. Every article inherits the authority of slack.com from day one. What to copy: the subfolder placement and task-based category naming.
Notion (notion.com/help) organizes by topic, with categories like "Sharing & permissions" and "Databases," plus a second cut by team role. Category descriptions are task-phrased, such as "Share Notion pages and collaborate with others." What to copy: category hubs organized by what users are trying to do.
Zapier (help.zapier.com) proves a subdomain is not fatal. Each category card pairs a name with an outcome description, like "create workflows that connect your apps to automate repetitive tasks." What to copy: outcome-phrased category descriptions that match how people search.
Anthropic (docs.anthropic.com) publishes an llms.txt file at its docs root, a live example of the spec in the wild. What to copy: the llms.txt file itself, listing the pages AI assistants should read first.
Knowledge base SEO is one system. Topics come from recurring tickets. Articles answer one question each, with the full answer in the first 60 words.
A subfolder, clean schema, an llms.txt file, and open AI crawlers finish the job. Google can find those answers, and ChatGPT can quote them.
The cost of waiting shows up in your queue: the same questions keep returning as tickets, and AI assistants quote someone else. Your team has already written every answer, one reply at a time. Helply turns those replies into articles, at $1 a ticket with every seat free.
Yes. Each article can rank for a specific long-tail question, builds topical authority around your product, and adds internal-link equity across the domain.
Index every public product article, and noindex internal-only content, thin stubs, and auto-generated tag or search pages.
As long as the answer requires. Most sit between 300 and 800 words, with the complete short answer in the first 40 to 60 words.
Enough to cover your recurring ticket topics. Start with your 20 most-asked questions and expand from real ticket patterns.
Yes. Helply drafts articles from recurring ticket patterns, and a human reviews each draft for accuracy before it publishes.
A plain-text file at your domain root that points AI crawlers to your most important pages. It helps language models find and cite your documentation.