diff --git a/internal/impl/pure/processor_bloblang.go b/internal/impl/pure/processor_bloblang.go
index 80644ae19..4bf04faf7 100644
--- a/internal/impl/pure/processor_bloblang.go
+++ b/internal/impl/pure/processor_bloblang.go
@@ -35,7 +35,7 @@ This processor was recently renamed to the `+"xref:components:processors/mapping
 Bloblang mappings can fail, in which case the message remains unchanged, errors are logged, and the message is flagged as having failed, allowing you to use
 xref:configuration:error_handling.adoc[standard processor error handling patterns].
 
-However, Bloblang itself also provides powerful ways of ensuring your mappings do not fail by specifying desired fallback behavior, which you can read about in xref:guides:bloblang/about#error-handling.adoc[Error handling].`).
+However, Bloblang itself also provides powerful ways of ensuring your mappings do not fail by specifying desired fallback behavior, which you can read about in xref:guides:bloblang/about.adoc#error-handling[Error handling].`).
 		Example("Mapping", `
 Given JSON documents containing an array of fans:
 
diff --git a/internal/impl/pure/processor_retry.go b/internal/impl/pure/processor_retry.go
index b2ec2b6da..ea9f0cea4 100644
--- a/internal/impl/pure/processor_retry.go
+++ b/internal/impl/pure/processor_retry.go
@@ -35,7 +35,7 @@ Executes child processors and if a resulting message is errored then, after a sp
 
 It is important to note that any mutations performed on the message during these child processors will be discarded for the next retry, and therefore it is safe to assume that each execution of the child processors will always be performed on the data as it was when it first reached the retry processor.
 
-By default the retry backoff has a specified `+"<<backoffmax_elapsed_time,`max_elapsed_time`>>"+`, if this time period is reached during retries and an error still occurs these errored messages will proceed through to the next processor after the retry (or your outputs). Normal xref:configuration:error_handling.adoc[error handling patterns] can be used on these messages.
+By default the retry backoff has a specified `+"<<backoff-max_elapsed_time,`max_elapsed_time`>>"+`, if this time period is reached during retries and an error still occurs these errored messages will proceed through to the next processor after the retry (or your outputs). Normal xref:configuration:error_handling.adoc[error handling patterns] can be used on these messages.
 
 In order to avoid permanent loops any error associated with messages as they first enter a retry processor will be cleared.