website: Fix numerous links with redirects or broken anchors

These links largely still go somewhere useful, but they have some kind of issue
revealed by our new link checker:

- Some of them point to a stale URL that redirects, and can be updated to the
  new destination.
- Some of them point to anchors that don't exist (anymore?) in the destination.
- Some of them end up redirecting unnecessarily due to how the server handles
  directory URLs without trailing slashes. Sorry, I know that's pointless, just,
  humor me for the time being so we can get our CI green. 😭

In a couple cases, I've added invisible anchors to destination pages, either to
preserve an old habit or because the current anchors kind of suck due to being
particularly long or meandering.

website/docs/backends/state.html.md

@@ -66,7 +66,7 @@ prior to forcing the overwrite.
 
 Backends are responsible for supporting [state locking](/docs/state/locking.html)
 if possible. Not all backend types support state locking. In the
-[list of supported backend types](/docs/backends/types) we explicitly note
+[list of supported backend types](/docs/backends/types/index.html) we explicitly note
 whether locking is supported.
 
 For more information on state locking, view the

website/docs/commands/0.13upgrade.html.markdown

@@ -23,7 +23,7 @@ providers are in use for a module, detect the source address for those
 providers where possible, and record this information in a
 [`required_providers` block][required-providers].
 
-[required-providers]: /docs/configuration/terraform.html#specifying-required-provider-versions
+[required-providers]: /docs/configuration/provider-requirements.html
 
 ~> Note: the command ignores `.tf.json` files and override files in the module.
 

website/docs/commands/apply.html.markdown

