kubernetes-sigs · YASHMAHAKAL · Dec 13, 2025 · Dec 15, 2025 · Dec 16, 2025 · Dec 16, 2025
diff --git a/site-src/guides/getting-started/simple-gateway.md b/site-src/guides/getting-started/simple-gateway.md
@@ -8,8 +8,8 @@ This guide is a great place to start if you are new to Gateway API. It shows the
 {% include 'standard/simple-gateway/gateway.yaml' %}
 ```
 
-The Gateway represents the instantiation of a logical load balancer and the
-GatewayClass defines the load balancer template when users create a Gateway.
+The [Gateway](../../../reference/spec/#gateway) represents the instantiation of a logical load balancer and the
+[GatewayClass](../../../reference/spec/#gatewayclass) defines the load balancer template when users create a Gateway.
 The example Gateway is templated from a hypothetical `example`
 GatewayClass, which is meant to be a placeholder and substituted by users. Here
 is a list of available
@@ -21,10 +21,10 @@ The Gateway listens for HTTP traffic on port 80. This particular GatewayClass
 automatically assigns an IP address which will be shown in the `Gateway.status`
 after it has been deployed. 
 
-Route resources specify the Gateways they want to attach to using `ParentRefs`. As long as 
+Route resources specify the Gateways they want to attach to using [`ParentRefs`](../../../reference/spec/#parentreference). As long as 
 the Gateway allows this attachment (by default Routes from the same namespace are trusted),
 this will allow the Route to receive traffic from the parent Gateway. 
-`BackendRefs` define the backends that traffic will be sent to. More complex 
+[`BackendRefs`](../../../reference/spec/#httpbackendref) define the backends that traffic will be sent to. More complex 
 bi-directional matching and permissions are possible and explained in other guides.
 
 The following HTTPRoute defines how traffic from the Gateway listener is routed

diff --git a/site-src/guides/grpc-routing.md b/site-src/guides/grpc-routing.md
@@ -1,7 +1,7 @@
 # gRPC routing
 
 The [GRPCRoute resource](../api-types/grpcroute.md) allows you to match on gRPC traffic and
-direct it to Kubernetes backends. This guide shows how the GRPCRoute matches
+direct it to Kubernetes backends. This guide shows how the [GRPCRoute](../../reference/spec/#grpcroute) matches
 traffic on host, header, and service, and method fields and forwards it to different
 Kubernetes Services.
 
@@ -74,6 +74,6 @@ been considered.
 {% include 'standard/grpc-routing/reflection-grpcroute.yaml' %}
 ```
 
-[gateway]: ../reference/spec.md#gateway.networking.k8s.io/v1.Gateway
-[spec]: ../reference/spec.md#gateway.networking.k8s.io%2fv1alpha2.GRPCRouteSpec
+[gateway]: ../../reference/spec/#gateway
+[spec]: ../../reference/spec/#grpcroutespec
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/
diff --git a/site-src/guides/http-cors.md b/site-src/guides/http-cors.md
@@ -8,7 +8,7 @@ Cross-Origin Resource Sharing (CORS). CORS is a security feature that allows
 or denies web applications running at one domain to make requests for resources
 from a different domain.
 
