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.
What Google says about AI Overviews
Google documents this directly. To appear as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to show in Search with a snippet, and Google states there are "no additional requirements" and no "special optimizations necessary". You don't need new machine-readable files, AI text files or markup, and no special schema.org structured data. That includes llms.txt: Google does not ask for it. Inclusion is still not guaranteed.
What Google does recommend is ordinary good practice: let crawlers in, link pages internally so they are easy to find, keep key content as text, and make sure structured data matches the visible page. Traffic from these features is counted in the Web search type of the Search Console Performance report, so you can measure it without a new tool. Other AI assistants may behave differently, but we have yet to see a reason to build a second site for them.
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.
Search intent decides what kind of page you need
Before choosing a keyword, ask what the person typing it wants. The same product can be searched in very different moods, and each one needs a different page.
| Intent | Typical query | Page that fits | What it must do |
|---|---|---|---|
| Learn | "how do quotations differ from invoices" | Guide or blog post | Explain clearly; point to the product only where it helps |
| Compare | "X vs Y", "best tools for Z" | Comparison page | Give criteria, honest trade-offs and a recommendation |
| Buy or hire | "software for accountants", "software company Thailand" | Landing page, pricing, shortlist | Show proof, price range and the next step |
| Solve now | "website offline what to do" | Checklist or help page | Give the fix first, the sales pitch last |
Our guide best software development companies in Thailand is an example of a buyer-intent page: the reader is already comparing options, so it gives criteria, a shortlist and prices instead of a definition of outsourcing. If your page type does not match the intent, no amount of optimisation will fix it. Google's own starter guide suggests thinking about the words a user might search for, and notes that people with different knowledge levels phrase the same need differently.
Do keyword research before you build
Most teams do keyword research when the site is finished. Do it when the roadmap is still open, because it can change the roadmap.
- List the problems, not the features. Use the words customers use in sales calls and support tickets.
- Search each problem yourself. Look at who ranks and which page types appear. If every result is a comparison and you plan a feature page, you have the wrong format.
- Check your own data. Search Console shows the queries you already get impressions for, which is the cheapest research you will ever do.
- Sort the findings into three piles: things we do and should write about, things we do but nobody searches for, and things people search for that we don't do. The third pile is product feedback; see above.
- Validate before building. A landing page for a planned feature, clearly marked as coming soon, is a cheap test of demand. Never describe it as available.
Plan the information architecture early
Site structure is a product decision. Google's SEO starter guide recommends organising the site logically, using descriptive URLs with words that help users rather than random identifiers, and linking pages with descriptive anchor text. It also notes that most new pages Google discovers each day are found through links.
A structure that works for most digital products:
- Hub pages for each main problem or audience (for example "software for accountants").
- Spoke pages underneath: features, use cases, comparisons, how-to guides, each linking back to the hub and sideways to related spokes.
- One URL per topic. If two pages answer the same question, merge them.
- The same structure in every language, so translated pages are not orphaned. The technical side of this is covered in SEO for developers.
Content types that tend to rank and convert
- Comparison pages ("X vs Y", "alternatives to X"). Readers are close to deciding. Be fair; a comparison that always crowns your product convinces nobody. We follow this pattern in Python vs Node.js and .NET vs Java.
- Problem guides that solve one question completely, with steps someone can follow today.
- FAQs written from real questions from sales and support, placed on the page where the question arises, not in a dumping-ground page.
- Pricing and cost pages. "How much does it cost" is among the most common buyer questions; see our own website cost in Thailand breakdown and pricing.
- Tools and calculators that answer a question directly. Our EngineeringScore audit and MigrateXtoY migration guides started as products and also attract people with exactly that need.
- Case studies with real numbers, such as our Shopify app case.
Google's people-first content guidance asks whether the content offers original information, research or analysis, shows clear sourcing and who wrote it, and goes beyond summarising what others say. A page built from your real product experience passes that test far more easily than a rewrite of the top ten results.
Programmatic pages: useful at scale, or spam at scale
Generating many pages from data can be legitimate. Think of one page per city, per integration, per industry or per migration path. It goes wrong when the pages differ only by a swapped keyword.
Google's spam policies define scaled content abuse as many pages generated "for the primary purpose of manipulating search rankings", and say the problem is large amounts of unoriginal content with little value, "no matter how it's created". Using generative AI to produce many pages without adding value is a listed example. Doorway abuse is creating "substantially similar pages" to rank for similar queries instead of a clearly defined, browseable hierarchy.
Our rules before generating a template-based set of pages:
- Does every page contain data or advice that is true and specific to that page? If you could only change the place name, don't publish it.
- Would a visitor who lands on it find a real answer, not a funnel to another page?
- Is it part of the site's normal navigation, and linked from a hub?
- Can you start with 10 strong pages and look at the results before making 1,000?
MigrateXtoY is a useful example of the good version: each migration between two platforms has its own steps, effort estimate and pitfalls, so every page is different in substance. Google also lists changing page dates to look fresh, without substantial updates, as a sign of search-engine-first content, so don't do that either.
Which approach should you choose?
- Pre-launch, no audience: do keyword and intent research, then build the hub pages and 5 to 10 buyer-intent and problem pages. Skip volume.
- Live product, little traffic: check Search Console, fix pages that get impressions but no clicks, add comparison and pricing pages.
- Many similar offers (cities, industries, integrations): a programmatic set is justified, but only with unique data per page.
- Worried about AI search: do the fundamentals above, keep key content as crawlable text, and measure in Search Console. Don't buy an "AI optimisation" package that promises something Google says isn't required.
If you want a quick view of where your current site stands technically, run it through EngineeringScore (free) or use our website check. For help planning a product site, see our projects or pricing.
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.
Sources
Frequently asked questions
When should SEO start in a product project?
Before development. The research about customer problems, wording and competitors is the same for product and SEO, and it can change what you build.
What is search intent?
It is the goal behind a query: learning, comparing, buying or fixing something now. Each goal needs a different type of page.
Do I need special markup or llms.txt to appear in Google AI Overviews?
No. Google's documentation says there are no additional requirements, no special optimisations and no special schema.org markup. The page must be indexed and eligible to show with a snippet.
Are programmatic SEO pages allowed?
Yes, if each page is genuinely useful. Google's spam policies target many pages made mainly to manipulate rankings, with little unique value, however they are created.
Which content types work best for a digital product?
Comparison pages, problem guides, honest pricing pages, FAQs from real customer questions, case studies and small tools. All of them should reflect what the product really does.
How do I measure traffic from AI Overviews?
Google reports it in the Search Console Performance report under the Web search type, together with your other search traffic.
Related articles
Added an SPF Record and Lost Google Search Console? Here's Why
Adding SPF can silently delete your Google verification code from the same DNS TXT record. How it happened to us on six domains, how to check yours and how to fix it.
Clinic Website Thailand: What Gets Bookings, What It Costs
What a clinic website in Thailand needs to turn visitors into bookings, which advertising rules apply, and what it costs: from ฿19,900 to ฿49,995 and up.
Real Estate Website in Thailand: Listings, Leads and Cost
What a real estate website in Thailand needs: listing pages, search, LINE buttons, lead capture, PDPA. Portal fees vs. your own site, and 2026 prices.
