diff --git a/docs/website/contents/about-ouroboros/References.md b/docs/website/contents/about-ouroboros/References.md
index dc1b5f9233..a1208e8617 100644
--- a/docs/website/contents/about-ouroboros/References.md
+++ b/docs/website/contents/about-ouroboros/References.md
@@ -2,6 +2,7 @@
 
 The following artifacts influence and/or describe the Consensus implementation.
 
+<!-- xrefcheck: ignore link -->
 * [Technical reports](../for-developers/TechnicalReports)
 * From the IOG researchers:
     * [Ouroboros BFT][ouroboros-bft]
diff --git a/docs/website/contents/about-ouroboros/index.md b/docs/website/contents/about-ouroboros/index.md
index 3e4489b4bb..7cb7628db8 100644
--- a/docs/website/contents/about-ouroboros/index.md
+++ b/docs/website/contents/about-ouroboros/index.md
@@ -40,6 +40,7 @@ The Ouroboros research papers that formalize the different protocols (such as Pr
 - the honest nodes will all continually and eventually agree on what the best chain is (unless an adversary controls more than half of the network's stake).
 - the best chain grows over time.
 
+<!-- xrefcheck: ignore link -->
 The Consensus Layer defines the core Consensus components and logic, notably the
 Ouroboros protocol. See [References](References).
 
diff --git a/docs/website/contents/for-developers/Glossary.md b/docs/website/contents/for-developers/Glossary.md
index 6620e9c8ec..8141f3d490 100644
--- a/docs/website/contents/for-developers/Glossary.md
+++ b/docs/website/contents/for-developers/Glossary.md
@@ -1,3 +1,4 @@
+<!-- xrefcheck: ignore file -->
 # Glossary
 
 Notes on the use and maintenance of this glossary:
diff --git a/docs/website/contents/for-developers/TechnicalReports.md b/docs/website/contents/for-developers/TechnicalReports.md
index 0b0df7e220..2d428292cd 100644
--- a/docs/website/contents/for-developers/TechnicalReports.md
+++ b/docs/website/contents/for-developers/TechnicalReports.md
@@ -4,12 +4,15 @@ The following artifacts influence and/or describe the Consensus implementation.
 
 ## Consensus and networking
 
+<!-- xrefcheck: ignore link -->
 * [The Cardano Consensus and Storage Layer](/pdfs/report.pdf).
 * [Introduction to the design of Data Diffusion and Networking of Cardano Shelley][network-report].
 
 ## UTxO-HD
 
+<!-- xrefcheck: ignore link -->
 * [Storing the Cardano ledger state on disk: analysis and design options (An IOHK technical report)](/pdfs/utxo-db.pdf)
+<!-- xrefcheck: ignore link -->
 * [Storing the Cardano ledger state on disk: API design concepts (An IOHK technical report)](/pdfs/utxo-db-api.pdf)
 
 
diff --git a/docs/website/contents/for-developers/VersioningSchemeDecision.md b/docs/website/contents/for-developers/VersioningSchemeDecision.md
index d4d138eed1..c5fb807863 100644
--- a/docs/website/contents/for-developers/VersioningSchemeDecision.md
+++ b/docs/website/contents/for-developers/VersioningSchemeDecision.md
@@ -495,7 +495,7 @@ This rule is so simple that the ✗ for EasyPR is somewhat surpising.
 The hidden problem is that this scheme causes spurious merge conflicts among all your PRs.
 It would only be possible to merge PRs sequentially and merging one PR requires rebasing every other PR and updating its version number diff (assuming a single target branch).
 That usually implies a very poor contributor experience.
-(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#RisingEdgeCompromises).)
+(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#possible-risingedge-compromises).)
 
 We assign ✓ for EasyRelease because each release doesn't require any additional work; merely announce the result of the latest PR.
 Relatedly, though, we assign ✗ for TypicalReleases because it's unrealistic to release after every PR.