Update various links

Update links to avoid redirects, and fix links
with 404 fails

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -21,7 +21,7 @@ There are many commercial and open source [directory servers](https://en.wikiped
 For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831484(v=ws.11)) is generally favored in a primarily Windows environment, as this allows quick integration with existing services. Other popular directory services include:
 - [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html)
-- [OpenLDAP](http://www.openldap.org/)
+- [OpenLDAP](https://www.openldap.org/)
 - [389 Directory](http://directory.fedoraproject.org/)
 - [OpenDJ (Renamed to Forgerock Directory Services)](https://www.forgerock.com/platform/directory-services)
 - [ApacheDS](https://directory.apache.org/)

doc/administration/auth/oidc.md

@@ -128,7 +128,7 @@ different providers with Omnibus GitLab.
 ### Google
 See the [Google
-documentation](https://developers.google.com/identity/protocols/OpenIDConnect)
+documentation](https://developers.google.com/identity/protocols/oauth2/openid-connect)
 for more details:
 ```ruby

doc/administration/geo/replication/security_review.md

@@ -3,7 +3,7 @@
 The following security review of the Geo feature set focuses on security aspects of
 the feature as they apply to customers running their own GitLab instances. The review
 questions are based in part on the [OWASP Application Security Verification Standard Project](https://owasp.org/www-project-application-security-verification-standard/)
-from [owasp.org](https://www.owasp.org/).
+from [owasp.org](https://owasp.org/).
 ## Business Model

doc/administration/gitaly/index.md

@@ -731,7 +731,7 @@ use a Ruby gem (library) called
 the form of a C library.
 Over time it has become clear to use that Rugged, and particularly
-Rugged in combination with the [Unicorn](https://bogomips.org/unicorn/)
+Rugged in combination with the [Unicorn](https://yhbt.net/unicorn/)
 web server, is extremely efficient. Because libgit2 is a *library* and
 not an external process, there was very little overhead between GitLab
 application code that tried to look up data in Git repositories, and the

doc/administration/high_availability/pgbouncer.md

@@ -4,7 +4,7 @@ type: reference
 # Working with the bundled PgBouncer service **(PREMIUM ONLY)**
-As part of its High Availability stack, GitLab Premium includes a bundled version of [PgBouncer](https://pgbouncer.github.io/) that can be managed through `/etc/gitlab/gitlab.rb`. PgBouncer is used to seamlessly migrate database connections between servers in a failover scenario. Additionally, it can be used in a non-HA setup to pool connections, speeding up response time while reducing resource usage.
+As part of its High Availability stack, GitLab Premium includes a bundled version of [PgBouncer](http://www.pgbouncer.org/) that can be managed through `/etc/gitlab/gitlab.rb`. PgBouncer is used to seamlessly migrate database connections between servers in a failover scenario. Additionally, it can be used in a non-HA setup to pool connections, speeding up response time while reducing resource usage.
 In a HA setup, it's recommended to run a PgBouncer node separately for each database node with an internal load balancer (TCP) serving each accordingly.

doc/administration/integration/plantuml.md

@@ -2,7 +2,7 @@
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8537) in GitLab 8.16.
-When [PlantUML](http://plantuml.com) integration is enabled and configured in
+When [PlantUML](https://plantuml.com) integration is enabled and configured in
 GitLab we are able to create simple diagrams in AsciiDoc and Markdown documents
 created in snippets, wikis, and repos.
@@ -161,10 +161,10 @@ Alice -> Bob : hi
 ```
 Inside the block you can add any of the supported diagrams by PlantUML such as
-[Sequence](http://plantuml.com/sequence-diagram), [Use Case](http://plantuml.com/use-case-diagram),
-[Class](http://plantuml.com/class-diagram), [Activity](http://plantuml.com/activity-diagram-legacy),
-[Component](http://plantuml.com/component-diagram), [State](http://plantuml.com/state-diagram),
-and [Object](http://plantuml.com/object-diagram) diagrams. You do not need to use the PlantUML
+[Sequence](https://plantuml.com/sequence-diagram), [Use Case](https://plantuml.com/use-case-diagram),
+[Class](https://plantuml.com/class-diagram), [Activity](https://plantuml.com/activity-diagram-legacy),
+[Component](https://plantuml.com/component-diagram), [State](https://plantuml.com/state-diagram),
+and [Object](https://plantuml.com/object-diagram) diagrams. You do not need to use the PlantUML
 diagram delimiters `@startuml`/`@enduml` as these are replaced by the AsciiDoc `plantuml` block.
 Some parameters can be added to the AsciiDoc block definition:

doc/administration/operations/puma.md

@@ -2,7 +2,7 @@
 ## Puma
-As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced [Unicorn](https://bogomips.org/unicorn/).
+As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced [Unicorn](https://yhbt.net/unicorn/).
 as the default web server.
 ## Why switch to Puma?

doc/administration/operations/unicorn.md

@@ -2,7 +2,7 @@
 ## Unicorn
-GitLab uses [Unicorn](https://bogomips.org/unicorn/), a pre-forking Ruby web
+GitLab uses [Unicorn](https://yhbt.net/unicorn/), a pre-forking Ruby web
 server, to handle web requests (web browsers and Git HTTP clients). Unicorn is
 a daemon written in Ruby and C that can load and run a Ruby on Rails
 application; in our case the Rails application is GitLab Community Edition or

doc/administration/repository_storage_paths.md

@@ -120,5 +120,5 @@ randomly placed on one of the selected paths.
 [reconfigure-gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure
 [backups]: ../raketasks/backup_restore.md
 [raketask]: https://gitlab.com/gitlab-org/gitlab/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56
-[repospath]: https://gitlab.com/gitlab-org/gitlab/blob/8-9-stable/config/gitlab.yml.example#L457
+[repospath]: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457
 [ce-11449]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11449

doc/api/graphql/getting_started.md

@@ -36,7 +36,7 @@ The examples below:
 - Can be run directly against GitLab 11.0 or later, though some of the types and fields
 may not be supported in older versions.
 - Will work against GitLab.com without any further setup. Make sure you are signed in and
-navigate to the [GraphiQL Explorer](https://www.gitlab.com/-/graphql-explorer).
+navigate to the [GraphiQL Explorer](https://gitlab.com/-/graphql-explorer).
 If you want to run the queries locally, or on a self-managed instance,
 you will need to either:

doc/development/architecture.md

@@ -125,18 +125,18 @@ Component statuses are linked to configuration documentation for each component.
 | Component | Description | [Omnibus GitLab](https://docs.gitlab.com/omnibus/) | [GitLab chart](https://docs.gitlab.com/charts/) | [Minikube Minimal](https://docs.gitlab.com/charts/development/minikube/#deploying-gitlab-with-minimal-settings) | [GitLab.com](https://gitlab.com) | [Source](../install/installation.md) | [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) | CE/EE |
 | --------- | ----------- |:--------------------:|:------------------:|:-----:|:--------:|:--------:|:-------:|:-------:|
-| [NGINX](#nginx) | Routes requests to appropriate components, terminates SSL | [✅][nginx-omnibus] | [✅][nginx-charts] | [⚙][nginx-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⤓][nginx-source] | ❌ | CE & EE |
+| [NGINX](#nginx) | Routes requests to appropriate components, terminates SSL | [✅][nginx-omnibus] | [✅][nginx-charts] | [⚙][nginx-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⤓][nginx-source] | ❌ | CE & EE |
 | [Unicorn (GitLab Rails)](#unicorn) | Handles requests for the web interface and API | [✅][unicorn-omnibus] | [✅][unicorn-charts] | [✅][unicorn-charts] | [✅](../user/gitlab_com/index.md#unicorn) | [⚙][unicorn-source] | [✅][gitlab-yml] | CE & EE |
 | [Sidekiq](#sidekiq) | Background jobs processor | [✅][sidekiq-omnibus] | [✅][sidekiq-charts] | [✅](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html) | [✅](../user/gitlab_com/index.md#sidekiq) | [✅][gitlab-yml] | [✅][gitlab-yml] | CE & EE |
-| [Gitaly](#gitaly) | Git RPC service for handling all Git calls made by GitLab | [✅][gitaly-omnibus] | [✅][gitaly-charts] | [✅][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][gitaly-source] | ✅ | CE & EE |
-| [Praefect](#praefect) | A transparent proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE |
-| [GitLab Workhorse](#gitlab-workhorse) | Smart reverse proxy, handles large HTTP requests | [✅][workhorse-omnibus] | [✅][workhorse-charts] | [✅][workhorse-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][workhorse-source] | ✅ | CE & EE |
-| [GitLab Shell](#gitlab-shell) | Handles `git` over SSH sessions | [✅][shell-omnibus] | [✅][shell-charts] | [✅][shell-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][shell-source] | [✅][gitlab-yml] | CE & EE |
+| [Gitaly](#gitaly) | Git RPC service for handling all Git calls made by GitLab | [✅][gitaly-omnibus] | [✅][gitaly-charts] | [✅][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⚙][gitaly-source] | ✅ | CE & EE |
+| [Praefect](#praefect) | A transparent proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE |
+| [GitLab Workhorse](#gitlab-workhorse) | Smart reverse proxy, handles large HTTP requests | [✅][workhorse-omnibus] | [✅][workhorse-charts] | [✅][workhorse-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⚙][workhorse-source] | ✅ | CE & EE |
+| [GitLab Shell](#gitlab-shell) | Handles `git` over SSH sessions | [✅][shell-omnibus] | [✅][shell-charts] | [✅][shell-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⚙][shell-source] | [✅][gitlab-yml] | CE & EE |
 | [GitLab Pages](#gitlab-pages) | Hosts static websites | [⚙][pages-omnibus] | [❌][pages-charts] | [❌][pages-charts] | [✅](../user/gitlab_com/index.md#gitlab-pages) | [⚙][pages-source] | [⚙][pages-gdk] | CE & EE  |
 | [Registry](#registry) | Container registry, allows pushing and pulling of images | [⚙][registry-omnibus] | [✅][registry-charts] | [✅][registry-charts] | [✅](../user/packages/container_registry/index.md#build-and-push-images-using-gitlab-cicd) | [⤓][registry-source] | [⚙][registry-gdk] | CE & EE  |
-| [Redis](#redis) | Caching service | [✅][redis-omnibus] | [✅][redis-omnibus] | [✅][redis-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⤓][redis-source] | ✅ | CE & EE |
+| [Redis](#redis) | Caching service | [✅][redis-omnibus] | [✅][redis-omnibus] | [✅][redis-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture) | [⤓][redis-source] | ✅ | CE & EE |
 | [PostgreSQL](#postgresql) | Database | [✅][postgres-omnibus] | [✅][postgres-charts] | [✅][postgres-charts] | [✅](../user/gitlab_com/index.md#postgresql) | [⤓][postgres-source] | ✅ | CE & EE |
-| [PgBouncer](#pgbouncer) | Database connection pooling, failover | [⚙][pgbouncer-omnibus] | [❌][pgbouncer-charts] | [❌][pgbouncer-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#database-architecture) | ❌ | ❌ | EE Only |
+| [PgBouncer](#pgbouncer) | Database connection pooling, failover | [⚙][pgbouncer-omnibus] | [❌][pgbouncer-charts] | [❌][pgbouncer-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#database-architecture) | ❌ | ❌ | EE Only |
 | [Consul](#consul) | Database node discovery, failover | [⚙][consul-omnibus] | [❌][consul-charts] | [❌][consul-charts] | [✅](../user/gitlab_com/index.md#consul) | ❌ | ❌ | EE Only |
 | [GitLab self-monitoring: Prometheus](#prometheus) | Time-series database, metrics collection, and query service | [✅][prometheus-omnibus] | [✅][prometheus-charts] | [⚙][prometheus-charts] | [✅](../user/gitlab_com/index.md#prometheus) | ❌ | ❌ | CE & EE |
 | [GitLab self-monitoring: Alertmanager](#alertmanager) | Deduplicates, groups, and routes alerts from Prometheus | [⚙][alertmanager-omnibus] | [✅][alertmanager-charts] |  [⚙][alertmanager-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
@@ -149,10 +149,10 @@ Component statuses are linked to configuration documentation for each component.
 | [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | [✅][gitlab-exporter-omnibus] | [✅][gitlab-exporter-charts] | [✅][gitlab-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Mattermost](#mattermost) | Open-source Slack alternative | [⚙][mattermost-omnibus] | [⤓][mattermost-charts] | [⤓][mattermost-charts] | [⤓](../user/project/integrations/mattermost.md) | ❌ | ❌ | CE & EE |
-| [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE |
+| [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE |
 | [Runner](#gitlab-runner) | Executes GitLab CI jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE |
 | [Database Migrations](#database-migrations) | Database migrations | [✅][database-migrations-omnibus] | [✅][database-migrations-charts] | [✅][database-migrations-charts] | ✅ | [⚙][database-migrations-source] | ✅ | CE & EE |
-| [Certificate Management](#certificate-management) | TLS Settings, Let's Encrypt | [✅][certificate-management-omnibus] | [✅][certificate-management-charts] | [⚙][certificate-management-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#secrets-management) | [⚙][certificate-management-source] | [⚙][certificate-management-gdk] | CE & EE |
+| [Certificate Management](#certificate-management) | TLS Settings, Let's Encrypt | [✅][certificate-management-omnibus] | [✅][certificate-management-charts] | [⚙][certificate-management-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management) | [⚙][certificate-management-source] | [⚙][certificate-management-gdk] | CE & EE |
 | [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | [⚙][geo-omnibus] | [❌][geo-charts] | [❌][geo-charts] | ✅ | ❌ | [⚙][geo-gdk] | EE Only |
 | [LDAP Authentication](#ldap-authentication) | Authenticate users against centralized LDAP directory | [⤓][ldap-omnibus] | [⤓][ldap-charts] | [⤓][ldap-charts] | [❌](https://about.gitlab.com/pricing/#gitlab-com) | [⤓][gitlab-yml] | [⤓][ldap-gdk] | CE & EE |
 | [Outbound email (SMTP)](#outbound-email) | Send email messages to users | [⤓][outbound-email-omnibus] | [⤓][outbound-email-charts] | [⤓][outbound-email-charts] | [✅](../user/gitlab_com/index.md#mail-configuration) | [⤓][gitlab-yml] | [⤓][gitlab-yml] | CE & EE |
@@ -446,7 +446,7 @@ Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue
 - Layer: Core Service (Processor)
 - Process: `unicorn`
-[Unicorn](https://bogomips.org/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
+[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
 #### LDAP Authentication

doc/development/chatops_on_gitlabcom.md

@@ -16,7 +16,7 @@ To request access to Chatops on GitLab.com:
 1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
 1. Ask in the [#production](https://gitlab.slack.com/messages/production) channel to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
-NOTE: **Note:** If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/team).
+NOTE: **Note:** If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
 ## See also

doc/development/code_review.md

@@ -79,7 +79,7 @@ from teams other than your own.
 #### Security requirements
-View the updated documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/engineering/security/index.html#internal-application-security-reviews) for **when** and **how** to request a security review.
+View the updated documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/engineering/security/#internal-application-security-reviews) for **when** and **how** to request a security review.
 ### The responsibility of the merge request author

doc/development/contributing/issue_workflow.md

@@ -14,7 +14,7 @@ see fit.
 ## Issue triaging
-Our issue triage policies are [described in our handbook](https://about.gitlab.com/handbook/engineering/issue-triage/).
+Our issue triage policies are [described in our handbook](https://about.gitlab.com/handbook/engineering/quality/issue-triage/).
 You are very welcome to help the GitLab team triage issues.
 We also organize [issue bash events](https://gitlab.com/gitlab-org/gitlab-foss/issues/17815)
 once every quarter.

doc/development/documentation/site_architecture/release_process.md

@@ -92,7 +92,7 @@ this needs to happen when the stable branches for all products have been created
    tagged with the branch name you created in the first step. In the end, the
    image will be uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
    and it will be listed under the
-   [`registry` environment folder](https://gitlab.com/gitlab-org/gitlab-docs/environments/folders/registry).
+   [`registry` environment folder](https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry).
 Optionally, you can test locally by building the image and running it:
@@ -179,11 +179,11 @@ The dropdown merge requests should have now been merged into their respective
 version (stable branch), which will trigger another pipeline. At this point,
 you need to only babysit the pipelines and make sure they don't fail:
-1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
+1. Check the pipelines page: `https://gitlab.com/gitlab-org/gitlab-docs/pipelines`
    and make sure all stable branches have green pipelines.
 1. After all the pipelines of the online versions succeed, merge the release merge request.
-1. Finally, run the [Build docker images weekly](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
-   pipeline that will build the `:latest` and `:archives` Docker images.
+1. Finally, from `https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules` run
+   the `Build docker images weekly` pipeline that will build the `:latest` and `:archives` Docker images.
 Once the scheduled pipeline succeeds, the docs site will be deployed with all
 new versions online.
@@ -191,8 +191,7 @@ new versions online.
 ## Update an old Docker image with new upstream docs content
 If there are any changes to any of the stable branches of the products that are
-not included in the single Docker image, just
-[rerun the pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new)
+not included in the single Docker image, just rerun the pipeline (`https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new`)
 for the version in question.
 ## Porting new website changes to old versions
@@ -239,7 +238,7 @@ branches for 12.2 were used, this wouldn't have failed, but as we can see from
 the [`compile_dev` job](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/328042427),
 the `master` branches were pulled.
-To fix this, [re-run the pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new)
+To fix this, re-run the pipeline (`https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new`)
 for the `update-12-2-for-release-12-4` branch, by including the following environment variables:
 - `BRANCH_CE` set to `12-2-stable`

doc/development/documentation/workflow.md

@@ -62,7 +62,7 @@ responsible for:
 - Liaising with their Product Manager to understand what documentation must be delivered, and when.
 - Requesting technical reviews from other developers within their group.
 - Requesting documentation reviews from the Technical Writer
-  [assigned to the DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments)
+  [assigned to the DevOps stage group](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)
   that is delivering the new feature or feature enhancements.
 TIP: **Tip:**
@@ -92,7 +92,7 @@ the Product Manager and Technical Writer for a given issue:
   - Documentation [Structure and template](structure.md) page.
   - [Style Guide](styleguide.md).
   - [Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/).
-- Contact the Technical Writer for the relevant [DevOps stage](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments)
+- Contact the Technical Writer for the relevant [DevOps stage](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)
   in your issue or merge request, or within `#docs` on GitLab Slack, if you:
   - Need any help to choose the correct place for documentation.
   - Want to discuss a documentation idea or outline.
@@ -423,7 +423,7 @@ Request help from the Technical Writing team if you:
 To request help:
 1. Locate the the Technical Writer for the relevant
-   [DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments).
+   [DevOps stage group](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments).
 1. Either:
    - If urgent help is required, directly assign the Technical Writer in the issue or in the merge request.
    - If non-urgent help is required, ping the Technical Writer in the issue or merge request.
@@ -439,7 +439,7 @@ Maintainers must make a good-faith effort to ensure that the content:
 - Meets the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
 If the author or reviewer has any questions, they can mention the writer who is assigned to the relevant
-[DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments).
+[DevOps stage group](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments).
 The process involves the following:
@@ -449,7 +449,7 @@ The process involves the following:
 - Technical Writer (Optional). If not completed for a merge request prior to merging, must be scheduled
   post-merge. Schedule post-merge reviews only if an urgent merge is required. To request a:
   - Pre-merge review, assign the Technical Writer listed for the applicable
-    [DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments).
+    [DevOps stage group](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments).
   - Post-merge review, see [Post-merge reviews](#post-merge-reviews).
 - Maintainer. For merge requests, Maintainers:
   - Can always request any of the above reviews.

doc/development/fe_guide/frontend_faq.md

@@ -63,7 +63,7 @@ banner on top of the component examples indicates that:
 > component.
 For example, at the time of writing, this type of warning can be observed for
-[all form components](https://design.gitlab.com/components/forms). It, however,
+[all form components](https://design.gitlab.com/components/forms/). It, however,
 doesn't imply that the component should not be used.
 GitLab always asks to use `<gl-*>` components whenever a suitable component exists.

doc/development/understanding_explain_plans.md

@@ -765,5 +765,5 @@ exec ROLLBACK
 ## Further reading
 A more extensive guide on understanding query plans can be found in
-the [presentation](https://www.dalibo.org/_media/understanding_explain.pdf)
-from [Dalibo.org](https://www.dalibo.org/en/).
+the [presentation](https://public.dalibo.com/exports/conferences/_archives/_2012/201211_explain/understanding_explain.pdf)
+from [Dalibo.org](https://www.dalibo.com/en/).

doc/install/openshift_and_gitlab/index.md

@@ -36,7 +36,7 @@ test OpenShift easily:
 - [VirtualBox]
 - [Vagrant]
-- [OpenShift Client](https://docs.okd.io/latest/cli_reference/get_started_cli.html) (`oc` for short)
+- [OpenShift Client](https://docs.okd.io/3.11/cli_reference/get_started_cli.html) (`oc` for short)
 It is also important to mention that for the purposes of this tutorial, the
 latest Origin release is used:
@@ -99,7 +99,7 @@ landing page looks like:
 ![openshift web console](img/web-console.png)
-You can see that a number of [projects](https://docs.okd.io/latest/dev_guide/projects.html) are already created for testing purposes.
+You can see that a number of [projects](https://docs.okd.io/3.11/dev_guide/projects.html) are already created for testing purposes.
 If you head over the `openshift-infra` project, a number of services with their
 respective pods are there to explore.
@@ -107,7 +107,7 @@ respective pods are there to explore.
 ![openshift web console](img/openshift-infra-project.png)
 We are not going to explore the whole interface, but if you want to learn about
-the key concepts of OpenShift, read the [core concepts reference](https://docs.okd.io/latest/architecture/core_concepts/index.html)
+the key concepts of OpenShift, read the [core concepts reference](https://docs.okd.io/3.11/architecture/core_concepts/index.html)
 in the official documentation.
 ### Explore the OpenShift CLI
@@ -115,7 +115,7 @@ in the official documentation.
 OpenShift Client (`oc`), is a powerful CLI tool that talks to the OpenShift API
 and performs pretty much everything you can do from the web UI and much more.
-Assuming you have [installed](https://docs.okd.io/latest/cli_reference/get_started_cli.html) it, let's explore some of its main
+Assuming you have [installed](https://docs.okd.io/3.11/cli_reference/get_started_cli.html) it, let's explore some of its main
 functionalities.
 Let's first see the version of `oc`:
@@ -172,7 +172,7 @@ The last command should spit a bunch of information about the statuses of the
 pods and the services, which if you look closely is what we encountered in the
 second image when we explored the web console.
-You can always read more about `oc` in the [OpenShift CLI documentation](https://docs.okd.io/latest/cli_reference/get_started_cli.html).
+You can always read more about `oc` in the [OpenShift CLI documentation](https://docs.okd.io/3.11/cli_reference/get_started_cli.html).
 ### Troubleshooting the all-in-one VM
@@ -248,7 +248,7 @@ The next step is to import the OpenShift template for GitLab.
 ### Import the template
-The [template](https://docs.okd.io/latest/architecture/core_concepts/templates.html) is basically a JSON file which describes a set of
+The [template](https://docs.okd.io/3.11/architecture/core_concepts/templates.html) is basically a JSON file which describes a set of
 related object definitions to be created together, as well as a set of
 parameters for those objects.
@@ -364,7 +364,7 @@ of resources, you'd be happy to know that you can scale up with the push of a
 button.
 In the **Overview** page just click the up arrow button in the pod where
-GitLab is. The change is instant and you can see the number of [replicas](https://docs.okd.io/latest/architecture/core_concepts/deployments.html#replication-controllers) now
+GitLab is. The change is instant and you can see the number of [replicas](https://docs.okd.io/3.11/architecture/core_concepts/deployments.html#replication-controllers) now
 running scaled to 2.
 ![GitLab scale](img/gitlab-scale.png)
@@ -382,7 +382,7 @@ scale up. If a pod is in pending state for too long, you can navigate to
 ### Scale GitLab using the `oc` CLI
 Using `oc` is super easy to scale up the replicas of a pod. You may want to
-skim through the [basic CLI operations](https://docs.okd.io/latest/cli_reference/basic_cli_operations.html) to get a taste how the CLI
+skim through the [basic CLI operations](https://docs.okd.io/3.11/cli_reference/basic_cli_operations.html) to get a taste how the CLI
 commands are used. Pay extra attention to the object types as we will use some
 of them and their abbreviated versions below.
@@ -455,7 +455,7 @@ In case you were wondering whether there is an option to autoscale a pod based
 on the resources of your server, the answer is yes, of course there is.
 We will not expand on this matter, but feel free to read the documentation on
-OpenShift's website about [autoscaling](https://docs.okd.io/latest/dev_guide/pod_autoscaling.html).
+OpenShift's website about [autoscaling](https://docs.okd.io/3.11/dev_guide/pod_autoscaling.html).
 ## Current limitations
@@ -470,7 +470,7 @@ bother us. In any case, it is something to keep in mind when deploying GitLab
 on a production cluster.
 In order to deploy GitLab on a production cluster, you will need to assign the
-GitLab service account to the `anyuid` [Security Context Constraints](https://docs.okd.io/latest/admin_guide/manage_scc.html).
+GitLab service account to the `anyuid` [Security Context Constraints](https://docs.okd.io/3.11/admin_guide/manage_scc.html).
 For OpenShift v3.0, you will need to do this manually:

doc/topics/authentication/index.md

@@ -47,4 +47,4 @@ This page gathers all the resources for the topic **Authentication** within GitL
 - [Kanboard Plugin GitLab Authentication](https://github.com/kanboard/plugin-gitlab-auth)
 - [Jenkins GitLab OAuth Plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+OAuth+Plugin)
 - [How to customize GitLab to support OpenID authentication](http://eric.van-der-vlist.com/blog/2013/11/23/how-to-customize-gitlab-to-support-openid-authentication/)
-- [OKD - Configuring Authentication and User Agent](https://docs.okd.io/latest/install_config/configuring_authentication.html#GitLab)
+- [OKD - Configuring Authentication and User Agent](https://docs.okd.io/3.11/install_config/configuring_authentication.html#GitLab)