SaaS SEO: how organic search works for software companies

Search for a software company follows the same rules as search for anyone else. Google crawls, renders and indexes the pages, and ranks them against the queries people type. The commercial context is what changes. Who is searching, how long they take to decide, how many people sign off and what the business counts as a result all decide which pages are worth building and which numbers are worth reporting.

A shop sells something in one visit. A software company usually sells over weeks or months. Somebody finds a page, signs up for a trial or books a demo, involves colleagues, compares two or three options, and buys later, often on a different device and after several more visits. The first organic visit is one step in a long path, and most of the steps happen outside search. G2's 2025 Buyer Behavior Report, a survey of 1,169 B2B software decision-makers in North America, EMEA and APAC run in April 2025, found that nearly two in three buyers now prefer to engage with vendor salespeople only in the later stages of their buying journey.¹ G2 runs a software review marketplace, so it has an interest in buyers researching on their own, but the finding fits the long, self-directed path described here.

For anything sold to a business, there is rarely one buyer. The person who searches for the problem is often not the person who signs the contract. A developer reads the documentation, a team lead reads the comparison page, finance reads the pricing page, and security asks for the compliance page. Each of those people arrives with a different query, and the site needs a page that answers each of them.

What counts as a conversion depends on how you sell

Traffic on its own is a weak measure of SaaS search. A post that ranks for a broad definition can bring thousands of students and job seekers who will never buy. A page that ranks for a narrow comparison query might bring a few dozen visits a month and a meaningful share of the pipeline. I would judge every piece of SaaS content by the second kind of number, and accept that it is harder to measure.

Plan a SaaS content programme around how much the searcher already knows. A person who knows they have a problem but not that software solves it searches very differently from a person choosing between two named products. Each stage calls for a different kind of page, and the stages closest to a decision usually convert best and are smallest in volume.

Two mistakes come up again and again. A new SaaS company starts at the top and publishes dozens of problem-aware articles because they are easy to brief, while the product, comparison and integration pages that buyers search for stay thin. Or it treats every stage as if it wanted a sales pitch. A problem-aware reader who meets a hard sell on a guide usually leaves, and the guide stops being worth linking to.

Problem-aware queries are mostly informational, and informational searches are where AI summaries now answer the question on the results page. Pew Research Center tracked the browsing of 900 US adults in March 2025 and found they clicked a traditional search result on 8% of visits to a Google results page with an AI summary, against 15% when there was none.² Ahrefs compared desktop click-through rates on 300,000 informational keywords and found that, by December 2025, an AI Overview correlated with a 58% lower average click-through rate for the top-ranking page.³ Neither study looked at software queries in particular, but both point the same way: a top-of-funnel guide earns fewer visits than its ranking used to promise, which is one more reason to start nearer the decision.

One of the self-assessment questions in Google's helpful content guidance is whether a site is producing lots of content on many topics in the hope that some of it performs.⁴ That question is aimed squarely at the SaaS blog that covers everything vaguely related to its category. Topics should be ones the company can write about from real knowledge of the problem and the product.

Most SaaS sites need the same small set of page types. The order in which they get built matters more than the exact list.

Product and feature pages

The homepage and core product pages carry the brand and category terms. Feature pages earn their place when a feature is something people search for by name, such as an approval workflow or a time-tracking report. If nobody searches for a feature and it only makes sense inside the product, it can live as a section on a product page. Splitting every feature onto its own URL tends to produce a set of thin pages that compete with each other.

Use-case and industry pages

Use-case pages ("for onboarding", "for month-end close") and industry pages ("for agencies", "for clinics") work when the product behaves or is set up differently for that audience, and the page shows the relevant workflow, the integrations that audience uses and real customers from that sector. A page that swaps the industry name into the same copy is a doorway. Substantially similar pages created to rank for specific, similar queries are an example of doorway abuse in Google's spam policies.⁵

Integration pages

