diff --git a/src/content/advanced/connectivity/ingress/service-type-loadbalancer/index.md b/src/content/advanced/connectivity/ingress/service-type-loadbalancer/index.md
index 0cce7fb5e7..db8c8a19f7 100644
--- a/src/content/advanced/connectivity/ingress/service-type-loadbalancer/index.md
+++ b/src/content/advanced/connectivity/ingress/service-type-loadbalancer/index.md
@@ -266,7 +266,7 @@ Always ensure to closely monitor the system throughout this entire process to mi
 
 There are several pitfalls and known limitations of AWS Network Load Balancers which can take a long time to troubleshoot.
 
-##### Martian Packets when using internal AWS Network Load Balancers.
+##### Martian Packets when using internal AWS Network Load Balancers
 
 When creating a service of type `LoadBalancer`, Kubernetes normally allocates node ports for each of the exposed ports. The cloud provider's load balancer then uses all your nodes in conjunction with those node ports in its target group to forward traffic into your cluster.
 
@@ -288,7 +288,7 @@ metadata:
 
 See [Target groups for your Network Load Balancers: Client IP preservation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#client-ip-preservation) for more information about this whole feature.
 
-##### Health Checks failing when using PROXY protocol and `externalTrafficPolicy: Local`.
+##### Health Checks failing when using PROXY protocol and `externalTrafficPolicy: Local`
 
 The before mentioned limitation directly leads us the next pitfall: One could think "well, if the integrated client IP preservation is not working, I can still use PROXY protocol". In theory and at least for the Kubernetes integrated Cloud Controller this should work. In theory.
 
@@ -302,7 +302,7 @@ Since the health check might get false negative when two pods are running on the
 
 At last this means there is currently no way of preserving the original client IP using internal AWS Network Load Balancers being accessed from inside the same cluster.
 
-##### Security Group configuration on internal AWS Network Load Balancers.
+##### Security Group configuration on internal AWS Network Load Balancers
 
 Last but not least there is one thing, you should take care of, left. If you are not accessing an internal AWS Network Load Balancer from inside your cluster and therefore can actually use the integrated client IP preservation, you might still want to access this load balancer from other internal sources, which is totally fine and working.