Disable multisite and locale middlewares

The Next.js App Router template uses a file-based routing system where routes are defined by folder structure at build time. It uses the following structure:

[site] - dynamic site segment required by the multisite middleware.
[locale] - dynamic locale segment required by the locale middleware.
[[...path]] - catch-all path segment for page routes.

If you set multisite.enabled to false or remove the locale middleware without restructuring your routes, you'll encounter 404 errors for all regular page requests and type errors in components expecting site or locale as parameters. Preview/Editing modes may work as they bypass some middleware checks but it's not guaranteed.

This happens because routes in Next.js App Router are hardcoded at build time. The folder structure [site]/[locale]/[[...path]] creates a contract that expects components to have site and locale as parameters. The middleware rewrites paths to include these segments. Removing the middleware breaks this contract.

The following sections describe how you can disable the multisite middleware, the locale middleware, and using a single-site/single-locale setup.

Important

To disable middlewares, you must make significant architectural changes to your route structure and components.

Disable multisite middleware

To disable the multisite middleware:

Restructure your route folders so that all files inside src/app/[site]/[locale]/ are inside src/app/[locale]/ (or src/app/ if removing locale also). You must also delete the empty [site] folder and update any nested routes accordingly.

For all page components in src/app/**/page.tsx:

Remove site: string from params
Remove site from the params destructuring
Remove any references to site

For the following initial file:

RequestResponse

type PageProps = {
  params: Promise<{ site: string; locale: string; path?: string[] }>;
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
};

export default async function Page({ params, searchParams }: PageProps) {
  const { site, locale, path } = await params;
  // Use site, locale, path
}

The changes would be as follows:

RequestResponse

type PageProps = {
  params: Promise<{ locale: string; path?: string[] }>;
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
};

export default async function Page({ params, searchParams }: PageProps) {
  const { locale, path } = await params;
  // Use locale, path (site removed)
}

For all components in src/app/**/layout.tsx:
- Remove site: string from params
- Remove any references to site
Remove the site parameter from all Sitecore client calls.

For example, in the following getPage call:
RequestResponse
```
// Find the following:
page = await client.getPage(path ?? [], { site, locale });

// Remove site
page = await client.getPage(path ?? [], { locale });
```
Note

If you require the site parameter, you can use the defaultSite parameter from sitecore.config.ts.

Update middleware configuration using one of the following options:

Remove multisite middleware from src/middleware.ts:

RequestResponse

export function middleware(req: NextRequest, ev: NextFetchEvent) {
  return defineMiddleware(locale, redirects, personalize).exec(req, ev);
  // multisite removed
}

Disable multisite middleware in sitecore.config.ts:

RequestResponse

export default defineConfig({
  multisite: {
    enabled: false, // Ensure you've completed the above steps
  },
  // ...
});

Update the site configuration so that it doesn't reference the site segment. Update route handlers if they expect the site in the path, update API routes and verify component mappings.

Update i18n configuration by changing the locale resolution as shown:

RequestResponse

// Find the following:
setRequestLocale(`${site}_${locale}`);

//Replace it with:
setRequestLocale(locale);

Disable locale middleware

To disable the locale middleware:

Restructure your locale folders so that all files inside src/app/[site]/[locale]/[[...path]]/ are inside src/app/[site]/[[...path]]/ (or src/app/[[...path]]/ if removing both).

For all page components, remove locale from the params destructuring as shown:

RequestResponse

// Find the following:
const { site, locale, path } = await params;

// Remove locale
const { site, path } = await params;

Remove the locale parameter from all Sitecore client calls.

For example, in the following getPage call:

RequestResponse

// Find the Sitecore client call
page = await client.getPage(path ?? [], { site, locale });

// Remove locale
page = await client.getPage(path ?? [], { site });

Remove locale middleware from src/middleware.ts:

RequestResponse

export function middleware(req: NextRequest, ev: NextFetchEvent) {
  return defineMiddleware(multisite, redirects, personalize).exec(req, ev);
  // locale removed
}

Update src/i18n/routing.ts to use a single locale or remove locale-based routing entirely.

Use a single-site/single-locale setup

Instead of disabling middlewares, you can configure them for a single-site or single-locale. This is the recommended approach.

To use a single-site:

Keep multisite.enabled: true in sitecore.config.ts.
Configure only one site in .sitecore/sites.json:
RequestResponse
```
[
  {
    "name": "my-site",
    "hostName": "*",
    "language": "en"
  }
]
```
The middleware always resolves to this site without breaking the route structure.

To use a single locale:

Keep locale middleware in src/middleware.ts.

Configure only one locale in src/i18n/routing.ts:

RequestResponse

export const routing: RoutingConfig = {
  locales: ['en'],
  defaultLocale: 'en',
};

Troubleshooting

This section outlines some common errors that you may encounter after disabling middlewares and how to mitigate them.

404 errors after disabling middlewares - This is because the route structure still expects the segment you removed. Make sure you've restructured all the folders after removing the middlewares.
Type errors in components - This happens when components have references to site or locale in their params. Ensure you've removed all references to site/locale.
Broken Preview/Editing modes - Preview modes may rely on site/locale segments. Double-check your editing route handlers and ensure they handle the new route structure.

Do you have some feedback for us?

If you have suggestions for improving this article,