diff --git a/docs/actions.md b/docs/actions.md
index 0db78d1a..14e2914a 100644
--- a/docs/actions.md
+++ b/docs/actions.md
@@ -15,7 +15,7 @@ worker will have a `context=worker` since it's operating on the worker level.
 An action to reboot a single worker would have `context=worker`.
 
 Queue Actions are conceptually related to [task
-actions](/manual/using/actions), in that both allow resources to expose
+actions](/docs/manual/using/actions), in that both allow resources to expose
 context-specific opportunities to manipulate those resources.  However, the
 implementations are completely different.
 
@@ -23,7 +23,7 @@ implementations are completely different.
 
 Actions are defined at the provisioner level. To set the actions to a
 provisioner, perform a call to the queue's
-[declareProvisioner](/reference/platform/taskcluster-queue/references/api#declareProvisioner)
+[declareProvisioner](/docs/reference/platform/taskcluster-queue/references/api#declareProvisioner)
 method, supplying a list of actions.
 
 An action is comprised with the following properties:
@@ -40,7 +40,7 @@ An action is comprised with the following properties:
 
 Note that the action endpoint should return early. In other words, if an action takes a while
 to finish, start it up and send the HTTP response. To notify a user with the action status,
-use [taskcluster-notify](https://docs.taskcluster.net/reference/core/taskcluster-notify).
+use [taskcluster-notify](/docs/reference/core/taskcluster-notify).
 
 
 ### Context
@@ -50,9 +50,9 @@ specific to a context will only be returned by the appropriate API method.
 
 | `context`     | API Method                                                                             |
 |---------------|----------------------------------------------------------------------------------------|
-| `provisioner` | [getProvisioner](/reference/platform/taskcluster-queue/references/api#getProvisioner)* |
-| `worker-type` | [getWorkerType](/reference/platform/taskcluster-queue/references/api#getWorkerType)    |
-| `worker`      | [getWorker](/reference/platform/taskcluster-queue/references/api#getWorker)            |
+| `provisioner` | [getProvisioner](/docs/reference/platform/taskcluster-queue/references/api#getProvisioner)* |
+| `worker-type` | [getWorkerType](/docs/reference/platform/taskcluster-queue/references/api#getWorkerType)    |
+| `worker`      | [getWorker](/docs/reference/platform/taskcluster-queue/references/api#getWorker)            |
 
 Note that all actions are declared at the provisioner level, regardless of
 context.  For symmetry, `getProvisioner` also returns all actions, not just
diff --git a/docs/worker-hierarchy.md b/docs/worker-hierarchy.md
index 41069947..36130bc4 100644
--- a/docs/worker-hierarchy.md
+++ b/docs/worker-hierarchy.md
@@ -7,7 +7,7 @@ The queue defines a hierarchy of resources that consume tasks from queues:
 
 ## Provisioners
 
-[Provisioners](/manual/task-execution/provisioning), identified with a
+[Provisioners](/docs/manual/task-execution/provisioning), identified with a
 `provisionerId`, are responsible for groups of worker types. While some
 provisioners, such as the AWS provisioner, are active software components,
 others are simply identifiers within the Queue service's data structures.  For
@@ -16,26 +16,26 @@ example, there is no active management of the
 `provisionerId`.
 
 Provisioners can be declared, and metadata associated with them, via the
-[declareProvisioner](/reference/platform/taskcluster-queue/references/api#declareProvisioner)
+[declareProvisioner](/docs/reference/platform/taskcluster-queue/references/api#declareProvisioner)
 API method.
 
 ## Worker Types
 
-[Worker Types](/manual/tasks/workertypes), identified by
+[Worker Types](/docs/manual/tasks/workertypes), identified by
 `provisionerId/workerType`, are nested under a single provisioner and gather
 interchangeable workers that can all perform the same work. Tasks are queued
 for a specific worker type, and workers claim work for a single worker type.
 
 Worker types can be declared, and metadata associated with them, via the
-[declareWorkerType](/reference/platform/taskcluster-queue/references/api#declareWorkerType)
+[declareWorkerType](/docs/reference/platform/taskcluster-queue/references/api#declareWorkerType)
 API method.
 
 ## Workers
 
-[Workers](/manual/task-execution/workers) are the entities that actually
+[Workers](/docs/manual/task-execution/workers) are the entities that actually
 perform work, and are identified by `workerGroup/workerId`. A worker claims and
 performs work from a single worker type.
 
 Workers can be declared, and metadata associated with them, via the
-[declareWorker](/reference/platform/taskcluster-queue/references/api#declareWorker)
+[declareWorker](/docs/reference/platform/taskcluster-queue/references/api#declareWorker)
 API method.
diff --git a/schemas/constants.yml b/schemas/constants.yml
index ede01aa1..27532530 100644
--- a/schemas/constants.yml
+++ b/schemas/constants.yml
@@ -121,7 +121,7 @@ action-description: |
   | worker-type | Workers Explorer               |
   | worker      | Worker Explorer                |
 
-  See [actions docs](https://docs.taskcluster.net/reference/platform/taskcluster-queue/docs/actions)
+  See [actions docs](/docs/reference/platform/taskcluster-queue/docs/actions)
   for more information.
 
 # Description of the url property in an action.
diff --git a/schemas/v1/actions.yml b/schemas/v1/actions.yml
index 544d2864..7eac8c09 100644
--- a/schemas/v1/actions.yml
+++ b/schemas/v1/actions.yml
@@ -1,7 +1,7 @@
 $schema:            http://json-schema.org/draft-06/schema#
 title:              "Actions"
 description: |
-  See taskcluster [actions](https://docs.taskcluster.net/reference/platform/taskcluster-queue/docs/actions) documentation.
+  See taskcluster [actions](/docs/reference/platform/taskcluster-queue/docs/actions) documentation.
 type:         array
 items:
   type:       object