Update conflicts.mdx with fixed anchors

product_docs/docs/pgd/5/consistency/conflicts.mdx

@@ -212,11 +212,11 @@ The database can clean up the deleted row by the time the `UPDATE` is received i
 
 Another type of `UPDATE`/`DELETE` conflict is when a `DELETE` for a row comes after that row was updated locally. In this situation, the outcome depends on the type of conflict detection used and the replication identity in use. 
 
-When using the default, [origin conflict detection](https://www.enterprisedb.com/docs/pgd/latest/consistency/conflicts/#origin-conflict-detection) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
+When using the default, [origin conflict detection](#origin-conflict-detection) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
 
 If `REPLICA IDENTITY FULL` is being used for replication, the conflict will be detected and a `delete_recently_updated` conflict is generated.
 
-Similarly, if [row version conflict detection](https://www.enterprisedb.com/docs/pgd/latest/consistency/conflicts/#row-version-conflict-detection) is enabled, a `delete_recently_updated` conflict is also generated in this scenario. 
+Similarly, if [row version conflict detection](#row-version-conflict-detection) is enabled, a `delete_recently_updated` conflict is also generated in this scenario. 
 
 The default resolution for `delete_recently_updated` is to `skip` the operation,  so the `DELETE` will not be applied.  You can configure this default resolution, using `bdr.alter_node_set_conflict_resolver` to update to apply the `DELETE` or set up a conflict trigger to handle it.