diff --git a/product_docs/docs/pgd/5/routing/readonly.mdx b/product_docs/docs/pgd/5/routing/readonly.mdx
index 41d3869c5b9..5d81cb32609 100644
--- a/product_docs/docs/pgd/5/routing/readonly.mdx
+++ b/product_docs/docs/pgd/5/routing/readonly.mdx
@@ -7,9 +7,9 @@ navTitle: Read-only routing
 
 By default, PGD Proxy routes connections to the currently selected write leader in the cluster. This allows the write traffic conflicts to be rapidly and consistently resolved. Just routing everything to a single node, the write leader, is a natural fit for traditional high availability deployments where system throughput is typically limited to the throughput of what a single node can handle.
 
-But for some use cases, this behavior also means that clients that are only querying the data are also placing a load on the current write leader. It's possible this writer leader could be equally well served by one of the non-write leader nodes in the cluster. 
+But for some use cases, this behavior also means that clients that are only querying the data are also placing a load on the current write leader. It's possible this read-only workload could be equally well served by one of the non-write leader nodes in the cluster. 
 
-If you could move traffic that was read-only queries to the non-write leader nodes, you could, at least in theory, handle a throughput which could be a multiple of a single nodes capability. 
+If you could move traffic that has read-only queries to the non-write leader nodes, you could, at least in theory, handle a throughput which could be a multiple of a single nodes capability. 
 An approach like this would, though, usually require changes to applications so that they were aware of details of cluster topology and the current node status to detect the write leader.
 
 ## Read-only routing in PGD Proxy