diff --git a/docs/ec_vs_other_software.md b/docs/ec_vs_other_software.md
index cd05186cc..f33608ee8 100644
--- a/docs/ec_vs_other_software.md
+++ b/docs/ec_vs_other_software.md
@@ -16,7 +16,7 @@ this job, because of the JRE runtime. This means higher memory footprint and lat
 Linkerd v2 was rewritten in Rust to get better performance. Unfortunately, just like Istio - it's Kubernetes only.
 
 ### Consul Connect
-[Consul Connect](https://www.consul.io/docs/connect/index.html) is a simple way to deploy Envoy to current
+[Consul Connect](https://www.consul.io/docs/connect) is a simple way to deploy Envoy to current
 Consul based infrastructure.
 The problem with Consul Connect is that versions prior to 1.6.0 had very limited traffic control capabilities.
 We want to have a fallback to instances from other DCs, canary deployment and other features specific to our
@@ -35,4 +35,4 @@ Control Plane implementation on. They're not a sufficient Control Plane by thems
 Discovery Service.
 
 Envoy Control is based on Java Control Plane and integrates with Consul by default. It also adds features like
-Cross DC Synchronization or Permission management.
\ No newline at end of file
+Cross DC Synchronization or Permission management.
diff --git a/docs/features/multi_dc_support.md b/docs/features/multi_dc_support.md
index 54f5439ca..2d9e05e43 100644
--- a/docs/features/multi_dc_support.md
+++ b/docs/features/multi_dc_support.md
@@ -47,7 +47,7 @@ The state is available in `LocalClusterStateChanges#latestServiceState`.
 
 Then build a `RemoteServices` class providing:
 
-* [AsyncControlPlaneClient](https://github.com/allegro/envoy-control/blob/master/envoy-control-runner/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/synchronization/AsyncRestTemplateControlPlaneClient.kt) - an HTTP client
+* [AsyncControlPlaneClient](https://github.com/allegro/envoy-control/blob/master/envoy-control-runner/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/synchronization/RestTemplateControlPlaneClient.kt) - an HTTP client
 * [ControlPlaneInstanceFetcher](https://github.com/allegro/envoy-control/blob/master/envoy-control-source-consul/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/consul/synchronization/SimpleConsulInstanceFetcher.kt) - the strategy of retrieving other Envoy Control from given cluster
 * `remoteClusters` - list of remote clusters
 
diff --git a/docs/integrations/consul.md b/docs/integrations/consul.md
index bb648fbf0..4352293fe 100644
--- a/docs/integrations/consul.md
+++ b/docs/integrations/consul.md
@@ -7,7 +7,7 @@ first-class integration with Consul.
 
 Popular Service Mesh solutions provide integration with Consul by polling periodically the state of all services.
 Assuming we polled the state each second in order to minimize change propagation latency, we would have to send a request
-for a [list of services](https://www.consul.io/api/catalog.html#list-services) and then a 
+for a [list of services](https://www.consul.io/api/catalog#list-services) and then a 
 [request per each service](https://www.consul.io/api/catalog.html#list-nodes-for-service).
 With 1,000 services, this would generate 1,000 rps per one instance of Control Plane.