SEO Is Part of the Product, Not a Post-Launch Afterthought

Start by letting search engines see the right page on the first request, then worry about keywords.

SEO is part of the product, not a post-launch afterthought.

Since I started building products on my own, I have looked at a lot of freshly launched websites and kept seeing the same class of problems. From rendering and language routing to robots, sitemaps, error states, test environments, page tags and keyword coverage, almost none of the foundational SEO setup is in place. SEO never entered the build process.

The most serious SEO problems

The most common mistake on new sites is that the basic SEO infrastructure is missing almost everywhere. Client-side rendering, language routing decided by the browser, robots.txt and sitemap returning the homepage, missing URLs returning 200, test environments indexed by Google, no canonical, no hreflang, no H1, no crawlable links, no structured data.

They share one pattern: on the first request, search engines cannot get an HTML page that explains what this page is. No matter how good the keywords are, there is nowhere for them to land.

SEO was never part of the build process. If a page was never designed as something that needs to be understood, indexed and correctly linked, adding content later is just patching.

The first shift: treating search queries as market signals

I started taking SEO seriously because of a strange query in Search Console, back when my product page had almost no traffic.

One of my product pages showed a misspelled, incomplete-looking search term. It made me see that a real query is a weak signal from the market and should not be treated as just another row in a report. A real query can contain at least three kinds of information:

• Demand signal: someone is actively looking for something;
• Distribution signal: Google already associates my page with that intent;
• Product signal: the search intent may reveal the problem users want to solve.

The approach became: treat a real query as a demand probe first, then decide whether to build a dedicated landing page for it. Producing SEO pages in bulk and waiting for demand gets the order wrong.

I keep this order in every project:

Real query → understand the intent → verify relevance → build a landing page → watch the queries expand

A landing page answers one question

The homepage has to explain brand, product, features, pricing, downloads and more. A landing page only needs to answer one specific question well. For example, when my product saw real queries like “Mac connected to Wi-Fi but no internet,” a page dedicated to that exact problem did more for search engines and users than the homepage could.

What matters after launch is which new queries it attracts. If a vague term gradually spreads into a whole cluster of queries, a workflow that is not yet well served may matter more than any single keyword.

Trust is scarcer than a click

While working on competitor pages, I made a concrete mistake: I treated an ambiguous product name as if it were one product and wrote that “this competitor has no Mac version.”

Several unrelated products shared the same name, and we were studying only one of them. I now follow a rule:

Whenever a competitor, brand or product name is involved, disambiguate the entity first.

At minimum, confirm the full product name, the developer or company, the official website, whether other products share the name, and whether platform, pricing and feature claims come from official sources for this specific entity. If the name is ambiguous, say so above the fold instead of hiding the clarification at the bottom.

Trust cannot be borrowed. For a small independent product, one SEO click has almost no long-term value. But if a user discovers that a page is deliberately confusing, hiding facts or exaggerating a competitor’s flaws, their judgment of the whole product and brand drops.

My rule is:

Search intent matches the page promise × page promise matches product capability

If either layer is inconsistent, more clicks only send more mismatched users through the door.

The order that works: rendering and routing, foundation files, test environments, then page signals and keywords.

The right order: let search engines reach the right page first

The order I use now is:

1. Fix rendering and language routing first. Move the homepage and core pages to SSR, SSG or pre-rendering so content, unique TDK, H1 and links are in the HTML on the first request. Stabilize the root, and make each language a clear, crawlable page.
2. Add foundation files and correct error states. Serve real robots.txt and sitemap.xml. Missing URLs should return 404 or 410, not all redirect to the homepage.
3. Isolate test environments. Gate internal test and dev subdomains with authentication. Any page that must be publicly previewed should use noindex.
4. Complete page signals and keyword entry points. Add canonical, hreflang, Open Graph, structured data and crawlable internal links, then split existing product capabilities into feature pages, tutorials and FAQ.

The key to this order: let Google reach the right page directly, then handle crawling, indexing and page signals, and only at the end keywords and content. Once a site is already live, do not rush to add new pages. Sort out the existing pages and foundations first.

Search intent, page promise, and product capability must line up before a click is worth earning.

My practice: putting SEO into the build process

Talk is cheap. I am already applying this order to my own projects:

• Main site i18n: English stays at the root and Chinese lives under /zh/. Every translated page has lang, canonical, two-way hreflang, OG locale and JSON-LD. Untranslated pages do not expose a /zh/ route, so half-finished pages are never indexed.
• Troubleshooting posts on the product site: for queries like “Mac connected to Wi-Fi but no internet,” the symptom decision table moves above the fold so Google and users see the diagnostic path faster. The FAQ adds troubleshooting questions and links to the right articles.
• Competitor and comparison pages: confirm the specific entity first, describe both the overlap and the fundamental difference, and say it directly when a competitor fits a need better.
• Multi-language game pages: fix JSON-LD language signals so every language has the correct inLanguage instead of everything being marked en.
• Private dashboard: public access is protected, the login page uses noindex, and the sitemap excludes internal pages.
• Baseline checks on every release: submit URL Inspection and sitemap discovery on launch day, save the deploy hash and change list, check indexing and crawl at day 7, query expansion at day 14, and make a fuller call at day 28.

The shared goal is: a real, correct, understandable page exists when search engines and users make their first request.

SEO is part of the product

The biggest lesson from these observations is:

SEO is part of the product, not a post-launch afterthought.

If a product is designed from day one with “how will search engines understand this page?” as a requirement, robots.txt, canonical and the indexing basics already exist before launch.

Independent developers have no operations team to catch what we missed. SEO is a normal part of the build: let search engines reach the right page first, then talk about keywords. Solve a real problem first, then chase traffic.

My standard for whether a page is done well is simple: it is real, correct and understandable.