diff --git a/website/content/docs/connect/cluster-peering/create-manage-peering.mdx b/website/content/docs/connect/cluster-peering/create-manage-peering.mdx
index 548b56218e..ba42697099 100644
--- a/website/content/docs/connect/cluster-peering/create-manage-peering.mdx
+++ b/website/content/docs/connect/cluster-peering/create-manage-peering.mdx
@@ -24,7 +24,7 @@ You can generate peering tokens and initiate connections from either the server
 
 To begin the cluster peering process, generate a peering token in one of your clusters. The other cluster uses this token to establish the peering connection.
 
-In “cluster-01,” run the ``generate-token`` command.
+In “cluster-01,” run the `generate-token` command.
 
 ```shell-session
 $ consul peering generate-token -peer="cluster-02"
@@ -32,7 +32,7 @@ $ consul peering generate-token -peer="cluster-02"
 
 The CLI outputs the peering token, which is an encoded string of alphanumeric characters and symbols.
 
-For the peering token to function correctly, you must enter the second cluster’s exact name in the ``peer`` parameter.
+For the peering token to function correctly, you must enter the second cluster’s exact name in the `peer` parameter.
 
 ## Establish a connection between clusters
 
@@ -42,15 +42,15 @@ Next, use the peering token to establish a secure connection between the cluster
 $ consul peering establish -peer="cluster-01" -token="eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlNvbHIifQ.5T7L_L1MPfQ_5FjKGa1fTPqrzwK4bNSM812nW6oyjb8"
 ```
 
-In the peer parameter, specify the first cluster’s exact name. The ``token`` parameter should include the entire peering token created in the first cluster.
+In the peer parameter, specify the first cluster’s exact name. The `token` parameter should include the entire peering token created in the first cluster.
 
-When you connect server agents through cluster peering, they will peer through their default partitions. To connect other partitions through server agents, you must specify the partitions you want to peer using the ``partition`` parameter.
+When you connect server agents through cluster peering, they will peer through their default partitions. To connect other partitions through server agents, you must specify the partitions you want to peer using the `partition` parameter.
 
 ## Connect service endpoints
 
 After you establish a connection between the clusters, you need to create a configuration entry that defines the services that are available for other clusters. Consul uses this configuration entry to make services and support queries for service mesh available to peered clusters.
 
-First, create a configuration entry and specify the ``Kind`` as ``“exported-services”``.
+First, create a configuration entry and specify the `Kind` as `“exported-services”`.
 
 <CodeBlockConfig filename="peering-config.hcl">
 
@@ -88,7 +88,7 @@ Before you proceed, wait for the clusters to sync and make services available to
 
 Before you can call services from peered clusters, you must set service intentions that authorize those clusters to use specific services. Consul prevents services from being exported to unauthorized clusters.
 
-First, create a configuration entry and specify the ``Kind`` as ``“service-intentions”``. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "backend-service" can access "frontend-service."
+First, create a configuration entry and specify the `Kind` as `“service-intentions”`. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "backend-service" can access "frontend-service."
 
 <CodeBlockConfig filename="peering-intentions.hcl">
 
@@ -108,7 +108,7 @@ Sources = [
 
 </CodeBlockConfig>
 
-**Tip:** If the peer’s name is not specified in ``Peer``, then Consul assumes that the service is in the local cluster.
+**Tip:** If the peer’s name is not specified in `Peer`, then Consul assumes that the service is in the local cluster.
 
 Then, add the configuration entry to your cluster.
 
@@ -118,20 +118,20 @@ $ consul config write peering-intentions.hcl
 
 ## Check peered cluster status
 
-To confirm that you peered your clusters, you can [query the ``/health/service`` endpoint](https://www.consul.io/api-docs/health) of one cluster from the other cluster. For example, in "cluster-02," query the endpoint and add the ``peer=cluster-01`` parameter to the end of the URL.
+To confirm that you peered your clusters, you can [query the `/health/service` endpoint](https://www.consul.io/api-docs/health) of one cluster from the other cluster. For example, in "cluster-02," query the endpoint and add the `peer=cluster-01` parameter to the end of the URL.
 
 ```shell-session
 $ curl \
     http://127.0.0.1:8500/v1/health/service/service-name?peer=cluster-01
 ```
 
-Successful connections include ``"Status": "passing"`` in the output.
+Successful connections include `"Status": "passing"` in the output.
 
 ## Remove peering connections
 
 After you create a peering connection between clusters in different datacenters, you can “unpeer” the connected clusters. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates.
 
-In “cluster-01,” run the ``peering delete`` command.
+In “cluster-01,” run the `peering delete` command.
 
 ```shell-session
 $ consul peering delete -peer="cluster-02"