Fix broken site links

site-src/faq.md

@@ -76,5 +76,5 @@
 [1]: https://github.com/kubernetes-sigs/gateway-api
 [2]: https://github.com/kubernetes-sigs/gateway-api/releases
 [tls]:https://en.wikipedia.org/wiki/Transport_Layer_Security
-[tlsroute]:/concepts/api-overview.md#tlsroute
-[tlsguide]:/guides/tls.md
+[tlsroute]:/concepts/api-overview#tlsroute
+[tlsguide]:/v1alpha2/guides/tls

site-src/geps/gep-724.md

@@ -16,7 +16,7 @@ for the future addition of Route inclusion (Routes including other Routes).
 Refactor cross-namespace Route-Gateway binding to:
 
 * Be more consistent with [cross-namespace references from
-  Routes](/geps/gep-709.md)
+  Routes](/geps/gep-709)
 * Provide a clear path to enable Route inclusion (Routes including Routes).
 * Simplify user experience based on initial feedback.
 * Enable other kinds of Route parents in addition to Gateway, this could include:
@@ -57,7 +57,7 @@ directly reference the Gateways they wanted to attach to. This pattern was
 already possible with the existing API, but not clearly documented.
 
 One of the key concepts in the [cross-namespace references from Routes
-GEP](/geps/gep-709/) was that of a handshake for
+GEP](/geps/gep-709) was that of a handshake for
 references that cross namespace boundaries. A key part of that handshake was
 that one direction included a direct reference, while the other direction
 provided a way to denote trust for a set of Namespaces and kind of resources.
@@ -686,7 +686,7 @@ spec:
 
 **GEPs**
 
-* [GEP 709: ReferencePolicy + Cross Namespace References from Routes](/geps/gep-709.md)
+* [GEP 709: ReferencePolicy + Cross Namespace References from Routes](/geps/gep-709)
 
 **Docs:**
 

site-src/v1alpha1/api-types/httproute.md

@@ -231,7 +231,7 @@ list.
 ### Merging
 Multiple HTTPRoutes can be attached to a single Gateway resource. Importantly,
 only one Route rule may match each request. For more information on how conflict
-resolution applies to merging, refer to the [API specification](httprouterule).
+resolution applies to merging, refer to the [API specification][httprouterule].
 
 [httproute]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute
 [gateways]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.RouteGateways

site-src/v1alpha1/guides/http-routing.md

@@ -33,7 +33,7 @@ bound to each other by their respective owners.
 ```
 
 An HTTPRoute can match against a [single set of
-hostnames](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteSpec).
+hostnames](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteSpec).
 These hostnames are matched before any other matching within the HTTPRoute takes
 place. Since `foo.example.com` and `bar.example.com` are separate hosts with
 different routing requirements, each is deployed as its own HTTPRoute -

site-src/v1alpha1/guides/multiple-ns.md

@@ -146,7 +146,7 @@ Routes can bind with.
 After these three Routes are deployed, they will all be bound to the 
 `shared-gateway` Gateway. The Gateway merges its bound Routes into a single flat
 list of routing rules. [Routing
-precedence](/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteRule)
+precedence](/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteRule)
 between the flat list of routing rules is determined by most specific match and
 conflicts are handled according to [conflict
 resolution](/concepts/guidelines#conflicts). This provides predictable and

site-src/v1alpha2/api-types/httproute.md

@@ -188,7 +188,7 @@ status:
 ### Merging
 Multiple HTTPRoutes can be attached to a single Gateway resource. Importantly,
 only one Route rule may match each request. For more information on how conflict
-resolution applies to merging, refer to the [API specification](httprouterule).
+resolution applies to merging, refer to the [API specification][httprouterule].
 
 
 [httproute]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute

site-src/v1alpha2/guides/multiple-ns.md

@@ -10,7 +10,7 @@ attach to Gateways across Namespace boundaries. This allows user access
 control to be applied differently across Namespaces for Routes and Gateways, 
 effectively segmenting access and control to different parts of the
 cluster-wide  routing configuration. The ability for Routes to attach to
-Gateways across Namespace boundaries are governed by [_Route Attachment_](cross-namespace-route-attachment). Route attachment is explored
+Gateways across Namespace boundaries are governed by [_Route Attachment_](#cross-namespace-route-attachment). Route attachment is explored
 in this guide and demonstrates how independent teams can safely share the same
 Gateway.
 
@@ -156,7 +156,7 @@ Gateway that these Routes want to attach to.
 
 After these three Routes are deployed, they will all be attached to the
 `shared-gateway` Gateway. The Gateway merges these Routes into a single flat
-list of routing rules. [Routing precedence](/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
+list of routing rules. [Routing precedence](/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRouteRule)
 between these routing rules is determined by most specific match and
 conflicts are handled according to [conflict
 resolution](/concepts/guidelines#conflicts). This provides predictable and

site-src/v1alpha2/guides/tcp.md

@@ -52,8 +52,8 @@ possible to use metadata to route traffic from the `Gateway` to the underlying
 See the [spec][tcproute] for more details on how to configure alternative logic
 for routing TCP traffic beyond just using ports and selecting `listener` names.
 
-[tcproute]:/v1alpha2/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.TCPRoute
+[tcproute]:/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.TCPRoute
 [tcp]:https://datatracker.ietf.org/doc/html/rfc793
-[httproute]:/v1alpha2/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute
-[gateway]:/v1alpha2/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway
+[httproute]:/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute
+[gateway]:/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/

site-src/v1alpha2/references/cross-namespace-references.md

@@ -87,7 +87,7 @@ While the API is simplistic in nature, it comes with a few notable decisions:
    Although a selector would be more powerful, it encourages unnecessarily
    insecure configuration.
 
-Please see the [API Specification](https://gateway-api.sigs.k8s.io/references/spec/)
+Please see the [API Specification](/v1alpha2/references/spec#gateway.networking.k8s.io/v1alpha2.ReferencePolicy)
 for the details of the object's behavior.
 
 ### Exceptions