chore: rewrite internal redirects (#32038)

website/docs/cli/auth/index.mdx

@@ -9,7 +9,7 @@ description: >-
 
 > **Hands-on:** Try the [Authenticate the CLI with Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-login?in=terraform/cloud&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
 
-[Terraform Cloud](/cloud) and
+[Terraform Cloud](https://cloud.hashicorp.com/products/terraform) and
 [Terraform Enterprise](/enterprise) are platforms that perform
 Terraform runs to provision infrastructure, offering a collaboration-focused
 environment that makes it easier for teams to use Terraform together. (For

website/docs/cli/cloud/migrating.mdx

@@ -17,7 +17,7 @@ When you run `terraform init` in the following scenarios, Terraform will ask you
 > **Hands On:** Try the [Migrate State to Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-migrate) tutorial.
 
 If the working directory already has state data available (using either local state or a [state
-backend](/language/settings/backends)), Terraform asks your approval to migrate
+backend](/language/settings/backends/configuration)), Terraform asks your approval to migrate
 that state to Terraform Cloud. You will need permission to manage workspaces in the destination Terraform Cloud organization. This process is interactive and self-documenting, and resembles
 moving between state backends.
 

website/docs/cli/cloud/settings.mdx

@@ -44,7 +44,7 @@ terraform {
 The `cloud` block also has some special restrictions:
 
 - A configuration can only provide one `cloud` block.
-- A `cloud` block cannot be used with [state backends](/language/settings/backends).
+- A `cloud` block cannot be used with [state backends](/language/settings/backends/configuration).
   A configuration can use one or the other, but not both.
 - A `cloud` block cannot refer to named values (like input variables, locals, or
   data source attributes).
@@ -98,7 +98,7 @@ Use the following environment variables to configure the `cloud` block:
 
 - `TF_CLOUD_HOSTNAME` - The hostname of a Terraform Enterprise installation. Terraform reads this when `hostname` is omitted from the `cloud` block. If both are specified, the configuration takes precendence.
 
-- `TF_WORKSPACE` - The name of a single Terraform Cloud workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. Terraform Cloud will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](https://www.terraform.io/cli/config/environment-variables#tf_workspace) for details.
+- `TF_WORKSPACE` - The name of a single Terraform Cloud workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. Terraform Cloud will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/cli/config/environment-variables#tf_workspace) for details.
 
 ## Excluding Files from Upload with .terraformignore
 

website/docs/cli/commands/0.12upgrade.mdx

@@ -11,7 +11,7 @@ The `terraform 0.12upgrade` command applies several automatic upgrade rules to
 help prepare a module that was written for Terraform v0.11 to be used
 with Terraform v0.12.
 
--> **This command is available only in Terraform v0.12 releases.** For more information, see [the Terraform v0.12 upgrade guide](/language/upgrade-guides/0-12).
+-> **This command is available only in Terraform v0.12 releases.** For more information, see [the Terraform v0.12 upgrade guide](/language/v1.1.x/upgrade-guides/0-12).
 
 ## Usage
 

website/docs/cli/commands/0.13upgrade.mdx

@@ -11,7 +11,7 @@ The `terraform 0.13upgrade` command updates existing configuration to add an
 explicit `source` attribute for each provider used in a given module. The
 provider source settings are stored in a `required_providers` block.
 
--> **This command is available only in Terraform v0.13 releases.** For more information, see [the Terraform v0.13 upgrade guide](/language/upgrade-guides/0-13).
+-> **This command is available only in Terraform v0.13 releases.** For more information, see [the Terraform v0.13 upgrade guide](/language/v1.1.x/upgrade-guides/0-13).
 
 ## Usage
 

website/docs/cli/commands/apply.mdx

@@ -107,7 +107,7 @@ that directory as the root module instead of the current working directory.
 
 That usage was deprecated in Terraform v0.14 and removed in Terraform v0.15.
 If your workflow relies on overriding the root module directory, use
-[the `-chdir` global option](/cli/commands/#switching-working-directory-with-chdir)
+[the `-chdir` global option](/cli/commands#switching-working-directory-with-chdir)
 instead, which works across all commands and makes Terraform consistently look
 in the given directory for all files it would normally read or write in the
 current working directory.

website/docs/cli/commands/init.mdx

@@ -192,7 +192,7 @@ that directory as the root module instead of the current working directory.
 That usage is still supported in Terraform v0.14, but is now deprecated and we
 plan to remove it in Terraform v0.15. If your workflow relies on overriding
 the root module directory, use
-[the `-chdir` global option](/cli/commands/#switching-working-directory-with-chdir)
+[the `-chdir` global option](/cli/commands#switching-working-directory-with-chdir)
 instead, which works across all commands and makes Terraform consistently look
 in the given directory for all files it would normally read or write in the
 current working directory.

website/docs/cli/commands/plan.mdx

@@ -350,7 +350,7 @@ module instead of the current working directory.
 
 That usage was deprecated in Terraform v0.14 and removed in Terraform v0.15.
 If your workflow relies on overriding the root module directory, use
-[the `-chdir` global option](/cli/commands/#switching-working-directory-with-chdir)
+[the `-chdir` global option](/cli/commands#switching-working-directory-with-chdir)
 instead, which works across all commands and makes Terraform consistently look
 in the given directory for all files it would normally read or write in the
 current working directory.

website/docs/cli/commands/state/push.mdx

@@ -17,7 +17,7 @@ manual intervention is necessary with the remote state.
 Usage: `terraform state push [options] PATH`
 
 This command pushes the state specified by PATH to the currently
-configured [backend](/language/settings/backends).
+configured [backend](/language/settings/backends/configuration).
 
 If PATH is "-" then the state data to push is read from stdin. This data
 is loaded completely into memory and verified prior to being written to

website/docs/cli/config/config-file.mdx

@@ -76,7 +76,7 @@ The following settings can be set in the CLI configuration file:
 
 ## Credentials
 
-[Terraform Cloud](/cloud) provides a number of remote network
+[Terraform Cloud](https://cloud.hashicorp.com/products/terraform) provides a number of remote network
 services for use with Terraform, and
 [Terraform Enterprise](/enterprise) allows hosting those
 services inside your own infrastructure. For example, these systems offer both

website/docs/cli/workspaces/index.mdx

@@ -81,6 +81,6 @@ Workspaces are also meant to be a shared resource. They are not private, unless
 
 For local state, Terraform stores the workspace states in a directory called `terraform.tfstate.d`. This directory should be treated similarly to local-only `terraform.tfstate`. Some teams commit these files to version control, but we recommend using a remote backend instead when there are multiple collaborators.
 
-For [remote state](/language/state/remote), the workspaces are stored directly in the configured [backend](/language/settings/backends). For example, if you use [Consul](/language/settings/backends/consul), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name must be valid to use in a URL path segment without escaping.
+For [remote state](/language/state/remote), the workspaces are stored directly in the configured [backend](/language/settings/backends/configuration). For example, if you use [Consul](/language/settings/backends/consul), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name must be valid to use in a URL path segment without escaping.
 
 Terraform stores the current workspace name locally in the ignored `.terraform` directory. This allows multiple team members to work on different workspaces concurrently. Workspace names are also attached to associated remote workspaces in Terraform Cloud. For more details about workspace names in Terraform Cloud, refer to the [CLI Integration (recommended)](/cli/cloud/settings#arguments) and [remote backend](/language/settings/backends/remote#workspaces) and  documentation.

website/docs/configuration/resources.mdx

@@ -34,7 +34,7 @@ Each resource meta-argument has moved to its own page:
 - [`for_each`](/language/meta-arguments/for_each)
 - [`provider`](/language/meta-arguments/resource-provider)
 - [`lifecycle`](/language/meta-arguments/lifecycle)
-- [Provisioners](/language/resources/provisioners)
+- [Provisioners](/language/resources/provisioners/syntax)
 
 <div style={{height: '100vh', margin: 0, padding: 0}} />
 
@@ -88,6 +88,6 @@ This information has moved to
 ### Provisioners
 
 This information has moved to
-[Provisioners](/language/resources/provisioners).
+[Provisioners](/language/resources/provisioners/syntax).
 
 <div style={{height: '100vh', margin: 0, padding: 0}} />

website/docs/internals/login-protocol.mdx

@@ -107,7 +107,7 @@ authorization errors once the token expires, after which the user can run
 
 -> **Note:** As a special case, Terraform can use a
 [Resource Owner Password Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.3)
-only when interacting with `app.terraform.io` ([Terraform Cloud](/cloud)),
+only when interacting with `app.terraform.io` ([Terraform Cloud](https://cloud.hashicorp.com/products/terraform)),
 under the recommendation in the OAuth specification to use this grant type only
 when the client and server are closely related. The `password` grant type is
 not supported for any other hostname and will be ignored.

website/docs/intro/index.mdx

@@ -48,7 +48,7 @@ Terraform configuration files are declarative, meaning that they describe the en
 
 ### Standardize configurations
 
-Terraform supports reusable configuration components called [modules](/docs/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the Terraform Registry, or write your own.
+Terraform supports reusable configuration components called [modules](/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the Terraform Registry, or write your own.
 
 ### Collaborate
 

website/docs/intro/terraform-editions.mdx

@@ -27,8 +27,8 @@ Terraform open source lets you:
 
 - Get Started tutorials for popular providers: [Amazon Web Services](https://learn.hashicorp.com/collections/terraform/aws-get-started), [Azure](https://learn.hashicorp.com/collections/terraform/azure-get-started), [Google Cloud Platform](https://learn.hashicorp.com/collections/terraform/gcp-get-started), [Oracle Cloud Infrastructure](https://learn.hashicorp.com/collections/terraform/oci-get-started), and [Docker](https://learn.hashicorp.com/collections/terraform/docker-get-started)
 - [What is Terraform?](/intro)
-- [Configuration Language Documentation](/docs/language/index.html)
-- [CLI Documentation](/docs/cli/index.html)
+- [Configuration Language Documentation](/language)
+- [CLI Documentation](/cli)
 
 ## Terraform Cloud
 
@@ -48,9 +48,9 @@ Terraform Cloud lets you:
 
 ### Resources
 
-- [Create a Terraform Cloud Account](https://app.terraform.io/signup/account)
-- [Terraform Cloud Documentation](/docs/cloud/index.html)
-- [Sentinel Documentation](/cloud-docs/sentinel)
+- [Create a Terraform Cloud Account](https://app.terraform.io/public/signup/account)
+- [Terraform Cloud Documentation](/cloud-docs)
+- [Sentinel Documentation](/cloud-docs/policy-enforcement)
 - [Get Started - Terraform Cloud](https://learn.hashicorp.com/collections/terraform/cloud-get-started) tutorials show you how to manage infrastructure using Terraform Cloud's VCS integration
 
 ## Terraform Enterprise
@@ -66,5 +66,5 @@ Terraform Enterprise lets you:
 
 ### Resources
 - [Terraform Pricing](https://www.hashicorp.com/products/terraform/pricing)
-- [Terraform Enterprise Documentation](/docs/enterprise/index.html)
+- [Terraform Enterprise Documentation](/enterprise)
 - [Recommended Enterprise Patterns](https://learn.hashicorp.com/collections/terraform/recommended-patterns) guides

website/docs/intro/use-cases.mdx

@@ -8,7 +8,7 @@ description: |-
 
 # Use Cases
 
-[HashiCorp Terraform](/intro/index.html) is an infrastructure as code tool that lets you define infrastructure resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to safely and efficiently provision and manage your infrastructure throughout its lifecycle.
+[HashiCorp Terraform](/intro) is an infrastructure as code tool that lets you define infrastructure resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to safely and efficiently provision and manage your infrastructure throughout its lifecycle.
 
 This page describes popular Terraform use cases and provides related resources that you can use to create Terraform configurations and workflows.
 
@@ -50,7 +50,7 @@ Terraform can help you enforce policies on the types of resources teams can prov
 
 - Try the [Control Costs with Policies](https://learn.hashicorp.com/tutorials/terraform/cost-estimation) tutorial to estimate the cost of infrastructure changes and define policy to limit it.
 
-- The [Sentinel documentation](/docs/cloud/sentinel/index.html) provides more in-depth information and a list of example policies that you can adapt for your use cases.
+- The [Sentinel documentation](/cloud-docs/policy-enforcement) provides more in-depth information and a list of example policies that you can adapt for your use cases.
 
 
 ## PaaS Application Setup
@@ -65,7 +65,7 @@ Try the [Deploy, Manage, and Scale an Application on Heroku](https://learn.hashi
 
 Terraform can interact with Software Defined Networks (SDNs) to automatically configure the network according to the needs of the applications running in it. This lets you move from a ticket-based workflow to an automated one, reducing deployment times.
 
-For example, when a service registers with [HashiCorp Consul](https://www.consul.io/), [Consul-Terraform-Sync](https://www.consul.io/docs/nia) can automatically generate Terraform configuration to expose appropriate ports and adjust network settings for any SDN that has an associated Terraform provider. Network Infrastructure Automation (NIA) allows you to safely approve the changes that your applications require without having to manually translate tickets from developers into the changes you think their applications need.
+For example, when a service registers with [HashiCorp Consul](https://www.consul.io/), [Consul-Terraform-Sync](https://developer.hashicorp.com/consul/docs/nia) can automatically generate Terraform configuration to expose appropriate ports and adjust network settings for any SDN that has an associated Terraform provider. Network Infrastructure Automation (NIA) allows you to safely approve the changes that your applications require without having to manually translate tickets from developers into the changes you think their applications need.
 
 ### Resources
 

website/docs/language/functions/timestamp.mdx

@@ -20,7 +20,7 @@ Terraform run. We do not recommend using this function in resource attributes,
 but in rare cases it can be used in conjunction with
 [the `ignore_changes` lifecycle meta-argument](/language/meta-arguments/lifecycle#ignore_changes)
 to take the timestamp only on initial creation of the resource. For more stable
-time handling, see the [Time Provider](https://registry.terraform.io/providers/hashicorp/time/).
+time handling, see the [Time Provider](https://registry.terraform.io/providers/hashicorp/time).
 
 Due to the constantly changing return value, the result of this function cannot
 be predicted during Terraform's planning phase, and so the timestamp will be

website/docs/language/index.mdx

@@ -8,7 +8,7 @@ description: >-
 
 This is the documentation for Terraform's configuration language. It is relevant
 to users of [Terraform CLI](/cli),
-[Terraform Cloud](/cloud), and
+[Terraform Cloud](https://cloud.hashicorp.com/products/terraform), and
 [Terraform Enterprise](/enterprise). Terraform's language is
 its primary user interface. Configuration files you write in Terraform
 language tell Terraform what plugins to install, what infrastructure to create,

website/docs/language/modules/index.mdx

@@ -44,7 +44,7 @@ download them automatically if you specify the appropriate source and version in
 a module call block.
 
 Also, members of your organization might produce modules specifically crafted
-for your own infrastructure needs. [Terraform Cloud](/cloud) and
+for your own infrastructure needs. [Terraform Cloud](https://cloud.hashicorp.com/products/terraform) and
 [Terraform Enterprise](/enterprise) both include a private
 module registry for sharing modules internally within your organization.
 

website/docs/language/settings/backends/gcs.mdx

@@ -91,7 +91,7 @@ To get started, follow this guide: [Use customer-managed encryption keys](https:
 
 If you want to remove customer-managed keys from your backend configuration or change to a different customer-managed key, Terraform _can_ manage a state migration without manual intervention. This ability is because GCP stores customer-managed encryption keys and are accessible during the state migration process. However, these changes do not fully come into effect until the first write operation occurs on the state file after state migration occurs. In the first write operation after state migration, the file decrypts with the old key and then writes with the new encryption method. This method is equivalent to the [rewrite](https://cloud.google.com/storage/docs/gsutil/commands/rewrite) operation described in the customer-supplied encryption keys section. Because of the importance of the first write to state after state migration, you should not delete old KMS keys until any state file(s) encrypted with that key update.
 
-Customer-managed keys do not need to be sent in requests to read files from GCS buckets because decryption occurs automatically within GCS. This process means that if you use the `terraform_remote_state` [data source](https://www.terraform.io/language/state/remote-state-data) to access KMS-encrypted state, you do not need to specify the KMS key in the data source's `config` object. 
+Customer-managed keys do not need to be sent in requests to read files from GCS buckets because decryption occurs automatically within GCS. This process means that if you use the `terraform_remote_state` [data source](/language/state/remote-state-data) to access KMS-encrypted state, you do not need to specify the KMS key in the data source's `config` object. 
 
 ~> **Important:** To use customer-managed encryption keys, you need to create a key and give your project's GCS service agent permission to use it with the Cloud KMS CryptoKey Encrypter/Decrypter predefined role. 
 

website/docs/language/settings/backends/local.mdx

@@ -89,7 +89,7 @@ backend type selected.
 
 We do not recommend using these options in new systems, even if you are running
 Terraform in automation. Instead,
-[select a different backend which supports remote state](/language/settings/backends) and configure it
+[select a different backend which supports remote state](/language/settings/backends/configuration) and configure it
 within your root module, which ensures that everyone working on your
 configuration will automatically retrieve and store state in the correct shared
 location without any special command line options.

website/docs/language/settings/terraform-cloud.mdx

@@ -14,7 +14,7 @@ Terraform through version control or the API.
 
 ## Usage Example
 
-To configure the Terraform Cloud CLI integration, add a nested `cloud` block within the `terraform` block. You cannot use the CLI integration and a [state backend](/language/settings/backends) in the same configuration.
+To configure the Terraform Cloud CLI integration, add a nested `cloud` block within the `terraform` block. You cannot use the CLI integration and a [state backend](/language/settings/backends/configuration) in the same configuration.
 
 Refer to [Using Terraform Cloud](/cli/cloud) in the Terraform CLI documentation for full configuration details, migration instructions, and command line arguments.
 

website/docs/language/state/locking.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # State Locking
 
-If supported by your [backend](/language/settings/backends), Terraform will lock your
+If supported by your [backend](/language/settings/backends/configuration), Terraform will lock your
 state for all operations that could write state. This prevents
 others from acquiring the lock and potentially corrupting your state.
 
@@ -21,7 +21,7 @@ a status message. If Terraform doesn't output a message, state locking is
 still occurring if your backend supports it.
 
 Not all backends support locking. The
-[documentation for each backend](/language/settings/backends)
+[documentation for each backend](/language/settings/backends/configuration)
 includes details on whether it supports locking or not.
 
 ## Force Unlock

website/docs/language/state/remote-state-data.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # The `terraform_remote_state` Data Source
 
-[backends]: /language/settings/backends
+[backends]: /language/settings/backends/configuration
 
 The `terraform_remote_state` data source uses the latest state snapshot from a specified state backend to retrieve the root module output values
 from some other Terraform configuration.
@@ -68,7 +68,7 @@ use of. For example:
   store or Consul service catalog can make that data also accessible via
   [Consul Template](https://github.com/hashicorp/consul-template)
   or the
-  [HashiCorp Nomad](https://www.nomadproject.io/docs/job-specification/template)
+  [HashiCorp Nomad](https://developer.hashicorp.com/nomad/docs/job-specification/template)
   `template` stanza.
 * If you use Kubernetes then you can
   [make Config Maps available to your Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/).
@@ -153,7 +153,7 @@ The following arguments are supported:
 
   The `config` object can use any arguments that would be valid in the
   equivalent `terraform { backend "<TYPE>" { ... } }` block. See
-  [the documentation of your chosen backend](/language/settings/backends)
+  [the documentation of your chosen backend](/language/settings/backends/configuration)
   for details.
 
   -> **Note:** If the backend configuration requires a nested block, specify

website/docs/language/state/remote.mdx

@@ -18,7 +18,7 @@ which can then be shared between all members of a team. Terraform supports
 storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/),
 [HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
 
-Remote state is implemented by a [backend](/language/settings/backends) or by
+Remote state is implemented by a [backend](/language/settings/backends/configuration) or by
 Terraform Cloud, both of which you can configure in your configuration's root module.
 
 ## Delegation and Teamwork

website/docs/language/state/sensitive-data.mdx

@@ -27,7 +27,7 @@ and some backends can be configured to encrypt the state data at rest.
 
 For example:
 
-- [Terraform Cloud](/cloud) always encrypts state at rest and
+- [Terraform Cloud](https://cloud.hashicorp.com/products/terraform) always encrypts state at rest and
   protects it with TLS in transit. Terraform Cloud also knows the identity of
   the user requesting state and maintains a history of state changes. This can
   be used to control access and track activity. [Terraform Enterprise](/enterprise)

website/docs/language/state/workspaces.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Workspaces
 
-Each Terraform configuration has an associated [backend](/language/settings/backends) that defines how Terraform executes operations and where Terraform stores persistent data, like [state](/language/state/purpose).
+Each Terraform configuration has an associated [backend](/language/settings/backends/configuration) that defines how Terraform executes operations and where Terraform stores persistent data, like [state](/language/state/purpose).
 
 The persistent data stored in the backend belongs to a workspace. The backend initially has only one workspace containing one Terraform state associated with that configuration. Some backends support multiple named workspaces, allowing multiple states to be associated with a single configuration. The configuration still has only one backend, but you can deploy multiple distinct instances of that configuration without configuring a new backend or changing authentication
 credentials.