cloudflare · korinne · Mar 6, 2026 · Mar 6, 2026 · Mar 6, 2026 · Mar 6, 2026
@@ -1964,6 +1964,7 @@
 /workers/tutorials/hello-world-rust/ /workers/tutorials/ 301
 /workers/tutorials/introduction-to-cloudflare-workers/ https://www.youtube.com/watch?v=H7Qe96fqg1M 301
 /workers/configuration/bindings/about-service-bindings/ /workers/runtime-apis/bindings/service-bindings/ 301
+/workers/configuration/previews/ /workers/previews/ 301
 /workers/tutorials/localize-a-website/ /pages/tutorials/localize-a-website/ 301
 /workers/tutorials/manage-projects-with-lerna/ /pages/configuration/monorepos/#monorepo-management-tools 301
 /workers/tutorials/create-sitemap-from-sanity-cms/ /resources/ 301

@@ -14,7 +14,7 @@ The Deploy to Cloudflare button:
 1. **Creates a new Git repository on your GitHub/ GitLab account**: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing. 
 2. **Automatically provisions resources the app needs**: If your repository requires Cloudflare primitives like a [Workers KV namespace](/kv/), a [D1 database](/d1/), or an [R2 bucket](/r2/), Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment. 
 3. **Configures Workers Builds (CI/CD)**: Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of [Workers Builds](/workers/ci-cd/builds/).
-4. **Adds preview URLs to each pull request**: If you'd like to test your changes before deploying, you can push changes to a [non-production branch](/workers/ci-cd/builds/build-branches/#configure-non-production-branch-builds) and [preview URLs](/workers/configuration/previews/) will be generated and [posted back to GitHub as a comment](/workers/ci-cd/builds/git-integration/github-integration/#pull-request-comment).   
+4. **Adds preview URLs to each pull request**: If you'd like to test your changes before deploying, you can push changes to a [non-production branch](/workers/ci-cd/builds/build-branches/#configure-non-production-branch-builds) and [preview URLs](/workers/previews/) will be generated and [posted back to GitHub as a comment](/workers/ci-cd/builds/git-integration/github-integration/#pull-request-comment).   
 
 ![Import repo or choose template](~/assets/images/workers/dtw-user-flow.png)
 

@@ -6,7 +6,7 @@ tags:
 date: 2025-08-14T01:00:00Z
 ---
 
-We've updated [preview URLs](/workers/configuration/previews/) for Cloudflare Workers to support long branch names.
+We've updated [preview URLs](/workers/previews/) for Cloudflare Workers to support long branch names.
 
 Previously, branch and Worker names exceeding the 63-character DNS limit would cause alias generation to fail, leaving pull requests without aliased preview URLs. This particularly impacted teams relying on descriptive branch naming.
 

@@ -5,7 +5,7 @@ date: 2025-09-17
 ---
 import { WranglerConfig, Aside } from "~/components";
 
-To prevent the accidental exposure of applications, we've updated how [Worker preview URLs](/workers/configuration/previews/) (`<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev`) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers. 
+To prevent the accidental exposure of applications, we've updated how [Worker preview URLs](/workers/previews/) (`<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev`) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers. 
 
 ## One-Time Update for Workers with workers.dev Disabled
 We performed a one-time update to disable preview URLs for existing Workers where the [workers.dev subdomain](/workers/configuration/routing/workers-dev/) was also disabled.
