Advanced Routing & Dynamic Routes in Next.js

Routing in the Next.js App Router is built on a file-system convention. Every folder under app/ becomes a route segment, and the files inside it decide what renders at that URL. This convention is simple for static pages, but real applications need dynamic paths, grouped layouts, parallel views, and generated metadata. Understanding how these pieces compose is the difference between a clean URL structure and a fragile one.

Dynamic routes let one page file match many URLs. A product page can serve /products/1, /products/2, and any other ID without creating a dedicated file for each item. Static generation can be combined with dynamic paths through generateStaticParams, so the performance benefits of SSG extend to data-driven pages. Route groups, parallel routes, and catch-all segments add organizational power without leaking into the URL.

This guide covers dynamic route segments, static generation for dynamic routes, dynamic metadata, route groups, parallel routes, catch-all patterns, programmatic navigation, and route precedence. The goal is a production-grade mental model: keep URLs stable, validate parameters, and let Next.js generate the right page for the right request.

A route segment is dynamic when its folder name is wrapped in square brackets. The file app/blog/[slug]/page.tsx matches /blog/hello-world, /blog/routing-guide, and any other value in the slug position. The matched value is passed to the page as the params prop.

In Next.js 16, params is a Promise that must be awaited before use. This matches the same async pattern used for searchParams and for data fetching in Server Components. Always await it and destructure the fields you need.

You can have multiple dynamic segments in the same path. app/shop/[category]/[productId]/page.tsx matches URLs like /shop/electronics/42, and the params object will contain both category and productId as strings. Use them together when the data model is nested.

Statically typed params are important because every param starts as a string. If you expect a number, parse it with Number.parseInt or a validation library such as Zod. Never cast a param directly to a narrower type without validation, because a malformed URL can produce runtime errors that TypeScript will not catch.

By default, a dynamic route is rendered on demand at request time. If the list of valid values is known at build time, you can pre-render the pages with generateStaticParams. This function returns an array of param objects, and Next.js builds one HTML page for each object during next build.

The function can be async, so it can fetch data from a CMS, database, or API. It runs at build time, not on the server at request time, so it should not depend on user-specific state. The returned array must contain one object per dynamic segment, with keys matching the bracket names in the folder path.

For nested dynamic segments, the returned params must match the full segment list. If the route is app/shop/[category]/[productId]/page.tsx, each object in the array needs both category and productId.

What happens when a request arrives for a path that was not returned by generateStaticParams? That depends on the dynamicParams segment config. By default, dynamicParams = true, which means unknown paths are generated on demand and cached. If you set it to false, unknown paths return a 404.

Use dynamicParams = false when the list of valid paths is closed and you want to avoid accidentally rendering a page for a bad slug. Use the default true when the list is large or changes often and you are willing to let the first request pay the generation cost. For large sites, consider combining generateStaticParams with ISR to revalidate pages incrementally.

SEO metadata for dynamic routes should be derived from the actual content. A product page should have the product name in the title, the product description in the Open Graph snippet, and a canonical URL that matches the request. Next.js supports this through the generateMetadata function, which receives the same params as the page.

Like the page component, generateMetadata must await params in Next.js 16. It can fetch data, but it should reuse the same cached fetch as the page to avoid double database hits. Use fetch with a stable cache key or a shared data function that Next.js can deduplicate.

You can also export a static metadata object when the page does not need dynamic values. Static metadata is merged with the root layout metadata. For dynamic routes, prefer generateMetadata so every URL has its own title and description.

Be careful with special characters in generated metadata. Always escape or encode values used in URLs, titles, and descriptions. The Open Graph image URL above uses encodeURIComponent so that ampersands, slashes, and spaces do not break the query string.

Route groups let you organize routes without affecting the URL. A folder wrapped in parentheses, such as (shop), is ignored when Next.js builds the URL. The file app/(shop)/products/page.tsx renders at /products, not /(shop)/products.

Groups are useful for two things: applying different layouts to different sections of the site, and keeping the file structure readable without changing the public URL. You can have multiple groups in the same app directory, and each group can have its own layout.tsx, error.tsx, and loading.tsx.

