Next.js Route Groups
Not every folder in your app directory needs to correspond to a URL segment. As a project grows, you'll often want to organize routes by team, feature, or concern — grouping a marketing site's pages together, or separating an admin section from customer-facing routes — without those organizational choices leaking into the actual URLs your users see. Route Groups solve exactly that: a folder-naming convention that lets you structure your codebase however makes sense for your team, while keeping the resulting URLs exactly as flat and clean as if the grouping folders didn't exist.
The Convention
Wrap a folder's name in parentheses — (folderName) — to create a route group. Next.js recognizes that syntax as purely organizational and excludes it entirely from the resulting URL path.
That's the entire mechanical convention. A folder named (marketing) containing about/page.js produces the URL /about, not /marketing/about — the parenthesized name never appears anywhere in the address bar.
What Route Groups Are Actually For
The docs list three concrete use cases, and they map to genuinely different motivations:
Organizing routes by team, concern, or feature. A large app might have (marketing), (shop), and (admin) route groups, each owned by a different part of the org, without any of that internal structure being visible to end users or affecting how routes resolve.
Defining multiple root layouts. This is the use case with real architectural weight — route groups are the standard mechanism for giving different sections of your app entirely separate root layouts (their own <html>, their own global providers), something you genuinely cannot do with a single shared root layout at the top of app.
Opting specific segments into sharing a layout while keeping others out. You can nest a layout inside a route group so it applies only to the routes within that group, letting you scope shared UI more precisely than "everything under this literal folder path" would otherwise allow.
Caveat: Full Page Loads Between Root Layouts
If you use route groups to define multiple root layouts and a user navigates between routes that live under different root layouts — say, from /cart (under app/(shop)/layout.js) to /blog (under app/(marketing)/layout.js) — that navigation triggers a full page reload, not a client-side transition.
This is a deliberate consequence, not a bug: Next.js can't preserve client-side state across a boundary where the entire document structure might legitimately differ between two independent root layouts, so it correctly falls back to a hard navigation rather than attempting to reconcile two potentially incompatible document trees. This caveat only applies when you actually have multiple root layouts — ordinary route groups sharing the same root layout don't trigger this behavior at all.
Caveat: Conflicting Paths
Because route group names are invisible in the URL, it's entirely possible to accidentally define two routes that resolve to the identical path without either file structurally overlapping on disk. app/(marketing)/about/page.js and app/(shop)/about/page.js both resolve to /about — and Next.js will raise an error rather than silently picking one, since there's no principled way to decide which "about" page should win.
This is worth watching for specifically in larger teams where different groups might independently create a route with the same name, unaware that another team's route group already claims that exact URL.
Caveat: The Home Route Needs a Group Too
If you're using multiple root layouts and deliberately have no top-level layout.js file directly in app (letting each route group's own layout serve as its respective root layout), make sure your home route (/) actually lives inside one of those groups — for instance, app/(marketing)/page.js — rather than sitting directly in app/page.js with no layout at all to wrap it. Without a group claiming the root path, there's no root layout available to render it.
Key Takeaways
| Aspect | Detail |
|---|---|
| Convention | (folderName) — parentheses mark a folder as organizational only |
| URL effect | None — the folder name never appears in the resulting path |
| Primary uses | Team/feature organization, multiple root layouts, scoped layout sharing |
| Navigating between root layouts | Triggers a full page reload — expected behavior, not a bug |
| Path conflicts | Different groups resolving to the same URL is a build error, not a silent override |
| Home route requirement | If using multiple root layouts with no top-level layout, / must live inside one of the groups |
Route Groups are one of the lowest-risk organizational tools in the App Router's convention vocabulary — they cost you nothing in terms of URL structure, and the only behaviors to actually watch for are the full-reload-between-root-layouts caveat and the silent-conflict risk when two groups happen to define the same path. Used well, they let your file structure mirror how your team actually thinks about the app, independent of how clean you want the resulting URLs to be.
