Merge pull request #12024 from hashicorp/docs/update-links-to-avoid-redirects

docs: Avoid redirects by pointing links to new URLs

website/components/footer/index.jsx

@@ -8,7 +8,7 @@ export default function Footer({ openConsentManager }) {
           <Link href="/intro">
             <a>Intro</a>
           </Link>
-          <Link href="/guides">
+          <Link href="/docs/guides">
             <a>Guides</a>
           </Link>
           <Link href="/docs">

website/content/api-docs/acl/auth-methods.mdx

@@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl
 
 - `Type` `(string: <required>)` - The type of auth method being configured.
   This field is immutable. For allowed values see the [auth method
-  documentation](/docs/acl/auth-methods).
+  documentation](/docs/security/acl/auth-methods).
 
 - `Description` `(string: "")` - Free form human readable description of the
   auth method.
@@ -69,7 +69,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl
 - `Config` `(map[string]string: <required>)` - The raw configuration to use for
   the chosen auth method. Contents will vary depending upon the type chosen.
   For more information on configuring specific auth method types, see the [auth
-  method documentation](/docs/acl/auth-methods).
+  method documentation](/docs/security/acl/auth-methods).
 
 - `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace to
   create the auth method within. If not provided in the JSON body, the value of
@@ -252,7 +252,7 @@ The corresponding CLI command is [`consul acl auth-method update`](/commands/acl
 - `Config` `(map[string]string: <required>)` - The raw configuration to use for
   the chosen auth method. Contents will vary depending upon the type chosen.
   For more information on configuring specific auth method types, see the [auth
-  method documentation](/docs/acl/auth-methods).
+  method documentation](/docs/security/acl/auth-methods).
 
 - `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace of
   the auth method to update. If not provided in the JSON body, the value of

website/content/api-docs/acl/index.mdx

@@ -276,7 +276,7 @@ agent_prefix "" {
 ## Login to Auth Method
 
 This endpoint was added in Consul 1.5.0 and is used to exchange an [auth
-method](/docs/acl/auth-methods) bearer token for a newly-created
+method](/docs/security/acl/auth-methods) bearer token for a newly-created
 Consul ACL token.
 
 | Method | Path         | Produces           |
@@ -407,7 +407,7 @@ $ curl \
 </EnterpriseAlert>
 
 This endpoint was added in Consul 1.8.0 and is used to obtain an authorization
-URL from Consul to start an [OIDC login flow](/docs/acl/auth-methods/oidc).
+URL from Consul to start an [OIDC login flow](/docs/security/acl/auth-methods/oidc).
 
 | Method | Path                 | Produces           |
 | ------ | -------------------- | ------------------ |
@@ -433,10 +433,10 @@ replication enabled.
 ### Parameters
 
 - `AuthMethod` `(string: <required>)` - The name of the auth method to use for
-  login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc).
+  login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc).
 
 - `RedirectURI` `(string: <required>)` - See [Redirect
-  URIs](/docs/acl/auth-methods/oidc#redirect-uris) for more information.
+  URIs](/docs/security/acl/auth-methods/oidc#redirect-uris) for more information.
 
 - `ClientNonce` `(string: "")` - Optional client-provided nonce that must match
   during callback, if present.
@@ -513,7 +513,7 @@ replication enabled.
 ### Parameters
 
 - `AuthMethod` `(string: <required>)` - The name of the auth method to use for
-  login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc).
+  login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc).
 
 - `State` `(string: <required>)` - Opaque state ID that is part of the
   Authorization URL and will be included in the the redirect following

website/content/api-docs/acl/legacy.mdx

@@ -45,7 +45,7 @@ The table below shows this endpoint's support for
   are: `client` and `management`.
 
 - `Rules` `(string: "")` - Specifies rules for this ACL token. The format of the
-  `Rules` property is detailed in the [ACL Rule documentation](/docs/acl/acl-rules).
+  `Rules` property is detailed in the [ACL Rule documentation](/docs/security/acl/acl-rules).
 
 ### Sample Payload
 
@@ -296,4 +296,4 @@ $ curl \
 
 ## Check ACL Replication
 
-The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api/acl/acl#check-acl-replication) to learn more about this endpoint.
+The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api-docs/acl#check-acl-replication) to learn more about this endpoint.

website/content/api-docs/acl/policies.mdx

@@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl policy create`](/commands/acl/poli
 - `Description` `(string: "")` - Free form human readable description of the policy.
 
 - `Rules` `(string: "")` - Specifies rules for the ACL policy. The format of the
-  `Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules).
+  `Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules).
 
 - `Datacenters` `(array<string>)` - Specifies the datacenters the policy is valid within.
   When no datacenters are provided the policy is valid in all datacenters including
@@ -227,7 +227,7 @@ The corresponding CLI command is [`consul acl policy update`](/commands/acl/poli
 - `Description` `(string: "")` - Free form human readable description of this policy.
 
 - `Rules` `(string: "")` - Specifies rules for this ACL policy. The format of the
-  `Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules).
+  `Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules).
 
 - `Datacenters` `(array<string>)` - Specifies the datacenters this policy is valid within.
   When no datacenters are provided the policy is valid in all datacenters including

website/content/api-docs/acl/roles.mdx

@@ -50,7 +50,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c
   breaking tokens.
 
 - `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