Because the group name is not part of the URL, two different groups can expose pages at the same path if you are not careful. Next.js will detect this conflict at build time and report an error. Keep the URL space in mind when placing files inside groups.

Route groups can also be nested. A folder like app/(dashboard)/(analytics)/reports/page.tsx still renders at /reports. The nested groups are only for layout composition and code organization. Do not use them to encode URL hierarchy.

Parallel routes allow multiple pages to render in the same layout simultaneously. They are created with folders prefixed by @, such as @team and @analytics. Each slot is independent and can have its own loading and error states, making them ideal for dashboards and split-pane layouts.

Slots are not part of the URL. The folder app/dashboard/@team/page.tsx does not change the URL from /dashboard. Instead, the parent layout receives each slot as a prop and renders them side by side. The prop name matches the slot folder name without the @ prefix.

The tricky part of parallel routes is navigation. When a user navigates to a sub-page, such as /dashboard/settings, the layout must know what to render in each slot. If a slot does not have a matching page for the new URL, Next.js looks for a default.tsx file in that slot and renders it instead.

Without a default.tsx, an unmatched slot renders nothing, which can leave a blank pane. The default.tsx is the fallback UI for a slot when the current URL does not map to a page in that slot. It is the equivalent of a catch-all placeholder for parallel views.

Catch-all routes match any number of segments after a point. A folder named [...slug] captures everything from that position onward into an array. The file app/docs/[...slug]/page.tsx matches /docs? No. It matches /docs/routing, /docs/routing/dynamic, and any deeper path.

Optional catch-all routes use double brackets: [[...slug]]. The file app/docs/[[...slug]]/page.tsx matches both /docs and /docs/routing. The slug array will be empty when no extra segments are present. This is useful for documentation sites where the root path should also be handled by the same page.

Catch-all routes are often used for documentation, blogs with nested categories, and CMS-driven pages where the content hierarchy is not fixed. The key risk is that a catch-all route can hide more specific routes if placed incorrectly. Next.js resolves routes from most specific to least specific, so a static folder like app/docs/routing/page.tsx wins over app/docs/[...slug]/page.tsx for /docs/routing.

Declarative links with <Link> cover most navigation, but there are times when you need to redirect from code. Server Components and route handlers use redirect and permanentRedirect from next/navigation. Client components use useRouter or the <Link> component.

redirect returns a 307 temporary redirect by default. It is the right choice after a form submission, when the user is not authenticated, or when a resource has moved. permanentRedirect returns a 308 and tells search engines that the old URL is gone forever. Use it for canonical URL migrations and SEO cleanup.

On the client, use useRouter from next/navigation for imperative navigation. It provides push, replace, back, forward, and refresh. The refresh method is useful after a mutation that should invalidate the current route data without a full navigation.

For declarative navigation, the <Link> component prefetches the target page when it enters the viewport, making subsequent navigation feel instant. Use it for menus, lists, and breadcrumbs. For interactions that require JavaScript state, such as a wizard stepper, use useRouter instead.

When multiple routes could match the same URL, Next.js uses a fixed precedence order. Static segments are more specific than dynamic segments, and dynamic segments are more specific than catch-all segments. Route groups are ignored in URL matching, so files inside different groups can collide if they resolve to the same URL.

The order is: static routes, dynamic routes with parameters, catch-all routes, optional catch-all routes. If two routes have the same specificity, the one that is defined earlier in the file-system order wins, but this is rare and usually indicates a design problem. The safest approach is to avoid overlapping route definitions.

A common conflict is a static route that looks like a dynamic one. For example, /blog/new and /blog/[slug] overlap because new is a valid slug string. Place the static route in its own folder, such as app/blog/new/page.tsx, and Next.js will match it before the dynamic route.

Route groups can create hidden conflicts. The files app/(marketing)/about/page.tsx and app/(company)/about/page.tsx both resolve to /about. Next.js will fail the build with a route conflict error. Resolve these by merging the content into a single page or by using different URL paths.