Integration searches come from people who already use another tool and want to know whether yours connects to it. That makes them unusually close to a decision. A good integration page says what data moves in which direction, what triggers a sync, what the integration cannot do, and how to set it up, with a link to the documentation. An integration page with a logo and two generic sentences is a weak answer to a specific question.

Comparison and alternatives pages

"Tool A vs tool B" and "tool A alternatives" are some of the most valuable queries a SaaS company can rank for, because the searcher has already decided to buy something in the category. They are also where SaaS marketing is at its least trustworthy. A page that claims to win on every row of a table, quotes a competitor's pricing from two years ago, or hides the cases where the other product is better will be read by somebody who is about to check. (I have written up how to write comparison pages that buyers trust.)

• Say who the competitor is a better fit for. This is the sentence that makes the rest of the page believable.
• Date the comparison and keep it current. Pricing and feature claims about other products go stale quickly.
• Compare on the criteria buyers use, which you can find in sales call notes and lost-deal reasons.
• Do not invent reviews or ratings for either product, in the copy or in markup. UK consumer law bans fake reviews and misleading ratings drawn from them,⁶ the US Federal Trade Commission's rule covers fake reviews including AI-generated ones,⁷ and marking up misleading content such as fake reviews breaks the structured data guidelines.⁸
• Write from use. First-hand expertise, for example from having used a product, is one of the qualities the helpful content guidance asks about.⁴ A comparison written by someone who has used both tools reads differently from one assembled from feature pages.

Pricing pages

Pricing pages attract branded searches late in the decision, and a vague one sends buyers to third-party sites to find out what the product costs. Even sales-led companies can usually publish how pricing works, meaning the unit (seats, usage, accounts), what each plan includes, and whether a free tier or trial exists. Keep the plans in HTML text so they can be crawled and quoted, and avoid putting the whole page behind a currency or region selector that only loads after a script runs.

Templates and free tools

Templates, calculators and small free tools can rank well and attract links because they do something useful on the page. They earn their place when they sit close to the product, so that the person using a template is the kind of person who might later want the software.

Documentation is often the most searched part of a SaaS site, and it is frequently treated as somebody else's problem. Developers and administrators search for error messages, API endpoints, setup steps and limits. Prospects search for the same things during evaluation, to check whether the product will do what they need before they talk to sales. Documentation that answers those questions clearly is doing sales work.

• Make docs crawlable. Docs platforms and help centre tools sometimes render content with JavaScript, set noindex by default on some sections, or require a login to read articles that could be public.
• Give each article a specific title that matches how people describe the task, and keep one task per page where possible.
• Retire or redirect articles for features that no longer exist. Outdated docs rank, confuse customers, and contradict the current product.
• Link from docs to the relevant product, integration and pricing pages, and back again. The two sites are usually run by different teams and rarely link to each other well.
• Decide what should be private. Internal runbooks and customer-specific articles need proper access control, because robots.txt alone does not keep a page out of the index.¹⁰ The robots.txt standard is explicit that its rules are not a form of access authorisation.¹¹

Programmatic SEO means generating many pages from a template and a dataset: one page per integration, per template, per city, per pair of competing tools, per currency conversion. Plenty of software companies have built useful page sets this way, because their product has hundreds of integrations or templates that people search for one at a time.

The risk is the large set of pages where only the keyword changes. Google's spam policies define scaled content abuse as generating many pages for the primary purpose of manipulating search rankings and not helping users.⁵ The listed examples include using generative AI or similar tools to generate many pages without adding value, stitching or combining content from different pages without adding value, and creating many pages where the content makes little sense to a reader but contains search keywords.⁵ The policy applies no matter how the content is created,⁵ so pages written by people at scale and pages written by a model are judged the same way.

SaaS technical problems tend to come from how the company was built. The marketing site was made by the engineering team with the same framework as the product. The docs went on one platform, the help centre on another, the blog on a third. Staging environments were created as needed and never cleaned up.