-  identities](/docs/acl/acl-system#acl-service-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-service-identities) that should be
   applied to the role. Added in Consul 1.5.0.
 
   - `ServiceName` `(string: <required>)` - The name of the service. The name
@@ -64,7 +64,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c
     but may in the future.
 
 - `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
-  identities](/docs/acl/acl-system#acl-node-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-node-identities) that should be
   applied to the role. Added in Consul 1.8.1.
 
   - `NodeName` `(string: <required>)` - The name of the node. The name
@@ -339,11 +339,11 @@ The corresponding CLI command is [`consul acl role update`](/commands/acl/role/u
   breaking tokens.
 
 - `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
-  identities](/docs/acl/acl-system#acl-service-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-service-identities) that should be
   applied to the role. Added in Consul 1.5.0.
 
 - `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
-  identities](/docs/acl/acl-system#acl-node-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-node-identities) that should be
   applied to the role. Added in Consul 1.8.1.
 
 - `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace of

website/content/api-docs/acl/tokens.mdx

@@ -62,7 +62,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token
   enables role renaming without breaking tokens. Added in Consul 1.5.0.
 
 - `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
-  identities](/docs/acl/acl-system#acl-service-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-service-identities) that should be
   applied to the token. Added in Consul 1.5.0.
 
   - `ServiceName` `(string: <required>)` - The name of the service. The name
@@ -76,7 +76,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token
     but may in the future.
 
 - `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
-  identities](/docs/acl/acl-system#acl-node-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-node-identities) that should be
   applied to the token. Added in Consul 1.8.1.
 
   - `NodeName` `(string: <required>)` - The name of the node. The name
@@ -329,7 +329,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token
   enables role renaming without breaking tokens.
 
 - `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
-  identities](/docs/acl/acl-system#acl-service-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-service-identities) that should be
   applied to the token. Added in Consul 1.5.0.
 
   - `ServiceName` `(string: <required>)` - The name of the service. The name
@@ -343,7 +343,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token
     but may in the future.
 
 - `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
-  identities](/docs/acl/acl-system#acl-node-identities) that should be
+  identities](/docs/security/acl/acl-system#acl-node-identities) that should be
   applied to the token. Added in Consul 1.8.1.
 
   - `NodeName` `(string: <required>)` - The name of the node. The name

website/content/api-docs/agent/check.mdx

@@ -18,7 +18,7 @@ using the HTTP API.
 It is important to note that the checks known by the agent may be different from
 those reported by the catalog. This is usually due to changes being made while
 there is no leader elected. The agent performs active
-[anti-entropy](/docs/internals/anti-entropy), so in most situations
+[anti-entropy](/docs/architecture/anti-entropy), so in most situations
 everything will be in sync within a few seconds.
 
 | Method | Path            | Produces           |

website/content/api-docs/agent/index.mdx

@@ -12,7 +12,7 @@ The `/agent` endpoints are used to interact with the local Consul agent.
 Usually, services and checks are registered with an agent which then takes on
 the burden of keeping that data synchronized with the cluster. For example, the
 agent registers services and checks with the Catalog and performs
-[anti-entropy](/docs/internals/anti-entropy) to recover from outages.
+[anti-entropy](/docs/architecture/anti-entropy) to recover from outages.
 
 In addition to these endpoints, additional endpoints are grouped in the
 navigation for `Checks` and `Services`.

website/content/api-docs/agent/service.mdx

@@ -20,7 +20,7 @@ or added dynamically using the HTTP API.
 It is important to note that the services known by the agent may be different
 from those reported by the catalog. This is usually due to changes being made
 while there is no leader elected. The agent performs active
-[anti-entropy](/docs/internals/anti-entropy), so in most situations
+[anti-entropy](/docs/architecture/anti-entropy), so in most situations
 everything will be in sync within a few seconds.
 
 | Method | Path              | Produces           |
@@ -137,7 +137,7 @@ configuration that was registered with the instance.
 It is important to note that the services known by the agent may be different
 from those reported by the catalog. This is usually due to changes being made
 while there is no leader elected. The agent performs active
-[anti-entropy](/docs/internals/anti-entropy), so in most situations
+[anti-entropy](/docs/architecture/anti-entropy), so in most situations
 everything will be in sync within a few seconds.
 
 | Method | Path                         | Produces           |
@@ -231,7 +231,7 @@ $ curl \
 ```
 
 The response has the same structure as the [service
-definition](/docs/agent/services) with one extra field `ContentHash` which
+definition](/docs/discovery/services) with one extra field `ContentHash` which
 contains the [hash-based blocking
 query](/api/features/blocking#hash-based-blocking-queries) hash for the result. The
 same hash is also present in `X-Consul-ContentHash`.
@@ -601,13 +601,13 @@ The corresponding CLI command is [`consul services register`](/commands/services
 
 ### Parameters
 
-Note that this endpoint, unlike most also [supports `snake_case`](/docs/agent/services#service-definition-parameter-case)
+Note that this endpoint, unlike most also [supports `snake_case`](/docs/discovery/services#service-definition-parameter-case)
 service definition keys for compatibility with the config file format.
 
 - `Name` `(string: <required>)` - Specifies the logical name of the service.
   Many service instances may share the same logical service name. We recommend using
   [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns).
+  for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns).
 
 - `ID` `(string: "")` - Specifies a unique ID for this service. This must be
   unique per _agent_. This defaults to the `Name` parameter if not provided.
@@ -615,7 +615,7 @@ service definition keys for compatibility with the config file format.
 - `Tags` `(array<string>: nil)` - Specifies a list of tags to assign to the
   service. These tags can be used for later filtering and are exposed via the APIs.
   We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns)
+  for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns)
 
 - `Address` `(string: "")` - Specifies the address of the service. If not
   provided, the agent's address is used as the address for the service during
@@ -639,9 +639,9 @@ service definition keys for compatibility with the config file format.
 - `Kind` `(string: "")` - The kind of service. Defaults to "" which is a
   typical Consul service. This value may also be "connect-proxy" for
   [Connect](/docs/connect) proxies representing another service,
-  "mesh-gateway" for instances of a [mesh gateway](/docs/connect/mesh-gateway),
+  "mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters),
-  "terminating-gateway" for instances of a [terminating gateway](/docs/connect/terminating-gateway),
+  "terminating-gateway" for instances of a [terminating gateway](/docs/connect/gateways/terminating-gateway),
-  or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/ingress-gateway).
+  or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/gateways/ingress-gateway).
 
 - `Proxy` `(Proxy: nil)` - From 1.2.3 on, specifies the configuration for a
   Connect service proxy instance. This is only valid if `Kind` defines a proxy or gateway.
@@ -681,7 +681,7 @@ service definition keys for compatibility with the config file format.
   modifications would be lost.
 
 - `Weights` `(Weights: nil)` - Specifies weights for the service. Please see the
-  [service documentation](/docs/agent/services) for more information about
+  [service documentation](/docs/discovery/services) for more information about
   weights. If this field is not provided weights will default to
   `{"Passing": 1, "Warning": 1}`.
 
@@ -691,7 +691,7 @@ service definition keys for compatibility with the config file format.
   are independent of one another. Updating the tags for the service registered
   on one node is independent of the same service (by name) registered on
   another node. If `EnableTagOverride` is not specified the default value is
-  `false`. See [anti-entropy syncs](/docs/internals/anti-entropy) for
+  `false`. See [anti-entropy syncs](/docs/architecture/anti-entropy) for
   more info.
 
 #### Connect Structure

website/content/api-docs/catalog.mdx

@@ -17,7 +17,7 @@ API methods look similar.
 This endpoint is a low-level mechanism for registering or updating
 entries in the catalog. It is usually preferable to instead use the
 [agent endpoints](/api/agent) for registration as they are simpler and
-perform [anti-entropy](/docs/internals/anti-entropy).
+perform [anti-entropy](/docs/architecture/anti-entropy).
 
 | Method | Path                | Produces           |
 | ------ | ------------------- | ------------------ |
@@ -54,7 +54,7 @@ The table below shows this endpoint's support for
   provided, it will be defaulted to the value of the `Service.Service` property.
   Only one service with a given `ID` may be present per node. We recommend using
   [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
-  for service definition names for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns).
+  for service definition names for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns).
   The service `Tags`, `Address`, `Meta`, and `Port` fields are all optional. For more
   information about these fields and the implications of setting them,
   see the [Service - Agent API](/api/agent/service) page
@@ -74,7 +74,7 @@ The table below shows this endpoint's support for
   check. The `Status` must be one of `passing`, `warning`, or `critical`.
 
   The `Definition` field can be provided with details for a TCP or HTTP health
-  check. For more information, see the [Health Checks](/docs/agent/checks) page.
+  check. For more information, see the [Health Checks](/docs/discovery/checks) page.
 
   Multiple checks can be provided by replacing `Check` with `Checks` and
   sending an array of `Check` objects.
@@ -168,7 +168,7 @@ $ curl \
 This endpoint is a low-level mechanism for directly removing
 entries from the Catalog. It is usually preferable to instead use the
 [agent endpoints](/api/agent) for deregistration as they are simpler and
-perform [anti-entropy](/docs/internals/anti-entropy).
+perform [anti-entropy](/docs/architecture/anti-entropy).
 
 | Method | Path                  | Produces           |
 | ------ | --------------------- | ------------------ |

website/content/api-docs/coordinate.mdx

@@ -13,7 +13,7 @@ The `/coordinate` endpoints query for the network coordinates for nodes in the
 local datacenter as well as Consul servers in the local datacenter and remote
 datacenters.
 
-Please see the [Network Coordinates](/docs/internals/coordinates) internals
+Please see the [Network Coordinates](/docs/architecture/coordinates) internals
 guide for more information on how these coordinates are computed, and for
 details on how to perform calculations with them.
 

website/content/api-docs/discovery-chain.mdx

@@ -13,13 +13,13 @@ description: The /discovery-chain endpoints are for interacting with the discove
 high-level proxy integration APIs may obviate the need for this API over time.
 
 The `/discovery-chain` endpoint returns the compiled [discovery
-chain](/docs/internals/discovery-chain) for a service.
+chain](/docs/connect/l7-traffic/discovery-chain) for a service.
 
 This will fetch all related [configuration
 entries](/docs/agent/config-entries) and render them into a form suitable
 for use by a [connect proxy](/docs/connect/proxies) implementation. This
 is a key component of [L7 Traffic
-Management](/docs/connect/l7-traffic-management).
+Management](/docs/connect/l7-traffic).
 
 ## Read Compiled Discovery Chain
 
@@ -95,7 +95,7 @@ The table below shows this endpoint's support for
   parameter.
 
 - `OverrideMeshGateway` `(MeshGatewayConfig: <optional>)` - Overrides the final
-  [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+  [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
   for this any service resolved in the compiled chain.
 
   This value comes from either the [proxy
@@ -111,7 +111,7 @@ The table below shows this endpoint's support for
 ### Sample Compilations
 
 Full documentation for the output fields is found on the [discovery chain
-internals](/docs/internals/discovery-chain#compileddiscoverychain)
+internals](/docs/connect/l7-traffic/discovery-chain#compileddiscoverychain)
 page.
 
 #### Multi-Datacenter Failover

website/content/api-docs/event.mdx

@@ -90,7 +90,7 @@ $ curl \
 This endpoint returns the most recent events (up to 256) known by the agent. As a
 consequence of how the [event command](/commands/event) works, each
 agent may have a different view of the events. Events are broadcast using the
-[gossip protocol](/docs/internals/gossip), so they have no global ordering
+[gossip protocol](/docs/architecture/gossip), so they have no global ordering
 nor do they make a promise of delivery.
 
 | Method | Path          | Produces           |
@@ -150,7 +150,7 @@ $ curl \
 The semantics of this endpoint's blocking queries are slightly different. Most
 blocking queries provide a monotonic index and block until a newer index is
 available. This can be supported as a consequence of the total ordering of the
-[consensus protocol](/docs/internals/consensus). With gossip, there is no
+[consensus protocol](/docs/architecture/consensus). With gossip, there is no
 ordering, and instead `X-Consul-Index` maps to the newest event that matches the
 query.
 

website/content/api-docs/health.mdx

@@ -421,7 +421,7 @@ Parameters and response format are the same as
 -> **1.8.0+:** This API is available in Consul versions 1.8.0 and later.
 
 This endpoint returns the service instances providing an [ingress
-gateway](/docs/connect/ingress-gateway) for a service in a given datacenter.
+gateway](/docs/connect/gateways/ingress-gateway) for a service in a given datacenter.
 
 | Method | Path                       | Produces           |
 | ------ | -------------------------- | ------------------ |

website/content/api-docs/index.mdx

@@ -40,7 +40,7 @@ Previously this was provided via a `?token=` query parameter. This functionality
 exists on many endpoints for backwards compatibility, but its use is **highly
 discouraged**, since it can show up in access logs as part of the URL.
 
-To learn more about the ACL system read the [documentation](/docs/acl/acl-system).
+To learn more about the ACL system read the [documentation](/docs/security/acl/acl-system).
 
 ## Version Prefix
 

website/content/api-docs/operator/area.mdx

@@ -425,4 +425,4 @@ $ curl \
 
 - `RTT` is an estimated network round trip time from the server answering the
   query to the given server, in nanoseconds. This is computed using [network
-  coordinates](/docs/internals/coordinates).
+  coordinates](/docs/architecture/coordinates).

website/content/api-docs/operator/index.mdx

@@ -14,7 +14,7 @@ operations manually, please check the documentation for the
 [`consul operator`](/commands/operator) command.
 
 If ACLs are enabled then a token with operator privileges may be required in
-order to use this interface. Check the [ACL Rules documentation](/docs/acl/acl-rules#operator-rules)
+order to use this interface. Check the [ACL Rules documentation](/docs/security/acl/acl-rules#operator-rules)
 for more information.
 
 Check the [Outage Recovery](https://learn.hashicorp.com/tutorials/consul/recovery-outage) tutorial for some examples of

website/content/api-docs/operator/keyring.mdx

@@ -9,7 +9,7 @@ description: |-
 # Keyring Operator HTTP API
 
 The `/operator/keyring` endpoints allow for management of the gossip encryption
-keyring. Please see the [Gossip Protocol Guide](/docs/internals/gossip) for
+keyring. Please see the [Gossip Protocol Guide](/docs/architecture/gossip) for
 more details on the gossip protocol and its use.
 
 ## List Gossip Encryption Keys
@@ -122,7 +122,7 @@ The table below shows this endpoint's support for
 | ---------------- | ----------------- | ------------- | --------------- |
 | `NO`             | `none`            | `none`        | `keyring:write` |
 
-The corresponding CLI command is [`consul keyring -intstall`](/commands/keyring#install).
+The corresponding CLI command is [`consul keyring -install`](/commands/keyring#install).
 
 ### Parameters
 

website/content/api-docs/operator/raft.mdx

@@ -11,7 +11,7 @@ description: |-
 The `/operator/raft` endpoints provide tools for management of Raft the
 consensus subsystem and cluster quorum.
 
-Please see the [Consensus Protocol Guide](/docs/internals/consensus) for
+Please see the [Consensus Protocol Guide](/docs/architecture/consensus) for
 more information about Raft consensus protocol and its use.
 
 ## Read Configuration

website/content/api-docs/query.mdx

@@ -17,7 +17,7 @@ would be possible given the limited entry points exposed by DNS.
 Check the [Geo Failover tutorial](https://learn.hashicorp.com/tutorials/consul/automate-geo-failover) for details and
 examples for using prepared queries to implement geo failover for services.
 
-Check the [prepared query rules](/docs/agent/acl-rules#prepared-query-rules)
+Check the [prepared query rules](/docs/security/acl/acl-rules#prepared-query-rules)
 section of the agent ACL documentation for more details about how prepared
 queries work with Consul's ACL system.
 
@@ -187,7 +187,7 @@ The table below shows this endpoint's support for
 
     - `NearestN` `(int: 0)` - Specifies that the query will be forwarded to up
       to `NearestN` other datacenters based on their estimated network round
-      trip time using [Network Coordinates](/docs/internals/coordinates)
+      trip time using [Network Coordinates](/docs/architecture/coordinates)
       from the WAN gossip pool. The median round trip time from the server
       handling the query to the servers in the remote datacenter is used to
       determine the priority.
@@ -214,7 +214,7 @@ The table below shows this endpoint's support for
     true, only nodes with checks in the passing state will be returned.
 
   - `Near` `(string: "")` - Specifies a node to sort near based on distance
-    sorting using [Network Coordinates](/docs/internals/coordinates). The
+    sorting using [Network Coordinates](/docs/architecture/coordinates). The
     nearest instance to the specified node will be returned first, and subsequent
     nodes in the response will be sorted in ascending order of estimated
     round-trip times. If the node given does not exist, the nodes in the response

website/content/api-docs/snapshot.mdx

@@ -10,7 +10,7 @@ description: |-
 
 The `/snapshot` endpoints save and restore the state of the Consul
 servers for disaster recovery. Snapshots include all state managed by Consul's
-Raft [consensus protocol](/docs/internals/consensus).
+Raft [consensus protocol](/docs/architecture/consensus).
 
 ## Generate Snapshot
 

website/content/commands/acl/index.mdx

@@ -12,7 +12,7 @@ line. It exposes top-level commands for bootstrapping the ACL system,
 managing tokens and policies, translating legacy rules, and setting the
 tokens for use by an agent.
 
-ACLs are also accessible via the [HTTP API](/api/acl/acl).
+ACLs are also accessible via the [HTTP API](/api-docs/acl).
 
 Bootstrap Consul's ACLs:
 

website/content/commands/agent.mdx

@@ -14,6 +14,6 @@ performs the important task of maintaining membership information,
 running checks, announcing services, handling queries, etc.
 
 Due to the power and flexibility of this command, the Consul agent
-is documented in its own section. See the [Consul Agent](/docs/agent/basics)
+is documented in its own section. See the [Consul Agent](/docs/agent)
 section for more information on how to use this command and the
 options it has.

website/content/commands/connect/expose.mdx

@@ -14,7 +14,7 @@ Command: `consul connect expose`
 The connect expose subcommand is used to expose a Connect-enabled service
 through an Ingress gateway by modifying the gateway's configuration and adding
 an intention to allow traffic from the gateway to the service. See the
-[Ingress gateway documentation](/docs/connect/ingress-gateway) for more information
+[Ingress gateway documentation](/docs/connect/gateways/ingress-gateway) for more information
 about Ingress gateways.
 
 ```text

website/content/commands/event.mdx

@@ -19,14 +19,14 @@ The `event` command provides a mechanism to fire a custom user event to an
 entire datacenter. These events are opaque to Consul, but they can be used
 to build scripting infrastructure to do automated deploys, restart services,
 or perform any other orchestration action. Events can be handled by
-[using a watch](/docs/agent/watches).
+[using a watch](/docs/dynamic-app-config/watches).
 
-Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip).
+Under the hood, events are propagated using the [gossip protocol](/docs/architecture/gossip).
 
 While the details are not important for using events, an understanding of
 the semantics is useful. The gossip layer will make a best-effort to deliver
 the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is
-replicated using [consensus](/docs/internals/consensus), event data
+replicated using [consensus](/docs/architecture/consensus), event data
 is purely peer-to-peer over gossip. This means it is not persisted and does
 not have a total ordering. In practice, this means you cannot rely on the
 order of message delivery. An advantage however is that events can still

website/content/commands/exec.mdx

@@ -17,7 +17,7 @@ the `web` service.
 
 Remote execution works by specifying a job, which is stored in the KV store.
 Agents are informed about the new job using the [event system](/commands/event),
-which propagates messages via the [gossip protocol](/docs/internals/gossip).
+which propagates messages via the [gossip protocol](/docs/architecture/gossip).
 As a result, delivery is best-effort, and there is **no guarantee** of execution.
 
 While events are purely gossip driven, remote execution relies on the KV store