@@ -16,7 +16,7 @@ If your Worker was affected, its preview URL (`<PREVIEW>-<WORKER_NAME>.<SUBDOMAI
 
 **How to Re-enable Your Preview URL**
 
-If your preview URL was disabled, you can re-enable it [via the Cloudflare dashboard](/workers/configuration/previews/#toggle-preview-urls-enable-or-disable) by navigating to your Worker's Settings page and toggling on the Preview URL.
+If your preview URL was disabled, you can re-enable it [via the Cloudflare dashboard](/workers/previews/#enable-or-disable-preview-urls) by navigating to your Worker's Settings page and toggling on the Preview URL.
 
 Alternatively, you can use Wrangler by adding the `preview_urls = true` setting to your Wrangler file and redeploying the Worker.
 

@@ -8,7 +8,7 @@ date: 2025-10-03
 
 import { DashButton } from "~/components";
 
-You can now enable [Cloudflare Access](/cloudflare-one/access-controls/policies/) for your [`workers.dev`](/workers/configuration/routing/workers-dev/) and [Preview URLs](/workers/configuration/previews/) in a single click.
+You can now enable [Cloudflare Access](/cloudflare-one/access-controls/policies/) for your [`workers.dev`](/workers/configuration/routing/workers-dev/) and [Preview URLs](/workers/previews/) in a single click.
 
 ![Screenshot of the Enable/Disable Cloudflare Access button on the workers.dev route settings page](~/assets/images/workers/changelog/workers-access.png)
 

@@ -3,7 +3,7 @@ title: Workers Preview URL default behavior now matches your workers.dev setting
 description: If a Workers Preview URL setting is not explicitly configured, its default behavior will now match the setting of the workers.dev subdomain.
 date: 2025-10-23
 ---
-We have updated the default behavior for Cloudflare Workers [Preview URLs](/workers/configuration/previews/). **Going forward, if a preview URL setting is not [explicitly configured](/workers/configuration/previews/#toggle-preview-urls-enable-or-disable) during deployment, its default behavior will automatically match the setting of your [`workers.dev` subdomain](/workers/configuration/routing/workers-dev/).**
+We have updated the default behavior for Cloudflare Workers [Preview URLs](/workers/previews/). **Going forward, if a preview URL setting is not [explicitly configured](/workers/previews/#enable-or-disable-preview-urls) during deployment, its default behavior will automatically match the setting of your [`workers.dev` subdomain](/workers/configuration/routing/workers-dev/).**
 
 This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your `workers.dev` configuration to prevent cases where a preview URL might remain public even after you disabled your `workers.dev` route.
 
@@ -12,7 +12,7 @@ This change is intended to provide a more intuitive and secure experience by ali
 - **If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled:** Preview URLs will default to enabled
 - **If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled:** Preview URLs will default to disabled
 
-You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the [API](/api/resources/workers/subresources/scripts/subresources/subdomain/), [Dashboard](/workers/configuration/previews/#from-the-dashboard), or [Wrangler](/workers/configuration/previews/#from-the-wrangler-configuration-file). 
+You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the [API](/api/resources/workers/subresources/scripts/subresources/subdomain/), [Dashboard](/workers/previews/#from-the-dashboard), or [Wrangler](/workers/previews/#from-the-wrangler-configuration-file). 
 
 **Wrangler Version Behavior**
 

@@ -6,7 +6,7 @@ products:
 date: 2025-10-30
 ---
 
-You can now access [preview URLs](/workers/configuration/previews/) directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.
+You can now access [preview URLs](/workers/previews/) directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.
 
 ![preview button](src/assets/images/changelog/workers/builds-preview-button.png)
 

@@ -6,7 +6,7 @@ sidebar:
   order: 6
 ---
 
-When you connect a git repository to Workers, commits made on the production git branch will produce a Workers Build. If you want to take advantage of [preview URLs](/workers/configuration/previews/) and [pull request comments](/workers/ci-cd/builds/git-integration/github-integration/#pull-request-comment), you can additionally enable "non-production branch builds" in order to trigger a build on all branches of your repository.
+When you connect a git repository to Workers, commits made on the production git branch will produce a Workers Build. If you want to take advantage of [preview URLs](/workers/previews/) and [pull request comments](/workers/ci-cd/builds/git-integration/github-integration/#pull-request-comment), you can additionally enable "non-production branch builds" in order to trigger a build on all branches of your repository.
 
 ## Change production branch
 

@@ -51,7 +51,7 @@
 
 The non-production branch deploy command is only applicable when you have enabled [non-production branch builds](/workers/ci-cd/builds/build-branches/#configure-non-production-branch-builds).
 
-It defaults to `npx wrangler versions upload`, producing a [preview URL](/workers/configuration/previews/). Like the build and deploy commands, it can be customized to instead run anything.
+It defaults to `npx wrangler versions upload`, producing a [preview URL](/workers/previews/). Like the build and deploy commands, it can be customized to instead run anything.
 
 Examples of other non-production branch deploy commands you can set include:
 
@@ -75,7 +75,7 @@
 It is recommended to consistently use the same API token across all uploads and deployments of your Worker to maintain consistent access permissions.

 ## Framework support

 [Static assets](/workers/static-assets/) and [frameworks](/workers/framework-guides/) are now supported in Cloudflare Workers. Learn to set up Workers projects and the commands for each framework in the framework guides:

 <DirectoryListing folder="workers/framework-guides" maxDepth={4} />

@@ -18,7 +18,7 @@ If a commit is on a pull request, Cloudflare will automatically post a comment o
 
 ![GitHub pull request comment](~/assets/images/workers/platform/ci-cd/github-pull-request-comment.png)
 
-A [preview URL](/workers/configuration/previews/) will be provided for any builds which perform `wrangler versions upload`. This is particularly useful when reviewing your pull request, as it allows you to compare the code changes alongside an updated version of your Worker.
+A [preview URL](/workers/previews/) will be provided for any builds which perform `wrangler versions upload`. This is particularly useful when reviewing your pull request, as it allows you to compare the code changes alongside an updated version of your Worker.
 
 Comment history reveals any builds completed earlier while the PR was open.
 

@@ -18,7 +18,7 @@ If a commit is on a merge request, Cloudflare will automatically post a comment
 
 ![GitLab merge request comment](~/assets/images/workers/platform/ci-cd/gitlab-pull-request-comment.png)
 
-A [preview URL](/workers/configuration/previews/) will be provided for any builds which perform `wrangler versions upload`. This is particularly useful when reviewing your pull request, as it allows you to compare the code changes alongside an updated version of your Worker.
+A [preview URL](/workers/previews/) will be provided for any builds which perform `wrangler versions upload`. This is particularly useful when reviewing your pull request, as it allows you to compare the code changes alongside an updated version of your Worker.
 
 :::note[Enabling GitLab Merge Request events for existing connections]
 New GitLab connections are automatically configured to receive merge request events, which enable commenting functionality. For existing connections, you'll need to manually enable `Merge request events` in the Webhooks tab of your project's settings. You can follow GitLab's documentation for guidance on [managing webhooks](https://docs.gitlab.com/user/project/integrations/webhooks/#manage-webhooks).

@@ -47,7 +47,7 @@ When connecting a repository to a Workers project, the Worker name in the Cloudf
 
 You can monitor a build's status and its build logs by navigating to **View build history** at the bottom of the **Deployments** tab of your Worker.
 
-If the build is successful, you can view the build details by selecting **View build** in the associated new [version](/workers/configuration/versions-and-deployments/) created under Version History. There you will also find the [preview URL](/workers/configuration/previews/) generated by the version under Version ID.
+If the build is successful, you can view the build details by selecting **View build** in the associated new [version](/workers/configuration/versions-and-deployments/) created under Version History. There you will also find the [preview URL](/workers/previews/) generated by the version under Version ID.
 
 :::note[Builds, versions, deployments]