[Start]: Would you use TanStack Start for static Landing Pages?

[JulioGrajales]

I want to build several landing pages and thought of using tanstack start as an opportunity to learn it, missed the next.js wave and i got interested in learning this instead, but SEO is critical for me and im not sure if this framework is the right tool for them or just for web apps, maturity is also a concern for me, i don't know how many novel problems i will run into when using this for static prerendered landing pages.

Any comment would help 🙏

[sophus-ingi]

Landing pages work well with Start if you turn on prerendering. Every page gets built to plain HTML at build time, so SEO is fine and you can host it on anything static.

tanstackStart({
  prerender: { enabled: true, crawlLinks: true },
})

Use head() on each route for titles and meta tags.

It’s less mature than Next, so there are fewer examples when you get stuck. Static pages barely touch the trickier parts, though, so I wouldn’t worry much. Build one page first and check the generated HTML to make sure the content and meta tags are there.

https://tanstack.com/start/latest/docs/framework/react/guide/static-prerendering

[wowill]

For your goal of learning Start, I'd try one landing page first. Two deployment details to add to the prerendering answer:

• Parameterized routes such as /products/$slug are not automatically discovered as static paths. Supply concrete URLs in pages, or make sure the prerender crawler can reach them through links. Otherwise a successful build can still leave landing pages missing.
• Prerendering a page does not turn runtime server functions or form endpoints into static files. A page with a contact form still needs somewhere to handle submissions (a Start server deployment or a separate service).

For an SEO-critical launch, test the actual static deployment: request each landing-page URL directly, inspect the returned HTML for its main content and route-specific title/description/canonical, and test refreshes on nested paths. Client-side navigation working in development doesn't verify those things. Content fetched during prerendering also needs a rebuild to update the static output.

The prerendering docs describe path discovery and explicit pages; the SEO guide covers metadata. Those checks would be my decision gate before moving the remaining pages over.

AI-assisted reply, checked against the current documentation; I haven't built your site.

[praveen-kumary]

Here is an honest breakdown of using TanStack Start for static landing pages, especially coming to it fresh with SEO and maturity in mind.

---

1. Can it do the job for SEO?

Yes. When static prerendering is enabled, TanStack Start outputs raw, fully formed HTML at build time (.output/public):

// app.config.ts
import { defineConfig } from '@tanstack/start/config'

export default defineConfig({
  server: {
    prerender: {
      routes: ['/'],
      crawlLinks: true,
    },
  },
})

Search engine crawlers (Googlebot, Bingbot) and social crawlers (Twitter, LinkedIn, Slack unfurls) receive pure HTML without executing JavaScript.

You manage SEO in routes via head():

export const Route = createFileRoute('/')({
  head: () => ({
    meta: [
      { title: 'Product Name — High Performance SaaS' },
      { name: 'description', content: 'Clean description for search results.' },
      { property: 'og:title', content: 'Product Name' },
      { property: 'og:image', content: 'https://example.com/og.png' },
    ],
    links: [
      { rel: 'canonical', href: 'https://example.com' },
    ],
    scripts: [
      {
        type: 'application/ld+json',
        children: JSON.stringify({
          '@context': 'https://schema.org',
          '@type': 'WebSite',
          name: 'Product Name',
          url: 'https://example.com',
        }),
      },
    ],
  }),
  component: LandingPage,
})

---

2. The Nuances & Trade-offs You Will Encounter

Because TanStack Start is primarily designed as a full-stack SPA framework with SSR/SSG capabilities, building a static marketing site comes with a few trade-offs compared to dedicated static-site generators:

A. Hydration Cost vs. Zero-JS

• TanStack Start ships the React runtime and router bundle to the browser to hydrate the page for client-side navigation.
• If your landing page is 95% text, gradients, and CSS-driven layout, running full client hydration will add 70–120 kB of JavaScript. On mobile devices on slower networks, this can introduce a slight penalty on Total Blocking Time (TBT) compared to content-first frameworks like Astro (which ship 0 kB JS by default).

B. Image Optimization Pipeline

• Next.js includes next/image which automatically handles on-the-fly resizing, WebP/AVIF transcoding, and caching.
• In static TanStack Start, there is no built-in runtime image optimizer. You should either:
  1. Pre-optimize assets during your build using a Vite plugin (e.g. vite-plugin-image-optimizer).
  2. Or serve imagery via an image CDN (Cloudflare Images, Imgix, Cloudinary, etc.).

C. Forms and Contact Endpoints

• In a static build, server functions (createServerFn) cannot run because there is no active Node.js server.
• If your landing page has a waitlist, lead capture, or newsletter signup form, you'll need an external serverless endpoint (e.g. Formspree, Resend, an AWS Lambda / Cloudflare Worker, or a standard API endpoint).

---

3. When Is TanStack Start the Right Choice?

Scenario	Recommendation
Landing page + app under one roof (e.g., / is marketing, /dashboard is the app)	TanStack Start is exceptional. One unified codebase, zero duplicate layout logic, instant client-side transitions after login.
Learning the TanStack ecosystem	Great choice. Static pages touch routing, Vite configuration, SEO head(), and SSR/prerender concepts without the complexity of database transactions or edge runtimes.
Purely static brochureware/blog with strict 100/100 mobile Lighthouse requirements	Consider Astro. Islands architecture leaves behind zero client-side JavaScript overhead.

Summary

If you want to use this project as a runway to master TanStack Router and Start, it is completely viable for static prerendered landing pages. Just remember to verify your static output in .output/public and handle image optimization and external form endpoints explicitly.