Building an Admin Dashboard With the Next.js App Router
How to use the App Router without turning the entire back office into one client-side component.
Published 2026-09-05 · Updated 2026-09-05 · 8 minute read
Use route groups to separate authenticated and public layouts, server components for data and static structure, and client components only for interactive state. Define loading, error and not-found behaviour at meaningful route boundaries.
Design Route Groups Around Shells
Keep marketing, authentication and application routes under layouts that reflect their actual chrome. Parentheses organize the source without changing public URLs.
Choose the Client Boundary Deliberately
Tables, menus and forms may require client behaviour; headings, descriptions and static page structure usually do not. Move the boundary down to the smallest component that needs browser state.
Make Route States Part of the Product
Use loading, error and not-found boundaries that preserve navigation and explain recovery. A blank suspense fallback or generic exception page is not enough for operational software.
Keep Public and Private SEO Separate
Public product pages need canonical metadata and crawlable text. Authenticated application routes and login pages generally need noindex directives and should never leak private data into metadata.
Questions
Should an admin dashboard be fully server-rendered?
No. Render data and structure on the server where useful, then add focused client islands for interaction.
Should private admin pages appear in the sitemap?
No. Sitemaps should contain canonical public URLs intended for discovery, not authenticated application routes.
Can the same components work in Vite and Next.js?
Yes when framework-specific routing, metadata and server behaviour remain outside the visual component package.