diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index 677586cb07eb542ea3cb3e46ba18334419ec97cf..5bddadcabed0f57c782fb107896639ed95b5ab03 100644
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@@ -133,7 +133,7 @@ you will need to follow the Consul [outage recovery](#outage-recovery) process.
 To be safe, it's recommended that you only restart Consul in one node at a time to
 ensure the cluster remains intact. For larger clusters, it is possible to restart
 multiple nodes at a time. See the
-[Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table)
+[Consul consensus document](https://www.consul.io/docs/architecture/consensus#deployment-table)
 for how many failures it can tolerate. This will be the number of simultaneous
 restarts it can sustain.
 
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md
index cc563ac1ac08b9a2178f7ac4a398ef68a992a1cd..a4e274c0a868bb7926989de0be83912833e21ced 100644
--- a/doc/administration/database_load_balancing.md
+++ b/doc/administration/database_load_balancing.md
@@ -167,7 +167,7 @@ When the list of hosts is updated, it might take a while for the old connections
 to be terminated. The `disconnect_timeout` setting can be used to enforce an
 upper limit on the time it will take to terminate all old database connections.
 
-Some nameservers (like [Consul](https://www.consul.io/docs/agent/dns.html#udp-based-dns-queries)) can return a truncated list of hosts when
+Some nameservers (like [Consul](https://www.consul.io/docs/discovery/dns#udp-based-dns-queries)) can return a truncated list of hosts when
 queried over UDP. To overcome this issue, you can use TCP for querying by setting
 `use_tcp` to `true`.
 
diff --git a/doc/development/adding_service_component.md b/doc/development/adding_service_component.md
index 0a07f67e7ba9a4c5acf39d6435318de54afc8a0e..a028675dbe2fba84726480ee2d51eba5f1d5e705 100644
--- a/doc/development/adding_service_component.md
+++ b/doc/development/adding_service_component.md
@@ -31,7 +31,7 @@ The following outline re-uses the [maturity metric](https://about.gitlab.com/dir
 
 The initial step for integrating a new component with GitLab starts with creating a [Feature proposal in the issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal).
 
-Identify the [product category](https://about.gitlab.com/handbook/product/categories/) the component falls under and assign the Engineering Manager and Product Manager responsible for that category.
+Identify the [product category](https://about.gitlab.com/handbook/product/product-categories/) the component falls under and assign the Engineering Manager and Product Manager responsible for that category.
 
 The general steps for getting any GitLab feature from proposal to release can be found in the [Product development flow](https://about.gitlab.com/handbook/product-development-flow/).
 
diff --git a/doc/development/agent/index.md b/doc/development/agent/index.md
index dd09a779318849f5c0ff3971e701d83de514e58f..95661c8ddbd48aa07bd77894adf2db4715287a1b 100644
--- a/doc/development/agent/index.md
+++ b/doc/development/agent/index.md
@@ -33,7 +33,7 @@ The agent can help you perform tasks like these:
 ## Architecture of the Kubernetes Agent
 
 The GitLab Kubernetes Agent and the GitLab Kubernetes Agent Server use
-[bidirectional streaming](https://grpc.io/docs/guides/concepts/#bidirectional-streaming-rpc)
+[bidirectional streaming](https://grpc.io/docs/what-is-grpc/core-concepts/#bidirectional-streaming-rpc)
 to allow the connection acceptor (the gRPC server, GitLab Kubernetes Agent Server) to
 act as a client. The connection acceptor sends requests as gRPC replies. The client-server
 relationship is inverted because the connection must be initiated from inside the
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index 98c2f19f71f326136634390648e69726c59d1dc3..894ae5a18939b4ac35af59537833ce34cf0da02d 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -47,7 +47,7 @@ the `author` field. GitLab team members **should not**.
 - Any user-facing change **must** have a changelog entry. This includes both visual changes (regardless of how minor), and changes to the rendered DOM which impact how a screen reader may announce the content.
 - Any client-facing change to our REST and GraphQL APIs **must** have a changelog entry.
 - Performance improvements **should** have a changelog entry.
-- Changes that need to be documented in the Product Analytics [Event Dictionary](https://about.gitlab.com/handbook/product/product-analytics-guide#event-dictionary)
+- Changes that need to be documented in the Product Analytics [Event Dictionary](https://about.gitlab.com/handbook/product/product-analytics-guide/#event-dictionary)
   also require a changelog entry.
 - _Any_ contribution from a community member, no matter how small, **may** have
   a changelog entry regardless of these guidelines if the contributor wants one.
@@ -55,7 +55,7 @@ the `author` field. GitLab team members **should not**.
 - Any docs-only changes **should not** have a changelog entry.
 - Any change behind a disabled feature flag **should not** have a changelog entry.
 - Any change behind an enabled feature flag **should** have a changelog entry.
-- Any change that adds new usage data metrics and changes that needs to be documented in Product Analytics [Event Dictionary](https://about.gitlab.com/handbook/product/product-analytics-guide#event-dictionary) **should** have a changelog entry.
+- Any change that adds new usage data metrics and changes that needs to be documented in Product Analytics [Event Dictionary](https://about.gitlab.com/handbook/product/product-analytics-guide/#event-dictionary) **should** have a changelog entry.
 - A change that adds snowplow events **should** have a changelog entry -
 - A change that [removes a feature flag](feature_flags/development.md) **should** have a changelog entry -
   only if the feature flag did not default to true already.
diff --git a/doc/development/documentation/restful_api_styleguide.md b/doc/development/documentation/restful_api_styleguide.md
index 13c6140114f9cdf0dbba65a606e7c4bc43968996..4bcd0bfcb31b1b31c48cdcc45a63a98e2682a9c1 100644
--- a/doc/development/documentation/restful_api_styleguide.md
+++ b/doc/development/documentation/restful_api_styleguide.md
@@ -107,7 +107,7 @@ Rendered example:
 
 ## cURL Examples
 
-The following sections include a set of [cURL](https://curl.haxx.se) examples
+The following sections include a set of [cURL](https://curl.se/) examples
 you can use in the API documentation.
 
 CAUTION: **Caution:**
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 744795d41499a0ac0808563fb137d63616e9ef3f..d4b4f9efaa6818106f72c4f8a39880cc79be3888 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -411,7 +411,7 @@ handleClick() {
 
 ### Working with pagination
 
-GitLab's GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/data/pagination/#cursor-based)
+GitLab's GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/pagination/overview/#cursor-based)
 for connection types. This means a "cursor" is used to keep track of where in the data
 set the next items should be fetched from. [GraphQL Ruby Connection Concepts](https://graphql-ruby.org/pagination/connection_concepts.html)
 is a good overview and introduction to connections.
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index f24a981dc098c33eb72c2a5dca7f4dc75b69ba1e..22777e653f52f2db323a5d90b3e0bbb838cb22f2 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -50,7 +50,7 @@ change feature flags or you do not [have access](#access).
 
 ### Enabling a feature for preproduction testing
 
-As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
+As a first step in a feature rollout, you should enable the feature on <https://about.staging.gitlab.com>
 and <https://dev.gitlab.org>.
 
 These two environments have different scopes.
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index 87a958ba08cddae29c72127c9e7d82f83b024607..11220e7f2768b662c570f33188af0e5440e0bd52 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -100,7 +100,7 @@ To propose additions to the glossary please
 ### Inclusive language in French
 
 <!-- vale gitlab.Spelling = NO -->
-In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
+In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000036068906/)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
 <!-- vale gitlab.Spelling = YES -->
diff --git a/doc/development/new_fe_guide/development/accessibility.md b/doc/development/new_fe_guide/development/accessibility.md
index 3a7c46b76158f291f31300354d61f07fb8ed5070..81f3773dd5cb27feb0c6f2b7dd7d46d7c87db708 100644
--- a/doc/development/new_fe_guide/development/accessibility.md
+++ b/doc/development/new_fe_guide/development/accessibility.md
@@ -42,7 +42,7 @@ In forms we should use the `for` attribute in the label statement:
 
 ## Testing
 
-1. On MacOS you can use [VoiceOver](https://www.apple.com/accessibility/mac/vision/) by pressing `cmd+F5`.
+1. On MacOS you can use [VoiceOver](http://www.apple.com/accessibility/vision/) by pressing `cmd+F5`.
 1. On Windows you can use [Narrator](https://www.microsoft.com/en-us/accessibility/windows) by pressing Windows logo key + Control + Enter.
 
 ## Online resources
diff --git a/doc/development/product_analytics/usage_ping.md b/doc/development/product_analytics/usage_ping.md
index 7293397c9beece26d29dec051a8c0cc5f803ce42..a9b48ec2d457625b087d78d80e38f41d321bc26f 100644
--- a/doc/development/product_analytics/usage_ping.md
+++ b/doc/development/product_analytics/usage_ping.md
@@ -118,7 +118,7 @@ sequenceDiagram
 1. `GitLab::UsageData.to_json` [cascades down](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb#L22) to ~400+ other counter method calls.
 1. The response of all methods calls are [merged together](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb#L14) into a single JSON payload in `GitLab::UsageData.to_json`.
 1. The JSON payload is then [posted to the Versions application]( https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/submit_usage_ping_service.rb#L20)
-   If a firewall exception is needed, the required URL depends on several things. If 
+   If a firewall exception is needed, the required URL depends on several things. If
    the hostname is `version.gitlab.com`, the protocol is `TCP`, and the port number is `443`,
    the required URL is <https://version.gitlab.com/>.
 
@@ -477,20 +477,20 @@ Next, get the unique events for the current week.
 We have the following recommendations for [Adding new events](#adding-new-events):
 
 - Event aggregation: weekly.
-- Key expiry time: 
+- Key expiry time:
   - Daily: 29 days.
   - Weekly: 42 days.
 - When adding new metrics, use a [feature flag](../../operations/feature_flags.md) to control the impact.
-- For feature flags triggered by another service, set `default_enabled: false`, 
+- For feature flags triggered by another service, set `default_enabled: false`,
   - Events can be triggered using the `UsageData` API, which helps when there are > 10 events per change
 
 ##### Enable/Disable Redis HLL tracking
 
 Events are tracked behind [feature flags](../feature_flags/index.md) due to concerns for Redis performance and scalability.
 
-For a full list of events and coresponding feature flags see, [known_events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/) files.
+For a full list of events and corresponding feature flags see, [known_events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/) files.
 
-To enable or disable tracking for specific event within <https://gitlab.com> or <https://staging.gitlab.com>, run commands such as the following to
+To enable or disable tracking for specific event within <https://gitlab.com> or <https://about.staging.gitlab.com>, run commands such as the following to
 [enable or disable the corresponding feature](../feature_flags/index.md).
 
 ```shell
@@ -666,7 +666,7 @@ We also use `#database-lab` and [explain.depesz.com](https://explain.depesz.com/
 
 ### 5. Add the metric definition
 
-When adding, changing, or updating metrics, please update the [Event Dictionary's **Usage Ping** table](https://about.gitlab.com/handbook/product/product-analytics-guide#event-dictionary).
+When adding, changing, or updating metrics, please update the [Event Dictionary's **Usage Ping** table](https://about.gitlab.com/handbook/product/product-analytics-guide/#event-dictionary).
 
 ### 6. Add new metric to Versions Application
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index c76e6d1880e6bfdf0f940f31c0ca568cb899efe5..5a93930981630206bed46285cb3eb295f7f8bfb2 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -106,7 +106,7 @@ Remember that the performance of each test depends on the environment.
 
 ### Timout error due to async components
 
-If your component is fetching some other components asynchroneously based on some conditions, it might happen so that your Jest suite for this component will become flaky timing out from time to time. 
+If your component is fetching some other components asynchroneously based on some conditions, it might happen so that your Jest suite for this component will become flaky timing out from time to time.
 
 ```javascript
 // ide.vue
@@ -223,8 +223,8 @@ Following you'll find some general common practices you will find as part of our
 When it comes to querying DOM elements in your tests, it is best to uniquely and semantically target
 the element.
 
-Preferentially, this is done by targeting what the user actually sees using [DOM Testing Library](https://testing-library.com/docs/dom-testing-library/intro).
-When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/dom-testing-library/api-queries#byrole)
+Preferentially, this is done by targeting what the user actually sees using [DOM Testing Library](https://testing-library.com/docs/dom-testing-library/intro/).
+When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/dom-testing-library/api-queries/#byrole)
 as these enforce accessibility best practices as well. The examples below demonstrate the order of preference.
 
 When writing Vue component unit tests, it can be wise to query children by component, so that the unit test can focus on comprehensive value coverage
diff --git a/doc/development/ux_guide/users.md b/doc/development/ux_guide/users.md
index 6d586ce807b0562e7a2a435e3ed7b62e188d6a38..a01aa4bcf35fd0538feecd2ab8d4bf14666f68b4 100644
--- a/doc/development/ux_guide/users.md
+++ b/doc/development/ux_guide/users.md
@@ -1,8 +1,8 @@
 ---
-redirect_to: 'https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/'
+redirect_to: 'https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/'
 ---
 
-This document was moved to [another location](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/).
+This document was moved to [another location](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/).
 
 <!-- This redirect file can be deleted after February 1, 2021. -->
 <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->