docs: Fix relative links in Advanced Server Rendering guide (#8765)

Author: iamursky

docs/framework/react/guides/advanced-ssr.md

@@ -5,15 +5,17 @@ title: Advanced Server Rendering
 
 Welcome to the Advanced Server Rendering guide, where you will learn all about using React Query with streaming, Server Components and the Next.js app router.
 
-You might want to read the [Server Rendering & Hydration guide](../ssr) before this one as it teaches the basics for using React Query with SSR, and [Performance & Request Waterfalls](../request-waterfalls) as well as [Prefetching & Router Integration](../prefetching) also contains valuable background.
+You might want to read the [Server Rendering & Hydration guide](./ssr) before this one as it teaches the basics for using React Query with SSR, and [Performance & Request Waterfalls](./request-waterfalls) as well as [Prefetching & Router Integration](./prefetching) also contains valuable background.
+
+https://tanstack.com/query/latest/docs/framework/react/guides/ssr
 
 Before we start, let's note that while the `initialData` approach outlined in the SSR guide also works with Server Components, we'll focus this guide on the hydration APIs.
 
 ## Server Components & Next.js app router
 
 We won't cover Server Components in depth here, but the short version is that they are components that are guaranteed to _only_ run on the server, both for the initial page view and **also on page transitions**. This is similar to how Next.js `getServerSideProps`/`getStaticProps` and Remix `loader` works, as these also always run on the server but while those can only return data, Server Components can do a lot more. The data part is central to React Query however, so let's focus on that.
 
-How do we take what we learned in the Server Rendering guide about [passing data prefetched in framework loaders to the app](../ssr#using-the-hydration-apis) and apply that to Server Components and the Next.js app router? The best way to start thinking about this is to consider Server Components as "just" another framework loader.
+How do we take what we learned in the Server Rendering guide about [passing data prefetched in framework loaders to the app](./ssr#using-the-hydration-apis) and apply that to Server Components and the Next.js app router? The best way to start thinking about this is to consider Server Components as "just" another framework loader.
 
 ### A quick note on terminology
 
@@ -601,7 +603,7 @@ For more information, check out the [NextJs Suspense Streaming Example](../../ex
 
 The big upside is that you no longer need to prefetch queries manually to have SSR work, and it even still streams in the result! This gives you phenomenal DX and lower code complexity.
 
-The downside is easiest to explain if we look back at [the complex request waterfall example](../request-waterfalls#code-splitting) in the Performance & Request Waterfalls guide. Server Components with prefetching effectively eliminates the request waterfalls both for the initial page load **and** any subsequent navigation. This prefetch-less approach however will only flatten the waterfalls on the initial page load but ends up the same deep waterfall as the original example on page navigations:
+The downside is easiest to explain if we look back at [the complex request waterfall example](./request-waterfalls#code-splitting) in the Performance & Request Waterfalls guide. Server Components with prefetching effectively eliminates the request waterfalls both for the initial page load **and** any subsequent navigation. This prefetch-less approach however will only flatten the waterfalls on the initial page load but ends up the same deep waterfall as the original example on page navigations:
 
 ```
 1. |> JS for <Feed>