JavaScript rendering on the marketing site

Google processes JavaScript pages in three phases: crawling, rendering and indexing, and pages can wait in a render queue before they are rendered.¹² Server-side rendering or pre-rendering is still worth doing even for Google, because it makes sites faster and not all bots can run JavaScript.¹² The crawlers behind most AI assistants are a different matter. A log analysis published by Vercel and MERJ in December 2024 found that none of the major AI crawlers it measured rendered JavaScript: OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot, Anthropic's ClaudeBot and PerplexityBot all read the HTML the server returned, and while ChatGPT's and Claude's crawlers did fetch JavaScript files, they did not execute them. The exceptions were Gemini, which runs on Google's infrastructure, and Applebot.¹³ The providers do not document their rendering themselves and it could change, but a marketing site that builds its copy in the browser should be assumed to look empty to ChatGPT search, Claude and Perplexity until it is server-rendered or pre-rendered. Dynamic rendering is a workaround and not a recommended solution; server-side rendering, static rendering or hydration are the long-term fixes.¹⁴ To test a marketing site, fetch the page without JavaScript and check whether the headings, copy and links are in the HTML. (I have written up how to check what crawlers see on a JavaScript site.)

The app subdomain

The logged-in product usually lives on its own subdomain, such as app.example.com. Login, signup and password reset pages there can get indexed and sometimes outrank the marketing site for branded queries. Decide which app pages should be in search (often only the login and signup pages, if any) and use noindex on the rest. A noindex rule only works if the page is not blocked by robots.txt, because the crawler has to fetch the page to see it.¹⁵

Staging, preview and noindex

Staging and preview environments are a common cause of duplicate content on SaaS sites, and a common cause of launch disasters in the other direction. Both usually come from a noindex or robots.txt rule meant for staging that ends up on the live site, or the reverse. Using JavaScript to remove a noindex tag may not work, because Google may skip rendering a page that starts with noindex.¹² Password protection is the more reliable way to keep staging out of search, and robots.txt is not a mechanism for keeping pages out of Google.¹⁰ Add a check for robots rules to the release process so the live site never ships with a staging setting.

Subdomain sprawl

A mature SaaS company might have www, app, docs, help, blog, community, status, developers and a few campaign subdomains. For search, that means inconsistent navigation, weak linking between sections, duplicated content across help and docs, and reporting split across many places.

Subdomain versus subfolder is argued about endlessly. In my judgement a move is only worth it if the current setup causes a real problem, because it carries all the usual risks of a website migration.

Schema.org defines a SoftwareApplication type, with subtypes including WebApplication and MobileApplication, and properties such as applicationCategory, operatingSystem and featureList.¹⁷ Google supports SoftwareApplication markup for a software app rich result, with name, an offer price, and either an aggregate rating or a review required, and applicationCategory and operatingSystem recommended.¹⁸

• It can make a page eligible for a rich result. Correct markup does not guarantee that a rich result will show.⁸
• It describes the product in a machine-readable way, which helps systems that read markup to understand what the page is about.
• It does not rank a page on its own, and it does not replace the visible content. Markup must represent what is visible on the page.⁸
• The rating requirement is a trap. Ratings in markup must reflect real reviews shown on the page. Inventing an aggregate rating to qualify for the rich result is the kind of misleading markup the guidelines prohibit.⁸

Organization markup on the homepage, BreadcrumbList on docs and product pages, and FAQ or HowTo content written as ordinary visible text are usually more useful day to day than chasing a rich result. If the product has no real public reviews, skip the software app rich result and spend the time elsewhere.

SaaS SEO measurement usually breaks because the data is split between tools that do not talk to each other. Search Console knows queries and clicks. Analytics knows sessions and events. The CRM knows which accounts became opportunities and revenue. Connecting them takes deliberate setup.

Branded and non-branded search

Branded search is people who already know the product, and its volume mostly reflects marketing, word of mouth and sales activity. Non-branded search is where SEO reaches people who did not know you existed. Reporting them together hides both: a successful launch can inflate branded clicks and make SEO look good, while a slow decline in non-branded visibility goes unnoticed.

Search Console now has a branded queries filter in the Performance report. Queries are classified by an AI-assisted system that includes brand name variants, misspellings, and queries about products unique to the site, and Google's own announcement admits some queries may occasionally be misidentified.²¹ It is only available for top-level properties with enough query volume, not for subdomain properties.²¹ Where it is not available, a regular expression filter on the brand name and its common misspellings does a reasonable job.

Buyers now ask ChatGPT, Gemini, Perplexity and Google's AI Mode which tools to shortlist. The answer names a few products and gives reasons, often lifted from whatever the assistant read, including public documentation. In G2's 2025 survey, 29% of respondents said they start research on platforms such as ChatGPT more often than on Google.¹

In Google's guidance, there are no additional requirements to appear in AI Overviews or AI Mode: a page must be indexed and eligible to show with a snippet to be used as a supporting link.²³ These features may issue several related searches across subtopics, a technique known as query fan-out.²³ For a software category, those related searches look a lot like comparison, integration, pricing and use-case queries.

• Be specific in public. Pricing, integrations, limits, security certifications and who the product is for should all be stated in crawlable text. An assistant cannot repeat a fact that sits behind a demo form.
• Keep facts consistent across your site, docs, review platforms, marketplace listings and partner pages. Conflicting descriptions give an assistant no reason to trust any of them.
• Allow the crawlers you want to be found by. OpenAI says sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, and lists GPTBot separately as the crawler for training data.²⁴ Anthropic separates ClaudeBot, which collects possible training data, from Claude-SearchBot and Claude-User, and says blocking those two may reduce a site's visibility in Claude's search results.²⁵ Perplexity describes PerplexityBot as the crawler that surfaces and links sites in its search results, and says it is not used to crawl content for AI foundation models.²⁶ Blocking a training crawler does not have to mean blocking a search crawler.
• Watch third-party coverage. Assistants read review sites, listicles and forum threads about your category, and a product absent from them is easy to leave out.

Traffic from AI Overviews and AI Mode is included in the overall search traffic in the Search Console Performance report, within the Web search type.²³ Traffic from other assistants arrives as referrals, often with no referrer at all. By default, browsers send only the referring site's origin on cross-site links, and nothing when a page or link uses the no-referrer policy.²⁷ HubSpot now files visits from platforms such as ChatGPT and Claude under a separate AI Referrals source.²⁰ For the wider picture of how these systems retrieve and cite sources, see the AI search pillar, and for a working model of how an assistant picks the names it gives, see how an assistant decides which businesses to name.

Software is easy to sell abroad and hard to localise well. Most early international search work goes into making sure the right version of a page shows in the right market.

• Only localise markets you can serve. A translated site with English-only support, pricing in the wrong currency and no local payment methods converts poorly and is hard to maintain.
• Pick a URL structure and stick to it. Country domains, subdomains and subdirectories each have trade-offs, and URL parameters for locale are best avoided.²⁸
• Do not redirect visitors automatically by IP. IP analysis is unreliable, and Google's guidance advises against automatically redirecting users from one language version to another.²⁸ Offer a language switcher instead.
• Localise pricing and comparison pages first, because those are the pages where currency, competitors and buyer expectations differ most by country.
• Keep docs in one language unless you can maintain translations. Out-of-date translated docs do more harm than English-only docs.

For hreflang, market selection and the structure decision, see the international SEO pillar.

For a SaaS company with a working product, a modest marketing site and little organic traffic, this is the order I would follow. It favours pages close to a buying decision, because they produce results sooner and teach you what your buyers search for.

A large blog calendar of top-of-funnel articles, a software app rich result without real reviews, and a subdomain-to-subfolder migration can all wait until the pages buyers search for are in place.