By Mehdi HassanHow do you build programmatic SEO pages with Next.js?
You build programmatic SEO pages with Next.js by defining a dynamic route such as app/integrations/[slug]/page.tsx, loading each page's data from your database or CMS by slug, and choosing how each page renders: statically at build time, on demand with incremental static regeneration, or a mix. Metadata, sitemaps and internal links come from the same dataset.
Next.js is the stack we reach for when a programmatic set grows into thousands of pages, needs nested URLs or pulls live data from a product. The strategy behind it, especially the unique-data rule, lives in our programmatic SEO hub. This guide is the engineering side, written for the developer who'll build it and the founder who'll approve it.
What does a programmatic SEO nextjs setup look like in the App Router?
A programmatic SEO nextjs setup in the App Router has four parts: a data layer that returns one record per page, a dynamic route that renders the record, metadata functions that describe it, and sitemap and linking code that helps crawlers find it. Keep the data layer separate from the components, so the same function feeds the page, the metadata and the sitemap.
Part | Next.js feature | Job |
|---|---|---|
Data layer | A server function per page type | Fetch one record by slug, and list all slugs |
Route | Dynamic segment, such as [slug] | Render the page from the record |
Static params | generateStaticParams | Choose which pages pre-render at build time |
Caching | revalidate and on-demand revalidation | Keep pages fast and fresh without full rebuilds |
Metadata | generateMetadata | Title, description, canonical and Open Graph per page |
Share image | opengraph-image route file | Generate an OG image per page from its data |
Sitemaps | sitemap file with generateSitemaps | Split URLs into multiple sitemaps |
Nested routes are a strength here. You can build app/[country]/[city]/page.tsx or /integrations/[category]/[tool] directly, which is one of the main reasons teams leave Webflow or Framer; see programmatic SEO in Framer for the limits on the other side.
Should programmatic pages use SSG or ISR?
Programmatic pages should usually use both: static generation for the pages you're sure matter, and incremental static regeneration for the long tail. Pre-rendering everything makes builds slow as the set grows, and rendering everything on demand makes the first crawl slower for every page. A split gives you fast builds and fast pages.
Pre-render the top set
Return your highest-value slugs from generateStaticParams, for example the variations with real search demand or the ones you've reviewed by hand.
Allow the rest on demand
Keep dynamicParams enabled so other valid slugs render on first request and then get cached like static pages.
Set a revalidation window
Export a revalidate value that matches how often the data really changes, such as daily for prices or weekly for integration details.
Revalidate on change
When a record changes in your CMS or database, call revalidatePath or revalidateTag from a webhook so only that page refreshes.
Return 404 for unknown slugs
If the data layer finds no record, call notFound, so random URLs don't render empty pages with a 200 status.
How do you generate metadata and OG images for thousands of pages?
Generate metadata and OG images for thousands of pages by building them from the same record that renders the page, inside generateMetadata and an opengraph-image route file. That keeps titles, descriptions, canonicals and share cards in sync with the content automatically, so you never ship a page whose snippet describes something else.
- Title and description: written as patterns with real data in them, not just the variable name, for example including the specific feature or price.
- Canonical: the clean URL of the page itself; filtered or sorted views point back to it.
- Open Graph image: a generated card with the page's name and one key fact, rendered with the ImageResponse API.
- Robots: noindex for variations below your quality bar, so they can exist for users without being submitted to search.
- Structured data: BreadcrumbList and the right page type as JSON-LD, built from the record.
Schema is hygiene, not a ranking trick. Ahrefs' 2026 controlled test found no lift in AI answers from adding schema, so spend more effort on the visible content than on markup. The programmatic page template covers what that content should be.
How do you build sitemaps for a large Next.js site?
Build sitemaps for a large Next.js site by splitting them by page type and size with generateSitemaps, so each file stays within the per-file limits in Google's sitemap documentation and each page set has its own file. Search Console then reports indexing per sitemap, which tells you which sets Google values.
- One sitemap per page type, such as integrations, templates and glossary, chunked if a type is very large.
- Accurate lastModified dates taken from the record's real update time, not the build time.
- Only indexable URLs: leave out noindexed, redirected and canonicalized pages.
- A sitemap index listed in robots, generated by a robots file in the app directory.
- Submit each sitemap in Search Console and check the pages report per sitemap after launch.
Sitemaps get pages discovered, not indexed. If a whole set stays unindexed, the problem is usually the content. Our guide to scaled content abuse explains how Google treats templated pages with little unique value.
How should internal linking work across thousands of pages?
Internal linking across thousands of pages should give every page at least one link from a browsable directory and several links from related pages, using descriptive anchors generated from the data. Pages that are only in a sitemap, with no internal links, are the ones Google tends to discover late and index least.
- Directory pages for each set, paginated with plain links, so crawlers can reach every item in a few clicks.
- Category hubs that group items and explain the category, which also rank in their own right.
- Related items computed from the data, such as tools in the same category or industries with similar workflows.
- Contextual links from blog posts and product pages into the highest-value items, as covered in our guide to topic clusters and pillar pages.
- Breadcrumbs that reflect the nested route, with matching BreadcrumbList data.
Hypothetical example: a 3,000-page integrations directory in Next.js
For example, suppose a data platform has 3,000 connector pages, each fed by the product's own connector registry: supported objects, sync frequency, auth method and setup steps.
The team pre-renders the 300 connectors with search demand at build time and lets the rest render on first request with a daily revalidate. A webhook from the registry calls revalidateTag when a connector changes. Sitemaps are split into connectors, categories and guides. Each connector page links to its category hub and to five related connectors chosen by shared objects. Connectors with fewer than four filled fields are noindexed until the data improves. The numbers are illustrative, not client results.
How do you make Next.js programmatic pages readable by AI crawlers?
Make Next.js programmatic pages readable by AI crawlers by rendering the main content on the server, keeping the key facts in HTML text and tables, and not blocking the crawlers you want in robots. Many AI crawlers don't run JavaScript, so content that only appears after client-side fetching may be invisible to them.
Server Components make this the default in the App Router, but it's easy to undo with a client-side fetch for the main data block. Check the raw HTML response for a few pages, not the browser view. Our guide to query fan-out explains why narrow, factual pages like these get pulled into AI answers. If you're migrating an existing set into Next.js, compare notes with our Webflow to Next.js case study, a hypothetical walkthrough of the process.
