diff --git a/15/umbraco-cms/customizing/development-flow/vite-package-setup.md b/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
index fe067e8c629..17de26a7554 100644
--- a/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
+++ b/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
@@ -185,7 +185,7 @@ export default class MyElement extends LitElement {
 ```
 {% endhint %}
 
-Learn more about the abilities of the manifest file in the [Umbraco Package Manifest](../../customize-the-backoffice/umbraco-package.md) article.
+Learn more about the abilities of the manifest file in the [Umbraco Package Manifest](../umbraco-package.md) article.
 
 #### Testing your package
 
diff --git a/15/umbraco-cms/customizing/extending-overview/extension-registry/extension-manifest.md b/15/umbraco-cms/customizing/extending-overview/extension-registry/extension-manifest.md
index 16c1c9371a3..e81a7155da6 100644
--- a/15/umbraco-cms/customizing/extending-overview/extension-registry/extension-manifest.md
+++ b/15/umbraco-cms/customizing/extending-overview/extension-registry/extension-manifest.md
@@ -53,11 +53,11 @@ Many of the Extension Types require additional information declared as part of a
 
 An Extension Manifest can be declared in multiple ways.
 
-The primary way is to declare it as part of the [Umbraco Package Manifest](../../../customize-the-backoffice/umbraco-package.md).
+The primary way is to declare it as part of the [Umbraco Package Manifest](../../umbraco-package.md).
 
 Additionally, two Extension types can be used to register other extensions.
 
-A typical use case is to declare one main Extension Manifest as part of the [Umbraco Package Manifest](../../../customize-the-backoffice/umbraco-package.md). Such main Extension Manifest would be using one of the following types:
+A typical use case is to declare one main Extension Manifest as part of the [Umbraco Package Manifest](../../umbraco-package.md). Such main Extension Manifest would be using one of the following types:
 
 ### The `bundle` extension type
 
diff --git a/15/umbraco-cms/customizing/foundation/contexts/README.md b/15/umbraco-cms/customizing/foundation/contexts/README.md
index fb3d82f8307..b9e7ce16f9a 100644
--- a/15/umbraco-cms/customizing/foundation/contexts/README.md
+++ b/15/umbraco-cms/customizing/foundation/contexts/README.md
@@ -10,6 +10,6 @@ This page is a work in progress and may undergo further revisions, updates, or a
 
 Below you can find some articles on how you can work with different contexts:
 
-## [Property Dataset Context](../../../customize-the-backoffice/foundation/contexts/property-dataset-context.md)
+## [Property Dataset Context](./property-dataset-context.md)
 
 A Dataset Context is the connection point between a Property Editor and a Workspace and covers a set of properties.
diff --git a/15/umbraco-cms/customizing/foundation/routes.md b/15/umbraco-cms/customizing/foundation/routes.md
index eff579be84e..8dd3d3f0340 100644
--- a/15/umbraco-cms/customizing/foundation/routes.md
+++ b/15/umbraco-cms/customizing/foundation/routes.md
@@ -12,14 +12,14 @@ This page is a work in progress and may undergo further revisions, updates, or a
 
 The routing in the backoffice is flexible and customizable. In this article, you can find a couple of starting points for routing.
 
-The overall **divider** is the [Section](../../customize-the-backoffice/extending-overview/extension-types/section.md) which is a `ManifestSection` extension type. It is also used internally by the following sections: Content, Media, Settings, Members, and so on.
+The overall **divider** is the [Section](../extending-overview/extension-types/sections/README.md) which is a `ManifestSection` extension type. It is also used internally by the following sections: Content, Media, Settings, Members, and so on.
 
 Depending on which section you are working on, there are different options:
 
-* **SectionView**: The [Section View](../../customize-the-backoffice/extending-overview/extension-types/section-view.md) is a view in a section and one of the automatic router extension types. It can be an entry point to a section. If a section has multiple views defined (or both dashboards and views) then the tabs and icons will be rendered. As some examples, you can check the **Packages** and **Member** sections.
-* **Dashboard**: The [Dashboard](../../customize-the-backoffice/extending-overview/extension-types/dashboard.md) is an entry point to a section. If there is more than one section view or dashboard then the defined tabs and icons will be rendered to make it possible to navigate.
-* **Workspace**: The [Workspace](../../customize-the-backoffice/workspaces.md) concept has built-in features to facilitate editing of an entity of a certain entity type. It is used by many entities in the backoffice like content, media, content types, data types, dictionaries and so on.
-* **Custom element**: A [Custom Element](umbraco-element/) is a section that can be configured to use any web component as the **entry point**. The `element()` can be configured in the manifest. By doing this we'll disable the possibility of using dashboards and section views for the section since they will not be automatically routed/rendered. This option should be used only when necessary.
+* **SectionView**: The [Section View](../extending-overview/extension-types/sections/section-view.md) is a view in a section and one of the automatic router extension types. It can be an entry point to a section. If a section has multiple views defined (or both dashboards and views) then the tabs and icons will be rendered. As some examples, you can check the **Packages** and **Member** sections.
+* **Dashboard**: The [Dashboard](../extending-overview/extension-types/dashboard.md) is an entry point to a section. If there is more than one section view or dashboard then the defined tabs and icons will be rendered to make it possible to navigate.
+* **Workspace**: The [Workspace](../../customizing/workspaces.md) concept has built-in features to facilitate editing of an entity of a certain entity type. It is used by many entities in the backoffice like content, media, content types, data types, dictionaries and so on.
+* **Custom element**: A [Custom Element](umbraco-element/README.md) is a section that can be configured to use any web component as the **entry point**. The `element()` can be configured in the manifest. By doing this we'll disable the possibility of using dashboards and section views for the section since they will not be automatically routed/rendered. This option should be used only when necessary.
 
 ### Building routing
 
@@ -60,7 +60,7 @@ The order in which the routes are defined is important as the first match will b
 In the render method of the element, render the `umb-router-slot`:
 
 ```html
-<umb-router-slot .routes=${this._routes}></umb-router-slot> 
+<umb-router-slot .routes=${this._routes}></umb-router-slot>
 ```
 
 One can create links to allow navigation to a given route:
diff --git a/15/umbraco-cms/customizing/foundation/working-with-data/context-api.md b/15/umbraco-cms/customizing/foundation/working-with-data/context-api.md
index 49328c0cb35..c0a5f0d1110 100644
--- a/15/umbraco-cms/customizing/foundation/working-with-data/context-api.md
+++ b/15/umbraco-cms/customizing/foundation/working-with-data/context-api.md
@@ -129,7 +129,7 @@ The consumption of the Additional API will never happen as the token uses the sa
 This is only relevant if you are going to make multiple context API for the same context. Discriminator only gives value for consumption of Context APIs that have a varying interface. The backoffice uses this for the different types of Workspace Contexts.
 {% endhint %}
 
-In some cases, it is needed to have different APIs for the same context. For example, the [Workspace Contexts](../../../customize-the-backoffice/extending-overview/extension-types/workspace-context.md).
+In some cases, it is needed to have different APIs for the same context. For example, the [Workspace Contexts](../../../customizing/extending-overview/extension-types/workspace-context.md).
 
 If someone wants the workspace name, they might not care about the specific API of the Workspace Context. These implementations can use a standard Context Token with a type of generic Workspace Context.
 
diff --git a/15/umbraco-cms/customizing/property-editors/README.md b/15/umbraco-cms/customizing/property-editors/README.md
index 224012211e8..333a7214232 100644
--- a/15/umbraco-cms/customizing/property-editors/README.md
+++ b/15/umbraco-cms/customizing/property-editors/README.md
@@ -18,7 +18,7 @@ This section describes how to work with and create Property Editors. A property
 
 A property editor is an editor used to insert content into Umbraco. A Property Editor is composed of two extensions: Property Editor Schema and Property Editor UI.
 
-## [Package Manifest](../../customize-the-backoffice/umbraco-package.md)
+## [Package Manifest](../umbraco-package.md)
 
 Reference for the package.manifest JSON file format to register one or more property editors for Umbraco.
 
diff --git a/15/umbraco-cms/customizing/property-editors/build-a-block-editor.md b/15/umbraco-cms/customizing/property-editors/build-a-block-editor.md
index a8cf8943b3d..8a8133dd14f 100644
--- a/15/umbraco-cms/customizing/property-editors/build-a-block-editor.md
+++ b/15/umbraco-cms/customizing/property-editors/build-a-block-editor.md
@@ -57,7 +57,7 @@ public class UnicornBlocksConfigurationEditor : ConfigurationEditor<BlockListCon
 {% hint style="info" %}
 It is not strictly necessary to define your own property editor in C#. As outlined in the [Composition](composition/) article, all Umbraco core property editors can be reused.
 
-The code sample above inherits all functionality from Block List and adds no new functionality. If this is sufficient, you can use the Block List property editor alias `"Umbraco.BlockList"` as Property Editor Schema in your [package manifest](../../customize-the-backoffice/umbraco-package.md).
+The code sample above inherits all functionality from Block List and adds no new functionality. If this is sufficient, you can use the Block List property editor alias `"Umbraco.BlockList"` as Property Editor Schema in your [package manifest](../umbraco-package.md).
 
 It is, however, recommended to declare your own Block Editors in C#. As you will see in the following, the property editor alias (`"MyOwn.UnicornBlocksEditor"`) will be part of the data structure. For any eventual future extensibility, it is good to have the correct alias in the content structure from the beginning.
 {% endhint %}