diff --git a/docs/frontend-system/architecture/01-index.md b/docs/frontend-system/architecture/00-index.md
similarity index 100%
rename from docs/frontend-system/architecture/01-index.md
rename to docs/frontend-system/architecture/00-index.md
diff --git a/docs/frontend-system/architecture/02-app.md b/docs/frontend-system/architecture/10-app.md
similarity index 95%
rename from docs/frontend-system/architecture/02-app.md
rename to docs/frontend-system/architecture/10-app.md
index 3b839d4232..532971d124 100644
--- a/docs/frontend-system/architecture/02-app.md
+++ b/docs/frontend-system/architecture/10-app.md
@@ -33,13 +33,13 @@ const rootEl = document.getElementById('root')!;
 ReactDOM.createRoot(rootEl).render(app);
 ```
 
-We call `createApp` to create a new app instance, which is responsible for wiring together all of the features that we provide to the app. It also provides a set of built-in [Extensions](./03-extensions.md) that help build out the foundations of the app, as well as defaults for many other systems such as [Utility API](./06-utility-apis.md) implementations, components, icons, themes, and how to load configuration. No real work is done at the point of creating the app though, it's all deferred to the rendering of the element returned from `app.createRoot()`.
+We call `createApp` to create a new app instance, which is responsible for wiring together all of the features that we provide to the app. It also provides a set of built-in [Extensions](./20-extensions.md) that help build out the foundations of the app, as well as defaults for many other systems such as [Utility API](./33-utility-apis.md) implementations, components, icons, themes, and how to load configuration. No real work is done at the point of creating the app though, it's all deferred to the rendering of the element returned from `app.createRoot()`.
 
-It is possible to explicitly install features when creating the app, although typically these will instead be discovered automatically which we'll explore later on. Nevertheless these features are what build out the actual functionality of the app by providing [Extensions](./03-extensions.md). These extensions are wired together by the app into a tree structure known as the app extension tree. Each node in this tree receives data from its child nodes, and passes along data to its parent. The following diagram illustrates the shape of a small app extension tree.
+It is possible to explicitly install features when creating the app, although typically these will instead be discovered automatically which we'll explore later on. Nevertheless these features are what build out the actual functionality of the app by providing [Extensions](./20-extensions.md). These extensions are wired together by the app into a tree structure known as the app extension tree. Each node in this tree receives data from its child nodes, and passes along data to its parent. The following diagram illustrates the shape of a small app extension tree.
 
 ![frontend system app structure diagram](../../assets/frontend-system/architecture-app.drawio.svg)
 
-Each node in this tree is an extension with a parent node and children. The colored shapes represent extension data inputs and output, where each color is one unique type of data. You can see that there are both extensions that output data that is ignored by the parent, as well as extensions that accept inputs but do not have any children. There are a couple of different tools at your disposal when creating and extension that lets you define different requirements for your inputs and output, which we will cover in greater details in the [Extensions](./03-extensions.md) section.
+Each node in this tree is an extension with a parent node and children. The colored shapes represent extension data inputs and output, where each color is one unique type of data. You can see that there are both extensions that output data that is ignored by the parent, as well as extensions that accept inputs but do not have any children. There are a couple of different tools at your disposal when creating and extension that lets you define different requirements for your inputs and output, which we will cover in greater details in the [Extensions](./20-extensions.md) section.
 
 A common type of data that is shared between extensions is React elements and components. These can in turn be rendered by each other in their own React components, which ends up forming a parallel tree of React components that is similar in shape to that of the app extension tree. At the top of the app extension tree is a built-in root extension that among other things outputs a React element. This element also ends up being the root of the parallel React tree, and is rendered by the React element returned by `app.createRoot()`.
 
diff --git a/docs/frontend-system/architecture/04-plugins.md b/docs/frontend-system/architecture/15-plugins.md
similarity index 100%
rename from docs/frontend-system/architecture/04-plugins.md
rename to docs/frontend-system/architecture/15-plugins.md
diff --git a/docs/frontend-system/architecture/03-extensions.md b/docs/frontend-system/architecture/20-extensions.md
similarity index 99%
rename from docs/frontend-system/architecture/03-extensions.md
rename to docs/frontend-system/architecture/20-extensions.md
index 2f3daba6f8..eec9947c97 100644
--- a/docs/frontend-system/architecture/03-extensions.md
+++ b/docs/frontend-system/architecture/20-extensions.md
@@ -8,7 +8,7 @@ description: Frontend extensions
 
 > **NOTE: The new frontend system is in alpha and is only supported by a small number of plugins.**
 
-As mentioned in the [previous section](./02-app.md), Backstage apps are built up from a tree of extensions. This section will go into more detail about what extensions are, how to create and use them, and how to create your own extensibility patterns.
+As mentioned in the [previous section](./10-app.md), Backstage apps are built up from a tree of extensions. This section will go into more detail about what extensions are, how to create and use them, and how to create your own extensibility patterns.
 
 ## Extension Structure
 
@@ -317,7 +317,7 @@ The `id` of the extension is then build out of `namespace`, `name` & `kind` like
 id: kind:namespace/name
 ```
 
-For more information on naming of extension refer to the [naming patterns documentation](./08-naming-patterns.md).
+For more information on naming of extension refer to the [naming patterns documentation](./50-naming-patterns.md).
 
 ### Extension Creators in libraries
 
diff --git a/docs/frontend-system/architecture/05-extension-overrides.md b/docs/frontend-system/architecture/25-extension-overrides.md
similarity index 99%
rename from docs/frontend-system/architecture/05-extension-overrides.md
rename to docs/frontend-system/architecture/25-extension-overrides.md
index 41702e6823..42a7f365a1 100644
--- a/docs/frontend-system/architecture/05-extension-overrides.md
+++ b/docs/frontend-system/architecture/25-extension-overrides.md
@@ -89,7 +89,7 @@ Note that it can still be a good idea to split your overrides out into separate
 To override an extension that is provided by a plugin, you need to provide a new extension that has the same ID as the existing extension. That is, all kind, namespace, and name options must match the extension you want to replace. This means that you typically need to provide an explicit `namespace` when overriding extensions from a plugin.
 
 :::info
-We recommend that plugin developers share the extension IDs in their plugin documentation, but usually you can infer the ID by following the [naming patterns](./08-naming-patterns.md) documentation.
+We recommend that plugin developers share the extension IDs in their plugin documentation, but usually you can infer the ID by following the [naming patterns](./50-naming-patterns.md) documentation.
 :::
 
 ### Example
diff --git a/docs/frontend-system/architecture/08-references.md b/docs/frontend-system/architecture/30-references.md
similarity index 100%
rename from docs/frontend-system/architecture/08-references.md
rename to docs/frontend-system/architecture/30-references.md
diff --git a/docs/frontend-system/architecture/06-utility-apis.md b/docs/frontend-system/architecture/33-utility-apis.md
similarity index 97%
rename from docs/frontend-system/architecture/06-utility-apis.md
rename to docs/frontend-system/architecture/33-utility-apis.md
index 49e5854b65..c20936f819 100644
--- a/docs/frontend-system/architecture/06-utility-apis.md
+++ b/docs/frontend-system/architecture/33-utility-apis.md
@@ -10,7 +10,7 @@ description: Utility APIs
 
 ## Overview
 
-Utility APIs are pieces of standalone functionality, interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves [extensions](../architecture/03-extensions.md) that can have inputs, be replaced, and be declaratively configured in your app-config.
+Utility APIs are pieces of standalone functionality, interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves [extensions](../architecture/20-extensions.md) that can have inputs, be replaced, and be declaratively configured in your app-config.
 
 A common example of a utility API is a client interface to interact with the backend part of a plugin, such as the catalog client. Any frontend plugin can then request an implementation of that interface to make requests through.
 
diff --git a/docs/frontend-system/architecture/07-routes.md b/docs/frontend-system/architecture/36-routes.md
similarity index 100%
rename from docs/frontend-system/architecture/07-routes.md
rename to docs/frontend-system/architecture/36-routes.md
diff --git a/docs/frontend-system/architecture/08-naming-patterns.md b/docs/frontend-system/architecture/50-naming-patterns.md
similarity index 100%
rename from docs/frontend-system/architecture/08-naming-patterns.md
rename to docs/frontend-system/architecture/50-naming-patterns.md
diff --git a/docs/frontend-system/building-apps/01-index.md b/docs/frontend-system/building-apps/01-index.md
index ea7fe20948..bb09fb6907 100644
--- a/docs/frontend-system/building-apps/01-index.md
+++ b/docs/frontend-system/building-apps/01-index.md
@@ -66,7 +66,7 @@ Linking routes from different plugins requires this configuration. You can do th
 
 ### Enable feature discovery
 
