[Workers] Add cross-references and tighten URL framing in Previews docs

Author: korinne

src/content/docs/workers/previews/concepts.mdx

@@ -20,34 +20,34 @@ One Preview can have many deployments over its lifetime. The latest deployment i
 
 **Preview settings** are the shared defaults stored on Cloudflare that apply to every new Preview on a Worker. They include:
 
-- Bindings (KV, D1, R2, Durable Objects, and so on)
-- Environment variables
-- Secrets
-- Observability, Logpush, and Tail Worker settings
-- Runtime limits
+- [Bindings](/workers/runtime-apis/bindings/) ([KV](/kv/), [D1](/d1/), [R2](/r2/), [Durable Objects](/durable-objects/), and so on)
+- [Environment variables](/workers/configuration/environment-variables/)
+- [Secrets](/workers/configuration/secrets/)
+- [Observability](/workers/observability/logs/workers-logs/), [Logpush](/workers/observability/logs/logpush/), and [Tail Worker](/workers/observability/logs/tail-workers/) settings
+- Runtime [limits](/workers/platform/limits/)
 
 Preview settings are distinct from your Production settings. Previews never inherit from production.
 
 When you create a new Preview — via `wrangler preview`, CI, the dashboard, or a pull request — it starts with your Worker's Preview settings. Individual deployments can override those values for one deployment without changing the shared settings. See [Per-deployment overrides](/workers/previews/configuring-previews/#per-deployment-overrides).
 
 ## Preview URLs
 
-Every Preview has an auto-generated URL on the `workers.dev` subdomain:
+Every Preview has two kinds of URLs on the `workers.dev` subdomain.
+
+The **Preview URL** is the stable URL for a Preview. Think of it as your branch URL — it always points at the latest deployment.
+
 `<preview-name>-<worker-name>.<subdomain>.workers.dev`
 
-Each Preview deployment also gets its own URL, so you can reach a specific immutable deployment directly:
-`<deployment-short-id>-<worker-name>.<subdomain>.workers.dev`
+The **Deployment URL** is the URL for a specific deployment. Think of it as your commit URL — it is immutable and, once created, always points at that exact deployment.
 
-The Preview URL always points to the latest deployment — you can think of it as your Preview domain. A deployment URL always points to that one specific deployment and never changes, even after you push a new deployment to the Preview.
+`<deployment-short-id>-<worker-name>.<subdomain>.workers.dev`
 
 You can also serve Previews from your own **custom domain**. When Previews are enabled on a Worker custom domain, Cloudflare provisions a wildcard DNS record (`*.app.example.com`) and a wildcard certificate to cover all Preview subdomains:
 
 - **Preview URL**: `<preview-name>.app.example.com`
 - **Deployment URL**: `<deployment-short-id>-<preview-name>.app.example.com`
 
