Organizing Routes with Laravel Route Groups

In a Laravel application, each route tells Laravel which code handles an incoming HTTP request, such as GET /users. A route group puts related route declarations together so they can share settings. Declare each shared path segment, middleware, or route-name prefix once instead of repeating it on every route.

A URI prefix changes the paths Laravel matches. Middleware adds request-handling behavior, such as checking whether a user is authenticated. A name prefix changes the identifiers Laravel uses to refer to routes; it does not change their URLs. Knowing which group setting does which job makes it easier to organize routes and work out the effective path, name, and middleware for each declaration.

Put shared route settings around related routes

A group applies its settings to each route declared inside it. For an administration area, you might give all routes the admin URI prefix, require authentication, and start each route name with admin.:

use App\Http\Controllers\Admin\UserController;
use Illuminate\Support\Facades\Route;

Route::prefix('admin')
    ->middleware(['auth'])
    ->name('admin.')
    ->group(function () {
        Route::get('/users', [UserController::class, 'index'])
            ->name('users.index');

        Route::get('/users/{user}', [UserController::class, 'show'])
            ->name('users.show');
    });

Here, prefix('admin') adds admin to each route’s path. The auth middleware applies to both routes. Middleware is code that runs while Laravel handles a request; Laravel’s auth middleware checks that the requester is authenticated. The project’s authentication setup determines how that check works.

The name('admin.') call adds the supplied text to each route name. The route named users.index inside the group becomes admin.users.index. The period is part of the prefix, so include it when you want a separator between the group prefix and local name.

The Laravel routing documentation describes groups as a way to share route attributes. This avoids repeating the same settings and puts them next to the routes they affect. A group alone does not control access. Configure its middleware and authorization checks to enforce the intended access rules.

Read from the outside of the group inward

To determine what a route does, first read the settings before group(...), then combine them with the route’s own declaration. In the example, the route declares GET /users. The group adds /admin to its URI, so the resulting path is /admin/users. The route name users.index gets the admin. prefix, producing admin.users.index. The group’s auth middleware also applies to the request.

The same rule gives the second route the path /admin/users/{user} and the name admin.users.show. The {user} segment is a route parameter: it marks a value in the URL that Laravel passes to the route handler.

Nested groups work the same way. Laravel combines a nested group’s settings with those of its parent: URI prefixes and name prefixes are appended, while middleware settings are merged. When reading a nested declaration, follow the outer group first, then add each inner group’s settings before reading the route itself.

Track each setting separately: the URI prefix changes the path, the name prefix changes the route’s identifier, and middleware changes how Laravel handles the request. Laravel 13.x documents php artisan route:list as a way to view registered routes. The -v option shows middleware information, and -vv expands middleware groups. Those options help confirm the result when a route file contains nested groups or several shared settings. See the route listing options.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com