Every Indian SaaS company past its first few customers ends up with two content properties that overlap: a marketing blog and a documentation site. Both publish about the product. Both get indexed. And in a surprising number of cases they compete with each other for the same queries, with the weaker page winning.
This is worth deciding deliberately, because the default outcome is usually the wrong one.
The three query types, and who should own each
Problem queries — how to reconcile GST invoices, why is my payroll register mismatching. The searcher does not know your product exists. These belong to the blog or a resources section, unambiguously. Docs written for existing users will not satisfy someone who has not yet named their problem.
Comparison and category queries — best invoicing software for Indian SMEs, <competitor> alternative, GST filing software pricing. These belong to marketing pages — landing pages, comparison pages, pricing. Not docs, not blog posts. A blog post targeting a comparison query converts badly because it reads as commentary rather than an offer.
How-do-I queries — how to add a GST number in <product>, <product> API rate limits, export report to Tally. These belong to docs, and docs should win them decisively. They are branded, high-intent, and mostly searched by people already paying you. A blog post from 2024 outranking your current documentation for how to configure X is an active support cost: the reader follows outdated instructions and raises a ticket.
The overlap problem in practice
The cannibalisation usually goes one way. An old blog post titled "How to set up recurring invoices in <product>" has three years of accumulated links and internal references. The documentation page covering the same thing is newer, better and less linked. Google keeps serving the blog post. Support keeps answering the same question.
The fix is not subtle: audit branded how-to queries in Search Console, find where a blog URL ranks above the equivalent docs URL, and resolve it. Usually that means redirecting the blog post to the docs page, or cutting the post back to a short pointer. Deleting is fine too, provided you redirect.
Do it in the right direction. Redirect the weaker, outdated page to the canonical one, and make sure the canonical one actually covers everything the old page did — otherwise you lose the long tail the old post was catching.
Things that make docs rank poorly, and are easy to fix
Client-side rendering with no server HTML. A lot of docs frameworks ship as a JavaScript app. If the content is not in the initial HTML, indexing is unreliable at best.
Versioned URLs without canonicals. /v1/, /v2/, /latest/ all serving the same page is three URLs splitting one page's authority. Canonical to /latest/ and be done.
No internal links from marketing to docs. Docs sites frequently sit on a subdomain with almost no links pointing in. Link from relevant product pages and blog posts; it costs nothing.
Noindex left on from the staging build. More common than it should be, and invisible until you look.
Titles written for navigation, not search. "Configuration" tells a searcher nothing. "Configuring GST rates and HSN codes" matches how people search and reads no worse inside the docs.
The subdomain question
docs.yoursite.com versus yoursite.com/docs/ — the subdirectory is marginally better for SEO because everything accumulates on one hostname, and most docs platforms can now be served from a subpath with a reverse proxy. But this is a smaller factor than people argue about. If your docs already live on a subdomain and work well, migrating carries real risk for a modest gain. Fix the internal linking and the rendering first; revisit the hostname only if you are rebuilding anyway.
A sensible order of operations
Map every branded how-to query in Search Console to the URL that currently ranks, and note where that is not the docs page. Resolve those conflicts first — they are the cheapest wins and they reduce support load immediately. Then check docs rendering and canonicals. Then, and only then, write new content, with each piece deliberately assigned to blog, marketing page or docs before anybody starts drafting.
Reading your own SEO proposal line items with this split in mind is a useful exercise too — a proposal that treats a SaaS site as one undifferentiated content pile is a proposal written without looking.
If you want the query-to-URL mapping done properly before you start moving pages, an SEO consultant in India who has untangled blog-versus-docs conflicts before will save you a migration you did not need.