SEO for a digital product: it starts long before you write your first article

When we're discussing a new website with a client for its product, the conversation almost never starts with SEO.

It starts with the product:

What are we actually building?
Who is it for?
Which problems does it solve?
What makes it different from the twelve competitors already on the market?
How would someone even search for a solution like this?

Interestingly enough, somewhere during that discussion, product development slowly turns into SEO without anyone really noticing.

Can we actually do what this page promises?
Should we build this feature before writing about it?
Does someone searching for this term have a problem our product genuinely solves?

Those questions sound like product development questions, because they are. The interesting part is that they are also SEO questions.

Many companies still see SEO as something that happens after development. The product is finished, marketing gets involved, someone performs keyword research, a few landing pages are written and, with a bit of luck, Google starts sending visitors.

Personally, I think that order is backwards.

At We Do Dev Work, we've always considered SEO to be another part of product development. Not because developers should suddenly become marketers, but because both disciplines start with exactly the same question: what are people trying to achieve?

Whether you're building software or writing content, you're trying to understand someone's problem before proposing a solution.

Product research and SEO research are almost the same exercise

Imagine you're building software for accountants.

Before writing a single line of code, you'll probably ask questions like:

What frustrates accountants today?
Which tools are they currently using?
What takes too much time?
Which industries experience these problems most often?
Which features would make enough of a difference for someone to switch?

An SEO specialist should be asking almost identical questions.

Instead of asking which feature deserves development time, they ask which problem deserves a landing page. Instead of prioritising a product backlog, they prioritise content opportunities. The underlying research, however, is remarkably similar.

That's why we don't like separating product development and SEO into two completely different projects. They should continuously influence one another.

Your product should define your content

One of the biggest mistakes we see is companies creating content for functionality they don't actually offer.

A keyword tool suggests a phrase with decent search volume, somebody writes a landing page around it, and suddenly the website starts implying that the software supports features that either don't exist or are only partially implemented.

That might generate traffic in the short term, but it creates disappointed visitors, lower conversion rates and eventually damages trust.

We prefer approaching it the other way around: every meaningful feature should naturally create content opportunities.

If you've built quotation management, you can explain how quotations differ from invoices, how quotation workflows work, common mistakes businesses make and why digital quotations save time.

If you've added multi-currency support, there are obvious opportunities to explain international invoicing, exchange rates and cross-border payments.

If you've specialised in a particular industry, that deserves dedicated landing pages explaining how your software solves the problems of that industry.

Notice what's happening here: the product isn't following the content, the content is following the product.

Search behaviour is valuable product feedback

The relationship also works in the opposite direction.

Keyword research shouldn't just tell your marketing team what to write. It should also tell your product team what people are looking for.

If hundreds or thousands of potential customers keep searching for a feature your software doesn't have, that's valuable information.

Sometimes the correct conclusion isn't to write another article explaining why you don't support it. Just put it on the roadmap.

Good SEO research often uncovers unmet customer needs long before they appear in a sales meeting.

SEO is becoming more technical again

People often divide SEO into technical SEO and content SEO, but we increasingly see technical SEO as simply part of building a good web application.

Let’s break it down:

Fast websites provide a better user experience.
Logical navigation helps visitors find information more easily.
Clear internal linking explains the relationship between different topics.
Structured data helps search engines understand your content.
Proper multilingual architecture prevents duplicate content issues and ensures the correct language is shown to the correct audience.

None of these improvements we do for Google. We build websites and applications for people. Why do we care about those? Simply, they improve the quality of the website itself.

If your website becomes easier for search engines to understand, it usually becomes easier for visitors as well.

What changed with AI?

Every few months there's a new headline announcing that SEO has fundamentally changed.

This year the conversation revolves around AI search, Generative Engine Optimisation (GEO), llms.txt files and optimising content for large language models.

Those developments are real and they're worth paying attention to. We already consider things like structured content, schema markup, clean documentation and AI-readable website architecture during development because they're sensible technical decisions.

At the same time, we don't think AI changed the fundamentals:

AI still needs reliable information
It still benefits from well-structured websites
It still prefers content that answers real questions

Perhaps the biggest change is that consistency matters even more than before. Your landing pages, documentation, help centre and product all need to tell the same story. If your website promises features your software doesn't deliver, that inconsistency becomes much easier to detect, whether it's by a search engine, an AI model or, more importantly, a potential customer.

Bringing SEO into product development

Instead of treating SEO as the final phase of a project, we prefer discussing it throughout development.

Whenever we're designing a new feature, we naturally ask ourselves a number of additional questions.

Product

Which customer problem does this solve?
Is that problem important enough for people to actively search for a solution?
Which terminology do customers use when describing it?
Which industries or user groups experience this problem most often?

Content

Does this feature deserve its own landing page?
Can we write supporting documentation or FAQs?
Are there blog topics that naturally follow from this functionality?
Can we demonstrate the feature with screenshots or real examples?

Technical SEO

Does this fit logically within the website architecture?
Will it strengthen our internal linking?
Do we need structured data?
Is it available in every supported language?
Can search engines and AI systems easily understand the page?

By the time a feature reaches production, most of the SEO thinking has already happened.

Writing the article is often the easiest part.

What is the message here

People often ask us whether SEO should be handled by marketing, developers or an external agency. Our answer is usually "all of the above.", as long they work together.

Marketing understands positioning
Developers understand the product
Designers understand usability

SEO sits somewhere in the middle of those disciplines.

The better those teams work together, the more natural your website becomes. Instead of writing pages because a keyword tool suggested them, you're documenting real functionality, answering genuine customer questions and building authority around the product you've created.

That's why we don't see SEO as something you add after launching a website.

We see it as something that starts the moment you begin thinking about the product itself.