-The `CORS` filter in an `HTTPRouteRule` can be used to specify the CORS policy.
+The [`CORS` filter](../../reference/spec/#httpcorsfilter) in an `HTTPRouteRule` can be used to specify the CORS policy.
 
 ## Allowing requests from a specific origin
 

diff --git a/site-src/guides/http-header-modifier.md b/site-src/guides/http-header-modifier.md
@@ -1,7 +1,7 @@
 # HTTP Header Modifiers
 
 [HTTPRoute resources](../api-types/httproute.md) can modify the headers of HTTP requests and the HTTP responses from clients.
-There are two types of [filters](../api-types/httproute.md#filters-optional) available to meet these requirements: `RequestHeaderModifier` and `ResponseHeaderModifier`.
+There are two types of [filters](../api-types/httproute.md#filters-optional) available to meet these requirements: [`RequestHeaderModifier`](../../reference/spec/#httpheaderfilter) and [`ResponseHeaderModifier`](../../reference/spec/#httpheaderfilter).
 
 This guide shows how to use these features.
 

diff --git a/site-src/guides/http-method-matching.md b/site-src/guides/http-method-matching.md
@@ -4,7 +4,7 @@
     This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md).
 
 The [HTTPRoute resource](../api-types/httproute.md) can be used to match
-requests based on the HTTP method. This guide shows how to use this
+requests based on the [HTTP method](../../reference/spec/#httproutematch). This guide shows how to use this
 functionality.
 
 ## Matching requests based on the HTTP method

diff --git a/site-src/guides/http-query-param-matching.md b/site-src/guides/http-query-param-matching.md
@@ -4,7 +4,7 @@
     This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md).
 
 The [HTTPRoute resource](../api-types/httproute.md) can be used to match
-requests based on query parameters. This guide shows how to use this
+requests based on [query parameters](../../reference/spec/#httpqueryparammatch). This guide shows how to use this
 functionality.
 
 ## Matching requests based on a single query parameter

diff --git a/site-src/guides/http-request-mirroring.md b/site-src/guides/http-request-mirroring.md
@@ -3,8 +3,7 @@
 ???+ info "Extended Support Feature: HTTPRouteRequestMirror"
     This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md).
 
-The [HTTPRoute resource](../api-types/httproute.md) can be used to mirror
-requests to multiple backends. This is useful for testing new services with
+The [HTTPRoute resource](../api-types/httproute.md) can be used to [mirror requests](../../reference/spec/#httprequestmirrorfilter) to multiple backends. This is useful for testing new services with
 production traffic.
 
 Mirrored requests will only be sent to one single destination endpoint

diff --git a/site-src/guides/http-routing.md b/site-src/guides/http-routing.md
@@ -57,6 +57,6 @@ missing or not `canary` then it'll be forwarded to `bar-svc`.
 {% include 'standard/http-routing/bar-httproute.yaml' %}
 ```
 
-[gateway]: ../reference/spec.md#gateway.networking.k8s.io/v1.Gateway
-[spec]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteSpec
+[gateway]: ../../reference/spec/#gateway
+[spec]: ../../reference/spec/#httproutespec
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/
diff --git a/site-src/guides/http-timeouts.md b/site-src/guides/http-timeouts.md
@@ -4,7 +4,7 @@
     This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md).
 
 The [HTTPRoute resource](../api-types/httproute.md) can be used to configure
-timeouts for HTTP requests. This is useful for preventing long-running requests
+[timeouts](../../reference/spec/#httproutetimeouts) for HTTP requests. This is useful for preventing long-running requests
 from consuming resources and for providing a better user experience.
 
 The `timeouts` field in an `HTTPRouteRule` can be used to specify a request

diff --git a/site-src/guides/tls.md b/site-src/guides/tls.md
@@ -54,11 +54,11 @@ The use of `Terminate` on `TLSRoute` is available on `Extended` [Support Level].
 
 ## Downstream TLS
 
-Downstream TLS settings are configured using listeners at the Gateway level.
+Downstream TLS settings are configured using [listeners](../../reference/spec/#listener) at the Gateway level.
 
 ### Listeners and TLS
 
-Listeners expose the TLS setting on a per domain or subdomain basis.
+Listeners expose the [TLS setting](../../reference/spec/#gatewaytlsconfig) on a per domain or subdomain basis.
 TLS settings of a listener are applied to all domains that satisfy the
 `hostname` criteria.
 
@@ -116,7 +116,7 @@ would be invalid.
 
 ## Upstream TLS
 
-Upstream TLS settings are configured using the `BackendTLSPolicy` attached to a
+Upstream TLS settings are configured using the [`BackendTLSPolicy`](../../reference/spec/#backendtlspolicy) attached to a
 `Service` via a target reference.
 
 This resource can be used to describe the SNI the Gateway should use to connect to the

diff --git a/site-src/guides/traffic-splitting.md b/site-src/guides/traffic-splitting.md
@@ -1,7 +1,7 @@
 # HTTP traffic splitting
 
 The [HTTPRoute resource](../api-types/httproute.md) allows you to specify
-weights to shift traffic between different backends. This is useful for
+[weights](../../reference/spec/#httpbackendref) to shift traffic between different backends. This is useful for
 splitting traffic during rollouts, canarying changes, or for emergencies.
 The HTTPRoute`spec.rules.backendRefs` accepts a list of backends that a route
 rule will send traffic to. The relative weights of these backends define
@@ -41,7 +41,7 @@ production user traffic for `foo.example.com`. The following HTTPRoute has no
 receive 100% of the traffic matched by each of their route rules. A canary
 route rule is used (matching the header `traffic=test`) to send synthetic test
 traffic before splitting any production user traffic to `foo-v2`.
-[Routing precedence](../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteRule)
+[Routing precedence](../../reference/spec/#httprouterule)
 ensures that all traffic with the matching host and header
 (the most specific match) will be sent to `foo-v2`.