SaaS SEO case study: early search traction for a new developer tool

The product and the problem

The client is a young B2B software company that sells a tool to developers and engineering teams. The name stays private. The client has agreed to show the anonymized Search Console data, and that data is all this page reports.

The site launched on a fresh domain. It had no links pointing to it, no search history, and nobody searching for the brand. The category was crowded: established products held the broad terms, and large documentation and media sites answered most of the general questions.

Founders in this position are usually told that SEO takes a year and that paid channels must carry the company until then. For a young product that is an expensive wait. Early search visits bring trial users, and the searches that bring them tell the founders which problems buyers actually type into Google. The question was narrow: could a new site earn real visibility quickly if every page matched a precise developer need and Google could read it on the first visit?

What the early research found

There was no old site to clean up, so the first step looked at the market instead of a crawl. Three openings stood out.

What we built, in order

1. Step 01

   Write pages for problems, not head terms

   Comparison pages and workflow guides were written around the problem searches the research found. Each page was marked up with clear schema so Google could see what it compares or solves.

   What this finds. Pages that match what a developer types in the middle of a task.

2. Step 02

   Link documentation, features, and signup together

   Guides, feature pages, and the signup flow were linked as one system, so a reader who arrived on a guide had a clear path to the product.

   What this finds. Visits that lead somewhere instead of ending on a guide.

3. Step 03

   Serve every page as server rendered HTML

   Pages were delivered as complete HTML in the first response, with no reliance on scripts to show the main content.

   What this finds. Full content on Google's first fetch of a brand new site.

The order mattered here too. Rendering work alone would have produced fast pages that matched no search. Content alone would have produced good pages that Google read slowly. Linking came second because a visit that cannot reach the product is wasted for a company that needs trials.

How to read the numbers

From 15 May to 26 July 2026, Google Search Console recorded 610 organic clicks in the first 72 days, view evidence clicks and 30.6K impressions for the site, with an average click through rate of 2% and an average position of 12.6. That window covers 72 days.

Average position is averaged across every search the site appeared for, including long tail comparisons where it sat lower. A figure of 12.6 means many of those searches showed the site near the bottom of page one or the top of page two. A click through rate of 2% fits that mix: people do click results at that depth, but not often.

The useful reading is fit, not size. The site was being shown for the problem and comparison searches it was built for, and developers were clicking. 610 clicks will not fund a company. They do show that Google indexed the site, trusted it enough to test it on real searches, and that the pages matched what searchers wanted.

What this case does not prove

The screenshot shows one period with no comparison period, so it shows reach in one window, not growth. It does not show that the domain was new. That detail comes from my project notes.

It measures clicks from Google, not trials, signups, or revenue. The client has not shared those figures for publication, so this page makes no claim about them. The three changes happened together, so the case cannot say which one mattered most. And a developer tool sold worldwide is a different market from a local business in Pakistan.

I cannot promise the same result for another product. Some categories have no gaps a new site can reach, and some products have no problem searches worth writing for.

Signs your product site has the same gaps

• Your pages target broad category terms that large companies already hold
• Nobody on your site compares your tool with the ones buyers are choosing between
• Your documentation or marketing pages show little or no text when scripts are turned off
• A reader on a guide has no clear link to the product or the signup page
• Search Console shows impressions for your brand name and almost nothing else

If your site gets visits but few trials, read my guide to visits that never turn into signups. It covers intent and landing page problems in more detail.

Why this approach suits a new domain

A new site cannot win a broad term in its first months, because Google has no history to judge it by. It can win a narrow search where the existing results answer the question badly. Each of those small wins gives Google another reason to show the site for the next search.

Comparison pages work for the same reason. Buyers who search for one tool against another are close to a decision, and large vendors often avoid writing those pages honestly. A fair comparison that admits where your product is weaker earns more trust than a sales page.

Rendering is the quiet part. Google can process JavaScript, but it costs more work and can delay what gets indexed. Plain HTML in the first response removes that delay for a site that has no credit to spend. It is part of the rendering and crawl work for software sites I do on most launches. The writing side, comparisons and guides, falls under comparison and guide writing for buyers.

The same logic shows up in other cases. A site with too many weak pages loses attention, as in the content site whose articles were buried in archives. A site whose pages compete loses it too, as in the firm whose service pages competed.

What a software company in Pakistan can take from this

Many Pakistani software houses build products for buyers abroad. Their sites often launch as a single page app with the content loaded by scripts, and their blogs chase broad terms written for local readers. Both choices waste the first months of a new domain.

Before launch, check three things. Does every main page show its content in plain HTML? Is there a page for each comparison a buyer makes? Does each guide link to the product? A launch review before the first page goes live covers all three.

If you sell to developers abroad, also check whether AI tools mention your product when buyers ask for alternatives. My guide on why a product is missing from AI answers explains the checks. For a quicker look, the free scan of a single page shows whether your content is in the HTML at all.

If you would rather talk it through, book a paid hour to read your Search Console together. Ongoing work is listed in monthly plans priced in Pakistani rupees.

Your next step

If your product site is new or stuck on page two, send me the site and the searches you care about. I reply within 24 hours.