diff --git a/doc/api/graphql/index.md b/doc/api/graphql/index.md
index 7550d8f122172d2df6799608d7d7fc9a1edf5fc8..d7c043a0cd2e694471bcff7e1bc97c8de56b5198 100644
--- a/doc/api/graphql/index.md
+++ b/doc/api/graphql/index.md
@@ -188,12 +188,11 @@ To make these calls, add a
 ### Deprecation and removal process
 
 The deprecation and removal process for the GitLab GraphQL API aligns with the wider GitLab
-[deprecation process](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes).
+[deprecation process](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes).
 
 Parts of the schema marked for removal from the GitLab GraphQL API are first
-[deprecated](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecation)
-but still available for at least six releases. They are then [removed](https://about.gitlab.com/handbook/product/gitlab-the-product/#removal)
-entirely during the next `XX.0` major release.
+deprecated but still available for at least six releases. They are then
+removed entirely during the next `XX.0` major release.
 
 Items are marked as deprecated in:
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 7e50f8f8815c0cdd0217aca9fce66602a6395ef5..182198a1524ef85ae109d3a353da87ec9158e74d 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -183,7 +183,7 @@ by a reviewer before passing it to a maintainer as described in the
 | Changes to development guidelines | Follow the [review process](development_processes.md#development-guidelines-review) and get the approvals accordingly. |
 | End-to-end **and** non-end-to-end changes <sup>4</sup> | [Software Engineer in Test](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors). |
 | Only End-to-end changes <sup>4</sup> **or** if the MR author is a [Software Engineer in Test](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors) | [Quality maintainer](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa). |
-| A new or updated [application limit](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits) | [Product manager](https://about.gitlab.com/company/team/). |
+| A new or updated [application limit](https://handbook.gitlab.com/handbook/product/product-processes/#introducing-application-limits) | [Product manager](https://about.gitlab.com/company/team/). |
 | Analytics Instrumentation (telemetry or analytics) changes | [Analytics Instrumentation engineer](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/engineers). |
 | An addition of, or changes to a [Feature spec](testing_guide/testing_levels.md#frontend-feature-tests) | [Quality maintainer](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa) or [Quality reviewer](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_qa). |
 | A new service to GitLab (Puma, Sidekiq, Gitaly are examples) | [Product manager](https://about.gitlab.com/company/team/). See the [process for adding a service component to GitLab](adding_service_component.md) for details. |
@@ -274,7 +274,7 @@ See the [test engineering process](https://handbook.gitlab.com/handbook/engineer
 1. You have included changelog trailers, or you have decided that they are not needed.
     - [Does this MR need a changelog?](changelog.md#what-warrants-a-changelog-entry)
 1. You have added/updated documentation or decided that documentation changes are unnecessary for this MR.
-    - [Is documentation required?](https://about.gitlab.com/handbook/product/ux/technical-writing/workflow/#when-documentation-is-required)
+    - [Is documentation required?](https://handbook.gitlab.com/handbook/product/ux/technical-writing/workflow/#documentation-for-a-product-change)
 
 ##### Security
 
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index c6027e273100f7006d316cb6a2cc936216087c98..4cd1043fffdd5e86a446be5a3262687b07646bf7 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -24,10 +24,10 @@ As a merge request (MR) author, you must:
   for all reviewers and can speed up the review process, especially if the changes
   are small.
 - Attach the ~UX label to any merge request that has any user facing changes. This will trigger our
-  Reviewer Roulette to suggest a UX [reviewer](https://about.gitlab.com/handbook/product/ux/product-designer/mr-reviews/#stage-group-mrs).
+  Reviewer Roulette to suggest a UX [reviewer](https://handbook.gitlab.com/handbook/product/ux/product-designer/mr-reviews/#stage-group-mrs).
 
 If you are a **team member**: We recommend assigning the Product Designer suggested by the
-[Reviewer Roulette](../code_review.md#reviewer-roulette) as reviewer. [This helps us](https://about.gitlab.com/handbook/product/ux/product-designer/mr-reviews/#benefits) spread work evenly, improve communication, and make our UI more
+[Reviewer Roulette](../code_review.md#reviewer-roulette) as reviewer. [This helps us](https://handbook.gitlab.com/handbook/product/ux/product-designer/mr-reviews/#benefits) spread work evenly, improve communication, and make our UI more
 consistent. If you have a reason to choose a different reviewer, add a comment to mention you assigned
 it to a Product Designer of your choice.
 
@@ -113,7 +113,7 @@ When the design is ready, _before_ starting its implementation:
 
 - Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#Copy_link)
   or [GitLab Designs feature](../../user/project/issues/design_management.md).
-  See [when you should use each tool](https://about.gitlab.com/handbook/product/ux/product-designer/#deliver).
+  See [when you should use each tool](https://handbook.gitlab.com/handbook/product/ux/product-designer/#deliver).
 - Document user flow and states (for example, using [Mermaid flowcharts in Markdown](../../user/markdown.md#mermaid)).
 - Document animations and transitions.
 - Document responsive behaviors.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 144a1300104ffe19524020739f2b283805a42fc8..94e78c8a52e7a7b5a5a421ca12b062a121fb30db 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -78,7 +78,7 @@ For a walkthrough of the contribution process, see [Tutorial: Make a GitLab cont
 
 *Live by smaller iterations.* Keep the amount of changes in a single MR **as small as possible**.
 If you want to contribute a large feature, think very carefully about what the
-[minimum viable change](https://about.gitlab.com/handbook/product/#the-minimally-viable-change)
+[minimum viable change](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)
 is. Can you split the functionality into two smaller MRs? Can you submit only the
 backend/API code? Can you start with a very simple UI? Can you do just a part of the
 refactor?
@@ -231,7 +231,7 @@ requirements.
      for assistance to execute the database query that checks the existing rows to
      ensure existing rows aren't impacted by the change.
    - Add the necessary validation with a feature flag to be gradually rolled out
-     following [the rollout steps](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#rollout).
+     following [the rollout steps](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#rollout).
 
    If this merge request is urgent, the code owners should make the final call on
    whether reviewing existing rows should be included as an immediate follow-up task
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 2bb2a6fc2672508c97da6867d3394c8af3c25979..0f286bbd8822cac80d3961003d134f6ad711b9db 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -27,7 +27,7 @@ A database review is required for:
   database review.
 - Changes in Service Data metrics that use `count`, `distinct_count`, `estimate_batch_distinct_count` and `sum`.
   These metrics could have complex queries over large tables.
-  See the [Analytics Instrumentation Guide](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/)
+  See the [Analytics Instrumentation Guide](https://handbook.gitlab.com/handbook/product/analytics-instrumentation-guide/)
   for implementation details.
 - Changes that use [`update`, `upsert`, `delete`, `update_all`, `upsert_all`, `delete_all` or `destroy_all`](#preparation-when-using-bulk-update-operations)
   methods on an ActiveRecord object.
diff --git a/doc/development/development_processes.md b/doc/development/development_processes.md
index 4a1f89324e48b8be9fa5b6ae372dc9170de1620f..6a3be20e3179b592d06440082cc876461465bbae 100644
--- a/doc/development/development_processes.md
+++ b/doc/development/development_processes.md
@@ -60,7 +60,7 @@ In these cases, use the following workflow:
    - [Frontend](https://handbook.gitlab.com/handbook/engineering/frontend/)
    - [Backend](https://handbook.gitlab.com/handbook/engineering/)
    - [Database](https://handbook.gitlab.com/handbook/engineering/development/database/)
-   - [User Experience (UX)](https://about.gitlab.com/handbook/product/ux/)
+   - [User Experience (UX)](https://handbook.gitlab.com/handbook/product/ux/)
    - [Security](https://handbook.gitlab.com/handbook/security/)
    - [Quality](https://handbook.gitlab.com/handbook/engineering/quality/)
      - [Engineering Productivity](https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/)
diff --git a/doc/development/fe_guide/onboarding_course/lesson_1.md b/doc/development/fe_guide/onboarding_course/lesson_1.md
index 4938eecb47871080ea99661a495984253bfa4ee2..d938e45ac655f26e3fd4f7fd459e385065bd9899 100644
--- a/doc/development/fe_guide/onboarding_course/lesson_1.md
+++ b/doc/development/fe_guide/onboarding_course/lesson_1.md
@@ -169,7 +169,7 @@ When writing a merge request there are some important things to be aware of:
 - The MRs that you create on GitLab are available to the public. This means you can add a link to MRs you are particularly proud of to your portfolio page when looking for a job.
 - Since an MR is a technical document, you should try to implement a technical writing style.
   If you don’t know what that is, here is a highly recommended short course from [Google on Technical writing](https://developers.google.com/tech-writing/one).
-  If you are also contributing to the documentation at GitLab, there is a [Technical Writing Fundamentals course available here from GitLab](https://about.gitlab.com/handbook/product/ux/technical-writing/fundamentals/).
+  If you are also contributing to the documentation at GitLab, there is a [Technical Writing Fundamentals course available here from GitLab](https://handbook.gitlab.com/handbook/product/ux/technical-writing/fundamentals/).
 
 ## Live coding
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 730260423e3513b4a781780a912c4fa4e1882feb..2ea5ecd272aa0ae519054d9688c392ba2189ce3d 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -39,7 +39,7 @@ easier to measure the impact of both separately.
 
 The GitLab feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the
-[Feature flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
+[Feature flags process](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
 time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
 
 For an up to date list of feature flag commands see
@@ -492,7 +492,7 @@ To remove a feature flag, open **one merge request** to make the changes. In the
 1. Add the ~"feature flag" label so release managers are aware of the removal.
 1. If the merge request has to be backported into the current version, follow the
    [patch release runbook](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md) process.
-   See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
+   See [the feature flag process](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
    for further details.
 1. Remove all references to the feature flag from the codebase, including tests.
 1. Remove the YAML definition for the feature from the repository.
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index c7c404d4f0d68ec5ba9ea8736ff8c39d6bc98e54..4fb8aecd48e58c9e162614d57d2a4195639036d1 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -24,7 +24,7 @@ Blueprints:
 
 This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
 
-For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
+For an [overview of the feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the feature flag lifecycle handbook page.
 
 ## When to use feature flags
 
diff --git a/doc/development/internal_analytics/metrics/metrics_dictionary.md b/doc/development/internal_analytics/metrics/metrics_dictionary.md
index c88479b60e18865574545ae6e3fb52e4930f7b08..b443be4837eb5e7b08dcb82903b9f6bc8eb8b780 100644
--- a/doc/development/internal_analytics/metrics/metrics_dictionary.md
+++ b/doc/development/internal_analytics/metrics/metrics_dictionary.md
@@ -150,7 +150,7 @@ For uniqueness, the generated files include a timestamp prefix in ISO 8601 forma
 
 ### Performance Indicator Metrics
 
-To use a metric definition to manage [performance indicator](https://about.gitlab.com/handbook/product/analytics-instrumentation-guide/#implementing-product-performance-indicators):
+To use a metric definition to manage [performance indicator](https://handbook.gitlab.com/handbook/product/analytics-instrumentation-guide/#instrumenting-metrics-and-events):
 
 1. Create a merge request that includes related changes.
 1. Use labels `~"analytics instrumentation"`, `"~Data Warehouse::Impact Check"`.
diff --git a/doc/development/labels/index.md b/doc/development/labels/index.md
index 3ec9785c9cb505aa6e25d04b31b9cf543762f818..403755d7a1be493b8cdf3f406f0a31726343882e 100644
--- a/doc/development/labels/index.md
+++ b/doc/development/labels/index.md
@@ -50,7 +50,7 @@ already reserved for category labels).
 The descriptions on the [labels page](https://gitlab.com/groups/gitlab-org/-/labels)
 explain what falls under each type label.
 
-The GitLab handbook documents [when something is a bug](https://about.gitlab.com/handbook/product/product-processes/#bug-issues) and [when it is a feature request](https://about.gitlab.com/handbook/product/product-processes/#feature-issues).
+The GitLab handbook documents [when something is a bug](https://handbook.gitlab.com/handbook/product/product-processes/#bug-issues) and [when it is a feature request](https://handbook.gitlab.com/handbook/product/product-processes/#feature-issues).
 
 ## Stage labels
 
diff --git a/doc/development/merge_request_concepts/performance.md b/doc/development/merge_request_concepts/performance.md
index 7a1e33494d0543ed62d6d4e147ca8f4cfdbfe013..6f362a5f12db047c8c97141cb4749aa7b7785c4c 100644
--- a/doc/development/merge_request_concepts/performance.md
+++ b/doc/development/merge_request_concepts/performance.md
@@ -460,7 +460,7 @@ Performance deficiencies should be addressed right away after we merge initial
 changes.
 
 Read more about when and how feature flags should be used in
-[Feature flags in GitLab development](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flags-in-gitlab-development).
+[Feature flags in GitLab development](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#how-to-use-feature-flags).
 
 ## Storage
 
diff --git a/doc/development/pages/index.md b/doc/development/pages/index.md
index b043843f95777fee1c19a41683f5409a90fb7e53..53685c899a041ee45f66783ec9cbdd733f4c6401 100644
--- a/doc/development/pages/index.md
+++ b/doc/development/pages/index.md
@@ -245,7 +245,7 @@ make && go test ./ -run TestRedirect
 ### Feature flags
 
 WARNING:
-All newly-introduced feature flags should be [disabled by default](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flags-in-gitlab-development).
+All newly-introduced feature flags should be [disabled by default](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#how-to-use-feature-flags).
 
 Consider adding a [feature flag](../feature_flags/index.md) for any non-trivial changes.
 Feature flags can make the release and rollback of these changes easier, avoiding
diff --git a/doc/tutorials/boards_for_teams/index.md b/doc/tutorials/boards_for_teams/index.md
index 846e3cc009849ecb63b033cda1ccef950e19bd86..07a5dfe8759ce51af90eb2a987f2f2bdc36470da 100644
--- a/doc/tutorials/boards_for_teams/index.md
+++ b/doc/tutorials/boards_for_teams/index.md
@@ -17,7 +17,7 @@ This tutorial shows you how to set up [issue boards](../../user/project/issue_bo
 In this example, you'll create two issue boards for the UX and Frontend teams.
 Using the following steps, you can create issue boards and workflows for more sub-teams, like Backend
 or Quality Assurance.
-To learn how we use workflow labels at GitLab, see [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow).
+To learn how we use workflow labels at GitLab, see [Product Development Flow](https://handbook.gitlab.com/handbook/product-development-flow/).
 
 To set up issue boards for multiple teams: