File-Based Routing with the App Router

Most frameworks make you register routes in a configuration file. Next.js takes a different approach: the folder structure inside the app directory is the router. Create a folder, drop in a page file, and you have a live URL. This lesson teaches you how folders map to routes, how nesting works, and which special files the App Router recognizes.

Folders Define Routes, Files Define UI

Two rules explain almost everything:

Each folder inside app represents a URL segment.
A route only becomes publicly accessible when the folder contains a page.js (or page.tsx) file.

Here is a small site and the URLs it produces:

text

app/
├── page.js               →  /
├── about/
│   └── page.js           →  /about
├── blog/
│   ├── page.js           →  /blog
│   └── first-post/
│       └── page.js       →  /blog/first-post
└── dashboard/
    └── settings/
        └── page.js       →  /dashboard/settings

Notice that /dashboard itself returns a 404 because the dashboard folder has no page.js - only its settings child does. Folders without a page file are purely organizational.

Your First Custom Route

Create app/about/page.js:

jsx

// app/about/page.js
export default function AboutPage() {
  return (
    <main>
      <h1>About Us</h1>
      <p>We teach practical web development at CodeYourCraft.</p>
    </main>
  );
}

Save the file and visit http://localhost:3000/about. No route registration, no config edits. The default export of page.js is the component rendered for that URL.

Special Files the Router Understands

Inside any route folder, certain file names have reserved meanings:

page.js - the unique UI for this route; makes the route public.
layout.js - shared UI that wraps this segment and all of its children.
loading.js - an instant loading state shown while the segment loads.
error.js - an error boundary that catches errors in this segment.
not-found.js - UI for 404s triggered within this segment.
route.js - an API endpoint instead of a page (covered in Lesson 9).

You will meet layouts in the next lesson and route handlers later; for now, remember that these names are reserved and everything else (components, utils, styles) can live alongside them safely.

Colocation: Keep Related Code Together

Because only special files affect routing, you can keep a component right next to the page that uses it:

text

app/blog/
├── page.js
├── PostCard.js      ← not a route, just a component
└── posts.data.js    ← not a route, just data

PostCard.js is never served as a URL. This colocation keeps features self-contained instead of scattering files across a giant components folder.

Route Groups: Organize Without Affecting URLs

Sometimes you want to group folders without adding a URL segment. Wrap the folder name in parentheses:

text

app/
├── (marketing)/
│   ├── about/page.js     →  /about
│   └── pricing/page.js   →  /pricing
└── (shop)/
    └── cart/page.js      →  /cart

The (marketing) and (shop) folders vanish from the URL. Route groups are perfect for giving different sections of a site different layouts, which we explore next lesson.

Private Folders

Prefix a folder with an underscore, like _components, and the router ignores it and everything inside it. This is a convention for utility folders you never want routed.

Key Takeaways

Folders in app map directly to URL segments; page.js makes a segment public.
Reserved file names (page, layout, loading, error, route) give each segment superpowers.
Non-reserved files can be colocated freely inside route folders.
Route groups (name) organize code without changing URLs; _folders are ignored entirely.

Next up: Lesson 4 covers pages, layouts, and templates - how shared UI persists across navigation.