The default SaaS marketing playbook says: start a blog, publish top-of-funnel content about your category, build an audience, convert them later. I have watched this produce large traffic numbers and almost no customers, many times. The reason is structural. A person reading "what is customer onboarding" is years away from buying onboarding software, if they ever do. A person searching "[competitor] alternatives" or "onboarding software for fintech" is buying this quarter. Those are different pages, and the second kind should be built first.
Map pages to the funnel, not to keywords
Every SaaS site needs a set of page types, and each type exists to catch a particular kind of search. Thinking in page types rather than keywords prevents the common failure of an enormous blog and nothing else.
| Page type | Query it catches | Funnel stage | Example | Notes |
|---|---|---|---|---|
| Product / feature pages | "[category] software", "[feature] tool" | Bottom | "Expense management software" | Highest intent; usually few pages; needs real depth, not a hero and three icons |
| Alternatives / comparison pages | "[competitor] alternatives", "[you] vs [competitor]" | Bottom | "Zoho Books alternatives" | Buyers actively switching; write honestly or they bounce |
| Use-case pages | "[category] for [industry/role]" | Bottom to middle | "Payroll software for startups" | Same product, framed for a segment; must contain segment-specific content |
| Integration pages | "[you] [other tool] integration", "[tool A] to [tool B]" | Bottom to middle | "Razorpay Tally integration" | Often programmatic; high intent because the searcher already uses the other tool |
| Templates / examples | "[document] template", "[thing] example" | Middle | "Invoice template", "OKR examples" | Captures people doing the job manually; converts via "do this in the product" |
| Free tools / calculators | "[thing] calculator", "[format] converter" | Middle | "GST calculator", "SaaS churn calculator" | Earns links and recurring use; needs a real tool, not a form |
| Docs / help centre | "how to [do thing] in [you]", error messages, API queries | Existing users and evaluators | "How to set up webhooks in [product]" | Massively under-optimised on most SaaS sites |
| Blog / guides | "how to [do the job]" | Top to middle | "How to run a sales pipeline review" | Builds authority; converts slowly; build after the above |
The table is roughly in the order I build. The first three rows usually account for the majority of signups attributable to organic search, and they are typically a few dozen pages. The blog, which is where most companies start, is last.
Bottom-of-funnel first
The reason to start at the bottom is not just that those pages convert. It is that they are the fastest to validate. A feature page or an alternatives page that ranks will show signups within weeks of ranking, which tells you the positioning works and the signup flow works. A blog post that ranks tells you nothing about either for months.
Feature and product pages
Most SaaS feature pages are thin: a headline, three benefit bullets, a screenshot, a CTA. They rank poorly against the category query because they say almost nothing. A feature page that competes needs to explain what the feature does, how it works, who it is for, what it replaces, what it integrates with, and what the limits are, with real screenshots and real workflows. It should read like the page a serious evaluator would want, because that is who searches "[category] software". Length is not the point; completeness is.
Alternatives and comparison pages
"[Competitor] alternatives" pages are the most reliable bottom-of-funnel play in SaaS, and the most frequently done badly. The bad version lists yourself first and nine strawmen. The version that ranks and converts is honest: it covers the real alternatives, says who each suits, and is clear about where your product fits and where it does not. Buyers in this stage have usually already tried the competitor; they detect spin instantly. "[You] vs [competitor]" pages follow the same rule.
Use-case and industry pages
"[Category] for [segment]" pages work when they contain content specific to the segment: the workflows that segment uses, the compliance it cares about, the integrations it needs, and ideally a customer in that segment. When they are the generic product page with the industry name swapped in, they are thin pages that cannibalise the main product page. The test is whether a buyer in that segment would learn something from the page they could not get from the homepage.
Programmatic opportunities
SaaS products often have structured data that maps directly onto search demand: integrations, supported file formats, countries, industries, templates, competitors. When that is the case, a well-built set of templated pages can cover hundreds of real queries. The classic examples are integration directories ("connect [product] with [tool]"), template libraries, and glossary pages.
The condition is the same as in my programmatic SEO guide: real demand for each page, real and distinct data on each page. An integration page that says "Connect X with Y in minutes" and nothing else is spam at scale. An integration page that shows what the integration actually does, which fields sync, what triggers exist, and how to set it up, with a screenshot, is a useful page that will rank and convert. If you cannot populate that from your product's data, do not build the directory yet. The programmatic framework has the thresholds I use.
Free tools
A free tool (calculator, generator, converter, checker) is often the single highest-return SEO asset a SaaS company can build. It targets a query with recurring demand, it earns links because people reference it, and it exposes the product to people doing the job the product automates. A GST calculator for an accounting product, a salary breakdown calculator for a payroll product, a subject-line tester for an email product.
Build it properly. A form that emails you a result is not a tool. The tool should work instantly, in the browser, without signup, with a clear path to "do this automatically in [product]". Give it its own URL under the main domain, not a subdomain, so its links benefit the site.
Docs and help centre SEO
Documentation is the most under-used SEO asset in SaaS. It is extensive, it is written by people who know the product, it answers specific questions, and it is often invisible to search because it lives on a subdomain, behind a JavaScript help-centre widget, or on a third-party platform with weak technical defaults.
Docs catch three kinds of search: existing users looking for how to do something (retention, support deflection), evaluators checking whether the product can do something specific before they sign up ("does [product] support SSO", "[product] API rate limits"), and people searching error messages or integration problems who may not know the product yet. The second group is a buying signal that most companies never see because the docs are not in their analytics.
What to fix, in order:
Put docs on the main domain or at least a crawlable subdomain
/docs/or/help/on the main domain consolidates authority.Make every article a real page
Unique title that matches how people search ("How to export invoices to Tally" not "Exporting"), one H1, crawlable navigation between articles, breadcrumbs, and a canonical. Many help-centre platforms render articles via JavaScript or hide them behind search; check what the crawler sees.
Link docs to product pages and back
Feature pages should link to the docs that show the feature in use; docs should link to the feature page for evaluators who landed there. This is one of the most effective internal-linking patterns in SaaS and almost nobody does it.
The pricing page
The pricing page is one of the highest-intent pages on the site, both for "[product] pricing" searches and because evaluators go there from every other page. It should be indexable (some companies noindex it, which hands the query to review sites), should actually state prices or at least plans, and should answer the questions buyers have (what counts as a user, what happens at limits, annual versus monthly, what is in the free tier). FAQ content on this page is content that converts. If pricing is "contact us", at least say who the product is for and what drives cost, so the page can rank for and satisfy the query.
Technical issues with JavaScript frameworks
SaaS marketing sites are usually built on the same stack as the product: React, Next.js, Vue, Nuxt, Angular, often with a headless CMS. This is where a large share of SaaS SEO problems originate, and they are invisible to anyone looking at the site in a browser.
The failure modes I see most often:
- Client-side rendering of content. The HTML the crawler receives is an empty shell; the content arrives via JavaScript. Google can render it, in a second wave, with delays and inconsistencies. Pages get indexed with missing content or titles, or not at all.
- Client-side routing without real URLs. Navigation changes the view without a crawlable link or a distinct URL, so pages exist for users but not for crawlers.
- Metadata set by JavaScript. Titles, canonicals and meta robots injected after load, sometimes with the wrong value present in the initial HTML. A canonical that says one thing server-side and another client-side is a coin toss.
The fix is server-side rendering or static generation for every indexable marketing, docs and programmatic page, with metadata in the server response. Most modern frameworks support this; it has to be configured and then verified. I verify by fetching the raw HTML and comparing it to the rendered DOM, and by using Search Console's URL inspection to see what Google actually rendered. My JavaScript SEO guide has the full diagnostic, and the rendering experiment shows the indexing difference between the approaches on a controlled set of pages.
International targeting: Indian SaaS selling globally
A large share of Indian SaaS companies have their customers in the United States, Europe, Southeast Asia and the Middle East, and a small share in India. Their SEO is therefore international SEO from day one, and the defaults work against them: the company is registered in India, hosting may be in India, the office address in the footer is in Bangalore, and Google's geographic signals lean towards India.
What matters:
- Use a gTLD (.com, .io, .ai) rather than .in if the market is global. A ccTLD is a strong geographic signal that you cannot override.
- Do not create country versions until there is a reason. One English site serving everyone is correct for most SaaS. Create
/en-us/,/en-gb/or localised versions only when pricing, compliance or language genuinely differs, and then implementhreflangproperly. Half-built country folders with duplicate content are a common self-inflicted wound. - Write for the target market's vocabulary. "Payroll" and "HRMS" mean different things in Bangalore and Boston. Comparison pages should name the competitors the target market knows, not the Indian ones.
- Put the target market's trust signals on the page. Customers from that market, relevant compliance (SOC 2, GDPR), support hours in their timezone, pricing in their currency.
Search Console's country report will tell you quickly if you are ranking in India for queries you want in the US. For companies selling into India specifically (payroll, GST, UPI-adjacent tools), the opposite applies: Indian vocabulary, Indian competitors, INR pricing. My international SEO guide covers the hreflang and structure decisions.
Measure signups, not traffic
The reporting that matters for SaaS SEO is organic signups (or trials, or demo requests) by landing page type, and ideally what those signups became. Traffic is a diagnostic. A content programme that triples traffic and does nothing to signups has failed, and that outcome is common enough that I treat traffic-only reporting as a warning sign.
The minimum setup:
- Signup, trial start and demo request as tracked conversion events, attributed to the landing page and source.
- Landing pages grouped by type (feature, comparison, use case, integration, tool, docs, blog) so the report reads "comparison pages produced N signups" rather than a list of URLs.
- Brand and non-brand separated, because brand organic is a function of everything else the company does, not of SEO.
- A join to the CRM or product analytics, so that signups from organic can be followed to activation and revenue. Even a monthly manual join is enough to learn which page types produce customers rather than tyre-kickers.
Once this exists, the plan writes itself: more of the page types that produce signups that activate, less of the ones that produce traffic that does not. See rankings are not the goal.
A build order
If I were starting a SaaS SEO programme from a thin marketing site, the sequence would be:
- Technical foundation
- Feature and product pages
- Comparison and alternatives
- Use cases and integrations
- Docs and pricing
- Tools and templates
- Guides and glossary
Technical foundation first because nothing else is visible without it; bottom-of-funnel next because it validates fastest; the blog last, once there is evidence of what converts. The first organic signups often arrive before the blog has published a post.
Frequently asked questions
Should a SaaS company start with a blog?
Usually not. Start with the technical foundation and the bottom-of-funnel pages: feature, comparison, use-case and integration pages. They produce signups sooner and tell you whether positioning and conversion work. Build the blog once you know what converts.
Is it risky to write about competitors on comparison pages?
It is normal, and it works when the comparison is accurate and fair. Misrepresenting a competitor is a legal risk and a conversion problem, because evaluators have usually used it. State facts, cite the competitor's own documentation, and say where your product is not the right choice.
Should docs be on a subdomain or the main domain?
Main domain where possible, as /docs/ or /help/. It consolidates authority and makes docs-to-product linking natural. If the help-centre platform forces a subdomain, make sure it is server-rendered, linked from the main navigation, and tracked in the same analytics property.
We are an Indian SaaS company selling to the US. Why are we ranking in India instead?
Common causes: a .in domain, Indian vocabulary and examples, Indian competitors on comparison pages, INR pricing, and an Indian office as the only address. Fix the content to match the US market's language and trust signals, use a gTLD, and check Search Console's country report to confirm the shift.
How do we handle programmatic integration pages without creating thin content?
Populate each page from real data about the integration: what syncs, what triggers exist, setup steps, screenshots, limitations. If your product data cannot supply that, build the pages only for the integrations you can document properly and add the rest as the data becomes available. Thin integration pages get ignored or hurt the site.
Where this connects
The SaaS SEO Framework is the operational version of this guide, with the page-type inventory, the build order and the measurement setup I use on engagements. The JavaScript rendering test in the SEO Lab shows how rendering choices on a modern front end affect indexing. The SaaS organic growth case study follows a software company through this sequence. If you want it done rather than described, my SaaS SEO service is built around exactly this system.