Programmatic SEO on Next.js and Vercel

Next.js can render a page at build time (static generation), on request (server rendering), or in the browser (client-side). For programmatic SEO only the first two are acceptable, because Google's first indexing pass and every AI crawler read the HTML the server returns without executing JavaScript. A client-rendered page returns a shell with a loading state; SerionFlow's own marketing site made this mistake and served 111 to 229 words of static HTML per page, which explained its "Crawled, currently not indexed" status and zero AI citations until the prerender was fixed.

Use static generation for pages whose data changes rarely and server rendering, with caching, for pages that must reflect fresh data. Incremental static regeneration blends the two.

Define a dynamic route such as app/guides/[slug]/page.tsx, load the page's content from a data source in the route, and render the full article with headings, tables, FAQ, and related links in the component. Export generateStaticParams to enumerate slugs at build time and generateMetadata to produce a unique title, description, and canonical per page. Add an app/sitemap.ts route that lists every generated URL with lastmod, and a robots route or static file. Structured data goes in a script tag rendered by the component so it is in the HTML.

Vercel rewrites, configured in vercel.json or next.config, map a path on your domain to another destination, including an external origin. A rewrite for /explore/:path* to SerionFlow's origin serves SerionFlow-generated pages under your domain while the rest of the app is unchanged. The pages are first-party URLs, they share the Search Console property, SerionFlow maintains their sitemap, and nothing in the Next.js codebase changes beyond the rewrite. This is one of the two routing paths SerionFlow documents, alongside Cloudflare Workers.

Teams use this when they want the app to stay focused on product and a separate loop to research, draft, review, and refresh SEO pages from Search Console data.

Build time grows with page count under static generation; use ISR or on-demand revalidation past a few thousand pages. Keep the data source, whether a database, a CMS, or JSON files, as the single source for content, metadata, and sitemap so they cannot drift. Generate related links from the data so no page is orphaned. Run a post-build check that fetches a sample of generated HTML and asserts word count, headings, canonical, and JSON-LD; it is cheap and catches regressions.

Fetch a generated page with curl and confirm the article is there. Fetch it with Googlebot and AI crawler user agents and confirm 200 with full HTML; Vercel's firewall and any bot protection should allow them. Confirm robots.txt allows the generated paths and the sitemap is submitted. Validate JSON-LD on a sample. SerionFlow's free AI crawler access checker and robots.txt checker cover the fetch tests without an account.

Build natively when you own the data, have engineering time, and want complete control over templates and rendering. Route to a platform when the pages must be discovered from Search Console and competitor evidence, drafted per intent, reviewed, and refreshed weekly, and when engineering time is better spent on the product. Many teams do both: native routes for data-driven pages and a rewrite to SerionFlow for research-driven ones.