diff --git a/solr/solr-ref-guide/src/colocating-collections.adoc b/solr/solr-ref-guide/src/colocating-collections.adoc
index cc6b5184b6e..a641b4e2099 100644
--- a/solr/solr-ref-guide/src/colocating-collections.adoc
+++ b/solr/solr-ref-guide/src/colocating-collections.adoc
@@ -18,24 +18,24 @@
 // specific language governing permissions and limitations
 // under the License.
 
-Solr provides a way to co-locate a collection with another so that cross-collection joins are always possible.
+Solr provides a way to colocate a collection with another so that cross-collection joins are always possible.
 
-The co-location guarantee applies to all future Collection operations made either via Collections API or by Autoscaling
+The colocation guarantee applies to all future Collection operations made either via Collections API or by Autoscaling
 actions.
 
 A collection may only be colocated with exactly one `withCollection`. However, arbitrarily many collections may be
 _linked_ to the same `withCollection`.
 
-== Create Collection using `withCollection`
+== Create a Colocated Collection
 The Create Collection API supports a parameter named `withCollection` which can be used to specify a collection
-with which the replicas of the newly created collection should be co-located. See <<collections-api.adoc#create, Create Collection API>>
+with which the replicas of the newly created collection should be colocated. See <<collections-api.adoc#create,Create Collection API>>.
 
 `/admin/collections?action=CREATE&name=techproducts&numShards=1&replicationFactor=2&withCollection=tech_categories`
 
-In the above example, all replicas of the `techproducts` collection will be co-located on a node with at least one
+In the above example, all replicas of the `techproducts` collection will be colocated on a node with at least one
 replica of the `tech_categories` collection.
 
-== Colocating existing collections
+== Colocating Existing Collections
 When collections already exist beforehand, the <<collections-api.adoc#modifycollection, Modify Collection API>> can be
 used to set the `withCollection` parameter so that the two collections can be linked. This will *not* trigger
 changes to the cluster automatically because moving a large number of replicas immediately might de-stabilize the system.
@@ -45,20 +45,20 @@ to change the cluster manually.
 Example:
 `/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=tech_categories`
 
-== Deleting colocated collections
+== Deleting Colocated Collections
 Deleting a collection which has been linked to another will fail unless the link itself is deleted first by using the
 <<collections-api.adoc#modifycollection, Modify Collection API>> to un-set the `withCollection` attribute.
 
 Example:
 `/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=`
 
-== Limitations and caveats
+== Limitations and Caveats
 
 The collection being used as the `withCollection` must have one shard only and that shard should be named `shard1`. Note
 that when using the default router, the shard name is always set to `shard1` but special care must be taken to name the
 shard as `shard1` when using the implicit router.
 
-In case new replicas of the `withCollection` have to be added to maintain the co-location guarantees then the new replicas
+In case new replicas of the `withCollection` have to be added to maintain the colocation guarantees then the new replicas
 will be of type `NRT` only. Automatically creating replicas of `TLOG` or `PULL` types is not supported.
 
 In case, replicas have to be moved from one node to another, perhaps in response to a node lost trigger, then the target
@@ -70,7 +70,7 @@ which can prevent such overloading by e.g. setting the maximum number of cores p
 Example:
 `{'cores' : '<8', 'node' : '#ANY'}`
 
-The co-location guarantee is one-way only i.e. a collection 'X' co-located with 'Y' will always have one or more
+The colocation guarantee is one-way only i.e., a collection 'X' colocated with 'Y' will always have one or more
 replicas of 'Y' on any node that has a replica of 'X' but the reverse is not true. There may be nodes which have one or
-more replicas of 'Y' but no replicas of 'X'. Such replicas of 'Y' will not be considered a violation of co-location
-rules and will not be cleaned up automatically.
\ No newline at end of file
+more replicas of 'Y' but no replicas of 'X'. Such replicas of 'Y' will not be considered a violation of colocation
+rules and will not be cleaned up automatically.