diff --git a/modules/deploy/pages/redpanda/manual/disaster-recovery/shadowing/setup.adoc b/modules/deploy/pages/redpanda/manual/disaster-recovery/shadowing/setup.adoc
index 12ecb1edfd..f84363a247 100644
--- a/modules/deploy/pages/redpanda/manual/disaster-recovery/shadowing/setup.adoc
+++ b/modules/deploy/pages/redpanda/manual/disaster-recovery/shadowing/setup.adoc
@@ -233,26 +233,6 @@ consumer_offset_sync_options:
 
 **Offset clamping:** When Redpanda replicates consumer group offsets from the source cluster, offsets are automatically "clamped" during the commit process. If a replicated offset is above the high watermark (HWM) of the shadow partition, Redpanda clamps the offset to the shadow partition's HWM. This ensures offsets remain valid and prevents consumers from seeking beyond available data on the shadow cluster.
 
-=== Schema Registry synchronization
-
-Shadowing can replicate Schema Registry data by shadowing the `_schemas` system topic. When enabled, this provides byte-for-byte replication of schema definitions, versions, and compatibility settings.
-
-To enable Schema Registry synchronization, add the following to your shadow link configuration:
-
-[,yaml]
-----
-schema_registry_sync_options:
-  shadow_schema_registry_topic: {}
-----
-
-**Requirements:**
-
-- The `_schemas` topic must exist on the source cluster
-- The `_schemas` topic must not exist on the shadow cluster, or must be empty
-- Once enabled, the `_schemas` topic will be replicated completely
-
-**Important:** Once the `_schemas` topic becomes a shadow topic, it cannot be stopped without either failing over the topic or deleting it entirely.
-
 === Starting offset for new shadow topics
 
 When a shadow topic is created for the first time, you can control where replication begins on the source topic. This setting only applies to empty shadow partitions and is crucial for disaster recovery planning.