website/content/commands/index.mdx

@@ -239,7 +239,7 @@ CONSUL_GRPC_ADDR=unix://var/run/consul_grpc.sock
 ```
 
 If the agent is [configured with TLS
-certificates](/docs/agent/encryption#rpc-encryption-with-tls), then the
+certificates](/docs/security/encryption#rpc-encryption-with-tls), then the
 gRPC listener will require TLS and present the same certificate as the https
 listener. As with `CONSUL_HTTP_ADDR`, if TLS is enabled either the `https://`
 scheme should be used, or `CONSUL_HTTP_SSL` set.

website/content/commands/info.mdx

@@ -19,9 +19,9 @@ There are currently the top-level keys for:
 
 - agent: Provides information about the agent
 - consul: Information about the consul library (client or server)
-- raft: Provides info about the Raft [consensus library](/docs/internals/consensus)
+- raft: Provides info about the Raft [consensus library](/docs/architecture/consensus)
-- serf_lan: Provides info about the LAN [gossip pool](/docs/internals/gossip)
+- serf_lan: Provides info about the LAN [gossip pool](/docs/architecture/gossip)
-- serf_wan: Provides info about the WAN [gossip pool](/docs/internals/gossip)
+- serf_wan: Provides info about the WAN [gossip pool](/docs/architecture/gossip)
 
 Here is an example output:
 

website/content/commands/keygen.mdx

@@ -12,6 +12,6 @@ description: >-
 Command: `consul keygen`
 
 The `keygen` command generates an encryption key that can be used for
-[Consul agent traffic encryption](/docs/agent/encryption).
+[Consul agent traffic encryption](/docs/security/encryption).
 The keygen command uses a cryptographically
 strong pseudo-random number generator to generate the key.

website/content/commands/keyring.mdx

@@ -10,7 +10,7 @@ Command: `consul keyring`
 Corresponding HTTP API Endpoints: [\[VARIES\] /v1/operator/keyring](/api-docs/operator/keyring)
 
 The `keyring` command is used to examine and modify the encryption keys used in
-Consul's [Gossip Pools](/docs/internals/gossip). It is capable of
+Consul's [Gossip Pools](/docs/architecture/gossip). It is capable of
 distributing new encryption keys to the cluster, retiring old encryption keys,
 and changing the keys used by the cluster to encrypt messages.
 

website/content/commands/kv/put.mdx

@@ -133,7 +133,7 @@ Success! Data written to: leaderboard/scores
 
 ~> **Warning**: For secret and sensitive values, you should consider using a
 secret management solution like **[HashiCorp's Vault](https://learn.hashicorp.com/tutorials/vault/static-secrets?in=vault/secrets-management)**.
-While it is possible to encrpyt data before writing it to Consul's KV store,
+While it is possible to encrypt data before writing it to Consul's KV store,
 Consul provides no built-in support for encryption at-rest.
 
 ### Atomic Check-And-Set (CAS)

website/content/commands/operator/area.mdx

@@ -269,7 +269,7 @@ spoken by the node.
 
 `RTT` is an estimated network round trip time from the server answering the query
 to the given server, in a human-readable format. This is computed using
-[network coordinates](/docs/internals/coordinates).
+[network coordinates](/docs/architecture/coordinates).
 
 The return code will indicate success or failure.
 

website/content/commands/rtt.mdx

@@ -14,7 +14,7 @@ Corresponding HTTP API Endpoints: [\[GET\] /v1/coordinate/datacenters](/api-docs
 The `rtt` command estimates the network round trip time between two nodes using
 Consul's network coordinate model of the cluster.
 
-See the [Network Coordinates](/docs/internals/coordinates) internals guide
+See the [Network Coordinates](/docs/architecture/coordinates) internals guide
 for more information on how these coordinates are computed.
 
 The table below shows this command's [required ACLs](/api#authentication). Configuration of

website/content/commands/services/deregister.mdx

@@ -17,7 +17,7 @@ be paired with `services register`.
 This is just one method for service deregistration. If the service was
 registered with a configuration file, then deleting that file and
 [reloading](/commands/reload) Consul is the correct method to
-deregister. See [Service Definition](/docs/agent/services) for more
+deregister. See [Service Definition](/docs/discovery/services) for more
 information about registering services generally.
 
 The table below shows this command's [required ACLs](/api#authentication). Configuration of

website/content/commands/services/index.mdx

@@ -8,7 +8,7 @@ page_title: 'Commands: Services'
 Command: `consul services`
 
 The `services` command has subcommands for interacting with Consul services
-registered with the [local agent](/docs/agent/basics). These provide
+registered with the [local agent](/docs/agent). These provide
 useful commands such as `register` and `deregister` for easily registering
 services in scripts, dev mode, etc.
 To view all services in the catalog, instead of only agent-local services,

website/content/commands/services/register.mdx

@@ -15,7 +15,7 @@ service deregistration. This command simplifies service registration from
 scripts, in dev mode, etc.
 
 This is just one method of service registration. Services can also be
-registered by placing a [service definition](/docs/agent/services)
+registered by placing a [service definition](/docs/discovery/services)
 in the Consul agent configuration directory and issuing a
 [reload](/commands/reload). This approach is easiest for
 configuration management systems that other systems that have access to
@@ -74,7 +74,7 @@ arguments are given, the flags below can be used to register a single
 service.
 
 Note that the behavior of each of the fields below is exactly the same
-as when constructing a standard [service definition](/docs/agent/services).
+as when constructing a standard [service definition](/docs/discovery/services).
 Please refer to that documentation for full details.
 
 - `-id` - The ID of the service. This will default to `-name` if not set.

website/content/commands/watch.mdx

@@ -19,7 +19,7 @@ a process with the latest values of the view. If no process is specified,
 the current values are dumped to STDOUT which can be a useful way to inspect
 data in Consul.
 
-There is more [documentation on watches here](/docs/agent/watches).
+There is more [documentation on watches here](/docs/dynamic-app-config/watches).
 
 ## Usage
 
@@ -28,7 +28,7 @@ Usage: `consul watch [options] [child...]`
 The only required option is `-type` which specifies the particular
 data view. Depending on the type, various options may be required
 or optionally provided. There is more documentation on watch
-[specifications here](/docs/agent/watches).
+[specifications here](/docs/dynamic-app-config/watches).
 
 #### API Options
 

website/content/docs/agent/index.mdx

@@ -17,7 +17,7 @@ Agents run in either client or server mode. Client nodes are lightweight process
 They interface with the server nodes for most operations and maintain very little state of their own.
 Clients run on every node where services are running.
 
-In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/internals/consensus).
+In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/architecture/consensus).
 The quorum is based on the Raft protocol, which provides strong consistency and availability in the case of failure.
 Server nodes should run on dedicated instances because they are more resource intensive than client nodes.
 
@@ -46,7 +46,7 @@ As a result, agent crashes are handled in the same manner is network failures.
 Once a node is marked as failed, this information is updated in the service
 catalog.
 
--> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/internals/consensus).
+-> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/architecture/consensus).
 Once the network recovers or a crashed agent restarts, the cluster will repair itself and unmark a node as failed.
 The health check in the catalog will also be updated to reflect the current state.
 

website/content/docs/agent/options.mdx

@@ -49,7 +49,7 @@ Environment variables **cannot** be used to configure the Consul client. They
 _can_ be used when running other `consul` CLI commands that connect with a
 running agent, e.g. `CONSUL_HTTP_ADDR=192.168.0.1:8500 consul members`.
 
