diff --git a/framework-docs/modules/ROOT/pages/core/aop/schema.adoc b/framework-docs/modules/ROOT/pages/core/aop/schema.adoc
index c8a7747975e7..3853fbeb5e4b 100644
--- a/framework-docs/modules/ROOT/pages/core/aop/schema.adoc
+++ b/framework-docs/modules/ROOT/pages/core/aop/schema.adoc
@@ -10,7 +10,7 @@ of advice parameters.
To use the aop namespace tags described in this section, you need to import the
`spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
-. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
+. See xref:core/appendix/xsd-schemas.adoc#xsd-schemas-aop[the AOP schema]
for how to import the tags in the `aop` namespace.
Within your Spring configurations, all aspect and advisor elements must be placed within
diff --git a/framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc b/framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc
index ca2fd246eda9..a5f70b191440 100644
--- a/framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc
+++ b/framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc
@@ -14,11 +14,11 @@ Spring distribution, you should first read the previous section on xref:core/app
To create new XML configuration extensions:
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-schema[Author] an XML schema to describe your custom element(s).
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
+. xref:core/appendix/xml-custom.adoc#xsd-custom-schema[Author] an XML schema to describe your custom element(s).
+. xref:core/appendix/xml-custom.adoc#xsd-custom-namespacehandler[Code] a custom `NamespaceHandler` implementation.
+. xref:core/appendix/xml-custom.adoc#xsd-custom-parser[Code] one or more `BeanDefinitionParser` implementations
(this is where the real work is done).
-. xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-registration[Register] your new artifacts with Spring.
+. xref:core/appendix/xml-custom.adoc#xsd-custom-registration[Register] your new artifacts with Spring.
For a unified example, we create an
XML extension (a custom XML element) that lets us configure objects of the type
@@ -553,7 +553,7 @@ Kotlin::
This works nicely, but it exposes a lot of Spring plumbing to the end user. What we are
going to do is write a custom extension that hides away all of this Spring plumbing.
-If we stick to xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the steps described previously], we start off
+If we stick to xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the steps described previously], we start off
by creating the XSD schema to define the structure of our custom tag, as the following
listing shows:
@@ -580,7 +580,7 @@ listing shows:
----
-Again following xref:core/appendix/xml-custom.adoc#core.appendix.xsd-custom-introduction[the process described earlier],
+Again following xref:core/appendix/xml-custom.adoc#xsd-custom-introduction[the process described earlier],
we then create a custom `NamespaceHandler`:
[tabs]
diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
index 35f1a900a813..06aeeaa375ec 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
@@ -179,7 +179,7 @@ infrastructure.
NOTE: The preceding definition of the `dataSource` bean uses the `` tag
from the `jee` namespace. For more information see
-xref:integration/appendix.adoc#xsd-schemas-jee[The JEE Schema].
+xref:integration/appendix.adoc#appendix.xsd-schemas-jee[The JEE Schema].
NOTE: If you use JTA, your transaction manager definition should look the same, regardless
of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported
diff --git a/framework-docs/modules/ROOT/pages/testing/resttestclient.adoc b/framework-docs/modules/ROOT/pages/testing/resttestclient.adoc
index 73244a574d57..71768d732595 100644
--- a/framework-docs/modules/ROOT/pages/testing/resttestclient.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/resttestclient.adoc
@@ -139,8 +139,8 @@ xref:integration/rest-clients.adoc#rest-restclient[`RestClient`] and `RestTestCl
the same API up to the point of the call to `exchange()`. After that, `RestTestClient`
provides two alternative ways to verify the response:
-1. xref:resttestclient-workflow[Built-in Assertions] extend the request workflow with a chain of expectations
-2. xref:resttestclient-assertj[AssertJ Integration] to verify the response via `assertThat()` statements
+1. xref:testing/resttestclient.adoc#resttestclient.workflow[Built-in Assertions] extend the request workflow with a chain of expectations
+2. xref:testing/resttestclient.adoc#resttestclient.assertj[AssertJ Integration] to verify the response via `assertThat()` statements
@@ -164,7 +164,7 @@ include-code::./RestClientWorkflowTests[tag=soft-assertions,indent=0]
You can then choose to decode the response body through one of the following:
* `expectBody(Class)`: Decode to single object.
-* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient-json[JSON Content] or an empty body.
+* `expectBody()`: Decode to `byte[]` for xref:testing/resttestclient.adoc#resttestclient.json[JSON Content] or an empty body.
If the built-in assertions are insufficient, you can consume the object instead and
diff --git a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc
index 43ead704e62b..fd9df4e18045 100644
--- a/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc
+++ b/framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc
@@ -2,7 +2,7 @@
= Context Configuration with Groovy Scripts
To load an `ApplicationContext` for your tests by using Groovy scripts that use the
-xref:core/beans/basics.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
+xref:languages/groovy.adoc#beans-factory-groovy[Groovy Bean Definition DSL], you can annotate
your test class with `@ContextConfiguration` and configure the `locations` or `value`
attribute with an array that contains the resource locations of Groovy scripts. Resource
lookup semantics for Groovy scripts are the same as those described for
diff --git a/framework-docs/modules/ROOT/pages/web/webflux/config.adoc b/framework-docs/modules/ROOT/pages/web/webflux/config.adoc
index 9c255395a730..07c6deeed1f2 100644
--- a/framework-docs/modules/ROOT/pages/web/webflux/config.adoc
+++ b/framework-docs/modules/ROOT/pages/web/webflux/config.adoc
@@ -659,7 +659,7 @@ whether to decode the request path nor whether to remove semicolon content for
path matching purposes.
Spring WebFlux also does not support suffix pattern matching, unlike in Spring MVC, where we
-are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[recommend] moving away from
+are also xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[recommend] moving away from
reliance on it.
====
diff --git a/framework-docs/modules/ROOT/pages/web/webmvc-test.adoc b/framework-docs/modules/ROOT/pages/web/webmvc-test.adoc
index 8456bdf01538..404d87d31d95 100644
--- a/framework-docs/modules/ROOT/pages/web/webmvc-test.adoc
+++ b/framework-docs/modules/ROOT/pages/web/webmvc-test.adoc
@@ -1,6 +1,6 @@
[[test]]
= Testing
-[.small]#xref:web-reactive.adoc#webflux-test[See equivalent in the Reactive stack]#
+[.small]#xref:web/webflux-test.adoc[See equivalent in the Reactive stack]#
This section summarizes the options available in `spring-test` for Spring MVC applications.
diff --git a/framework-docs/modules/ROOT/pages/web/webmvc/mvc-config/content-negotiation.adoc b/framework-docs/modules/ROOT/pages/web/webmvc/mvc-config/content-negotiation.adoc
index abe246e508aa..9f5b2f8212da 100644
--- a/framework-docs/modules/ROOT/pages/web/webmvc/mvc-config/content-negotiation.adoc
+++ b/framework-docs/modules/ROOT/pages/web/webmvc/mvc-config/content-negotiation.adoc
@@ -10,8 +10,7 @@ By default, only the `Accept` header is checked.
If you must use URL-based content type resolution, consider using the query parameter
strategy over path extensions. See
-xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-suffix-pattern-match[Suffix Match]
-and xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
+xref:web/webmvc/mvc-controller/ann-requestmapping.adoc#mvc-ann-requestmapping-rfd[Suffix Match and RFD] for
more details.
You can customize requested content type resolution, as the following example shows: