Documentation SEO: how to rank developer docs and help centres (2026)

Documentation SEO is the work of getting your developer docs, API reference and help centre found in Google and read correctly by AI tools. It comes down to five decisions. Where the docs live: a subdomain or a folder. Which version Google should rank. Whether crawlers get the full page without running JavaScript. How AI coding assistants reach a clean copy through llms.txt and Markdown pages, and how each doc links to the pages that sell. Get those right and your docs start bringing in signups.

I'm Brenden House, and I run Searchmaxxed, an SEO and AI SEO agency for enterprise, B2B SaaS, venture-backed, manufacturing and public-sector companies. It's for the growth or marketing lead whose docs pull traffic but send almost none to a trial. On 27 October 2026 (AEST) I used Firecrawl to check how 23 well-known API companies set up their docs, and the results are below.

In summary

Documentation SEO makes your docs easy for Google, ChatGPT and coding assistants to find, read and trust. Then it routes developers to a signup.

• 21 of the 23 docs sites I checked serve an llms.txt file, and 16 of those 21 point agents to Markdown copies of each page.
• Google treats subdomains and folders "the same" in general, according to John Mueller. The setup around them decides the result.
• ChatGPT and Claude's crawlers don't run JavaScript, so script-only docs can be invisible to AI answers.
• Searchmaxxed runs the technical SEO across your marketing site, docs and app, and builds the pages your docs should feed.

What is documentation SEO?

Documentation SEO means making product documentation discoverable in search engines and AI answers, so the people who need it find the right page. It covers developer docs, API reference, SDK guides, changelogs, and help centre or knowledge base articles.

Five terms matter here:

• Developer docs are the guides and tutorials that show engineers how to build with your product.
• API reference is the page-per-endpoint listing of every request, parameter and response.
• A help centre (help center in US spelling) is the customer-facing knowledge base, often run on Zendesk, Intercom or a similar tool.
• A canonical tag tells Google which URL is the main copy when several pages carry the same content.
• llms.txt is a Markdown file at a site's root that gives AI tools a short map of the site and links to its key pages.

Documentation SEO differs from blog SEO in one big way. You don't pick topics to chase traffic. The product sets the topics, and your job is making sure people and machines can find and trust every answer.

Why does documentation SEO matter for SaaS and API companies?

Docs are where technical buyers decide whether your product works for them. An engineer evaluating three APIs searches the error message, the integration and the "how do I" question long before anyone books a demo.

That traffic arrives with intent. Someone searching "webhook signature verification Node" for your product is already building with it, or close to it. Redocly makes the same point. API documentation, it says, is "not only a sales conversion tool, but also a traffic generation tool" (Redocly).

There's a newer reader too. Coding assistants like Cursor, Claude Code and Codex pull docs into their context while they write code. If they read an old version or an empty JavaScript shell, they write broken integrations against your API without anyone filing a ticket.

So documentation SEO now serves three readers: Google, the AI answer engines, and the coding agents working beside your future customers. One clean setup serves all three.

How do leading API companies set up their docs?

Most put docs on a subdomain, almost all publish an llms.txt, and most offer Markdown copies of each page for AI agents. On 27 October 2026 (AEST) I loaded the docs home and llms.txt of 23 API companies with Firecrawl. They're my own pick of well-known docs sites, not a ranking.

The count: 12 on a subdomain, 8 in a folder on the main domain, and 3 on a separate domain. 21 of 23 serve an llms.txt. Sizes run from about 3,300 characters at Supabase to about 381,000 at Twilio.

Three things stood out to me.

First, docs move. Four of them have moved their docs, and every old address I tried still redirects to the new one. Stripe's stripe.com/docs now goes to docs.stripe.com. Segment's docs now sit at twilio.com/docs/segment. Anthropic's docs.anthropic.com goes to platform.claude.com, and platform.openai.com/docs goes to developers.openai.com. Plan your redirects as if you'll move one day, because you probably will.

Second, location matters for llms.txt. HubSpot's file works at developers.hubspot.com/docs/llms.txt, but the host root returns a 404. An agent that only checks the root finds nothing.

Third, the best files talk to coding agents directly. Stripe's llms.txt tells agents to "always check the npm registry for the latest version rather than relying on memorized version numbers". OpenAI's API docs home opens with a pointer to its llms.txt. The same line says "Markdown versions of documentation pages are available by appending .md to the page URL."

None of the top five guides for this search had a count like this when I read them, which is why I ran it.

Should docs live on a subdomain or a subfolder?

Either can rank. Google's John Mueller said in 2018: "In general, we see these the same. I would personally try to keep things together as much as possible" (Search Engine Journal). The setup decides the result.

Google's robots.txt rules are blunt on that third row: "A robots.txt on a subdomain is only valid for that subdomain" (Google Search Central).

My recommendation: if your docs win new customers, and for an API company they usually do, a folder is the simpler path. Less to maintain, nothing to stitch together. If your docs tool only runs on a subdomain and a proxy isn't worth the engineering time, a subdomain is fine. Set it up as its own site, then connect it.

Moving docs badly is the bigger risk. If you change hosts, map every old URL to its new one with a 301 redirect, page for page. Keep those redirects for good. We map them page for page before any docs move we work on. Our SaaS SEO strategy guide has the full checklist for setting up docs and app subdomains.

How do you handle versioned documentation?

Give every page one current URL and point older matching copies to it with a canonical tag. List only current pages in your sitemap. That tells Google which version to rank, so developers land on code that still works.

Versioning creates near-duplicates. v2 and v3 of a "Create a payment" page might share most of their words. Google sees two pages answering one search and picks one, sometimes the older page, which has had years to collect links.

Google orders the signals by strength. A redirect is "a strong signal that the target of the redirect should become canonical". A rel="canonical" link is also "a strong signal". Google also warns against noindex for this job, "because it will completely block the page from Search" (Google Search Central).

The setup I recommend for versioned docs:

1. Serve a stable "latest" path, such as /docs/payments.
2. Keep older versions at versioned paths, such as /docs/v2/payments, for teams still on them.
3. Add a canonical tag from each old page to its current equivalent wherever the content still matches, so the two never compete.
4. Leave old pages self-canonical where the behaviour changed, and show a banner linking to the current page.
5. List only current URLs in the XML sitemap.
6. Redirect pages for versions you've fully retired.

Postman shows another approach. Its docs-level llms.txt opens with "This page is for Postman Docs, version Latest (v12) (default)" and points to other versions. A coding agent can't miss which version it's reading.

How do you make sure Google and AI crawlers can read your docs?

Send the full text, title, canonical and links in the first HTML response, then check what Google renders in Search Console. Many docs tools build pages in the browser with JavaScript, and that's where docs go missing.

Google renders JavaScript before it indexes a page, while most AI crawlers fetch the raw HTML and never run your scripts at all. Vercel and MERJ's 2024 study found that "none of the major AI crawlers currently render JavaScript", apart from Google's Gemini and Applebot. It adds that ChatGPT and Claude "can't read client-side rendered content" (Vercel). Docs need server-side rendering or static generation. Test it per template, because custom single-page docs portals are the usual place it breaks. We run these rendering checks across site, docs and app as part of our technical SEO work.

Other common crawl problems on docs sites:

Redocly's guide is plain about it: "you must use noindex directives" to keep a page out of the index, because robots.txt alone won't (Redocly). If you're deciding which AI bots to allow, our guide on whether to block AI crawlers goes through each one.

What should documentation pages target?

Target the exact words developers type when they're stuck: error messages, "how to" tasks, integration names, and your product name plus a language or framework. Docs rarely win broad terms, but they can win thousands of specific ones.

Four free sources give you those words:

1. Your docs site search. The searches with zero results are pages you haven't written yet.
2. Search Console, filtered to the docs host or folder. Look for searches with impressions but few clicks; those pages usually need a clearer title.
3. Support tickets and community threads. When ten customers ask the same question, that's a missing doc.
4. Error strings from your own API. Each error message deserves a page that explains it and gives the fix.

Use the searcher's words. If developers search "rate limit exceeded", don't title the page "Throttling policy". Put the error text in the heading and explain the concept in the first sentence, in plain words a tired engineer can scan.

How do AI coding assistants read your documentation?

Coding assistants get your docs three ways. They fetch your pages live, query docs indexes such as Context7, or call MCP servers you publish. Each one works better when your docs offer clean Markdown at a stable URL.

• Live fetching. Assistants such as ChatGPT and Claude fetch pages while answering. Their crawlers read the raw HTML, so docs built only in JavaScript come back empty.
• Docs indexes. Context7 describes itself as serving "current, version-specific docs and code examples for any library" to Claude, Codex, Cursor and other agents (Context7).
• MCP servers. The Model Context Protocol lets an agent call tools you publish. Twilio's llms.txt links a "Twilio MCP server" page for connecting AI coding agents.

The practical upshot for an API company: publish a Markdown copy of every page at a predictable URL, such as the page URL plus .md. Put the version on the page. Keep code samples complete and copy-ready. Those three things help a coding agent write working code against your API, and working code is what turns a trial into a customer. Our Agentic Search Engineering package tracks what ChatGPT, Gemini, Perplexity and AI Overviews say in your category, including which docs they cite.

Should your docs have an llms.txt file?

Yes, if you sell to developers, because it gives AI agents a clean map of your docs. It won't help Google rankings. Google's guidance names llms.txt as something to ignore for Search, because "Google Search itself doesn't use them" (Google Search Central).

So treat llms.txt as developer experience. 21 of the 23 docs sites in my check ship one, and 16 of those 21 link mostly to Markdown versions of each page. Cloudflare, Datadog and Algolia split theirs into one file per product or section, which keeps each file small enough for an agent to load.

A good docs llms.txt:

1. Sits at the root of the docs host, and at /docs/llms.txt if your docs live in a folder.
2. Opens with one line on what the product does and which version the file covers.
3. Groups links by task, such as quickstart, guides, API reference, SDKs and errors, so an agent can jump to what it needs.
4. Links to Markdown copies of each page.
5. Gives coding agents any rules they keep getting wrong, the way Stripe does for package versions.
6. Rebuilds on every docs deploy, so it never lists deleted pages.

For the full background on the file and who reads it, see our explainer, what is llms.txt.

How should docs link to your marketing pages?

Link both ways, page to page. Each integration page should link to its setup guide, and each setup guide should link back to that page, the pricing page and a signup. A header logo doesn't count.

This is where SaaS docs lose money. The docs pull in developers by the thousand, and the only path to a trial is a "Sign up" button in the top corner. Meanwhile the marketing site's integration pages rank poorly because nothing points at them.

The reverse links matter as much. Product and feature pages should link to the doc that shows the feature working. A technical buyer wants proof the API does what the page claims, and the doc is that proof. Our SaaS SEO service builds the integration and comparison pages these links point to.

What's different about help centre SEO?

Help centres need the same basics as developer docs, plus decisions about what to index. Public how-to articles should rank. Thin articles, duplicates and anything behind a login should stay out.

Zendesk's own help article says it builds in canonical tags, hreflang for translated content and an automatic XML sitemap. It also notes that "Web crawlers cannot access closed or restricted help centers" (Zendesk). Locked help centres get no search traffic.

One common tip is out of date. Several help centre guides still recommend FAQ schema for rich results. In August 2023, Google said FAQ rich results "will only be shown for well-known, authoritative government and health websites" (Google Search Central). On 7 May 2026 it stopped showing them for every site. FAQ markup can still describe the page, but a SaaS help centre won't get the dropdowns in Google from it.

What works for help centres:

• One article per task, titled the way customers phrase it: "Change your billing email", not "Account settings".
• Merge near-duplicates into one strong article and redirect the rest.
• Link each article to related ones, and to the product page for the feature.
• Run localised help centres with hreflang, so each country sees its own language.

How do you measure documentation SEO?

Measure three things. Clicks to the docs host in Search Console, the path from docs to signup in GA4, and whether AI answers link your docs. Traffic on its own tells you little.

Use a Domain property in Search Console so docs, help and marketing hosts report together. Add the docs sitemap to Bing Webmaster Tools as well. Search Console also has a Generative AI performance report for Google's AI features (Google Search Central).

Then check your tracking. Here's what we found when we checked the GA4 setup on an enterprise B2B client's account. A client's four enquiry types never counted as conversions. Their event names ran 41 to 50 characters; GA4 cuts at 40. The 40-character "career" event counted every time. Nobody had noticed, because the events still showed up.

AI traffic needs the same scepticism, and an enterprise B2B account of ours shows why. A client's GA4 showed AI-assistant visits jump from 354 to 6,050 in a month. Almost none of it was real. About 5,700 came in three one-hour bursts: same 1920x1080 desktop Chrome, all new users, no referrer, about 20 seconds each, landing on two pages. Real AI traffic was 385 sessions against 354 the month before, roughly flat.

Here's the docs dashboard I'd trust, with four numbers on it each month:

1. Google clicks to docs, by section.
2. Signups or API keys created after a docs visit.
3. Clicks from docs pages through to your integration, pricing and comparison pages, because those are the paths that lead to a sale.
4. AI-assistant sessions, checked for bots.

A worked example: one API company, three fixes

Take a B2B SaaS company with a payments API. This is an example, not a client. Its docs run on docs.example.com as a client-side React app. v2 and v3 are both live, and every page title starts with the section name.

Here's what it sees. Google ranks the v2 webhook guide above v3. ChatGPT's answers quote v2 code that no longer works. The docs pull plenty of visits, but almost none reach a trial.

The fixes, in order:

1. Rendering. Switch the docs to static generation, so the full page arrives in the first HTML response.
2. Versions. Add canonicals from v2 pages to matching v3 pages, show a version banner, and drop v2 from the sitemap.
3. Linking. Link each integration guide to its integration page, and each quickstart to the signup.

Then add an llms.txt with Markdown copies of each page. Judge it after a quarter. Which version does Google rank, which version do AI answers quote, and how many signups follow a docs visit?

How does Searchmaxxed handle documentation SEO?

Searchmaxxed does the technical SEO across your marketing site, docs and app, then builds the pages your docs should feed. That covers rendering, indexing, canonicals, subdomains or folders, redirects, sitemaps, structured data and internal links. It also covers GEO, AEO and LLM SEO, so ChatGPT, Gemini, Perplexity and Google's AI answers can read your docs correctly.

Writing your API reference stays with your team. Your engineers know the endpoints. Our job is making sure Google and AI tools can find, read and trust what they write, and that the docs send developers somewhere useful.

A page release is an approved new page or a substantial rebuild of one. Every package includes ongoing audits, a 90-day plan in weekly releases, the build work itself and a monthly decision memo. You own the site, repository, content and data from day one.

Here's how we do it. We work on a website you own, our Agentic Website. AI agents pull your Search Console and GA4 data, read the Google results and check what AI answers say about you and your competitors. That feeds the Managed Search Loop, which shows which page, fix or link should bring in the most signups next. We build it, check the live page and measure what changed. Off your site, the Off-Page Source Layer builds the links, digital PR and mentions AI answers draw on. Our technical SEO service sets out the site-level work in detail.

Searchmaxxed's work has generated more than A$10 million in revenue through search for its clients.

Is Searchmaxxed right for you?

We're a good fit for SaaS and API companies whose docs pull traffic that never reaches a trial. You get one team on the marketing site, docs and AI answers together. We're the wrong fit if you want someone to write the docs themselves.

If you're in the right-hand column, a docs platform's built-in SEO settings or a technical writer will serve you better.

Frequently asked questions

What should you do next?

Open your docs in a browser with JavaScript turned off, then search one of your own error messages in Google and ChatGPT. If the page is blank, or the answer quotes an old version, start there. If you'd like us to scope the work across your site, docs and app, let's talk pricing.