-See [Consul Commands](/docs/commands#environment-variables) for more
+See [Consul Commands](/commands#environment-variables) for more
 information.
 
 ## Command-line Options ((#commandline_options))
@@ -260,7 +260,7 @@ The options below are all specified on the command-line.
   PTR query responses will always use `-domain`, since the desired domain cannot be included in the query.
 
 - `-enable-script-checks` ((#\_enable_script_checks)) This controls whether
-  [health checks that execute scripts](/docs/agent/checks) are enabled on this
+  [health checks that execute scripts](/docs/discovery/checks) are enabled on this
   agent, and defaults to `false` so operators must opt-in to allowing these. This
   was added in Consul 0.9.0.
 
@@ -414,7 +414,7 @@ The options below are all specified on the command-line.
   As of Consul 0.9.1, `retry-join` accepts a unified interface using the
   [go-discover](https://github.com/hashicorp/go-discover) library for doing
   automatic cluster joining using cloud metadata. For more information, see
-  the [Cloud Auto-join page](/docs/agent/cloud-auto-join).
+  the [Cloud Auto-join page](/docs/install/cloud-auto-join).
 
   <CodeBlockConfig heading="Using Cloud Auto-Joining">
 
@@ -506,7 +506,7 @@ The options below are all specified on the command-line.
 
 - `-raft-protocol` ((#\_raft_protocol)) - This controls the internal version
   of the Raft consensus protocol used for server communications. This must be set
-  to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrade-specific#raft-protocol-version-compatibility) for more details.
+  to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details.
 
 - `-recursor` ((#\_recursor)) - Specifies the address of an upstream DNS
   server. This option may be provided multiple times, and is functionally equivalent
@@ -686,7 +686,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
     leader node, the down policy is applied. In "allow" mode, all actions are permitted,
     "deny" restricts all operations, and "extend-cache" allows any cached objects
     to be used, ignoring the expiry time of the cached entry. If the request uses an
-    ACL that is not in the cache, "extend-cache" falls back to the behaviour of
+    ACL that is not in the cache, "extend-cache" falls back to the behavior of
     `default_policy`.
     The value "async-cache" acts the same way as "extend-cache"
     but performs updates asynchronously when ACL is present but its TTL is expired,
@@ -710,7 +710,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
     secondary Consul datacenters will perform replication of only ACL policies and
     roles. Setting this configuration will will enable ACL token replication and
     allow for the creation of both [local tokens](/api/acl/tokens#local) and
-    [auth methods](/docs/acl/auth-methods) in connected secondary datacenters.
+    [auth methods](/docs/security/acl/auth-methods) in connected secondary datacenters.
 
     ~> **Warning:** When enabling ACL token replication on the secondary datacenter,
     global tokens already present in the secondary datacenter will be lost. For
@@ -1102,7 +1102,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
 
     - `static` This object controls configuring the static authorizer setup in the Consul
       configuration file. Almost all sub-keys are identical to those provided by the [JWT
-      Auth Method](/docs/acl/auth-methods/jwt).
+      Auth Method](/docs/security/acl/auth-methods/jwt).
 
       - `jwt_validation_pub_keys` (Defaults to `[]`) A list of PEM-encoded public keys
         to use to authenticate signatures locally.
@@ -1634,13 +1634,13 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
 - `encrypt_verify_incoming` - This is an optional
   parameter that can be used to disable enforcing encryption for incoming gossip
   in order to upshift from unencrypted to encrypted gossip on a running cluster.
-  See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster)
+  See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster)
   for more information. Defaults to true.
 
 - `encrypt_verify_outgoing` - This is an optional
   parameter that can be used to disable enforcing encryption for outgoing gossip
   in order to upshift from unencrypted to encrypted gossip on a running cluster.
-  See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster)
+  See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster)
   for more information. Defaults to true.
 
 - `disable_keyring_file` - Equivalent to the
@@ -2068,7 +2068,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
 
 - `read_replica` - Equivalent to the [`-read-replica` command-line flag](#_read_replica).
 
-- `session_ttl_min` The minimum allowed session TTL. This ensures sessions are not created with TTL's
+- `session_ttl_min` The minimum allowed session TTL. This ensures sessions are not created with TTLs
   shorter than the specified limit. It is recommended to keep this limit at or above
   the default to encourage clients to send infrequent heartbeats. Defaults to 10s.
 
@@ -2423,7 +2423,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
 
 - `watches` - Watches is a list of watch specifications which
   allow an external process to be automatically invoked when a particular data view
-  is updated. See the [watch documentation](/docs/agent/watches) for more detail.
+  is updated. See the [watch documentation](/docs/dynamic-app-config/watches) for more detail.
   Watches can be modified when the configuration is reloaded.
 
 ## TLS Configuration Reference

website/content/docs/agent/sentinel.mdx

@@ -19,7 +19,7 @@ policies to support full conditional logic and integration with external systems
 
 Sentinel policies are applied during writes to the KV Store.
 
-An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/agent/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1".
+An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/security/acl/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1".
 
 <CodeBlockConfig heading="Ensure values written during KV updates end in 'dc1'">
 

website/content/docs/architecture/anti-entropy.mdx

@@ -26,7 +26,7 @@ health checks and updating their local state.
 Services and checks within the context of an agent have a rich set of
 configuration options available. This is because the agent is responsible for
 generating information about its services and their health through the use of
-[health checks](/docs/agent/checks).
+[health checks](/docs/discovery/checks).
 
 #### Catalog
 
@@ -43,7 +43,7 @@ responsible for recording and returning information _about_ services, nodes, and
 health.
 
 The catalog is maintained only by server nodes. This is because the catalog is
-replicated via the [Raft log](/docs/internals/consensus) to provide a
+replicated via the [Raft log](/docs/architecture/consensus) to provide a
 consolidated and consistent view of the cluster.
 
 ### Anti-Entropy
@@ -118,7 +118,7 @@ database and its monitoring service Redis Sentinel have this kind of
 relationship. Redis instances are responsible for much of their
 configuration, but Sentinels determine whether the Redis instance is a
 primary or a secondary. Using the Consul service configuration item
-[enable_tag_override](/docs/agent/services) you can instruct the
+[enable_tag_override](/docs/discovery/services) you can instruct the
 Consul agent on which the Redis database is running to NOT update the
 tags during anti-entropy synchronization. For more information see
-[Services](/docs/agent/services#enable-tag-override-and-anti-entropy) page.
+[Services](/docs/discovery/services#enable-tag-override-and-anti-entropy) page.

website/content/docs/architecture/index.mdx

@@ -14,7 +14,7 @@ users and developers of Consul form a mental model of how it works, this
 page documents the system architecture.
 
 -> Before describing the architecture, we recommend reading the
-[glossary](/docs/glossary) of terms to help
+[glossary](/docs/install/glossary) of terms to help
 clarify what is being discussed.
 
 The architecture concepts in this document can be used with the [Reference Architecture guide](https://learn.hashicorp.com/tutorials/consul/reference-architecture?utm_source=consul.io&utm_medium=docs) when deploying Consul in production.
@@ -36,7 +36,7 @@ availability in the case of failure and performance, as consensus gets progressi
 slower as more machines are added. However, there is no limit to the number of clients,
 and they can easily scale into the thousands or tens of thousands.
 
-All the agents that are in a datacenter participate in a [gossip protocol](/docs/internals/gossip).
+All the agents that are in a datacenter participate in a [gossip protocol](/docs/architecture/gossip).
 This means there is a gossip pool that contains all the agents for a given datacenter. This serves
 a few purposes: first, there is no need to configure clients with the addresses of servers;
 discovery is done automatically. Second, the work of detecting agent failures
@@ -47,7 +47,7 @@ when important events such as leader election take place.
 The servers in each datacenter are all part of a single Raft peer set. This means that
 they work together to elect a single leader, a selected server which has extra duties. The leader
 is responsible for processing all queries and transactions. Transactions must also be replicated to
-all peers as part of the [consensus protocol](/docs/internals/consensus). Because of this
+all peers as part of the [consensus protocol](/docs/architecture/consensus). Because of this
 requirement, when a non-leader server receives an RPC request, it forwards it to the cluster leader.
 
 The server agents also operate as part of a WAN gossip pool. This pool is different from the LAN pool
@@ -82,8 +82,8 @@ disrupted or the servers are temporarily unavailable.
 ## Getting in depth
 
 At this point we've covered the high level architecture of Consul, but there are many
-more details for each of the subsystems. The [consensus protocol](/docs/internals/consensus) is
+more details for each of the subsystems. The [consensus protocol](/docs/architecture/consensus) is
-documented in detail as is the [gossip protocol](/docs/internals/gossip). The [documentation](/docs/internals/security)
+documented in detail as is the [gossip protocol](/docs/architecture/gossip). The [documentation](/docs/security)
 for the security model and protocols used are also available.
 
 For other details, either consult the code, ask in IRC, or reach out to the mailing list.

website/content/docs/connect/config-entries/ingress-gateway.mdx

@@ -1038,7 +1038,7 @@ You can specify the following parameters to configure ingress gateway configurat
               type: 'string: ""',
               description: `The name of the service that should be exposed
                                   through this listener. This can be either a service registered in the
-                                  catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic-management). If the wildcard specifier,
+                                  catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic). If the wildcard specifier,
                                   \`*\`, is provided, then ALL services will be exposed through the listener.
                                   This is not supported for listeners with protocol \`tcp\`.`,
             },

website/content/docs/connect/config-entries/mesh.mdx

@@ -98,7 +98,7 @@ spec:
 </Tab>
 </Tabs>
 
-Note that the Kuberetes example does not include a `partition` field. Configuration entries are applied on Kubernetes using [custom resource definitions (CRD)](/docs/k8s/crds), which can only be scoped to their own partition.
+Note that the Kubernetes example does not include a `partition` field. Configuration entries are applied on Kubernetes using [custom resource definitions (CRD)](/docs/k8s/crds), which can only be scoped to their own partition.
 
 ## Available Fields
 

website/content/docs/connect/config-entries/proxy-defaults.mdx

@@ -285,7 +285,7 @@ spec:
       name: 'MeshGateway',
       type: 'MeshGatewayConfig: <optional>',
       description: `Controls the default
-      [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+      [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
       for all proxies. Added in v1.6.0.`,
       children: [
         {

website/content/docs/connect/config-entries/service-defaults.mdx

@@ -359,7 +359,7 @@ spec:
                     [\`service-defaults\`](/docs/connect/config-entries/service-defaults)
                     config entry for the upstream destination service. Configuring it in a
                     proxy upstream config will not fully enable some
-                    [L7 features](/docs/connect/l7-traffic-management).
+                    [L7 features](/docs/connect/l7-traffic).
                     It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                   `,
             },
@@ -374,7 +374,7 @@ spec:
                       [\`service-resolver\`](/docs/connect/config-entries/service-resolver)
                       config entry for the upstream destination service.
                       Configuring it in a proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                     `,
                 yaml: `The number of milliseconds to allow when making upstream connections before timing out.<br><br>
@@ -384,7 +384,7 @@ spec:
                       [\`ServiceResolver\`](/docs/connect/config-entries/service-resolver)
                       CRD for the upstream destination service.
                       Configuring it in a proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                 `,
               },
@@ -393,8 +393,8 @@ spec:
               name: 'MeshGateway',
               type: 'MeshGatewayConfig: <optional>',
               description: `Controls the default
-                  [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+                [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
-                  for this upstream.`,
+                for this upstream.`,
               children: [
                 {
                   name: 'Mode',
@@ -480,7 +480,7 @@ spec:
                       [\`service-defaults\`](/docs/connect/config-entries/service-defaults)
                       config entry for the upstream destination service. Configuring it in a
                       proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                     `,
                 yaml: `The protocol for the upstream listener.<br><br>
@@ -490,7 +490,7 @@ spec:
                       [\`ServiceDefaults\`](/docs/connect/config-entries/service-defaults)
                       CRD for the upstream destination service. Configuring it in a
                       proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                     `,
               },
@@ -506,7 +506,7 @@ spec:
                       [\`service-resolver\`](/docs/connect/config-entries/service-resolver)
                       config entry for the upstream destination service.
                       Configuring it in a proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                     `,
                 yaml: `The number of milliseconds to allow when making upstream connections before timing out.<br><br>
@@ -516,7 +516,7 @@ spec:
                       [\`ServiceResolver\`](/docs/connect/config-entries/service-resolver)
                       CRD for the upstream destination service.
                       Configuring it in a proxy upstream config will not fully enable some
-                      [L7 features](/docs/connect/l7-traffic-management).
+                      [L7 features](/docs/connect/l7-traffic).
                       It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
                     `,
               },
@@ -525,7 +525,7 @@ spec:
               name: 'MeshGateway',
               type: 'MeshGatewayConfig: <optional>',
               description: `Controls the default
-                  [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+                  [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
                   for this upstream.`,
               children: [
                 {
@@ -629,7 +629,7 @@ spec:
       name: 'MeshGateway',
       type: 'MeshGatewayConfig: <optional>',
       description: `Controls the default
-      [mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+      [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
       for this service. Added in v1.6.0.`,
       children: [
         {

website/content/docs/connect/config-entries/service-resolver.mdx

@@ -21,7 +21,7 @@ and discovery terminates.
 ## Interaction with other Config Entries
 
 - Service resolver config entries are a component of [L7 Traffic
-  Management](/docs/connect/l7-traffic-management).
+  Management](/docs/connect/l7-traffic).
 
 ## UI
 

website/content/docs/connect/config-entries/service-router.mdx

@@ -21,7 +21,7 @@ service of the same name.
 ## Interaction with other Config Entries
 
 - Service router config entries are a component of [L7 Traffic
-  Management](/docs/connect/l7-traffic-management).
+  Management](/docs/connect/l7-traffic).
 
 - Service router config entries are restricted to only services that define
   their protocol as HTTP-based via a corresponding

website/content/docs/connect/config-entries/service-splitter.mdx

@@ -25,7 +25,7 @@ resolution stage.
 ## Interaction with other Config Entries
 
 - Service splitter config entries are a component of [L7 Traffic
-  Management](/docs/connect/l7-traffic-management).
+  Management](/docs/connect/l7-traffic).
 
 - Service splitter config entries are restricted to only services that define
   their protocol as http-based via a corresponding

website/content/docs/connect/config-entries/terminating-gateway.mdx

@@ -20,7 +20,7 @@ and will apply to all instances of the gateway with that name.
 across all federated Consul datacenters. If terminating gateways in different Consul datacenters need to route to different
 sets of services within their datacenter then the terminating gateways **must** be registered with different names.
 
-See [Terminating Gateway](/docs/connect/terminating-gateway) for more information.
+See [Terminating Gateway](/docs/connect/gateways/terminating-gateway) for more information.
 
 ## TLS Origination
 

website/content/docs/connect/configuration.mdx

@@ -76,7 +76,7 @@ You can override centralized configurations for individual proxy instances in
 their
 [sidecar service definitions](/docs/connect/registration/sidecar-service),
 and the default protocols for service instances in their [service
-registrations](/docs/agent/services).
+registrations](/docs/discovery/services).
 
 ## Schedulers
 
@@ -92,7 +92,7 @@ Connect can be used with Nomad to provide secure service-to-service
 communication between Nomad jobs and task groups. The ability to use the dynamic
 port feature of Nomad makes Connect particularly easy to use. Learn about how to
 configure Connect on Nomad by reading the
-[integration documentation](/docs/connect/platform/nomad)
+[integration documentation](/docs/connect/nomad)
 
 ### Kubernetes
 

website/content/docs/connect/connectivity-tasks.mdx

@@ -23,9 +23,9 @@ appropriate destination based on the server name requested. The data within the
 the Gateway.
 
 As of Consul 1.8.0, mesh gateways can also forward gossip and RPC traffic between Consul servers.
-This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways).
+This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
 
-For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway)
+For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
 and the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways).
 
 ![Mesh Gateway Architecture](/img/mesh-gateways.png)

website/content/docs/connect/gateways/index.mdx

@@ -27,7 +27,7 @@ They operate by sniffing and extracting the server name indication (SNI) header
 
 Mesh gateways enable the following scenarios:
 
-- **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways) for additional information.
+* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information.
 - **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information.
 - **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information.
 

website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx

@@ -26,7 +26,7 @@ The following diagram describes the architecture for using mesh gateways for cro
 
 Ensure that your Consul environment meets the following requirements.
 
-### Consul 
+### Consul
 
 * Consul version 1.6.0 or newer.
 * A local Consul agent is required to manage its configuration.
@@ -35,18 +35,18 @@ Ensure that your Consul environment meets the following requirements.
 * Each datacenters must be [WAN joined](https://learn.hashicorp.com/tutorials/consul/federarion-gossip-wan).
 * The [primary datacenter](/docs/agent/options#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other.
 * [gRPC](/docs/agent/options#grpc_port) must be enabled.
-* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
+* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
 
 ### Network
 
 * General network connectivity to all services within its local Consul datacenter.
 * General network connectivity to all mesh gateways within remote Consul datacenters.
 
-### Proxy 
+### Proxy
 
 Envoy is the only proxy with mesh gateway capabilities in Consul.
 
-Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration. 
+Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration.
 Consul can only translate mesh gateway registration information into Envoy configuration.
 
 Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration.
@@ -264,4 +264,4 @@ service:
       mesh_gateway:
       - mode: none
   ```
-  </CodeTabs>
+  </CodeTabs>

website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx

@@ -25,10 +25,10 @@ Ensure that your Consul environment meets the following requirements.
 * Consul Enterprise version 1.11.0 or newer.
 * A local Consul agent is required to manage its configuration.
 * Consul service mesh must be enabled in all partitions. Refer to the [`connect` documentation](/docs/agent/options#connect) for details.
-* Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enteprise/admin-partitions) for details.
+* Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enterprise/admin-partitions) for details.
-* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
+* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
 
-### Proxy 
+### Proxy
 
 Envoy is the only proxy with mesh gateway capabilities in Consul.
 

website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx

@@ -9,7 +9,7 @@ description: |-
 
 -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
 
-~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway).
+~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters).
 
 WAN federation via mesh gateways allows for Consul servers in different datacenters
 to be federated exclusively through mesh gateways.
@@ -38,7 +38,7 @@ Sometimes this prerequisite is difficult or undesirable to meet:
 
 Operators looking to simplify their WAN deployment and minimize the exposed
 security surface area can elect to join these datacenters together using [mesh
-gateways](/docs/connect/gateways/mesh-gateway) to do so.
+gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) to do so.
 
 [![WAN federation with mesh gateways](/img/wan-federation-connectivity-mesh-gateways.png)](/img/wan-federation-connectivity-mesh-gateways.png)
 

website/content/docs/connect/gateways/terminating-gateway.mdx

@@ -22,14 +22,14 @@ For additional use cases and usage patterns, review the tutorial for
 [understanding terminating gateways](https://learn.hashicorp.com/tutorials/consul/service-mesh-terminating-gateways).
 
 ~> **Known limitations:** Terminating gateways currently do not support targeting service subsets with
-[L7 configuration](/docs/connect/l7-traffic-management). They route to all instances of a service with no capabilities
+[L7 configuration](/docs/connect/l7-traffic). They route to all instances of a service with no capabilities
 for filtering by instance.
 
 ## Security Considerations
 
 ~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways
 hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect
-to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/mesh-gateway)
+to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
 whenever possible since they are not capable of decrypting traffic or connecting directly to services.
 
 By specifying a path to a [CA file](/docs/connect/config-entries/terminating-gateway#cafile) connections
@@ -120,7 +120,7 @@ All services registered in the Consul catalog must be associated with a node, ev
 not managed by a Consul client agent. All agent-less services with the same address can be registered under the same node name and address.
 However, ensure that the [node name](/api/catalog#node) for external services registered directly in the catalog
 does not match the node name of any Consul client agent node. If the node name overlaps with the node name of a Consul client agent,
-Consul's [anti-entropy sync](/docs/internals/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint.
+Consul's [anti-entropy sync](/docs/architecture/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint.
 
 For a complete example of how to register external services review the
 [external services tutorial](https://learn.hashicorp.com/tutorials/consul/service-registration-external-services).

website/content/docs/connect/l7-traffic/discovery-chain.mdx

@@ -224,7 +224,7 @@ A single node in the compiled discovery chain.
     be considered healthy.
 
 - `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway
-  configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
+  configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
   to use when connecting to this target's service instances.
 
   - `Mode` `(string: "")` - One of `none`, `local`, or `remote`.

website/content/docs/connect/native/index.mdx

@@ -138,7 +138,7 @@ natively. This enables the service to be returned as part of service
 discovery for Connect-capable services, used by other Connect-native applications
 and client [proxies](/docs/connect/proxies).
 
-This can be specified directly in the [service definition](/docs/agent/services):
+This can be specified directly in the [service definition](/docs/discovery/services):
 
 ```json
 {

website/content/docs/connect/observability/index.mdx

@@ -46,7 +46,7 @@ Find other possible metrics syncs in the [Connect Envoy documentation](/docs/con
 
 You can specify the [service protocol](/docs/connect/config-entries/service-defaults#protocol)
 in the `service-defaults` configuration entry. You can override it in the
-[service registration](/docs/agent/services). By default, proxies only give
+[service registration](/docs/discovery/services). By default, proxies only give
 you L4 metrics. This protocol allows proxies to handle requests at the right L7
 protocol and emit richer L7 metrics. It also allows proxies to make per-request
 load balancing and routing decisions.

website/content/docs/connect/proxies/envoy.mdx

@@ -23,7 +23,7 @@ Consul can configure Envoy sidecars to proxy traffic over the following protocol
 
 On Consul 1.5.0 and older, Envoy proxies can only proxy TCP traffic at L4.
 
-Some [L7 features](/docs/connect/l7-traffic-management) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy.
+Some [L7 features](/docs/connect/l7-traffic) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy.
 
 ~> **Note:** When using Envoy with Consul and not using the [`consul connect envoy` command](/commands/connect/envoy)
 Envoy must be run with the `--max-obj-name-len` option set to `256` or greater for Envoy versions prior to 1.11.0.
@@ -240,7 +240,7 @@ defaults that are inherited by all services.
     [`service-defaults`](/docs/connect/config-entries/service-defaults)
     config entry for the service. Configuring it in a
     proxy config will not fully enable some [L7
-    features](/docs/connect/l7-traffic-management).
+    features](/docs/connect/l7-traffic).
     It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
 
 - `bind_address` - Override the address Envoy's public listener binds to. By
@@ -274,7 +274,7 @@ definition](/docs/connect/registration/service-registration) or
   [`service-defaults`](/docs/connect/config-entries/service-defaults)
   config entry for the upstream destination service. Configuring it in a
   proxy upstream config will not fully enable some [L7
-  features](/docs/connect/l7-traffic-management).
+  features](/docs/connect/l7-traffic).
   It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
 
 - `connect_timeout_ms` - The number of milliseconds to allow when making upstream

website/content/docs/connect/proxies/integrate.mdx

@@ -127,7 +127,7 @@ If you are only implementing L4 support in your proxy, set the
 fetching the discovery chain so that L7 features, such as HTTP routing rules, are
 not returned.
 
-For each [target](/docs/internals/discovery-chain#targets) in the resulting
+For each [target](/docs/connect/l7-traffic/discovery-chain#targets) in the resulting
 discovery chain, a list of healthy, Connect-capable endpoints may be fetched
 from the [`/v1/health/connect/:service_id`] API endpoint as described in the [Service
 Discovery](#service-discovery) section.

website/content/docs/connect/proxies/managed-deprecated.mdx

@@ -18,7 +18,7 @@ definition.
 !> **Consul 1.6.0 removes Managed Proxies completely.**
 This documentation is provided for prior versions only. You may consider using
 [sidecar service
-registrations](/docs/connect/proxies/sidecar-service) instead.
+registrations](/docs/connect/registration/sidecar-service) instead.
 
 Managed proxies have been deprecated since Consul 1.3 and have been fully removed
 in Consul 1.6. Anyone using Managed Proxies should aim to change their workflow
@@ -42,7 +42,7 @@ with other workloads. So the high implementation cost of building robust process
 supervision didn't actually benefit most real use-cases.
 
 Instead of this Connect 1.3.0 introduces the concept of [sidecar service
-registrations](/docs/connect/proxies/sidecar-service) which
+registrations](/docs/connect/registration/sidecar-service) which
 have almost all of the benefits of simpler configuration but without any of the
 additional process management complexity. As a result they can be used to
 simplify configuration in both container-based and realistic production
@@ -55,7 +55,7 @@ page will document how they work in the interim.
 
 -> **Deprecation Note:** It's _strongly_ recommended you do not build anything
 using Managed proxies and consider using [sidecar service
-registrations](/docs/connect/proxies/sidecar-service) instead.
+registrations](/docs/connect/registration/sidecar-service) instead.
 
 Managed proxies are given
 a unique proxy-specific ACL token that allows read-only access to Connect
@@ -103,7 +103,7 @@ to re-adopt them on restart.
 ### Minimal Configuration
 
 Managed proxies are configured within a
-[service definition](/docs/agent/services). The simplest possible
+[service definition](/docs/discovery/services). The simplest possible
 managed proxy configuration is an empty configuration. This enables the
 default managed proxy and starts a listener for that service:
 

website/content/docs/connect/registration/index.mdx

@@ -10,7 +10,7 @@ description: >-
 # Proxy Registration
 
 To make Connect aware of proxies you will need to register them in a [service
-definition](/docs/agent/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
+definition](/docs/discovery/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
 
 ## Proxy Service Registration
 

website/content/docs/connect/registration/service-registration.mdx

@@ -193,7 +193,7 @@ You can configure the service mesh proxy to create listeners for upstream servic
 
 Upstreams support multiple destination types. The following examples include information about each implementation.
 
--> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/agent/services#service-definition-parameter-case) for additional information.
+-> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/discovery/services#service-definition-parameter-case) for additional information.
 
 <CodeTabs heading="Example service destination upstream">
 <CodeBlockConfig>
@@ -306,7 +306,7 @@ The following examples show additional configuration for transparent proxies.
 Added in v1.10.0.
 
 -> Note that `snake_case` is used here as it works in both [config file and API
-registrations](/docs/agent/services#service-definition-parameter-case).
+registrations](/docs/discovery/services#service-definition-parameter-case).
 
 #### Configure a proxy listener for outbound traffic on port 22500
 
@@ -332,7 +332,7 @@ registrations](/docs/agent/services#service-definition-parameter-case).
 The following examples show all possible mesh gateway configurations.
 
 -> Note that `snake_case` is used here as it works in both [config file and API
-registrations](/docs/agent/services#service-definition-parameter-case).
+registrations](/docs/discovery/services#service-definition-parameter-case).
 
 #### Using a Local/Egress Gateway in the Local Datacenter
 
@@ -390,7 +390,7 @@ non-Connect-enabled applications to contact an HTTP endpoint.
 Some examples include: exposing a `/metrics` path for Prometheus or `/healthz` for kubelet liveness checks.
 
 -> Note that `snake_case` is used here as it works in both [config file and API
-registrations](/docs/agent/services#service-definition-parameter-case).
+registrations](/docs/discovery/services#service-definition-parameter-case).
 
 #### Expose listeners in Envoy for HTTP and GRPC checks registered with the local Consul agent
 

website/content/docs/connect/registration/sidecar-service.mdx

@@ -14,7 +14,7 @@ the same VM or running as a separate container in the same network namespace.
 
 To simplify the configuration experience when deploying a sidecar for a service
 instance, Consul 1.3 introduced a new field in the Connect block of the [service
-definition](/docs/agent/services).
+definition](/docs/discovery/services).
 
 To deploy a service and sidecar proxy locally, complete the
 [Getting Started guide](https://learn.hashicorp.com/tutorials/consul/get-started-service-networking?utm_source=consul.io&utm_medium=docs).
@@ -136,7 +136,7 @@ proxy.
 - `kind` - Defaults to `connect-proxy`. This can't be overridden currently.
 - `check`, `checks` - By default we add a TCP check on the local address and
   port for the proxy, and a [service alias
-  check](/docs/agent/checks#alias) for the parent service. If either
+  check](/docs/discovery/checks#alias) for the parent service. If either
   `check` or `checks` fields are set, only the provided checks are registered.
 - `proxy.destination_service_name` - Defaults to the parent service name.
 - `proxy.destination_service_id` - Defaults to the parent service ID.
@@ -145,7 +145,7 @@ proxy.
 
 ## Limitations
 
-Almost all fields in a [service definition](/docs/agent/services) may be
+Almost all fields in a [service definition](/docs/discovery/services) may be
 set on the `connect.sidecar_service` except for the following:
 
 - `id` - Sidecar services get an ID assigned and it is an error to override

website/content/docs/connect/security.mdx

@@ -13,7 +13,7 @@ Connect enables secure service-to-service communication over mutual TLS. This
 provides both in-transit data encryption as well as authorization. This page
 will document how to secure Connect. To try Connect locally, complete the
 [Getting Started guide](https://learn.hashicorp.com/tutorials/consul/service-mesh?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) or for a full security model reference,
-see the dedicated [Consul security model](/docs/internals/security) page. When
+see the dedicated [Consul security model](/docs/security) page. When
 setting up Connect in production, review this [tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-production-checklist?utm_source=consul.io&utm_medium=docs).
 
 Connect will function in any Consul configuration. However, unless the checklist
@@ -22,7 +22,7 @@ built for. The checklist below can be incrementally adopted towards full
 security if you prefer to operate in less secure models initially.
 
 ~> **Warning**: The checklist below should not be considered exhaustive. Please
-read and understand the [Consul security model](/docs/internals/security)
+read and understand the [Consul security model](/docs/security)
 in depth to assess whether your deployment satisfies the security requirements
 of Consul.
 
@@ -54,7 +54,7 @@ to verify server authenticity with each server having a unique TLS certificate.
 affect Connect since requests must also always contain a valid ACL token.
 Clients calling Consul APIs should be forced over encrypted connections.
 
-See the [Consul agent encryption page](/docs/agent/encryption) to
+See the [Consul agent encryption page](/docs/security/encryption) to
 learn more about configuring agent encryption.
 
 **If encryption is not enabled**, a malicious actor can sniff network
@@ -68,7 +68,7 @@ clients and servers should be protected from unauthorized access. This
 protection must be done outside of Consul via access control systems provided
 by your target operating system.
 
-The [full Consul security model](/docs/internals/security) explains the
+The [full Consul security model](/docs/security) explains the
 risk of unauthorized access for both client agents and server agents. In
 general, the blast radius of unauthorized access for client agent directories
 is much smaller than servers. However, both must be protected against

website/content/docs/connect/transparent-proxy.mdx

@@ -136,7 +136,7 @@ transparent proxy's datacenter. Services can also dial explicit upstreams in oth
 [annotation](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) such as
 `"consul.hashicorp.com/connect-service-upstreams": "my-service:1234:dc2"` to reach an upstream service called `my-service`
 in the datacenter `dc2`.
-* In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](https://www.consul.io/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be
+* In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be
 `"consul.hashicorp.com/connect-service-upstreams": "my-service:1234"`, where `my-service` is the service that exists in another Kubernetes cluster and is exposed on port `1234`. Although Transparent Proxy is enabled, KubeDNS is not utilized when communicating between services existing on separate Kubernetes clusters.
 * When dialing headless services the request will be proxied using a plain TCP proxy with a 5s connection timeout.
 Currently the upstream's protocol and connection timeout are not considered.

website/content/docs/discovery/checks.mdx

@@ -420,7 +420,7 @@ updating a TTL check via the HTTP interface can set the `notes` value.
 
 Checks may also contain a `token` field to provide an ACL token. This token is
 used for any interaction with the catalog for the check, including
-[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
+[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
 For Alias checks, this token is used if a remote blocking query is necessary
 to watch the state of the aliased node or service.
 

website/content/docs/discovery/dns.mdx

@@ -102,7 +102,7 @@ A service lookup is used to query for service providers. Service queries support
 two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782).
 
 By default, SRV weights are all set at 1, but changing weights is supported using the
-`Weights` attribute of the [service definition](/docs/agent/services).
+`Weights` attribute of the [service definition](/docs/discovery/services).
 
 Note that DNS is limited in size per request, even when performing DNS TCP
 queries.
@@ -394,7 +394,7 @@ To find ingress-enabled services:
 <service>.ingress.<domain>
 ```
 
-This will find all [ingress gateway](/docs/connect/ingress-gateway)
+This will find all [ingress gateway](/docs/connect/gateways/ingress-gateway)
 endpoints for the given `service`.
 
 This endpoint currently only finds services within the same datacenter

website/content/docs/discovery/services.mdx

@@ -212,7 +212,7 @@ This is the root-level parameter that defines the service. You can specify the p
 | `tagged_addresses`    | Tagged addresses are additional addresses that may be defined for a node or service. See [Tagged Addresses](#tagged-addresses) for details.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | None                          | Optional                     |
 | `port`                | Integer value that specifies a service-specific port number. The port number should be specified when the `address` parameter is defined to improve service discoverability.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | Optional                      |
 | `socket_path`         | String value that specifies the path to the service socket. <br/>Specify this parameter to expose the service to the mesh if the service listens on a Unix Domain socket.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | None                          | Optional                     |
-| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled. <br/> If set to `true`, then external agents can update this service in the catalog and modify the tags.<br/> Subsequent local sync operations by this agent will ignore the updated tags. <br/> This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently. <br/>Updating the tags for services registered on one node is independent from the same service (by name) registered on another node. <br/> See [anti-entropy syncs](/docs/internals/anti-entropy) for additional information.<br/> | False                         | Optional                     |
+| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled. <br/> If set to `true`, then external agents can update this service in the catalog and modify the tags.<br/> Subsequent local sync operations by this agent will ignore the updated tags. <br/> This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently. <br/>Updating the tags for services registered on one node is independent from the same service (by name) registered on another node. <br/> See [anti-entropy syncs](/docs/architecture/anti-entropy) for additional information.<br/> | False                         | Optional                     |
 | `checks`              | Array of objects that define health checks for the service. See [Health Checks](#health-checks) for details.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | None                          | Optional                     |
 | `kind`                | String value that identifies the service as a Connect proxy. See [Connect](#connect) for details.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | None                          | Optional                     |
 | `proxy_destination`   | String value that specifies the _name_ of the destination service that the service currently being configured proxies to. <br/>This parameter is deprecated. Use `proxy.destination_service` instead. <br/>See [Connect](#connect) for additional information.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    | None                          | Optional                     |
@@ -233,7 +233,7 @@ You can add semantic meta data to the service using the `meta` parameter. This p
 ### Security Configurations
 
 If the ACL system is enabled, specify a value for the `token` parameter to provide an ACL token. This token is
-used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
+used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
 
 Services registered in Consul clusters where both [Consul Namespaces](/docs/enterprise/namespaces)<EnterpriseAlert inline />
 and the ACL system are enabled can be registered to specific namespaces that are associated with
@@ -252,7 +252,7 @@ The health check name is automatically generated as `service:<service-id>`. If t
 registered, the ID will be generated as `service:<service-id>:<num>` where
 `<num>` is an incrementing number starting from `1`.
 
-Consul includes several check types with different options. Refer to the [health checks documentation](/docs/agent/checks) for details.
+Consul includes several check types with different options. Refer to the [health checks documentation](/docs/discovery/checks) for details.
 
 ### Proxy
 
@@ -319,7 +319,7 @@ is present in the agent DNS configuration or the `passing` query parameter is us
 
 Services may also contain a `token` field to provide an ACL token. This token is
 used for any interaction with the catalog for the service, including
-[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
+[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
 
 You can optionally disable the anti-entropy feature for this service using the
 `enable_tag_override` flag. External agents can modify tags on services in the
@@ -336,7 +336,7 @@ configuration items are independent of one another. Updating the tags
 for the service registered on one node is independent of the same
 service (by name) registered on another node. If `enable_tag_override` is
 not specified the default value is false. See [anti-entropy
-syncs](/docs/internals/anti-entropy) for more info.
+syncs](/docs/architecture/anti-entropy) for more info.
 
 For Consul 0.9.3 and earlier you need to use `enableTagOverride`. Consul 1.0
 supports both `enable_tag_override` and `enableTagOverride` but the latter is

website/content/docs/dynamic-app-config/kv.mdx

@@ -15,7 +15,7 @@ similarities to one.
 
 The Consul KV datastore is located on the servers, but can be accessed by any
 agent (client or server). The natively integrated [RPC
-functionality](/docs/internals/architecture) allows clients to forward
+functionality](/docs/architecture) allows clients to forward
 requests to servers, including key/value reads and writes. Part of Consul’s
 core design allows data to be replicated automatically across all the servers.
 Having a quorum of servers will decrease the risk of data loss if an outage
@@ -32,7 +32,7 @@ subcommands](/commands/kv), [HTTP API](/api/kv), and Consul UI.
 To restrict access, enable and configure
 [ACLs](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production).
 Once the ACL system has been bootstrapped, users and services, will need a
-valid token with KV [privileges](/docs/agent/acl-rules#key-value-rules) to
+valid token with KV [privileges](/docs/security/acl/acl-rules#key-value-rules) to
 access the the data store, this includes even reads. We recommend creating a
 token with limited privileges, for example, you could create a token with write
 privileges on one key for developers to update the value related to their
@@ -75,9 +75,9 @@ to be initiated on value changes to a Consul key.
 ### Watches
 
 Consul KV can also be extended with the use of watches.
-[Watches](/docs/agent/watches) are a way to monitor data for updates. When
+[Watches](/docs/dynamic-app-config/watches) are a way to monitor data for updates. When
 an update is detected, an external handler is invoked. To use watches with the
-KV store the [key](/docs/agent/watches#key) watch type should be used.
+KV store the [key](/docs/dynamic-app-config/watches#key) watch type should be used.
 
 ### Consul Sessions
 
@@ -87,7 +87,7 @@ API supports an `acquire` and `release` operation. The `acquire` operation acts
 like a Check-And-Set operation. On success, there is a key update and an
 increment to the `LockIndex` and the session value is updated to reflect the
 session holding the lock. Review the session documentation for more information
-on the [integration](/docs/internals/sessions#k-v-integration).
+on the [integration](/docs/dynamic-app-config/sessions#k-v-integration).
 
 Review the following tutorials to learn how to use Consul sessions for [application leader election](https://learn.hashicorp.com/tutorials/consul/application-leader-elections) and
 to [build distributed semaphores](https://learn.hashicorp.com/tutorials/consul/distributed-semaphore).

website/content/docs/dynamic-app-config/sessions.mdx

@@ -51,7 +51,7 @@ deleted by Consul.
 
 While this is a simple design, it enables a multitude of usage
 patterns. By default, the
-[gossip based failure detector](/docs/internals/gossip)
+[gossip based failure detector](/docs/architecture/gossip)
 is used as the associated health check. This failure detector allows
 Consul to detect when a node that is holding a lock has failed and
 to automatically release the lock. This ability provides **liveness** to

website/content/docs/enterprise/audit-logging.mdx

@@ -25,7 +25,7 @@ For more experience leveraging Consul's audit logging functionality, explore our
 HashiCorp Learn tutorial [Capture Consul Events with Audit Logging](https://learn.hashicorp.com/tutorials/consul/audit-logging).
 
 For detailed configuration information on configuring the Consul Enterprise's audit
-logging, review the Consul [Audit Log](https://www.consul.io/docs/agent/options#audit)
+logging, review the Consul [Audit Log](/docs/agent/options#audit)
 documentation.
 
 ## Example Configuration

website/content/docs/enterprise/index.mdx

@@ -23,7 +23,7 @@ Features include:
 - [Namespaces](/docs/enterprise/namespaces)
 - [NIA with Terraform Enterprise](/docs/nia/enterprise)
 - [Sentinel](/docs/enterprise/sentinel)
-- [OIDC Auth Method](/docs/acl/auth-methods/oidc)
+- [OIDC Auth Method](/docs/security/acl/auth-methods/oidc)
 
 These features are part of [Consul
 Enterprise](https://www.hashicorp.com/consul).

website/content/docs/enterprise/license/faq.mdx

@@ -35,9 +35,9 @@ Please visit the [Enterprise License Tutorial](https://learn.hashicorp.com/tutor
 
 The list below is a great starting point for learning more about the license changes introduced in Consul Enterprise 1.10.0+ent.
 
-- [Consul Enterprise Upgrade Documentation](https://www.consul.io/docs/enterprise/upgrades)
+- [Consul Enterprise Upgrade Documentation](/docs/enterprise/upgrades)
 
-- [Consul License Documentation](/docs/enterprise/license)
+- [Consul License Documentation](/docs/enterprise/license/overview)
 
 - [License configuration values documentation](/docs/enterprise/license/overview#binaries-without-built-in-licenses)
 
@@ -90,7 +90,7 @@ Consul snapshot agents will attempt to retrieve the license from servers if cert
 
 ## Q: Where can users get a trial license for Consul Enterprise?
 
-Visit https://www.consul.io/trial for a free 30-day trial license.
+Visit [consul.io/trial](/trial) for a free 30-day trial license.
 
 ## Q: Are the license files locked to a specific cluster?
 

website/content/docs/enterprise/network-segments.mdx

@@ -142,7 +142,7 @@ segments are:
 
 Each client agent can only be a member of one segment at a time. This will be the
 `<default>` segment unless otherwise specified in the agent's
-[`segment`](/docs/agent/options.html#_segment) agent configuration option.
+[`segment`](/docs/agent/options#_segment) agent configuration option.
 
 ### Join a Client to a Segment ((#join_a_client_to_a_segment))
 

website/content/docs/install/bootstrapping.mdx

@@ -12,18 +12,18 @@ description: >-
 # Bootstrapping a Datacenter
 
 An agent can run in either client or server mode. Server nodes are responsible for running the
-[consensus protocol](/docs/internals/consensus) and storing the cluster state.
+[consensus protocol](/docs/architecture/consensus) and storing the cluster state.
 The client nodes are mostly stateless and rely heavily on the server nodes.
 
 Before a Consul cluster can begin to service requests,
 a server node must be elected leader. Bootstrapping is the process
 of joining these initial server nodes into a cluster. Read the
-[architecture documentation](/docs/internals/architecture) to learn more about
+[architecture documentation](/docs/architecture) to learn more about
 the internals of Consul.
 
 It is recommended to have three or five total servers per datacenter. A single server deployment is _highly_ discouraged
 as data loss is inevitable in a failure scenario. Please refer to the
-[deployment table](/docs/internals/consensus#deployment-table) for more detail.
+[deployment table](/docs/architecture/consensus#deployment-table) for more detail.
 
 ~> **Note**: In versions of Consul prior to 0.4, bootstrapping was a manual process. For details on using the `-bootstrap` flag directly, see the
 [manual bootstrapping documentation](/docs/install/bootstrapping#manually-join-the-servers).

website/content/docs/install/glossary.mdx

@@ -48,14 +48,14 @@ transactions are applied to a
 [finite-state machine](https://en.wikipedia.org/wiki/Finite-state_machine), our definition
 of consensus implies the consistency of a replicated state machine. Consensus is described
 in more detail on [Wikipedia](<https://en.wikipedia.org/wiki/Consensus_(computer_science)>),
-and our implementation is described [here](/docs/internals/consensus).
+and our implementation is described [here](/docs/architecture/consensus).
 
 ## Gossip
 
 Consul is built on top of [Serf](https://www.serf.io/) which provides a full
 [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) that is used for multiple purposes.
 Serf provides membership, failure detection, and event broadcast. Our use of these
-is described more in the [gossip documentation](/docs/internals/gossip). It is enough to know
+is described more in the [gossip documentation](/docs/architecture/gossip). It is enough to know
 that gossip involves random node-to-node communication, primarily over UDP.
 
 ## LAN Gossip
@@ -83,9 +83,9 @@ An Access Control List (ACL) is a list of user permissions for a file, folder, o
 other object. It defines what users and groups can access the object and what 
 operations they can perform.
 
-Consul uses Access Control Lists (ACLs) to secure the UI, API, CLI, service 
+Consul uses Access Control Lists (ACLs) to secure the UI, API, CLI, service
-communications, and agent communications.  
+communications, and agent communications.
-Visit [Consul ACL Documentation and Guides](https://www.consul.io/docs/acl)
+Visit [Consul ACL Documentation and Guides](/docs/security/acl)
 
 ## API Gateway	
 An Application Programming Interface (API) is a common software interface that 

website/content/docs/install/index.mdx

@@ -79,4 +79,4 @@ $ consul version
 
 Consul currently supports all 'evergreen' browsers, as they are generally on
 up-to-date versions. For more information on supported browsers, please see our
-[FAQ](/docs/faq)
+[FAQ](/docs/troubleshoot/faq)

website/content/docs/install/manual-bootstrap.mdx

@@ -12,13 +12,13 @@ description: >-
 
 When deploying Consul to a datacenter for the first time, there is an initial
 bootstrapping that must be done. As of Consul 0.4, an
-[automatic bootstrapping](/docs/guides/bootstrapping) is available and is
+[automatic bootstrapping](/docs/install/bootstrapping) is available and is
 the recommended approach. However, older versions only support a manual
 bootstrap that is documented here.
 
 Generally, the first nodes that are started are the server nodes. Remember that
 an agent can run in both client and server mode. Server nodes are responsible
-for running the [consensus protocol](/docs/internals/consensus), and
+for running the [consensus protocol](/docs/architecture/consensus), and
 storing the cluster state. The client nodes are mostly stateless and rely on the
 server nodes, so they can be started easily.
 
@@ -35,7 +35,7 @@ something like the following will be logged:
 ```
 
 Once `Node A` is running, we can start the next set of servers. There is a
-[deployment table](/docs/internals/consensus#toc_4) that covers various
+[deployment table](/docs/architecture/consensus#deployment_table) that covers various
 options, but it is recommended to have 3 or 5 total servers per datacenter. A
 single server deployment is _**highly**_ discouraged as data loss is inevitable
 in a failure scenario. We start the next servers **without** specifying

website/content/docs/install/performance.mdx

@@ -9,7 +9,7 @@ description: >-
 
 # Server Performance
 
-Since Consul servers run a [consensus protocol](/docs/internals/consensus) to
+Since Consul servers run a [consensus protocol](/docs/architecture/consensus) to
 process all write operations and are contacted on nearly all read operations, server
 performance is critical for overall throughput and health of a Consul cluster. Servers
 are generally I/O bound for writes because the underlying Raft log store performs a sync

website/content/docs/integrate/partnerships.mdx

@@ -33,7 +33,7 @@ By leveraging Consul’s RESTful HTTP API system, prospective partners are able
 
 **Infrastructure**: There are two integration options in this category: natively through a direct integration with Consul or via Consul-Terraform-Sync (CTS). By leveraging Consul’s powerful **Network Infrastructure Automation (NIA)*** capabilities through CTS, changes in an infrastructure are seamlessly automated when Consul detects a change in its service catalog. For example, these integrations could be used to automate IP updates of load balancers or firewall security policies by leveraging Consul service discovery.
 
--> **Network Infrastructure Automation (NIA)***: These integrations leverage Consul’s service catalog to seamlessly integrate with Consul-Terraform-Sync (CTS) to automate changes in network infrastructure via a publisher-subscriber method. More details can be found [here](https://www.consul.io/docs/integrate/nia-integration).
+-> **Network Infrastructure Automation (NIA)***: These integrations leverage Consul’s service catalog to seamlessly integrate with Consul-Terraform-Sync (CTS) to automate changes in network infrastructure via a publisher-subscriber method. More details can be found [here](/docs/integrate/nia-integration).
 
 ## Development Process
 

website/content/docs/internals/acl.mdx

@@ -12,5 +12,5 @@ description: >-
 
 This content has been moved into the [ACL Guide](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production).
 
-See [Complete ACL Coverage in Consul 0.8](/docs/acl/acl-legacy) for details
+See [Complete ACL Coverage in Consul 0.8](/docs/security/acl/acl-legacy) for details
 about ACL changes in Consul 0.8 and later.

website/content/docs/internals/index.mdx

@@ -13,14 +13,14 @@ use it in production.
 
 Please review the following documentation to understand how Consul works.
 
-- [Architecture](/docs/internals/architecture)
+- [Architecture](/docs/architecture)
-- [Consensus Protocol](/docs/internals/consensus)
+- [Consensus Protocol](/docs/architecture/consensus)
-- [Gossip Protocol](/docs/internals/gossip)
+- [Gossip Protocol](/docs/architecture/gossip)
-- [Network Coordinates](/docs/internals/coordinates)
+- [Network Coordinates](/docs/architecture/coordinates)
-- [Sessions](/docs/internals/sessions)
+- [Sessions](/docs/security/acl/auth-methods/oidc)
-- [Anti-Entropy](/docs/internals/anti-entropy)
+- [Anti-Entropy](/docs/architecture/anti-entropy)
-- [Security Model](/docs/internals/security)
+- [Security Model](/docs/security)
-- [Discovery Chain](/docs/internals/discovery-chain)
+- [Discovery Chain](/docs/connect/l7-traffic/discovery-chain)
 
-You should also be familiar with [Jepsen testing](/docs/internals/jepsen), before deploying
+You should also be familiar with [Jepsen testing](/docs/architecture/jepsen), before deploying
 a production datacenter.

website/content/docs/intro/index.mdx

@@ -86,7 +86,7 @@ application developers, making it perfect for modern, elastic infrastructures.
 Consul is a distributed, highly available system. This section will cover the
 basics, purposely omitting some unnecessary detail, so you can get a quick
 understanding of how Consul works. For more detail, please refer to the
-[in-depth architecture overview](/docs/internals/architecture).
+[in-depth architecture overview](/docs/architecture).
 
 Every node that provides services to Consul runs a _Consul agent_. Running
 an agent is not required for discovering other services or getting/setting
@@ -103,7 +103,7 @@ The servers maintain a _catalog_, which is formed by aggregating information
 submitted by the agents. The catalog maintains the high-level view of the cluster,
 including which services are available, which nodes run those services, health
 information, and more. How agents and the catalog interact can be found
-[here](/docs/internals/anti-entropy#catalog).
+[here](/docs/architecture/anti-entropy#catalog).
 
 Components of your infrastructure that need to discover other services
 or nodes can query any of the Consul servers _or_ any of the Consul agents.
@@ -115,7 +115,7 @@ forward the request to the remote datacenter and return the result.
 
 ## Next Steps
 
-- See [how Consul compares to other software](/intro/vs) to assess how it fits into your
+- See [how Consul compares to other software](/docs/intro/vs) to assess how it fits into your
   existing infrastructure.
 - Continue onwards with [HashiCorp Learn](https://learn.hashicorp.com/tutorials/consul/get-started-install)
   to learn more about Consul and how to get Consul up and running.

website/content/docs/intro/vs/eureka.mdx

@@ -32,9 +32,9 @@ most applications to be Consul unaware, performing the service registration via
 files and discovery via DNS or load balancer sidecars.
 
 Consul provides a strong consistency guarantee, since servers replicate state using the
-[Raft protocol](/docs/internals/consensus). Consul supports a rich set of health checks
+[Raft protocol](/docs/architecture/consensus). Consul supports a rich set of health checks
 including TCP, HTTP, Nagios/Sensu compatible scripts, or TTL based like Eureka. Client nodes
-participate in a [gossip based health check](/docs/internals/gossip), which distributes
+participate in a [gossip based health check](/docs/architecture/gossip), which distributes
 the work of health checking, unlike centralized heartbeating which becomes a scalability challenge.
 Discovery requests are routed to the elected Consul leader which allows them to be strongly consistent
 by default. Clients that allow for stale reads enable any server to process their request allowing

website/content/docs/intro/vs/nagios.mdx

@@ -36,8 +36,8 @@ allowing the system to be much more scalable.
 An astute reader may notice that if a Consul agent dies, then no edge triggered
 updates will occur. From the perspective of other nodes, all checks will appear
 to be in a steady state. However, Consul guards against this as well. The
-[gossip protocol](/docs/internals/gossip) used between clients and servers
+[gossip protocol](/docs/architecture/gossip) used between clients and servers
 integrates a distributed failure detector. This means that if a Consul agent fails,
 the failure will be detected, and thus all checks being run by that node can be
 assumed failed. This failure detector distributes the work among the entire cluster
-while, most importantly, enabling the edge triggered architecture to work.
+while, most importantly, enabling the edge triggered architecture to work.

website/content/docs/intro/vs/serf.mdx

@@ -21,7 +21,7 @@ Serf does not provide any high-level features such as service discovery, health
 checking or key/value storage. Consul is a complete system providing all of those
 features.
 
-The internal [gossip protocol](/docs/internals/gossip) used within Consul is in
+The internal [gossip protocol](/docs/architecture/gossip) used within Consul is in
 fact powered by the Serf library: Consul leverages the membership and failure detection
 features and builds upon them to add service discovery. By contrast, the discovery
 feature of Serf is at a node level, while Consul provides a service and node level
@@ -42,7 +42,7 @@ catalog while Serf is only eventually-consistent.
 In addition to the service level abstraction and improved health checking,
 Consul provides a key/value store and support for multiple datacenters.
 Serf can run across the WAN but with degraded performance. Consul makes use
-of [multiple gossip pools](/docs/internals/architecture) so that
+of [multiple gossip pools](/docs/architecture) so that
 the performance of Serf over a LAN can be retained while still using it over
 a WAN for linking together multiple datacenters.
 

website/content/docs/intro/vs/smartstack.mdx

@@ -25,7 +25,7 @@ and dynamically configures HAProxy. Finally, clients speak to HAProxy, which doe
 health checking and load balancing across service providers.
 
 Consul is a much simpler and more contained system as it does not rely on any external
-components. Consul uses an integrated [gossip protocol](/docs/internals/gossip)
+components. Consul uses an integrated [gossip protocol](/docs/architecture/gossip)
 to track all nodes and perform server discovery. This means that server addresses
 do not need to be hardcoded and updated fleet-wide on changes, unlike SmartStack.
 

website/content/docs/k8s/connect/ingress-gateways.mdx

@@ -8,10 +8,10 @@ description: Configuring Ingress Gateways on Kubernetes
 
 -> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher
 
-~> This topic requires familiarity with [Ingress Gateways](/docs/connect/ingress-gateway).
+~> This topic requires familiarity with [Ingress Gateways](/docs/connect/gateways/ingress-gateway).
 
 This page describes how to enable external access to Connect Service Mesh services running inside Kubernetes using Consul ingress gateways.
-See [Ingress Gateways](/docs/connect/ingress-gateway) for more information on use-cases and how it works.
+See [Ingress Gateways](/docs/connect/gateways/ingress-gateway) for more information on use-cases and how it works.
 
 Adding an ingress gateway is a multi-step process that consists of the following steps:
 

website/content/docs/k8s/connect/terminating-gateways.mdx

@@ -8,7 +8,7 @@ description: Configuring Terminating Gateways on Kubernetes
 
 -> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher
 
-~> This topic requires familiarity with [Terminating Gateways](/docs/connect/terminating-gateway).
+~> This topic requires familiarity with [Terminating Gateways](/docs/connect/gateways/terminating-gateway).
 
 Adding a terminating gateway is a multi-step process:
 

website/content/docs/k8s/index.mdx

@@ -48,7 +48,7 @@ Kubernetes can choose to leverage Consul.
 ## Architecture
 
 Consul runs on Kubernetes with the same
-[architecture](/docs/internals/architecture)
+[architecture](/docs/architecture)
 as other platforms. There are some benefits Kubernetes can provide
 that eases operating a Consul cluster and we document those below. The standard
 [production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an

website/content/docs/k8s/installation/compatibility.mdx

@@ -4,15 +4,15 @@ page_title: Compatibility Matrix
 description: Compatibility Matrix for Consul Kubernetes
 ---
 
-# Compatibility Matrix for Consul on Kubernetes 
+# Compatibility Matrix for Consul on Kubernetes
 
-For every release of Consul on Kubernetes, a Helm chart, `consul-k8s-control-plane` binary and a `consul-k8s` CLI binary is built and distributed through a single version. When deploying via Helm, the recommended best path for upgrading Consul on Kubernetes, is to upgrade using the same `consul-k8s-control-plane` version as the Helm Chart, as the Helm Chart and Control Plane binary are tightly coupled. 
+For every release of Consul on Kubernetes, a Helm chart, `consul-k8s-control-plane` binary and a `consul-k8s` CLI binary is built and distributed through a single version. When deploying via Helm, the recommended best path for upgrading Consul on Kubernetes, is to upgrade using the same `consul-k8s-control-plane` version as the Helm Chart, as the Helm Chart and Control Plane binary are tightly coupled.
 
 ## Supported Consul versions
 
 ### Version 0.33.0 and above
 
-Starting with Consul Kubernetes 0.33.0, Consul Kubernetes versions all of its components (`consul-k8s` CLI, `consul-k8s-control-plane`, and Helm chart) with a single semantic version. 
+Starting with Consul Kubernetes 0.33.0, Consul Kubernetes versions all of its components (`consul-k8s` CLI, `consul-k8s-control-plane`, and Helm chart) with a single semantic version.
 
 | Consul Version | Compatible consul-k8s Versions  |
 | -------------- | ------------------------------- |
@@ -21,7 +21,7 @@ Starting with Consul Kubernetes 0.33.0, Consul Kubernetes versions all of its co
 
 ### Prior to version 0.33.0
 
-Prior to Consul Kubernetes 0.33.0, a separately versioned Consul Helm chart was distributed to deploy the Consul on Kubernetes binary. The default version of the `consul-k8s` binary specified by the Helm chart should be used to ensure proper compatibility, since the Helm chart is designed and tested with the default `consul-k8s` version. To find the default version for the appropriate Helm chart version, navigate to the corresponding tag (i.e. 0.32.1) in [`values.yaml`](https://github.com/hashicorp/consul-helm/blob/v0.32.1/values.yaml) and retrieve the `imageK8S` global value. 
+Prior to Consul Kubernetes 0.33.0, a separately versioned Consul Helm chart was distributed to deploy the Consul on Kubernetes binary. The default version of the `consul-k8s` binary specified by the Helm chart should be used to ensure proper compatibility, since the Helm chart is designed and tested with the default `consul-k8s` version. To find the default version for the appropriate Helm chart version, navigate to the corresponding tag (i.e. 0.32.1) in [`values.yaml`](https://github.com/hashicorp/consul-helm/blob/v0.32.1/values.yaml) and retrieve the `imageK8S` global value.
 
 | Consul Version | Compatible Consul Helm Versions (default `consul-k8s` image) |
 | -------------- | -----------------------------------------------------------|
@@ -33,20 +33,20 @@ Prior to Consul Kubernetes 0.33.0, a separately versioned Consul Helm chart was
 
 ## Supported Envoy versions
 
-Supported versions of Envoy for Consul versions are also found in [Envoy - Supported Versions](https://www.consul.io/docs/connect/proxies/envoy#supported-versions). The recommended best practice is to use the default version of Envoy that is provided in the Helm values.yml file, as that is the version that has been tested with the default Consul and Consul Kubernetes binaries for a given Helm chart.
+Supported versions of Envoy for Consul versions are also found in [Envoy - Supported Versions](/docs/connect/proxies/envoy#supported-versions). The recommended best practice is to use the default version of Envoy that is provided in the Helm values.yml file, as that is the version that has been tested with the default Consul and Consul Kubernetes binaries for a given Helm chart.
 
-## Red Hat OpenShift compatability 
+## Red Hat OpenShift compatibility
 
-Consul Kubernetes delivered Red Hat OpenShift support starting with Consul Helm chart version 0.25.0 for Consul 1.8.4. Please note the following details regarding OpenShift support. 
+Consul Kubernetes delivered Red Hat OpenShift support starting with Consul Helm chart version 0.25.0 for Consul 1.8.4. Please note the following details regarding OpenShift support.
 
-- Red Hat OpenShift is only supported for OpenShift 4.4.x and above. 
+- Red Hat OpenShift is only supported for OpenShift 4.4.x and above.
-- Only the default CNI Plugin, [OpenShift SDN CNI Plugin](https://docs.openshift.com/container-platform/4.9/networking/openshift_sdn/about-openshift-sdn.html) is currently supported. 
+- Only the default CNI Plugin, [OpenShift SDN CNI Plugin](https://docs.openshift.com/container-platform/4.9/networking/openshift_sdn/about-openshift-sdn.html) is currently supported.
 
 ## Vault as a Secrets Backend compatibility
 
-Starting with Consul K8s 0.39.0 and Consul 1.11.x, Consul Kubernetes supports the ability to utilize Vault as the secrets backend for all the secrets utilized by Consul on Kubernetes.  
+Starting with Consul K8s 0.39.0 and Consul 1.11.x, Consul Kubernetes supports the ability to utilize Vault as the secrets backend for all the secrets utilized by Consul on Kubernetes.
 
-| `consul-k8s` Versions    | Compatible Vault Versions | Compatible `vault-k8s` Versions | 
+| `consul-k8s` Versions    | Compatible Vault Versions | Compatible `vault-k8s` Versions |
 | ------------------------ | --------------------------| ----------------------------- |
 | 0.39.0 - latest          | 1.9.0 - latest            | 0.14.0 - latest               |
 

website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx

@@ -26,7 +26,7 @@ with the server pod or host IP addresses.
 
 ## Auto-join
 The recommended way to join a cluster running within Kubernetes is to
-use the ["k8s" cloud auto-join provider](/docs/agent/cloud-auto-join#kubernetes-k8s).
+use the ["k8s" cloud auto-join provider](/docs/install/cloud-auto-join#kubernetes-k8s).
 
 The auto-join provider dynamically discovers IP addresses to join using
 the Kubernetes API. It authenticates with Kubernetes using a standard

website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx

@@ -23,7 +23,7 @@ their pod IPs (`false`).
 
 Finally, `client.join` is set to an array of valid
 [`-retry-join` values](/docs/agent/options#retry-join). In the
-example above, a fake [cloud auto-join](/docs/agent/cloud-auto-join)
+example above, a fake [cloud auto-join](/docs/install/cloud-auto-join)
 value is specified. This should be set to resolve to the proper addresses of
 your existing Consul cluster.
 
@@ -57,7 +57,7 @@ You may also consider adopting Consul Enterprise for
 -> **Note:** Consul on Kubernetes currently does not support external servers that require mutual authentication
 for the HTTPS clients of the Consul servers, that is when servers have either
 `verify_incoming` or `verify_incoming_https` set to `true`.
-As noted in the [Security Model](/docs/internals/security#secure-configuration),
+As noted in the [Security Model](/docs/security#secure-configuration),
 that setting isn't strictly necessary to support Consul's threat model as it is recommended that
 all requests contain a valid ACL token.
 
@@ -94,7 +94,7 @@ to help initialize ACL tokens for Consul clients and consul-k8s components for y
 
 ### Manually Bootstrapping ACLs
 
-If you would like to call the [ACL bootstrapping API](/api/acl/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs,
+If you would like to call the [ACL bootstrapping API](/api-docs/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs,
 you can provide the bootstrap token to the Helm chart. The Helm chart will then use this token to configure ACLs
 for Consul clients and any consul-k8s components you are enabling.
 
@@ -128,7 +128,7 @@ The bootstrap token requires the following minimal permissions:
 Next, configure external servers. The Helm chart will use this configuration to talk to the Consul server's API
 to create policies, tokens, and an auth method. If you are [enabling Consul Connect](/docs/k8s/connect),
 `k8sAuthMethodHost` should be set to the address of your Kubernetes API server
-so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/acl/auth-methods/kubernetes)
+so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/security/acl/auth-methods/kubernetes)
 with `consul login`.
 
 <CodeBlockConfig filename="config.yaml">

website/content/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s.mdx

@@ -169,7 +169,7 @@ the value of `cluster.server` for the second cluster.
 
 Lastly, we need to set up the clients so that they can discover the servers in the first cluster.
 For this, we will use Consul's cloud auto-join feature
-for the [Kubernetes provider](https://www.consul.io/docs/install/cloud-auto-join#kubernetes-k8s).
+for the [Kubernetes provider](/docs/install/cloud-auto-join#kubernetes-k8s).
 To use it we need to provide a way for the Consul clients to reach the first Kubernetes cluster.
 To do that, we need to save the `kubeconfig` for the first cluster as a Kubernetes secret in the second cluster
 and reference it in the `clients.join` value. Note that we're making that secret available to the client pods
@@ -177,7 +177,7 @@ by setting it in `client.extraVolumes`.
 
 ~> **Note:** The kubeconfig you're providing to the client should have minimal permissions.
 The cloud auto-join provider will only need permission to read pods.
-Please see [Kubernetes Cloud auto-join](https://www.consul.io/docs/install/cloud-auto-join#kubernetes-k8s)
+Please see [Kubernetes Cloud auto-join](/docs/install/cloud-auto-join#kubernetes-k8s)
 for more details.
 
 Now we're ready to install!
@@ -188,7 +188,7 @@ $ helm install cluster2 --values cluster2-config.yaml hashicorp/consul
 
 ## Verifying the Consul Service Mesh works
 
-~> When Transparent proxy is enabled, services in one Kubernetes cluster that need to communicate with a service in another Kubernetes cluster must have a explicit upstream configured through the ["consul.hashicorp.com/connect-service-upstreams"](https://www.consul.io/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation.
+~> When Transparent proxy is enabled, services in one Kubernetes cluster that need to communicate with a service in another Kubernetes cluster must have a explicit upstream configured through the ["consul.hashicorp.com/connect-service-upstreams"](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation.
 
 Now that we have our Consul cluster in multiple k8s clusters up and running, we will
 deploy two services and verify that they can connect to each other.

website/content/docs/k8s/installation/install.mdx

@@ -98,7 +98,7 @@ cluster with default configurations. We strongly recommend [learning about the c
 of Consul. This provides a less complicated out-of-box experience for new users,
 but is not appropriate for a production setup. We strongly recommend using
 a properly-secured Kubernetes cluster or making sure that you understand and enable
-the [recommended security features](/docs/internals/security). Currently,
+the [recommended security features](/docs/security). Currently,
 some of these features are not supported in the Helm chart and require additional
 manual configuration.
 
@@ -180,7 +180,7 @@ NAME: consul
 ```
 
 If you've already installed Consul and want to make changes, you'll need to run
-`helm upgrade`. See [Upgrading](/docs/k8s/operations/upgrading) for more details.
+`helm upgrade`. See [Upgrading](/docs/k8s/upgrade) for more details.
 
 ## Viewing the Consul UI
 

website/content/docs/k8s/installation/multi-cluster/index.mdx

@@ -13,7 +13,7 @@ with one another. This enables the following features:
 
 - Services on all clusters can make calls to each other through Consul Service Mesh.
 - [Intentions](/docs/connect/intentions) can be used to enforce rules about which services can communicate across all clusters.
-- [L7 Routing Rules](/docs/connect/l7-traffic-management) can enable multi-cluster failover
+- [L7 Routing Rules](/docs/connect/l7-traffic) can enable multi-cluster failover
   and traffic splitting.
 - The Consul UI has a drop-down menu that lets you navigate between datacenters.