diff --git a/doc/development/backend/ruby_style_guide.md b/doc/development/backend/ruby_style_guide.md
index d320a779cbfd81aeb16400c79a3bb6f78b1fa9e2..7e9dcd37a504adbf88eda9c3823ed0ea5f44102e 100644
--- a/doc/development/backend/ruby_style_guide.md
+++ b/doc/development/backend/ruby_style_guide.md
@@ -6,7 +6,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
 
 # Ruby style guide
 
-This is a GitLab-specific style guide for Ruby code. Everything documented in this page can be [reopened for discussion](https://about.gitlab.com/handbook/values/#disagree-commit-and-disagree).
+This is a GitLab-specific style guide for Ruby code. Everything documented in this page can be [reopened for discussion](https://handbook.gitlab.com/handbook/values/#disagree-commit-and-disagree).
 
 We use [RuboCop](../rubocop_development_guide.md) to enforce Ruby style guide rules.
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 182198a1524ef85ae109d3a353da87ec9158e74d..7724b183ad3f13bda32f42cb7ad9a191335eaabd 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -725,13 +725,13 @@ author.
   well. Building abstractions and good design is what makes it possible to hide
   complexity and makes future changes easier.
 - Enforcing and improving [code style](contributing/style_guides.md) should be primarily done through
-  [automation](https://about.gitlab.com/handbook/values/#cleanup-over-sign-off)
+  [automation](https://handbook.gitlab.com/handbook/values/#cleanup-over-sign-off)
   instead of review comments.
 - Asking the author to change the design sometimes means the complete rewrite
   of the contributed code. It's usually a good idea to ask another maintainer or
   reviewer before doing it, but have the courage to do it when you believe it is
   important.
-- In the interest of [Iteration](https://about.gitlab.com/handbook/values/#iteration),
+- In the interest of [Iteration](https://handbook.gitlab.com/handbook/values/#iteration),
   if your review suggestions are non-blocking changes, or personal preference
   (not a documented or agreed requirement), consider approving the merge request
   before passing it back to the author. This allows them to implement your suggestions
@@ -803,7 +803,7 @@ Properties of customer critical merge requests:
 - The DRI applies the `customer-critical-merge-request` label to the merge request.
 - It is required that the reviewers and maintainers involved with a customer critical merge request are engaged as soon as this decision is made.
 - It is required to prioritize work for those involved on a customer critical merge request so that they have the time available necessary to focus on it.
-- It is required to adhere to GitLab [values](https://about.gitlab.com/handbook/values/) and processes when working on customer critical merge requests, taking particular note of family and friends first/work second, definition of done, iteration, and release when it's ready.
+- It is required to adhere to GitLab [values](https://handbook.gitlab.com/handbook/values/) and processes when working on customer critical merge requests, taking particular note of family and friends first/work second, definition of done, iteration, and release when it's ready.
 - Customer critical merge requests are required to not reduce security, introduce data-loss risk, reduce availability, nor break existing functionality per the process for [prioritizing technical decisions](https://handbook.gitlab.com/handbook/engineering/development/principles/#prioritizing-technical-decisions).
 - On customer critical requests, it is _recommended_ that those involved _consider_ coordinating synchronously (Zoom, Slack) in addition to asynchronously (merge requests comments) if they believe this may reduce the elapsed time to merge even though this _may_ sacrifice [efficiency](https://about.gitlab.com/company/culture/all-remote/asynchronous/#evaluating-efficiency.md).
 - After a customer critical merge request is merged, a retrospective must be completed with the intention of reducing the frequency of future customer critical merge requests.
diff --git a/doc/development/database/database_reviewer_guidelines.md b/doc/development/database/database_reviewer_guidelines.md
index 5b28def28b7f07af676a7c747e13b38d75166691..e0bbe908ba953031a5bf74f0c9ac77114a61085e 100644
--- a/doc/development/database/database_reviewer_guidelines.md
+++ b/doc/development/database/database_reviewer_guidelines.md
@@ -88,7 +88,7 @@ For database specific requirements, see [`Project maintainer process for gitlab-
 
 ## What to do if you feel overwhelmed
 
-Similar to all types of reviews, [unblocking others is always a top priority](https://about.gitlab.com/handbook/values/#global-optimization).
+Similar to all types of reviews, [unblocking others is always a top priority](https://handbook.gitlab.com/handbook/values/#global-optimization).
 Database reviewers are expected to [review assigned merge requests in a timely manner](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#review-turnaround-time)
 or let the author know as soon as possible and help them find another reviewer or maintainer.
 
diff --git a/doc/development/database/namespaces_storage_statistics.md b/doc/development/database/namespaces_storage_statistics.md
index 07754839a1fd56846432f92997d5c8fc4441cd65..1d74e7de4e433f555e29539ac4fd938b2163e686 100644
--- a/doc/development/database/namespaces_storage_statistics.md
+++ b/doc/development/database/namespaces_storage_statistics.md
@@ -114,7 +114,7 @@ Same benefits and downsides as attempt A.
 ### Attempt C: Get rid of the model and store the statistics on Redis
 
 We could get rid of the model that stores the statistics in aggregated form and instead use a Redis Set.
-This would be the [boring solution](https://about.gitlab.com/handbook/values/#boring-solutions) and the fastest one
+This would be the [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions) and the fastest one
 to implement, as GitLab already includes Redis as part of its [Architecture](../architecture.md#redis).
 
 The downside of this approach is that Redis does not provide the same persistence/consistency guarantees as PostgreSQL,
diff --git a/doc/development/deprecation_guidelines/index.md b/doc/development/deprecation_guidelines/index.md
index c1dd415025447366a064eb81d517ca515439f7ff..2258efa6a867fbaf2d2d737927db80f761be625c 100644
--- a/doc/development/deprecation_guidelines/index.md
+++ b/doc/development/deprecation_guidelines/index.md
@@ -27,7 +27,7 @@ Use a separate MR to create a deprecation entry. For steps to create a deprecati
 
 Development on deprecated features is restricted to Priority 1 / Severity 1 bug fixes. Any community contributions to deprecated features are unlikely to be prioritized during milestone planning.
 
-However, at GitLab, we [give agency](https://about.gitlab.com/handbook/values/#give-agency) to our team members. So, a member of the team associated with the contribution may decide to review and merge it at their discretion.
+However, at GitLab, we [give agency](https://handbook.gitlab.com/handbook/values/#give-agency) to our team members. So, a member of the team associated with the contribution may decide to review and merge it at their discretion.
 
 ## When can a feature be removed/changed?
 
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index 3662a9c234542e1ad8bca80f8870f1020146e7ec..d0b73da9941169c457cc48bb4bd57290426b01ea 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -1447,7 +1447,7 @@ Use **press** when talking about keyboard keys. For example:
 
 ## profanity
 
-Do not use profanity. Doing so may negatively affect other users and contributors, which is contrary to the GitLab value of [Diversity, Inclusion, and Belonging](https://about.gitlab.com/handbook/values/#diversity-inclusion).
+Do not use profanity. Doing so may negatively affect other users and contributors, which is contrary to the GitLab value of [Diversity, Inclusion, and Belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion).
 
 ## provision
 
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index 022d1110304de68f3776db0f38b296347a3706e2..06095427662b10f42ea3d68867f3786556317010 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -215,7 +215,7 @@ expect(findText()).toBe('Lorem ipsum dolor sit');
 
 #### Recommendations
 
-If strings are reused throughout a component, it can be useful to define these strings as variables. We recommend defining an `i18n` property on the component's `$options` object. If there is a mixture of many-use and single-use strings in the component, consider using this approach to create a local [Single Source of Truth](https://about.gitlab.com/handbook/values/#single-source-of-truth) for externalized strings.
+If strings are reused throughout a component, it can be useful to define these strings as variables. We recommend defining an `i18n` property on the component's `$options` object. If there is a mixture of many-use and single-use strings in the component, consider using this approach to create a local [Single Source of Truth](https://handbook.gitlab.com/handbook/values/#single-source-of-truth) for externalized strings.
 
 ```javascript
 <script>
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index ed3afb8efa6f94f868b8fae9c216bc4972f64194..8bcddcfdddeac623eefc3b73152d420f2507c1e4 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -82,7 +82,7 @@ level of formality.
 
 ### Inclusive language
 
-[Diversity, inclusion, and belonging](https://about.gitlab.com/handbook/values/#diversity-inclusion)
+[Diversity, inclusion, and belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion)
 are GitLab values. We ask you to avoid translations that exclude people based on their gender or
 ethnicity. In languages that distinguish between a male and female form, use both or choose a
 neutral formulation.
diff --git a/doc/development/packages/new_format_development.md b/doc/development/packages/new_format_development.md
index 018d9c0cde9db0ccce3db1a9a6e2421d8886828f..44d4f82794b7751e7c22760d16d9a5a2fbb14289 100644
--- a/doc/development/packages/new_format_development.md
+++ b/doc/development/packages/new_format_development.md
@@ -99,7 +99,7 @@ Packages can be configured to use object storage, therefore your code must suppo
 
 ## MVC Approach
 
-The way new package systems are integrated in GitLab is using an [MVC](https://about.gitlab.com/handbook/values/#minimum-viable-change-mvc). Therefore, the first iteration should support the bare minimum user actions:
+The way new package systems are integrated in GitLab is using an [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc). Therefore, the first iteration should support the bare minimum user actions:
 
 - Authentication with a GitLab job, personal access, project access, or deploy token
 - Uploading a package and displaying basic metadata in the user interface
diff --git a/doc/development/ux/index.md b/doc/development/ux/index.md
index de4491f997c09fba08bd78c2fedd16416095c856..922311199b019ed9b33aa0b01ffe71948666499c 100644
--- a/doc/development/ux/index.md
+++ b/doc/development/ux/index.md
@@ -22,5 +22,5 @@ To contribute to [Pajamas design system](https://design.gitlab.com/) and the [UI
 
 1. Review the list of available UX issues that are currently [seeking community contribution](https://gitlab.com/groups/gitlab-org/-/issues/?sort=weight&state=opened&label_name%5B%5D=UX&label_name%5B%5D=Seeking%20community%20contributions&first_page_size=100).
 1. Find an issue that does not have an Assignee to ensure someone else is not working on a solution. Add the `~"workflow::design"` and `~"Community contribution"` labels and mention `@gitlab-com/gitlab-ux/reviewers` to request they assign the issue to you.
-1. Add your design proposal to the issue description/[design management](../../user/project/issues/design_management.md) section. Remember to keep the scope of the proposal/change small following our [MVCs guidelines](https://about.gitlab.com/handbook/values/#minimal-viable-change-mvc).
+1. Add your design proposal to the issue description/[design management](../../user/project/issues/design_management.md) section. Remember to keep the scope of the proposal/change small following our [MVCs guidelines](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc).
 1. If you have any questions or are ready for a review of your proposal, mention `@gitlab-com/gitlab-ux/reviewers` in a comment to make your request.