DEV Community

sepideh jafari
sepideh jafari

Posted on

What Building SEO for a New SaaS Product Taught Me

SEO for an established website and SEO for a new SaaS product are two very different problems.

An established website usually gives you data.

You have rankings, impressions, landing pages, backlinks, conversion history, and enough Search Console information to understand how people are finding you.

A new SaaS product gives you almost none of that.

You have a product, a market, a set of assumptions, and a website that search engines barely know exists.

That changes the job.

Instead of asking, “How do we improve this page?”, you often have to ask a much earlier question:

Which pages should exist in the first place?

Start With Problems, Not Features

SaaS teams naturally think in features.

The product may offer dashboards, user management, reporting, payments, messaging, automation, or dozens of other capabilities.

Users rarely begin their search there.

They search for problems.

Someone might search for:

software to manage clients,
a way to deliver programs online,
a tool to organize customer payments,
an alternative to spreadsheets,
or a platform for managing an online service.

This distinction matters because a feature list is not automatically a search strategy.

A good SaaS architecture needs to connect:

User problem → Search intent → Landing page → Product capability

When that relationship is clear, SEO becomes much more useful to the business.

The Homepage Can't Rank for Everything

One mistake I often see with young products is asking the homepage to do too much.

The company wants it to rank for the brand, the product category, every major feature, several use cases, and multiple commercial keywords.

That usually creates an unfocused page.

The homepage has an important job: explain what the product is, who it is for, and why someone should care.

More specific search intents often deserve their own landing pages.

For example, instead of forcing several different intents onto one page, a SaaS site might eventually have separate pages around:

Product category

Core use cases

High-value features

Specific audiences

Alternatives or comparisons

The exact structure depends on actual demand, but the principle is consistent:

One page shouldn't be responsible for every query in the market.

Search Intent Should Shape the Landing Page

Creating a page for a keyword isn't enough.

The page needs to satisfy the reason behind the search.

Someone searching for information may need an explanation.

Someone comparing software may need features, screenshots, pricing context, limitations, and differentiation.

Someone already searching for your brand may simply need a clear route to sign in or start using the product.

Those are different journeys.

This is why I prefer thinking about landing pages as part of a search journey rather than as isolated SEO assets.

The keyword gets someone to the door.

The page still has to convince them to enter.

SEO and Conversion Design Have to Work Together

Ranking a SaaS landing page without thinking about conversion is an incomplete win.

A page can attract organic traffic and still fail commercially.

The visitor needs to understand quickly:

What is this?
Is it made for someone like me?
What problem does it solve?
What can I do with it?
What should I do next?

This is where SEO, UX, copywriting, and product marketing begin to overlap.

A perfectly optimized H1 won't rescue a page that leaves users confused.

And a beautiful landing page won't generate organic acquisition if search engines can't understand what it's about.

The two disciplines need to meet.

A Real Example: Coachiko

I've been working through these questions while developing the organic search strategy for Coachiko, a platform designed to help fitness coaches manage their students and deliver training and nutrition programs.

It's an interesting SEO project because the potential search space is much broader than the product itself.

A coach may not search for the brand.

They may search for a way to manage students, create workout programs, work with clients online, or organize their coaching business.

That means our job isn't simply to describe Coachiko's features.

We need to understand the problems coaches already search for and build useful landing experiences around those intents.

This has reinforced a principle I find increasingly important:

SaaS SEO should translate product capabilities into existing user demand.

Public Pages and Application Pages Need Different SEO Rules

SaaS products often contain two very different websites under the same brand.

There is the public acquisition website.

And then there is the application itself.

Search engines generally need access to pages such as:

the homepage,
product landing pages,
feature pages,
use-case pages,
useful guides,
and other public resources.

They usually don't need to index:

login pages,
registration flows,
user dashboards,
private profiles,
account settings,
or application states.

Making that distinction early prevents unnecessary indexation problems later.

Not every route your application creates should become a search result.

Canonicals Still Matter on Small SaaS Websites

Canonical problems aren't exclusive to giant e-commerce stores.

A young SaaS product can create confusing signals too.

Public landing pages should generally communicate clearly which URL represents the primary version of the page.

Meanwhile, authentication pages and private application areas need their own indexing strategy.

This sounds basic, but implementing it during development is far easier than discovering hundreds of unwanted indexed URLs later.

SEO architecture is cheapest when it is designed before it becomes a problem.

Branded Search Is a Different Battle

For a new product, ranking for your own brand may sound trivial.

It isn't always.

Search engines don't initially have much information connecting a new word or name to a specific entity.

A new SaaS brand benefits from consistency:

the same name,

the same domain,

clear descriptions,

consistent profiles,

relevant mentions,

and eventually genuine references from other websites.

This isn't about manufacturing signals.

It's about making the entity easier to understand.

Over time, branded search becomes one of the clearest indicators that people are beginning to know the product exists.

Don't Create 50 Landing Pages Before Validating Five

Programmatic SEO and AI make it tempting to create large numbers of SaaS landing pages very early.

That can be useful in the right situation.

But scale should follow evidence.

I'd rather build a smaller set of genuinely differentiated landing pages, measure how search engines and users respond, and expand from there.

Otherwise, you risk creating dozens of pages with slightly different keywords but essentially the same purpose.

That isn't an information architecture.

It's duplication with different headings.

Content Should Support the Product Architecture

Blog traffic can be valuable for SaaS.

But traffic alone isn't the objective.

The strongest content strategy creates a relationship between informational demand and commercial pages.

A useful guide can answer a real question while naturally introducing a relevant product capability or landing page.

That creates a path:

Question → Education → Solution → Product

Without that relationship, a SaaS blog can accumulate impressive traffic while contributing very little to product discovery.

Traffic should have somewhere meaningful to go.

Measure More Than Rankings

Rankings are useful.

For a SaaS product, they are only part of the picture.

Organic growth should eventually connect to metrics such as:

qualified landing-page visits,
registrations,
demo requests,
activation,
branded searches,
and conversions from organic sessions.

A keyword moving from position 12 to position 6 is encouraging.

A landing page bringing in the right users is much more interesting.

SEO needs to connect with business outcomes.

The Bigger Lesson

SEO for a new SaaS product isn't primarily about optimizing what already exists.

It's about helping determine what should exist.

Which problems deserve landing pages?

Which features correspond to real demand?

Which application routes should search engines see?

How should informational content connect to commercial pages?

And how do we turn someone who has never heard of the brand into someone who understands why the product is relevant?

Those questions sit somewhere between SEO, product strategy, UX, and marketing.

That's what makes SaaS SEO interesting.

You're not simply trying to rank a website. You're helping build the search-facing architecture of a product while the product itself is still growing.

Top comments (0)