-Previews can only be reached through these auto-generated URLs and custom domain wildcard URLs.
-
-User-managed triggers like Worker routes, cron triggers, and Queue consumers do not apply to Previews.
+Previews can only be reached through these auto-generated URLs and custom domain wildcard URLs. User-managed triggers like [Worker routes](/workers/configuration/routing/routes/), [cron triggers](/workers/configuration/cron-triggers/), and [Queue](/queues/) consumers do not apply to Previews.
 
 For configuration details, see [Use a custom domain for Previews](/workers/previews/#use-a-custom-domain-for-previews).
 
@@ -61,10 +61,11 @@ Previews are designed so that testing changes does not risk your production data
 
 When your Worker defines the class itself, these binding types give each Preview its own isolated namespace, instances, and storage — separate from production and from every other Preview:
 
-- **Durable Objects**
-- **Workflows**
-- **Containers** (hosted on Durable Objects)
-  Concretely, this means:
+- [**Durable Objects**](/durable-objects/)
+- [**Workflows**](/workflows/)
+- [**Containers**](/containers/) (hosted on Durable Objects)
+
+Concretely, this means:
 - A Durable Object you reach via `env.MY_DO.getByName("some-id")` in a Preview returns a different instance — with different storage — than the same call in production, and different from the same call in another Preview.
 - Writes to `ctx.storage` inside a Preview's Durable Object never affect production data or other Previews.
 - State persists across deployments within the same Preview. Pushing a new deployment to the Preview keeps its Durable Object storage intact.
@@ -78,23 +79,23 @@ For Durable Objects and Workflows defined in the same Worker, you can access the
 
 These binding types reference resources that exist at the account level. All Previews pointing at the same resource ID share it with each other and with production (unless you override the ID in `previews`):
 
-- KV
-- D1
-- R2
-- Queues (producers only — Previews cannot consume from Queues)
-- Vectorize
-- Hyperdrive
-- Analytics Engine
-- Pipelines
-- Secrets Store
-- mTLS certificates
-- Dispatch namespaces
+- [KV](/kv/)
+- [D1](/d1/)
+- [R2](/r2/)
+- [Queues](/queues/) (producers only — Previews cannot consume from Queues)
+- [Vectorize](/vectorize/)
+- [Hyperdrive](/hyperdrive/)
+- [Analytics Engine](/analytics/analytics-engine/)
+- [Pipelines](/pipelines/)
+- [Secrets Store](/secrets-store/)
+- [mTLS certificates](/workers/runtime-apis/bindings/mTLS/)
+- [Dispatch namespaces](/cloudflare-for-platforms/workers-for-platforms/)
 
 To keep Preview writes separate from production, create a dedicated resource for Previews and reference it under `previews`, or use [auto-provisioning](/workers/previews/configuring-previews/#auto-provisioning) for KV, D1, and R2.
 
 ### Always target production
 
-- **Service bindings** from a Preview always resolve to the bound Worker's production deployment. You cannot point a service binding at another Preview.
+- [**Service bindings**](/workers/runtime-apis/bindings/service-bindings/) from a Preview always resolve to the bound Worker's production deployment. You cannot point a service binding at another Preview.
 
 ### Scoped to the Preview
 

src/content/docs/workers/previews/configuring-previews.mdx

@@ -235,11 +235,11 @@ This reference example shows all supported binding types in `previews`.
 
 Previews do **not** inherit bindings from your top-level Wrangler configuration. Any binding you want available inside a Preview must be declared in the `previews` block. If you omit a binding here, your Preview will not have access to it at runtime.
 
-For most binding types — such as KV, D1, R2, Queues, Vectorize, and Hyperdrive — all of your Previews share the same underlying resource that you specify in `previews`. These are account-level resources referenced by ID or name, so pointing two Previews at the same `kv_namespaces.id` means they read and write the same data.
+For most binding types — such as [KV](/kv/), [D1](/d1/), [R2](/r2/), [Queues](/queues/), [Vectorize](/vectorize/), and [Hyperdrive](/hyperdrive/) — all of your Previews share the same underlying resource that you specify in `previews`. These are account-level resources referenced by ID or name, so pointing two Previews at the same `kv_namespaces.id` means they read and write the same data.
 
 If you need a Preview's writes to stay separate from production, create a dedicated resource for Previews, or use [auto-provisioning](#auto-provisioning) for KV, D1, and R2.
 
-The exceptions are **Durable Objects**, **Workflows**, and **Containers**. When your Worker defines the class itself (no `script_name` on the binding), each Preview automatically gets its own isolated namespace and instances, separate from production and from other Previews. State persists across deployments within the same Preview and is deleted when the Preview is deleted. If you set `script_name` to point at another Worker, the binding targets that Worker's production instance and this isolation does not apply — prefer [`ctx.exports`](/workers/runtime-apis/context/#exports) for Durable Objects and Workflows defined in the same Worker.
+The exceptions are [**Durable Objects**](/durable-objects/), [**Workflows**](/workflows/), and [**Containers**](/containers/). When your Worker defines the class itself (no `script_name` on the binding), each Preview automatically gets its own isolated namespace and instances, separate from production and from other Previews. State persists across deployments within the same Preview and is deleted when the Preview is deleted. If you set `script_name` to point at another Worker, the binding targets that Worker's production instance and this isolation does not apply — prefer [`ctx.exports`](/workers/runtime-apis/context/#exports) for Durable Objects and Workflows defined in the same Worker.
 
 [Service bindings](/workers/runtime-apis/bindings/service-bindings/) behave differently from both: they always resolve to the bound Worker's production deployment, and cannot be pointed at another Worker's Preview.
 | `previews` field | How it behaves |
@@ -314,12 +314,12 @@ Some `previews` fields are not runtime bindings, but they still change how new P
 | `define` | Changes compile-time replacements for the Preview build. It does not create a runtime binding. |
 Some Preview-related settings come from the top level of your Wrangler config, not from `previews`:
 
-- `compatibility_date`
-- `compatibility_flags`
-- `placement`
-- `assets`
-- `migrations`
-- `containers`
+- [`compatibility_date`](/workers/configuration/compatibility-dates/)
+- [`compatibility_flags`](/workers/configuration/compatibility-flags/)
+- [`placement`](/workers/configuration/smart-placement/)
+- [`assets`](/workers/static-assets/)
+- [`migrations`](/durable-objects/reference/durable-objects-migrations/)
+- [`containers`](/containers/)
 
 ## Use environment-specific Preview defaults
 

src/content/docs/workers/previews/index.mdx

@@ -18,9 +18,10 @@ You create or update a Preview by:
 
 Each Preview has two kinds of **URLs**:
 
-- A stable **Preview URL** that always points at the latest deployment.
-- A **Deployment URL** for each individual deployment, which is immutable and never changes.
-  When you connect your Git repository, Cloudflare posts these URLs on your pull requests as a comment. By default, Previews are served from your `workers.dev` subdomain. You can also route them through a [custom domain](/workers/previews/#use-a-custom-domain-for-previews).
+- A **Preview URL** that points at the latest deployment. Think of it as your branch URL — it always serves whatever you pushed most recently.
+- A **Deployment URL** for each individual deployment. Think of it as your commit URL — it is immutable and never changes.
+
+When you connect your Git repository, Cloudflare posts these URLs on your pull requests as a comment. By default, Previews are served from your `workers.dev` subdomain. You can also route them through a [custom domain](/workers/previews/#use-a-custom-domain-for-previews).
 
 ## Getting started