-Use this setting to enable experimental feature discovery when building your app with `@backstage/cli`. With this configuration your application tries to discover and install package extensions automatically, check [here](../architecture/02-app.md#feature-discovery) for more details.
+Use this setting to enable experimental feature discovery when building your app with `@backstage/cli`. With this configuration your application tries to discover and install package extensions automatically, check [here](../architecture/10-app.md#feature-discovery) for more details.
 
 :::warning
 Remember that package extensions that are not auto-discovered must be manually added to the application when creating an app. See [features](#install-features-manually) for more details.
@@ -99,7 +99,7 @@ export default app.createRoot();
 ```
 
 :::info
-You can also pass overrides to the features array, for more details, please read the [extension overrides](../architecture/05-extension-overrides.md) documentation.
+You can also pass overrides to the features array, for more details, please read the [extension overrides](../architecture/25-extension-overrides.md) documentation.
 :::
 
 ### Using an async features loader
diff --git a/docs/frontend-system/building-apps/03-built-in-extensions.md b/docs/frontend-system/building-apps/03-built-in-extensions.md
index a5e6476eb0..5f74100df0 100644
--- a/docs/frontend-system/building-apps/03-built-in-extensions.md
+++ b/docs/frontend-system/building-apps/03-built-in-extensions.md
@@ -24,7 +24,7 @@ Be careful when disabling built-in extensions, as there may be other extensions
 
 ## Override built-in extensions
 
-You can override any built-in extension whenever their customizations, whether through configuration or input, do not meet a use case for your Backstage instance. Check out [this](../architecture/05-extension-overrides.md) documentation on how to override application extensions.
+You can override any built-in extension whenever their customizations, whether through configuration or input, do not meet a use case for your Backstage instance. Check out [this](../architecture/25-extension-overrides.md) documentation on how to override application extensions.
 
 :::warning
 Be aware there could be some implementation requirements to properly override an built-in extension, such as using same apis and do not remove inputs or configurations otherwise you can cause a side effect in other parts of the system that expects same minimal behavior.
diff --git a/docs/frontend-system/building-apps/08-migrating.md b/docs/frontend-system/building-apps/08-migrating.md
index 716e0da772..5d92478661 100644
--- a/docs/frontend-system/building-apps/08-migrating.md
+++ b/docs/frontend-system/building-apps/08-migrating.md
@@ -23,7 +23,7 @@ import { createApp } from '@backstage/frontend-app-api';
 
 This immediate switch will lead to a lot of breakages that we need to fix.
 
-Let's start by addressing the change to `app.createRoot(...)`, which no longer accepts any arguments. This represents a fundamental change that the new frontend system introduces. In the old system the app element tree that you passed to `app.createRoot(...)` was the primary way that you installed and configured plugins and features in your app. In the new system this is instead replaced by extensions that are wired together into an extension tree. Much more responsibility has now been shifted to plugins, for example you no longer have to manually provide the route path for each plugin page, but instead only configure it if you want to override the default. For more information on how the new system works, see the [architecture](../architecture/01-index.md) section.
+Let's start by addressing the change to `app.createRoot(...)`, which no longer accepts any arguments. This represents a fundamental change that the new frontend system introduces. In the old system the app element tree that you passed to `app.createRoot(...)` was the primary way that you installed and configured plugins and features in your app. In the new system this is instead replaced by extensions that are wired together into an extension tree. Much more responsibility has now been shifted to plugins, for example you no longer have to manually provide the route path for each plugin page, but instead only configure it if you want to override the default. For more information on how the new system works, see the [architecture](../architecture/00-index.md) section.
 
 Given that the app element tree is most of what builds up the app, it's likely also going to be the majority of the migration effort. In order to make the migration as smooth as possible we have provided a helper that lets you convert an existing app element tree into plugins that you can install in a new app. This in turn allows for a gradual migration of individual plugins, rather than needing to migrate the entire app structure at once.
 
@@ -95,7 +95,7 @@ At this point the contents of your app should be past the initial migration stag
 
 ## Migrating `createApp` Options
 
-Many of the `createApp` options have been migrated to use extensions instead. Each will have their own [extension creator](../architecture/03-extensions.md#extension-creators) that you use to create a custom extension. To add these standalone extensions to the app they need to be passed to `createExtensionOverrides`, which bundles them into a _feature_ that you can install in the app. See the [standalone extensions](../architecture/05-extension-overrides.md#create-standalone-extensions) section for more information.
+Many of the `createApp` options have been migrated to use extensions instead. Each will have their own [extension creator](../architecture/20-extensions.md#extension-creators) that you use to create a custom extension. To add these standalone extensions to the app they need to be passed to `createExtensionOverrides`, which bundles them into a _feature_ that you can install in the app. See the [standalone extensions](../architecture/25-extension-overrides.md#create-standalone-extensions) section for more information.
 
 For example, assuming you have a `lightTheme` extension that you want to add to your app, you can use the following:
 
@@ -176,7 +176,7 @@ createApp({
 });
 ```
 
-Plugins don't even have to be imported manually after installing their package if [features discovery](../architecture/02-app.md#feature-discovery) is enabled.
+Plugins don't even have to be imported manually after installing their package if [features discovery](../architecture/10-app.md#feature-discovery) is enabled.
 
 ```yaml title="in app-config.yaml"
 app:
@@ -219,7 +219,7 @@ createPlugin({
 
 Many app components are now installed as extensions instead using `createComponentExtension`. See the section on [configuring app components](./01-index.md#configure-your-app) for more information.
 
-The `Router` component is now a built-in extension that you can [override](../architecture/05-extension-overrides.md) using `createRouterExtension`.
+The `Router` component is now a built-in extension that you can [override](../architecture/25-extension-overrides.md) using `createRouterExtension`.
 
 The Sign-in page is now installed as an extension using the `createSignInPageExtension` instead.
 
@@ -341,7 +341,7 @@ const app = createApp({
 
 ### `bindRoutes`
 
-Route bindings can still be done using this option, but you now also have the ability to bind routes using static configuration instead. See the section on [binding routes](../architecture/07-routes.md#binding-external-route-references) for more information.
+Route bindings can still be done using this option, but you now also have the ability to bind routes using static configuration instead. See the section on [binding routes](../architecture/36-routes.md#binding-external-route-references) for more information.
 
 Note that if you are binding routes from a legacy plugin that was converted using `convertLegacyApp`, you will need to use the `convertLegacyRouteRefs` and/or `convertLegacyRouteRef` to convert the routes to be compatible with the new system.
 
@@ -470,7 +470,7 @@ const routes = (
 );
 ```
 
-If you are using [app feature discovery](../architecture/02-app.md#feature-discovery) the installation step is simple, it's already done! The new version of the scaffolder plugin was already discovered and present in the app, it was simply disabled because the plugin created from the legacy route had higher priority. If you do not use feature discovery, you will instead need to manually install the new scaffolder plugin in your app through the `features` option of `createApp`.
+If you are using [app feature discovery](../architecture/10-app.md#feature-discovery) the installation step is simple, it's already done! The new version of the scaffolder plugin was already discovered and present in the app, it was simply disabled because the plugin created from the legacy route had higher priority. If you do not use feature discovery, you will instead need to manually install the new scaffolder plugin in your app through the `features` option of `createApp`.
 
 Continue this process for each of your legacy routes until you have migrated all of them. For any plugin with additional extensions installed as children of the `Route`, refer to the plugin READMEs for more detailed instructions. For the entity pages, refer to the [separate section](#entity-pages).
 
@@ -482,7 +482,7 @@ The entity pages are typically defined in `packages/app/src/components/catalog`
 
 New apps feature a built-in sidebar extension (`app/nav`) that will render all nav item extensions provided by plugins. This is a placeholder implementation and not intended as a long-term solution. In the future we will aim to provide a more flexible sidebar extension that allows for more customization out of the box.
 
-Because the built-in sidebar is quite limited you may want to override the sidebar with your own custom implementation. To do so, use `createExtension` directly and refer to the [original sidebar implementation](https://github.com/backstage/backstage/blob/master/packages/frontend-app-api/src/extensions/AppNav.tsx). The following is an example of how to take your existing sidebar from the `Root` component that you typically find in `packages/app/src/components/Root.tsx`, and use it in an [extension override](../architecture/05-extension-overrides.md):
+Because the built-in sidebar is quite limited you may want to override the sidebar with your own custom implementation. To do so, use `createExtension` directly and refer to the [original sidebar implementation](https://github.com/backstage/backstage/blob/master/packages/frontend-app-api/src/extensions/AppNav.tsx). The following is an example of how to take your existing sidebar from the `Root` component that you typically find in `packages/app/src/components/Root.tsx`, and use it in an [extension override](../architecture/25-extension-overrides.md):
 
 ```tsx
 const nav = createExtension({
diff --git a/docs/frontend-system/building-plugins/01-index.md b/docs/frontend-system/building-plugins/01-index.md
index f8d80f9382..618e660f2b 100644
--- a/docs/frontend-system/building-plugins/01-index.md
+++ b/docs/frontend-system/building-plugins/01-index.md
@@ -8,9 +8,9 @@ description: Building frontend plugins using the new frontend system
 
 > **NOTE: The new frontend system is in alpha and is only supported by a small number of plugins.**
 
-This section covers how to build your own frontend [plugins](../architecture/04-plugins.md) and
-[overrides](../architecture/05-extension-overrides.md). They are sometimes collectively referred to as
-frontend _features_, and what you install to build up a Backstage frontend [app](../architecture/02-app.md).
+This section covers how to build your own frontend [plugins](../architecture/15-plugins.md) and
+[overrides](../architecture/25-extension-overrides.md). They are sometimes collectively referred to as
+frontend _features_, and what you install to build up a Backstage frontend [app](../architecture/10-app.md).
 
 ## Creating a new plugin
 
@@ -43,13 +43,13 @@ export { examplePlugin as default } from './plugin';
 
 Note that we export the plugin as the default export of our package from `src/index.ts`. This is important, as it is how users of our plugin are able to seamlessly install the plugin package in a Backstage app without having to reference the plugin instance through code.
 
-The plugin ID should be a lowercase dash-separated string, while the plugin instance variable should be the camel case version of the ID with a `Plugin` suffix. For more details on naming patterns within the frontend system, see [the article on naming patterns](../architecture/08-naming-patterns.md). By sticking to these naming patterns you ensure that users of your plugin more easily recognize the exports and features provided by your plugin.
+The plugin ID should be a lowercase dash-separated string, while the plugin instance variable should be the camel case version of the ID with a `Plugin` suffix. For more details on naming patterns within the frontend system, see [the article on naming patterns](../architecture/50-naming-patterns.md). By sticking to these naming patterns you ensure that users of your plugin more easily recognize the exports and features provided by your plugin.
 
 ## Adding extensions
 
-The plugin that we created above is empty, and doesn't provide any actual functionality. To add functionality to a plugin you need to create and provide it with one or more [extensions](../architecture/03-extensions.md). Let's continue by adding a standalone page to our plugin, as well as a navigation item that allows users to navigate to the page.
+The plugin that we created above is empty, and doesn't provide any actual functionality. To add functionality to a plugin you need to create and provide it with one or more [extensions](../architecture/20-extensions.md). Let's continue by adding a standalone page to our plugin, as well as a navigation item that allows users to navigate to the page.
 
-To create a new extension you typically use pre-defined [extension creators](../architecture/03-extensions.md#extension-creators), provided either by the framework itself or by other plugins. In this case we'll need to use `createPageExtension` and `createNavItemExtension`, both from `@backstage/frontend-plugin-api`. We will also need to [create a route reference](../architecture/07-routes.md#creating-a-route-reference) to use as a reference for out page, allowing us to dynamically create URLs that link to our page.
+To create a new extension you typically use pre-defined [extension creators](../architecture/20-extensions.md#extension-creators), provided either by the framework itself or by other plugins. In this case we'll need to use `createPageExtension` and `createNavItemExtension`, both from `@backstage/frontend-plugin-api`. We will also need to [create a route reference](../architecture/36-routes.md#creating-a-route-reference) to use as a reference for out page, allowing us to dynamically create URLs that link to our page.
 
 ```tsx title="in src/routes.ts"
 import { createRouteRef } from '@backstage/frontend-plugin-api';
@@ -106,7 +106,7 @@ export const examplePlugin = createPlugin({
 
 What we've built here is a very common type of plugin. It's a top-level tool that provides a single page, along with a method for navigating to that page. The implementation of the page component, in this case the highlighted `ExamplePage`, can be arbitrarily complex. It can be anything from a single simple information page, to a full-blown application with multiple sub-pages.
 
-We have also provided external access to our route reference by passing it to the plugin `routes` option. This makes it possible for app integrators to bind an external link from a different plugin to our plugin page. You can read more about how this works in the [External Route References](../architecture/07-routes.md#external-route-references) section.
+We have also provided external access to our route reference by passing it to the plugin `routes` option. This makes it possible for app integrators to bind an external link from a different plugin to our plugin page. You can read more about how this works in the [External Route References](../architecture/36-routes.md#external-route-references) section.
 
 ## Utility APIs
 
diff --git a/docs/frontend-system/building-plugins/02-testing.md b/docs/frontend-system/building-plugins/02-testing.md
index 26c9503c6d..f665ed0f0c 100644
--- a/docs/frontend-system/building-plugins/02-testing.md
+++ b/docs/frontend-system/building-plugins/02-testing.md
@@ -41,7 +41,7 @@ describe('Entity details component', () => {
 });
 ```
 
-To mock [Utility APIs](../architecture/06-utility-apis.md) that are used by your component you can use the `TestApiProvider` to override individual API implementations. In the snippet below, we wrap the component within a `TestApiProvider` in order to mock the catalog client API:
+To mock [Utility APIs](../architecture/33-utility-apis.md) that are used by your component you can use the `TestApiProvider` to override individual API implementations. In the snippet below, we wrap the component within a `TestApiProvider` in order to mock the catalog client API:
 
 ```tsx
 import React from 'react';
diff --git a/docs/frontend-system/building-plugins/03-extension-types.md b/docs/frontend-system/building-plugins/03-extension-types.md
index 1f3baaa710..c7c2e2ab1f 100644
--- a/docs/frontend-system/building-plugins/03-extension-types.md
+++ b/docs/frontend-system/building-plugins/03-extension-types.md
@@ -8,7 +8,7 @@ description: Extension types provided by the frontend system and core features
 
 > **NOTE: The new frontend system is in alpha and is only supported by a small number of plugins.**
 
-This section covers many of the [extension types](../architecture/03-extensions.md#extension-creators) available at your disposal when building Backstage frontend plugins.
+This section covers many of the [extension types](../architecture/20-extensions.md#extension-creators) available at your disposal when building Backstage frontend plugins.
 
 ## Built-in extension types
 
diff --git a/docs/frontend-system/building-plugins/04-built-in-data-refs.md b/docs/frontend-system/building-plugins/04-built-in-data-refs.md
index dacbbf30f1..d13e734279 100644
--- a/docs/frontend-system/building-plugins/04-built-in-data-refs.md
+++ b/docs/frontend-system/building-plugins/04-built-in-data-refs.md
@@ -8,7 +8,7 @@ description: Configuring or overriding built-in extension data references
 
 > **NOTE: The new frontend system is in alpha and is only supported by a small number of plugins.**
 
-To have a better understanding of extension data references please read [the corresponding architecture section](../architecture/03-extensions.md#extension-data) first.
+To have a better understanding of extension data references please read [the corresponding architecture section](../architecture/20-extensions.md#extension-data) first.
 
 ## Built-in extension data references
 
diff --git a/docs/frontend-system/utility-apis/01-index.md b/docs/frontend-system/utility-apis/01-index.md
index 37120a5152..07f7dcc2a8 100644
--- a/docs/frontend-system/utility-apis/01-index.md
+++ b/docs/frontend-system/utility-apis/01-index.md
@@ -8,7 +8,7 @@ description: Working with Utility APIs in the New Frontend System
 
 > **NOTE: The new frontend system is in alpha and is only supported by a small number of plugins.**
 
-As described [in the architecture section](../architecture/06-utility-apis.md), utility APIs are pieces of shared functionality - interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves [extensions](../architecture/03-extensions.md) that can accept inputs, be declaratively configured in your app-config, or transparently be replaced entirely with custom implementations that fulfill the same contract.
+As described [in the architecture section](../architecture/33-utility-apis.md), utility APIs are pieces of shared functionality - interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves [extensions](../architecture/20-extensions.md) that can accept inputs, be declaratively configured in your app-config, or transparently be replaced entirely with custom implementations that fulfill the same contract.
 
 ## Creating utility APIs
 
diff --git a/docs/frontend-system/utility-apis/02-creating.md b/docs/frontend-system/utility-apis/02-creating.md
index fcb7ff1a65..77caaf55f0 100644
--- a/docs/frontend-system/utility-apis/02-creating.md
+++ b/docs/frontend-system/utility-apis/02-creating.md
@@ -86,7 +86,7 @@ For illustration we make a skeleton implementation class and the API extension a
 
 The code also illustrates how the API factory declares a dependency on another utility API - the core storage API in this case. An instance of that utility API is then provided to the factory function.
 
-The resulting extension ID of the work API will be the kind `api:` followed by the plugin ID as the namespace, in this case ending up as `api:plugin.example.work`. Check out [the naming patterns doc](../architecture/08-naming-patterns.md) for more information on how this works. You can now use this ID to refer to the API in app-config and elsewhere.
+The resulting extension ID of the work API will be the kind `api:` followed by the plugin ID as the namespace, in this case ending up as `api:plugin.example.work`. Check out [the naming patterns doc](../architecture/50-naming-patterns.md) for more information on how this works. You can now use this ID to refer to the API in app-config and elsewhere.
 
 ## Adding configurability
 
diff --git a/docs/frontend-system/utility-apis/04-configuring.md b/docs/frontend-system/utility-apis/04-configuring.md
index 7acf23decf..d22e10011b 100644
--- a/docs/frontend-system/utility-apis/04-configuring.md
+++ b/docs/frontend-system/utility-apis/04-configuring.md
@@ -12,7 +12,7 @@ Utility APIs are extensions and can therefore optionally be amended with configu
 
 ## Configuring
 
-To configure your Utility API extension, first you'll need to know its ID. That ID is formed from the API ref ID; check [the naming patterns docs](../architecture/08-naming-patterns.md) for details.
+To configure your Utility API extension, first you'll need to know its ID. That ID is formed from the API ref ID; check [the naming patterns docs](../architecture/50-naming-patterns.md) for details.
 
 Our example work API from [the creating section](./02-creating.md) would have the ID `api:plugin.example.work`. You configure it and all other extensions under the `app.extensions` section of your app-config.
 
@@ -37,7 +37,7 @@ Well written input-enabled extension often have extension creator functions that
 
 ## Replacing a Utility API implementation
 
-Like with other extension types, you replace Utility APIs with your own custom implementation using [extension overrides](../architecture/05-extension-overrides.md).
+Like with other extension types, you replace Utility APIs with your own custom implementation using [extension overrides](../architecture/25-extension-overrides.md).
 
 ```tsx title="in your app"
 /* highlight-add-start */
diff --git a/docs/plugins/composability.md b/docs/plugins/composability.md
index 1a9c0babf9..a0e0e2d5e6 100644
--- a/docs/plugins/composability.md
+++ b/docs/plugins/composability.md
@@ -329,7 +329,7 @@ You can also use static configuration to bind routes, removing the need to make
 changes to the app code. It does however mean that you won't get type safety
 when binding routes and compile-time validation of the bindings. Static
 configuration of route bindings is done under the `app.routes.bindings` key in
-`app-config.yaml`. It works the same way as [route bindings in the new frontend system](../frontend-system/architecture/07-routes.md#binding-external-route-references),
+`app-config.yaml`. It works the same way as [route bindings in the new frontend system](../frontend-system/architecture/36-routes.md#binding-external-route-references),
 for example:
 
 ```yaml
@@ -342,7 +342,7 @@ app:
 ### Default Targets for External Route References
 
 Following the `1.28` release of Backstage you can now define default targets for
-external route references. They work the same way as [default targets in the new frontend system](../frontend-system/architecture/07-routes.md#default-targets-for-external-route-references),
+external route references. They work the same way as [default targets in the new frontend system](../frontend-system/architecture/36-routes.md#default-targets-for-external-route-references),
 for example:
 
 ```ts
diff --git a/microsite/sidebars.json b/microsite/sidebars.json
index ddccb14c91..be17d76e03 100644
--- a/microsite/sidebars.json
+++ b/microsite/sidebars.json
@@ -452,13 +452,13 @@
         "items": [
           "frontend-system/architecture/index",
           "frontend-system/architecture/app",
-          "frontend-system/architecture/extensions",
           "frontend-system/architecture/plugins",
+          "frontend-system/architecture/extensions",
           "frontend-system/architecture/extension-overrides",
+          "frontend-system/architecture/references",
           "frontend-system/architecture/utility-apis",
           "frontend-system/architecture/routes",
-          "frontend-system/architecture/naming-patterns",
-          "frontend-system/architecture/references"
+          "frontend-system/architecture/naming-patterns"
         ]
       },
       {