Product-led SEO: turning the product itself into indexable surface area

Canva ranks for “poster maker” because Canva makes posters, not because someone wrote an article about poster making. That is the whole idea, and it is much harder to copy than it looks.

Product-led SEO means the ranking asset is the product, or a piece of it, rather than content describing the product. Done well it is close to unbeatable, because a competitor writing about the thing cannot outrank the thing itself.

Four shapes it takes

Free standalone tools. A calculator, converter, generator, or analyser that solves one narrow problem instantly with no signup. HubSpot’s early signature generator, Ahrefs’ free backlink checker, every mortgage calculator on the internet. These rank because the searcher’s intent is to do something and the page lets them do it.

Public objects created by users. Job listings, status pages, public dashboards, shared documents, community answers. The content is generated by usage. This is the highest-leverage version and the hardest to retrofit, because it requires that your product naturally produces something worth making public.

Template and example galleries. Notion, Figma, Airtable. Each template is a page, each page has genuine unique content, and the gallery converts extremely well because someone looking for a template is looking to start using something.

Integration and app directories. If you connect to 180 tools, that is 180 pages of legitimately distinct content, and each one captures searches from people already using the other tool.

When this beats content, and when it does not

Product-led wins when the searcher’s intent is transactional in the small sense — they want to do a thing now, not read about it. “Convert PDF to CSV” is a doing query. No article will beat a converter.

It loses when the intent is genuinely to understand something, when the tool would be trivially copyable, or when building it costs more engineering time than the traffic justifies. A free tool is a permanent maintenance commitment. We have watched two clients build calculators that broke in a browser update and stayed broken for a year because nobody owned them.

The honest test before building: if this tool got 5,000 visits a month and none of them signed up, would it still have been worth the engineering? If no, you need a much clearer path from tool to product before you start.

The three ways it fails

The tool is gated. Someone decides that email capture before results will improve conversion. It improves the email capture rate on a much smaller number of people, destroys the engagement signals, and the page stops ranking. Give the answer first, ask afterward.

There is no bridge to the product. A free tool with 40,000 monthly visits and no relationship to what you sell is a charity project. The bridge has to be structural: the tool’s output naturally leads to the next problem your product solves. A salary benchmark tool for an HR platform works. A random word generator for the same platform does not.

Nobody maintains it. Free tools rot. Currency rates, tax tables, API changes, browser deprecations. Assign an owner or do not build it.

Public objects, which is the interesting one

If your product creates something that a user might reasonably want other people to see, you may be sitting on the strongest version of this.

The pattern: users opt in to making an object public, that object gets a stable URL, and the URL is indexable with a canonical structure and a template built for search rather than for the app.

The design questions are genuinely hard, and getting them wrong is worse than not doing it. Default must be private, always, with an explicit opt-in that is clear about what public means. There needs to be a quality floor, because indexing thousands of empty or test objects will damage the whole domain. Deletion has to work properly, including from the index. And you need a plan for the moment someone publishes something abusive under your domain.

A client of ours enabled public sharing on a class of report objects last year. About 4% of users opted in, which produced roughly 2,800 indexable pages in the first year. Those pages now drive 14% of their organic sessions and, more usefully, arrive with strong intent because someone shared them in a professional context.

Building the bridge

The mistake is treating a free tool like a landing page and covering it with CTAs. The reader came to do something; let them do it.

What works better is a next step that follows from the result. A tool that analyses something should offer to monitor it. A calculator should offer to save the scenario. A generator should offer to store what was generated. In each case the offer arrives after the value and it is a continuation rather than an interruption.

Measure the tool on assisted conversions and on returning visitors, not on immediate signups. Most of these produce their value on the second or third visit.

What to build first

If you are starting from nothing, the integration directory is usually the highest expected value, because the data already exists in your codebase, the search demand is real and easy to verify, and the intent is close to purchase.

Free tools come next but only where you can name the specific query and check that the current top three results are worse than what you would build.

Public objects come last, because the product work is substantial and the privacy design has to be right before a single page is indexed.