@@ -72,11 +72,11 @@ The command-line flags are all optional. The list of available flags are:
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
-  specified via this flag.
+  [literal expressions](/docs/configuration/expressions/types.html) in the
+  Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-files). If
+  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files
@@ -92,7 +92,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](./#switching-working-directory-with--chdir)
+[the `-chdir` global option](./#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 normaly read or write in the
 current working directory.
@@ -100,6 +100,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
+[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/commands/import.html.md

@@ -75,11 +75,12 @@ in the configuration for the target resource, and that is the best behavior in m
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
-  specified via this flag. This is only useful with the `-config` flag.
+  [literal expressions](/docs/configuration/expressions/types.html) in the
+  Terraform language, so list and map values can be specified via this flag.
+  This is only useful with the `-config` flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-files). If
+  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files

website/docs/commands/init.html.markdown

@@ -142,10 +142,12 @@ You can modify `terraform init`'s plugin behavior with the following options:
   cause Terraform to ignore any selections recorded in the dependency lock
   file, and to take the newest available version matching the configured
   version constraints.
-- `-get-plugins=false` — Skip plugin installation. _Note: Since Terraform 0.13, this
-  command has been superseded by [`provider_installation`](./cli-config.html#provider-installation)
-  blocks or using the [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) setting.
-  It should not be used in Terraform versions 0.13+.
+- `-get-plugins=false` — Skip plugin installation.
+
+    -> Note: Since Terraform 0.13, this option has been superseded by the
+    [`provider_installation`](./cli-config.html#provider-installation) and
+    [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) settings.
+    It should not be used in Terraform versions 0.13+.
 - `-plugin-dir=PATH` — Force plugin installation to read plugins _only_ from
   the specified directory, as if it had been configured as a `filesystem_mirror`
   in the CLI configuration. If you intend to routinely use a particular
@@ -176,7 +178,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](./#switching-working-directory-with--chdir)
+[the `-chdir` global option](./#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 normaly read or write in the
 current working directory.
@@ -184,6 +186,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
+[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/commands/plan.html.markdown

@@ -76,13 +76,13 @@ The available options are:
   Address](/docs/internals/resource-addressing.html) to target. This flag can
   be used multiple times. See below for more information.
 
-* `-var=foo=bar` - Set a variable in the Terraform configuration. This flag
+* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
-  specified via this flag.
+  [literal expressions](/docs/configuration/expressions/types.html) in the
+  Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-files). If
+  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files
@@ -142,7 +142,7 @@ 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](./#switching-working-directory-with--chdir)
+[the `-chdir` global option](./#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 normaly read or write in the
 current working directory.
@@ -150,6 +150,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR)
+[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/commands/refresh.html.markdown

@@ -56,11 +56,11 @@ The `terraform refresh` command accepts the following options:
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
-  specified via this flag.
+  [literal expressions](/docs/configuration/expressions/types.html) in the
+  Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-files). If
+  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files

website/docs/commands/state/push.html.md

@@ -20,7 +20,7 @@ manual intervention is necessary with the remote state.
 Usage: `terraform state push [options] PATH`
 
 This command will push the state specified by PATH to the currently
-configured [backend](/docs/backends).
+configured [backend](/docs/configuration/blocks/backends/index.html).
 
 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/configuration-0-11/interpolation.html.md

@@ -409,7 +409,7 @@ The supported built-in functions are:
 
   * `timestamp()` - Returns a UTC timestamp string in RFC 3339 format. This string will change with every
    invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the
-   [`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute.
+   [`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute.
 
   * `timeadd(time, duration)` - Returns a UTC timestamp string corresponding to adding a given `duration` to `time` in RFC 3339 format.
     For example, `timeadd("2017-11-22T00:00:00Z", "10m")` produces a value `"2017-11-22T00:10:00Z"`.
@@ -424,7 +424,7 @@ The supported built-in functions are:
 
   * `urlencode(string)` - Returns an URL-safe copy of the string.
 
-  * `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute.
+  * `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute.
 
   * `values(map)` - Returns a list of the map values, in the order of the keys
     returned by the `keys` function. This function only works on flat maps and

website/docs/configuration-0-11/modules.html.md

@@ -233,7 +233,7 @@ resource "aws_s3_bucket" "example" {
 This approach is recommended in the common case where only a single
 configuration is needed for each provider across the entire configuration.
 
-In more complex situations there may be [multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances),
+In more complex situations there may be [multiple provider instances](./providers.html#multiple-provider-instances),
 or a child module may need to use different provider settings than
 its parent. For such situations, it's necessary to pass providers explicitly
 as we will see in the next section.
@@ -272,7 +272,7 @@ module "example" {
 
 The `providers` argument within a `module` block is similar to
 the `provider` argument within a resource as described for
-[multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances),
+[multiple provider instances](./providers.html#multiple-provider-instances),
 but is a map rather than a single string because a module may contain resources
 from many different providers.
 

website/docs/configuration-0-11/providers.html.md

@@ -220,7 +220,7 @@ may also be used, but currently may cause errors when running `terraform destroy
 ## Third-party Plugins
 
 Anyone can develop and distribute their own Terraform providers. (See
-[Writing Custom Providers](/docs/extend/writing-custom-providers.html) for more
+[Writing Custom Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) for more
 about provider development.) These third-party providers must be manually
 installed, since `terraform init` cannot automatically download them.
 

website/docs/configuration-0-11/variables.html.md

@@ -211,7 +211,7 @@ $ TF_VAR_image=foo terraform apply
 ```
 
 Maps and lists can be specified using environment variables as well using
-[HCL](./syntax.html#HCL) syntax in the value.
+[HCL](./syntax.html) syntax in the value.
 
 For a list variable like so:
 

website/docs/configuration/meta-arguments/resource-provider.html.md

@@ -51,7 +51,7 @@ ensure that the provider is fully configured before any resource actions
 are taken.
 
 The `provider` meta-argument expects
-[a `<PROVIDER>.<ALIAS>` reference](/docs/configuration/providers.html#referring-to-alternate-providers),
+[a `<PROVIDER>.<ALIAS>` reference](/docs/configuration/providers.html#referring-to-alternate-provider-configurations),
 which does not need to be quoted. Arbitrary expressions are not permitted for
 `provider` because it must be resolved while Terraform is constructing the
 dependency graph, before it is safe to evaluate expressions.

website/docs/configuration/outputs.html.md

@@ -66,6 +66,8 @@ value as `module.web_server.instance_ip_addr`.
 
 `output` blocks can optionally include `description`, `sensitive`, and `depends_on` arguments, which are described in the following sections.
 
+<a id="description"></a>
+
 ### `description` — Output Value Documentation
 
 Because the output values of a module are part of its user interface, you can
@@ -85,6 +87,8 @@ string might be included in documentation about the module, and so it should be
 written from the perspective of the user of the module rather than its
 maintainer. For commentary for module maintainers, use comments.
 
+<a id="sensitive"></a>
+
 ### `sensitive` — Suppressing Values in CLI Output
 
 An output can be marked as containing sensitive material using the optional
@@ -151,6 +155,8 @@ Sensitive output values are still recorded in the
 to access the state data. For more information, see
 [_Sensitive Data in State_](/docs/state/sensitive-data.html).
 
+<a id="depends_on"></a>
+
 ### `depends_on` — Explicit Output Dependencies
 
 Since output values are just a means for passing data out of a module, it is

website/docs/configuration/providers.html.md

@@ -80,7 +80,7 @@ empty default configuration for any provider that is not explicitly configured.
 
 ## `alias`: Multiple Provider Configurations
 
-[inpage-alias]: #alias-multiple-provider-instances
+[inpage-alias]: #alias-multiple-provider-configurations
 
 You can optionally define multiple configurations for the same provider, and
 select which one to use on a per-resource or per-module basis. The primary

website/docs/configuration/resources.html.md

@@ -14,6 +14,7 @@ pages.
 <a id="resource-arguments"></a>
 <a id="documentation-for-resource-types"></a>
 <a id="meta-arguments"></a>
+<a id="timeouts"></a>
 <a id="operation-timeouts"></a>
 
 ## Syntax and Elements of Resource Blocks
@@ -66,7 +67,9 @@ This information has moved to
 
 
 <a id="count-multiple-resource-instances-by-count"></a>
+<a id="count-multiple-resource-instances"></a>
 <a id="the-count-object"></a>
+<a id="count-index"></a>
 <a id="referring-to-instances"></a>
 <a id="using-expressions-in-count"></a>
 <a id="when-to-use-for_each-instead-of-count"></a>
@@ -82,6 +85,8 @@ This information has moved to
 
 <a id="for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings"></a>
 <a id="the-each-object"></a>
+<a id="each-key"></a>
+<a id="each-value"></a>
 <a id="using-expressions-in-for_each"></a>
 <a id="referring-to-instances-1"></a>
 <a id="using-sets"></a>
@@ -107,6 +112,9 @@ This information has moved to
 
 
 <a id="lifecycle-lifecycle-customizations"></a>
+<a id="prevent_destroy"></a>
+<a id="create_before_destroy"></a>
+<a id="ignore_changes"></a>
 
 ### `lifecycle`
 

website/docs/configuration/variables.html.md

@@ -349,6 +349,8 @@ terraform apply -var='image_id_map={"us-east-1":"ami-abc123","us-east-2":"ami-de
 
 The `-var` option can be used any number of times in a single command.
 
+<a id="variable-files"></a>
+
 ### Variable Definitions (`.tfvars`) Files
 
 To set lots of variables, it is more convenient to specify their values in

website/docs/import/index.html.md

@@ -31,7 +31,7 @@ behavior. For more information on this assumption, see
 ## Currently State Only
 
 The current implementation of Terraform import can only import resources
-into the [state](/docs/state). It does not generate configuration. A future
+into the [state](/docs/state/). It does not generate configuration. A future
 version of Terraform will also generate configuration.
 
 Because of this, prior to running `terraform import` it is necessary to write

website/docs/internals/json-format.html.md

@@ -56,7 +56,7 @@ The extra wrapping object here will allow for any extension we may need to add i
 
 A plan consists of a prior state, the configuration that is being applied to that state, and the set of changes Terraform plans to make to achieve that.
 
-For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#value-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state.
+For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#values-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state.
 
 ```javascript
 {

website/docs/internals/remote-service-discovery.html.md

@@ -85,7 +85,7 @@ version 1 of the module registry protocol:
 
 At present, the following service identifiers are in use:
 
-* `login.v1`: [login protocol version 1](/docs/commands/login.html#protocol-v1)
+* `login.v1`: [login protocol version 1](/docs/commands/login.html)
 * `modules.v1`: [module registry API version 1](module-registry-protocol.html)
 * `providers.v1`: [provider registry API version 1](provider-registry-protocol.html)
 

website/docs/modules/providers.html.md

@@ -80,7 +80,7 @@ however, specify any of the configuration settings that determine what remote
 endpoints the provider will access, such as an AWS region; configuration
 settings come from provider _configurations_, and a particular overall Terraform
 configuration can potentially have
-[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-instances).
+[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-configurations).
 
 If you are writing a shared Terraform module, constrain only the minimum
 required provider version using a `>=` constraint. This should specify the

website/docs/plugins/basics.html.md

@@ -43,7 +43,6 @@ directory, located at `%APPDATA%\terraform.d\plugins` on Windows and
 For more information, see:
 
 - [Configuring Providers](/docs/configuration/providers.html)
-- [Configuring Providers: Third-party Plugins](/docs/configuration/providers.html#third-party-plugins)
 
 For developer-centric documentation, see:
 

website/docs/plugins/provider.html.md

@@ -75,9 +75,8 @@ an official release.
 When constructing a new provider from scratch, it's recommended to follow
 a similar repository structure as for the existing providers, with the main
 package in the repository root and a library package in a subdirectory named
-after the provider. For more information, see
-[Writing Custom Providers](/docs/extend/writing-custom-providers.html) in the
-[Extending Terraform section](/docs/extend/index.html).
+after the provider. For more information, see the
+[Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn.
 
 When making changes only to files within the provider repository, it is _not_
 necessary to re-build the main Terraform executable. Note that some packages

website/docs/provisioners/index.html.markdown

@@ -166,8 +166,13 @@ You must include [a `connection` block](./connection.html) so that Terraform
 will know how to communicate with the server.
 
 Terraform includes several built-in provisioners; use the navigation sidebar to
-view their documentation. You can also install third-party provisioners in
-[the user plugins directory](../configuration/providers.html#third-party-plugins).
+view their documentation.
+
+It's also possible to use third-party provisioners as plugins, by placing them
+in `%APPDATA%\terraform.d\plugins`, `~/.terraform.d/plugins`, or the same
+directory where the Terraform binary is installed. However, we do not recommend
+using any provisioners except the built-in `file`, `local-exec`, and
+`remote-exec` provisioners.
 
 All provisioners support the `when` and `on_failure` meta-arguments, which
 are described below (see [Destroy-Time Provisioners](#destroy-time-provisioners)

website/docs/state/locking.html.md

@@ -8,7 +8,7 @@ description: |-
 
 # State Locking
 
-If supported by your [backend](/docs/backends), Terraform will lock your
+If supported by your [backend](/docs/backends/), 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,8 +21,8 @@ If acquiring the lock is taking longer than expected, Terraform will output
 a status message. If Terraform doesn't output a message, state locking is
 still occurring if your backend supports it.
 
-Not all [backends](/docs/backends) support locking. Please view the list
-of [backend types](/docs/backends/types) for details on whether a backend
+Not all [backends](/docs/backends/) support locking. Please view the list
+of [backend types](/docs/backends/types/) for details on whether a backend
 supports locking or not.
 
 ## Force Unlock

website/docs/state/remote.html.md

@@ -19,7 +19,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 a feature of [backends](/docs/backends), which you can activate
+Remote state is a feature of [backends](/docs/backends/), which you can activate
 in your configuration's root module.
 
 ## Delegation and Teamwork

website/docs/state/workspaces.html.md

@@ -195,7 +195,7 @@ control, although using a remote backend instead is recommended when there are
 multiple collaborators.
 
 For [remote state](/docs/state/remote.html), the workspaces are stored
-directly in the configured [backend](/docs/backends). For example, if you
+directly in the configured [backend](/docs/backends/). For example, if you
 use [Consul](/docs/backends/types/consul.html), 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

website/guides/terraform-provider-development-program.html.md

@@ -13,7 +13,7 @@ The Verified badge helps users easily identify and discover integrations develop
 
 ![Verified Provider Card](/assets/images/docs/verified-card.png)
 
--> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Writing Custom Providers guide](https://www.terraform.io/docs/extend/writing-custom-providers.html) and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section.
+-> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IOhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section of the documentation.
 
 
 ## What is a Terraform Provider?
@@ -66,7 +66,7 @@ The provider development process is divided into five steps below. By following
 ![Provider Development Process](/assets/images/docs/program-steps.png)
 
 1. **Apply**: Initial contact between vendor and HashiCorp
-2. **Prepare**: Follow documentation while developing the provider 
+2. **Prepare**: Follow documentation while developing the provider
 3. **Verify**: Share public GPG key with HashiCorp
 4. **Publish**: Release the provider on the Registry
 5. **Support**: Ongoing maintenance and support of the provider by the vendor.
@@ -112,7 +112,7 @@ We’ve found the provider development process to be fairly straightforward and
 
 ### 3. Verify
 
-At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature. 
+At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature.
 
 -> **Important:** This step requires that you have signed and accepted our Technology Partner Agreement. If you have not received this, please see step #1 above.
 
@@ -128,7 +128,7 @@ $ gpg --armor --export "{Key ID or email address}"
 
 Once the verification step is complete please follow the steps on [Publishing a Provider](https://www.terraform.io/docs/registry/providers/publishing.html).  This step does not require additional involvement from HashiCorp as publishing is a fully self-service process in the [Terraform Registry](https://registry.terraform.io).
 
-Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly. 
+Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly.
 
 ### 5. Maintain & Support
 

website/upgrade-guides/0-10.html.markdown

@@ -60,9 +60,18 @@ eventually support a similar approach for third-party plugins, but we wish
 to ensure the robustness of the installation and versioning mechanisms before
 generalizing this feature.
 
-In the mean time,
-[the prior mechanisms for installing third-party providers](/docs/plugins/basics.html#installing-a-plugin)
-are still supported. Maintainers of third-party providers may optionally
+-> **Note:** As of Terraform 0.13, Terraform can automatically install
+third-party providers released on the Terraform Registry.
+
+In the mean time, third-party providers can be installed by placing them in the
+user plugins directory:
+
+Operating system  | User plugins directory
+------------------|-----------------------
+Windows           | `%APPDATA%\terraform.d\plugins`
+All other systems | `~/.terraform.d/plugins`
+
+Maintainers of third-party providers may optionally
 make use of the new versioning mechanism by naming provider binaries
 using the scheme `terraform-provider-NAME_v0.0.1`, where "0.0.1" is an
 example version. Terraform expects providers to follow the

website/upgrade-guides/0-13.html.markdown

@@ -44,7 +44,7 @@ Upgrade guide sections:
 * [New Filesystem Layout for Local Copies of Providers](#new-filesystem-layout-for-local-copies-of-providers)
   * [Special considerations for in-house providers](#in-house-providers)
 * [Destroy-time provisioners may not refer to other resources](#destroy-time-provisioners-may-not-refer-to-other-resources)
-* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by--refresh-false)
+* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by-refresh-false)
 * [Frequently Asked Questions](#frequently-asked-questions)
 
 ## Before You Upgrade
@@ -135,7 +135,7 @@ for a module that must remain compatible with both Terraform v0.12 and
 Terraform v0.13; the `terraform 0.13upgrade` result includes a conservative
 version constraint for Terraform v0.13 or later, which you can weaken to
 `>= 0.12.26` if you follow the guidelines in
-[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v012-compatible-provider-requirements).
+[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v0-12-compatible-provider-requirements).
 
 Each module must declare its own set of provider requirements, so if you have
 a configuration which calls other modules then you'll need to run this upgrade
@@ -441,7 +441,7 @@ accurate plan, and so there is no replacement mechanism in Terraform v0.13
 to restore the previous behavior.
 
 ## Frequently Asked Questions
-### Why do I see `-/provider` during init? 
+### Why do I see `-/provider` during init?
 
 Provider source addresses starting with `registry.terraform.io/-/` are a special
 way Terraform marks legacy addresses where the true namespace is unknown. For
@@ -473,7 +473,7 @@ While this does not cause any problems for Terraform, it has been confusing. You
 may circumvent this by using the `terraform state replace-provider` subcommand
 to tell Terraform exactly what provider addresses are required in state.
 Continuing from the example above, the following commands tell Terraform the
-source address for the `null` and `random` providers: 
+source address for the `null` and `random` providers:
 
 ```
 terraform state replace-provider -- -/random registry.terraform.io/hashicorp/random