Last year a SaaS founder messaged me. Product was live, launch was done, three months of Product Hunt and Twitter traffic had come and gone. Now nothing. "Why isn't Google sending us anyone?" he asked, and pasted a few URLs. Every page looked like /app?view=pricing&tab=teams. The whole thing was client-side rendered, so Googlebot was reading an empty
I told him something he didn't want to hear: this isn't an SEO problem, it's an architecture problem. Fixing it meant rewriting most of the frontend. That is the bill you pay when SEO is the last thing on the roadmap.
SEO is architecture, not an add-on
Most teams treat SEO as a marketing task. Write the page, sprinkle keywords, add a meta description, ship it. But the most expensive SEO decisions happen long before anyone writes copy. Which framework? What rendering strategy? How are URLs structured? How is the sitemap generated? None of those sit on the content writer's desk.
Think of it this way. You don't pour concrete into a foundation after the building is up. SEO is the same. The later you involve it, the more it costs to retrofit. SEO-first means making product decisions under the constraint of organic discoverability. Once you accept the constraint, you stop accumulating rework.
If your first sprint contains zero conversation about search, you are pre-paying an agency invoice you don't see yet. I have watched this play out across dozens of products and the pattern never changes.
Keyword research is really intent research
People treat keyword research like Excel sorting. "Project management tool" gets 90,000 searches a month, beautiful, target acquired. No. If you do not know what the searcher actually wants, ranking number one will still produce zero conversions.
Intent comes in four flavors. Informational, commercial investigation, transactional, navigational. The same keyword can serve different ones. Someone searching "asana alternative" is fleeing Asana and comparing options. Give them a comparison page, not a blog post. Someone searching "what is project management" is not ready to see your pricing page.
The practical method is brutally simple. Type the keyword into Google, look at the top 10 results. All listicles? The intent is listicle. All product pages? The intent is transactional. Google has already told you what format wins for that query. If you fight that signal and ship a different format, you lose.
URL and information architecture
URL structure is one of the most expensive things to change once you go live. 301 redirect chains, lost backlink equity, indexing turbulence; all of those compound into a long tail of pain. Get it right on day one.
A clean hierarchy looks like /features/projects, /features/tasks, /blog/seo-first-development, /customers/acme-corp. A bad one looks like /page?id=42, /p/3f8a2c, /feature.html?type=task. URLs should tell both humans and Googlebot what the page is about. Pick a trailing slash convention and stick with it. Pick www or apex and set canonicals.
Information architecture goes deeper than URLs. How is the site categorized? Which page links to which? What does the breadcrumb look like? At Poitim our project management surfaces live under /features/projects, team management under /features/teams, and they cross-link naturally. That structure draws a coherent picture in the user's head and in Google's site graph at the same time.
Render strategy: SSR, SSG, ISR, and the SPA trap
A pure client-side SPA is great for an authenticated dashboard. It is a disaster for marketing pages. Yes, Googlebot runs JavaScript now. No, that does not mean everything works. There is a render queue, there are timeouts, there are silent failures. I have seen many projects where Search Console shows a page as indexed but the rendered HTML view is empty. Looks fine in your browser, looks blank to the bot.
The rule of thumb. Marketing surfaces (homepage, features, pricing, blog) should be SSG or SSR. App surfaces behind login can be CSR because they are noindex anyway. Next.js, Remix, Astro, SvelteKit all support this hybrid model. ISR is a nice middle ground for blogs and frequently updated pages; the page is statically generated but refreshed on a cadence.
One hosting warning. If you misconfigure edge SSR cache and Cache-Control headers, you can serve stale content for months and Google will index the stale version. Take cache invalidation seriously.
On-page without the checklist feel
On-page SEO usually shows up as a boring checklist. Title, H1, meta description, alt text, internal link. Yes, all of it matters. But treating each item as a mechanical task makes pages feel mechanical. Treat them as part of the page's story instead.
The title tag is the ad you sell on the search results page. Put the keyword early, brand at the end, stay under 60 characters. "Project Management Software | Poitim" works fine. The H1 can and should differ from the title; the H1 speaks to the visitor on the page, the title speaks to the searcher in the result. Meta description is not a direct ranking factor but it heavily influences click-through, and click-through indirectly influences ranking.
Use the keyword inside the body, but in a sane density. "Looking for a project management tool then this project management tool is the project management tool" does not fool Google, it just exhausts the reader. Synonyms, related concepts, supporting subheadings; together they describe the topic's shape. This is what semantic SEO means and modern algorithms read it well.
If you have a content team and more than one person ships posts, you need a single source of truth. Who is writing which keyword, who is editing, when does it publish? At Poitim our blog roadmap lives in a project board where every post is a task and every edit is a subtask. Spreadsheets fall apart by month three.
Schema.org structured data
Schema markup is how you tell search engines what your page actually is. A blog post? A product? A FAQ? A software application? When you mark the right type, you become eligible for rich results. Star ratings, FAQ accordions, breadcrumbs, pricing snippets; all of those run on schema.
For a SaaS landing page, SoftwareApplication or Product schema is a natural fit:
For blog posts use Article, for FAQ sections use FAQPage, for breadcrumbs use BreadcrumbList. Validate everything in Google's Rich Results Test, because a single missing field will silently disqualify the entire block.
Core Web Vitals are not optional anymore
LCP, INP, CLS. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. PageSpeed Insights lab data is nice but field data is what counts; that is the real Chrome User Experience Report.
The most common performance killers I see. Unoptimized hero images (3 MB JPEG instead of 80 KB AVIF), font flash (fix it with font-display: swap), third-party scripts (analytics, chat widget, A/B test tool, each one eating a second), layout shift (please specify width and height on every image). It is 2026 and there are still 5-second-loading sites whose owners wonder why Google sends no traffic.
Topic clusters as content strategy
Writing one-off blog posts and hoping something hits was already dead in 2018. Modern content strategy runs on topic clusters. A pillar page covers a broad subject, cluster pages around it dive into subtopics, all of them link to the pillar and to each other.
Example. "SaaS SEO" is a pillar. The clusters might be "Keyword research for SaaS", "SaaS landing page optimization", "Link building for SaaS", "Core Web Vitals for SaaS". Every cluster links to the pillar, the pillar links to every cluster, and clusters can cross-link. Google sees the structure and starts treating the site as a serious authority on SaaS SEO.
Running this requires real planning and reporting. Which cluster ships when, which pillar is pulling traffic, which post needs a refresh? Track it. If you work with a content team, set up role-based ownership so quality does not drift between writers, and watch traffic numbers in a reporting view rather than a chaotic spreadsheet.
Beginner mistakes that keep repeating
Same patterns, dozens of products. First, depending on a single launch channel. Twitter and Product Hunt fire on launch day, traffic dies a month later, panic mode begins. Organic SEO needs to start six months before launch because results take another six months to show.
Second, deleting pages or changing URLs too aggressively. "We rebranded so we changed every URL" usually means organic traffic gets cut in half and takes a year to recover. If you must rebrand, at least 301 every old URL to its new equivalent.
Third, copying what everyone else is doing. Same listicle, same "what is X" post, same "top 10 alternatives" tables. If the top results are 5,000-word polished guides, your 6,000-word copy of the same idea will not beat them. Try a different format. Original research. A real case study. An interactive tool. Google rewards content that brings something genuinely new.
Fourth, impatience. SEO seeds sprout in six to twelve months. Founders who quit after eight weeks and pivot to ads usually quit at the worst possible moment. Build a consistent program. If you want organic to be a real channel, put planning into a tool your team actually uses and ship something every week, even if small. Pick a setup that fits your team size and start.
SEO-first is discipline, not heroism. The right decisions in the right order. The product team does not need to learn SEO; SEO needs to be translated into the product team's language. Do that and you stop chasing agencies the morning after launch.