diff --git a/doc/modules/ROOT/pages/buckets.adoc b/doc/modules/ROOT/pages/buckets.adoc
index 181952c1..e403e5cb 100644
--- a/doc/modules/ROOT/pages/buckets.adoc
+++ b/doc/modules/ROOT/pages/buckets.adoc
@@ -4,7 +4,7 @@
 = Basics of Hash Tables
 
 The containers are made up of a number of _buckets_, each of which can contain
-any number of elements. For example, the following diagram shows a <<unordered_set,`boost::unordered_set`>> with 7 buckets containing 5 elements, `A`,
+any number of elements. For example, the following diagram shows a `xref:reference/unordered_set.adoc#unordered_set[boost::unordered_set]` with 7 buckets containing 5 elements, `A`,
 `B`, `C`, `D` and `E` (this is just for illustration, containers will typically
 have more buckets).
 
@@ -141,7 +141,7 @@ h|*Method* h|*Description*
 A note on `max_load` for open-addressing and concurrent containers: the maximum load will be
 (`max_load_factor() * bucket_count()`) right after `rehash` or on container creation, but may
 slightly decrease when erasing elements in high-load situations. For instance, if we
-have a <<unordered_flat_map,`boost::unordered_flat_map`>> with `size()` almost
+have a `xref:reference/unordered_flat_map.adoc#unordered_flat_map[boost::unordered_flat_map]` with `size()` almost
 at `max_load()` level and then erase 1,000 elements, `max_load()` may decrease by around a
 few dozen elements. This is done internally by Boost.Unordered in order
 to keep its performance stable, and must be taken into account when planning for rehash-free insertions.
diff --git a/doc/modules/ROOT/pages/rationale.adoc b/doc/modules/ROOT/pages/rationale.adoc
index 9023440a..5ef4d874 100644
--- a/doc/modules/ROOT/pages/rationale.adoc
+++ b/doc/modules/ROOT/pages/rationale.adoc
@@ -102,7 +102,7 @@ and *high* and *low* are the upper and lower halves of an extended word, respect
 In 64-bit architectures, _C_ is the integer part of 2^64^&#8725;https://en.wikipedia.org/wiki/Golden_ratio[_&phi;_],
 whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].
 
-When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated <<hash_traits_hash_is_avalanching,`hash_is_avalanching`>>trait.
+When using a hash function directly suitable for open addressing, post-mixing can be opted out of via a dedicated `xref:reference/hash_traits.adoc#hash_traits_hash_is_avalanching[hash_is_avalanching]` trait.
 `boost::hash` specializations for string types are marked as avalanching.
 
 === Platform Interoperability
diff --git a/doc/modules/ROOT/pages/regular.adoc b/doc/modules/ROOT/pages/regular.adoc
index 3e1a343f..bd6f0a6a 100644
--- a/doc/modules/ROOT/pages/regular.adoc
+++ b/doc/modules/ROOT/pages/regular.adoc
@@ -48,7 +48,7 @@ three,3
 ----
 
 There are other differences, which are listed in the
-<<comparison,Comparison with Associative Containers>> section.
+xref:regular.adoc#comparison[Comparison with Associative Containers] section.
 
 == Iterator Invalidation
 
@@ -123,7 +123,7 @@ See the xref:reference/unordered_map.adoc#unordered_map_rehash[reference for mor
 |`iterator`, `const_iterator` are of at least the forward category.
 
 |Iterators, pointers and references to the container's elements are never invalidated.
-|<<regular_iterator_invalidation,Iterators can be invalidated by calls to insert or rehash>>. +
+|xref:regular.adoc#regular_iterator_invalidation[Iterators can be invalidated by calls to insert or rehash]. +
 **Node-based containers:** Pointers and references to the container's elements are never invalidated. +
 **Flat containers:** Pointers and references to the container's elements are invalidated when rehashing occurs.