diff --git a/docs/concepts/01_what_is_kilt.md b/docs/concepts/01_what_is_kilt.md
index 401a4c289..735059fbc 100644
--- a/docs/concepts/01_what_is_kilt.md
+++ b/docs/concepts/01_what_is_kilt.md
@@ -7,10 +7,10 @@ KILT is a protocol for self-sovereign data and interoperability built on top of
 
 The core component of KILT is a digital identity protocol for:
 
-1. Generating and managing [**decentralized identifiers (DIDs)**](./10_glossary.md#Decentralized-Identifiers-(DID))
-2. Issuing and presenting digital [**verifiable credentials (VCs)**](./10_glossary.md#verifiable-credentials).
+1. Generating and managing [**decentralized identifiers (DIDs)**](./10_glossary.md)
+2. Issuing and presenting digital [**verifiable credentials (VCs)**](./10_glossary.md).
 
-In contrast to other centralized alternatives, KILT features self-sovereign data and revocable [credentials](./10_glossary.md#credential) anchored to the KILT blockchain.
+In contrast to other centralized alternatives, KILT features self-sovereign data and revocable [credentials](./10_glossary.md) anchored to the KILT blockchain.
 
 KILT was built to be a business enabler, not only for the software industry but also for any entity.
 Such entities can establish a business model based on the trust infrastructure KILT provides, which is an essential building block of Web 3.0.
@@ -19,9 +19,9 @@ Such entities can establish a business model based on the trust infrastructure K
 
 In particular, KILT provides:
 
-* A **universal identity protocol** for individuals, organizations, objects, and intelligent agents to obtain credentials for arbitrary attributes about themselves issued by trusted [Attesters](./10_glossary.md#attester).
+* A **universal identity protocol** for individuals, organizations, objects, and intelligent agents to obtain credentials for arbitrary attributes about themselves issued by trusted [Attesters](./10_glossary.md).
 * A **self-sovereign mechanism** for putting credential holders in control of their own data, allowing them to choose if and where they make their credentials public and how much information from those credentials they wish to share.
-* A **[Trust Market](./10_glossary.md#trust-market) for [Attesters](./10_glossary.md#attester)** of such credentials, allowing widely trusted entities to be compensated for their valuable attestation work.
+* A **[Trust Market](./10_glossary.md) for [Attesters](./10_glossary.md)** of such credentials, allowing widely trusted entities to be compensated for their valuable attestation work.
 
 KILT's main goal is to generate a level playing field for companies to explore new business models related to trust relationships and data sovereignty.
 KILT enables businesses and governments to rely on a common standard owned by everyone participating and not by a single company or set thereof.
@@ -56,13 +56,13 @@ KILT Protocol aims to change that and give users back control over their data.
 
 ## The solution
 
-KILT provides a protocol and the tools for people to manage their own data, and to build a [digital identity](./10_glossary.md#digital-identity) by collecting credentials issued by trusted entities.
+KILT provides a protocol and the tools for people to manage their own data, and to build a [digital identity](./10_glossary.md) by collecting credentials issued by trusted entities.
 Such credentials aren't publicly available but stay within the user's control.
 This is similar to the approach used for centuries before big corporations monetized our data.
 
 The core ideas are:
 
 * Managing user identities in the form of [decentralized identifiers (DIDs)](https://w3c-ccg.github.io/did-spec/), with the support of the KILT blockchain
-* Obtaining digital [verifiable credentials](./10_glossary.md#verifiable-credentials) for user-specified claims
+* Obtaining digital [verifiable credentials](./10_glossary.md) for user-specified claims
 * Supporting revocation of verifiable credentials by their Attesters
 * Presenting and verifying verifiable credentials in a privacy-preserving and user-controlled way
diff --git a/docs/concepts/07_dip/05_dapp_developer.md b/docs/concepts/07_dip/05_dapp_developer.md
index 7409dc288..0083e33f7 100644
--- a/docs/concepts/07_dip/05_dapp_developer.md
+++ b/docs/concepts/07_dip/05_dapp_developer.md
@@ -51,7 +51,7 @@ For example, `did:kilt:4q4QzFTs9hKh4QizLB3B7zuGYCG3QPamiBFEgwM6gTM7gK3g`
 Currently only supports version 1.
 -   `blockNumber`: The block number of the relay chain to use for the generation of the DIP proof.
 If not provided, uses the last finalized block.
--   `linkedAccounts`: An array of [account addresses linked to the DID](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md##linking-an-account-to-a-did) to reveal in the generated proof.
+-   `linkedAccounts`: An array of [account addresses linked to the DID](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did) to reveal in the generated proof.
 -   `web3Name`: Whether to reveal [the web3name of the DID subject](../../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) in the generated proof.
 
 In the example code, the configuration also has extra parameters for the time-bound DID signature extension [mentioned below](#creating-extensions-for-specific-proofs).
@@ -108,7 +108,7 @@ await signAndSubmitTx(consumerApi, dipSubmittable, submitterKeypair)
 Linked accounts let you specify which accounts you want to prove that you control when you make the cross-chain proof.
 As part of the proof provided, you can also include other values, such as the web3name.
 
-For all the accounts you want to link, use the `associateAccountToChainArgs` method, [as detailed in this guide](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md##linking-an-account-to-a-did).
+For all the accounts you want to link, use the `associateAccountToChainArgs` method, [as detailed in this guide](../../develop/01_sdk/02_cookbook/03_account_linking/01_link.md#linking-an-account-to-a-did).
 
 You can then batch all the linked account transactions and authorize them using the `authorizeTx` method.
 
diff --git a/docs/develop/01_sdk/02_cookbook/05_public_credentials/02_credential_retrieval.md b/docs/develop/01_sdk/02_cookbook/05_public_credentials/02_credential_retrieval.md
index b2514585a..925becd7f 100644
--- a/docs/develop/01_sdk/02_cookbook/05_public_credentials/02_credential_retrieval.md
+++ b/docs/develop/01_sdk/02_cookbook/05_public_credentials/02_credential_retrieval.md
@@ -52,7 +52,7 @@ Verifying a public credential is shown in the following snippet:
 What the `verifyCredential` function does internally is the following:
 
 1. Derive the credential identifier from the provided content and attester information.
-2. Fetch the actual credential from the blockchain, as shown in the [section above](#retrieve-a-credential-by-id), failing if the credential does not exist.
+2. Fetch the actual credential from the blockchain, as shown in the [section above](#retrieve-a-credential-by-its-identifier), failing if the credential does not exist.
 3. [OPTIONAL] Verify that the credential structure matches what the optionally-provided CType defines.
 4. Verify that the rest of the fields in the provided credential (i.e., revocation status, identifier, creation block number) match the retrieved credential.
 
@@ -65,4 +65,4 @@ Rather, the block number in which the extrinsic is submitted is stored inside th
 This represents a very good tradeoff between **security** - because the blockchain itself dictates what the creation block number is for any given public credential - and **storage efficiency** - since the full credential is stored off-chain, accessible via any KILT archive node or indexing service.
 :::
 
-[asset-did-concept]: ../../../../concepts/04_asset_dids.md
\ No newline at end of file
+[asset-did-concept]: ../../../../concepts/04_asset_dids.md
diff --git a/docs/develop/01_sdk/03_chain_setup/index.md b/docs/develop/01_sdk/03_chain_setup/index.md
index 84c89539e..76cb5d16e 100644
--- a/docs/develop/01_sdk/03_chain_setup/index.md
+++ b/docs/develop/01_sdk/03_chain_setup/index.md
@@ -13,7 +13,7 @@ This gives developers like you the chance to test your software with any new fea
 Nevertheless, there are a scenarios where a public network (that everyone else is also using) is not ideal.
 For instance, if you need more funds than the faucet can provide, or if you need to reset the state of the blockchain at any time, you will need to setup your own little KILT blockchain.
 
-In this section, we will guide you through the process of 
+In this section, we will guide you through the process of
 1. [Running your own KILT blockchain](./01_standalone_setup.md)
 2. [Connecting to the Peregrine test network](./02_peregrine_setup.md)
 3. [Connecting to the Spiritnet production network](./03_prod_chain_setup.md)
@@ -21,4 +21,4 @@ In this section, we will guide you through the process of
 ## Set up your Project
 
 We expect you to already have a small project which can connect and potentially interact with a KILT blockchain given the WebSocket address of a KILT node.
-If that is not the case, please take a look at our [Quickstart section](../01_quickstart.md#connecting-to-kilt-blockchain) which will provide you with all necessary means to create and run a basic script.
+If that is not the case, please take a look at our [Quickstart section](../01_quickstart.md) which will provide you with all necessary means to create and run a basic script.
diff --git a/docs/participate/01_staking/03_delegate/02_become.md b/docs/participate/01_staking/03_delegate/02_become.md
index 5e5b34f91..4fbd67484 100644
--- a/docs/participate/01_staking/03_delegate/02_become.md
+++ b/docs/participate/01_staking/03_delegate/02_become.md
@@ -69,7 +69,7 @@ If the delegation pool of your chosen collator candidate is full, you may still
 When that happens,
 
 - The kicked delegator will be replaced by the delegator with a higher delegation (you) immediately
-- The kicked delegator's stake is prepared for unstaking as if they revoked the delegation (*see [revoking](#Revoking)*)
+- The kicked delegator's stake is prepared for unstaking as if they revoked the delegation
 - A delegator needs to wait 7 days (in block time) to be able to unlock the stake.
 Please note that it can take longer in real time as the block times assumes a constant block time of 12s, which is not guaranteed.
 
diff --git a/docusaurus.config.js b/docusaurus.config.js
index ca1b7b1df..da0c749ea 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -287,34 +287,5 @@ module.exports = {
         },
       },
     ],
-    [
-      'docusaurus-plugin-remote-content',
-      {
-        // Pulls external files and adds them as files in the Docusaurus folder, rewriting the title and the file name
-        name: 'switch-pallet',
-        sourceBaseUrl:
-          'https://raw.githubusercontent.com/KILTprotocol/kilt-node/refs/heads/master/pallets/pallet-asset-switch/',
-        outDir: 'docs/develop/09_polarpath',
-        documents: ['README.md'],
-        modifyContent(filename, content) {
-          if (filename.includes('README')) {
-            const regex = /\.\/[^\/]+\/[^\/]+\/([^\/]+\/mod\.rs)/g
-            var trimContent = content.replaceAll(
-              regex,
-              'https://raw.githubusercontent.com/KILTprotocol/kilt-node/refs/heads/master/pallets/pallet-asset-switch/src/xcm/$1'
-            )
-            var trimContent2 = trimContent.replace(
-              '../../runtime-api/asset-switch/',
-              'https://github.com/KILTprotocol/kilt-node/tree/master/runtime-api/asset-switch'
-            )
-            return {
-              filename: '02_switch_pallet.md',
-              content: trimContent2,
-            }
-          }
-          return undefined
-        },
-      },
-    ],
   ],
 }