WCH Documentation

WCH (Webflow Custom Hosting) turns your Webflow site into a static website and delivers it to hosting you control, such as AWS S3, Azure Blob Storage, Aliyun OSS, SFTP, or GitHub. You keep designing and editing in Webflow. WCH rebuilds your site on every publish, hosts it on a staging site for review, and sends it to your live site only when you choose. New to WCH? Start with the WCH Overview, then follow Steps to Publishing in WCH.

301 Redirects The 301 Redirects page shows every permanent redirect set up for your site in one place and lets you download the full list as a CSV or JSON file for audits, backups, or moving them to your production host.
AWS Production Deployment A recommended AWS setup for hosting a WCH project: a private S3 bucket receives the WCH archive, CodePipeline or Lambda extracts it, and CloudFront serves the site.
AWS S3 Authentication An AWS S3 destination can authenticate to your bucket three ways: Assume Role, Resource Policy, or Access Key. This page explains each one, what to set up on the AWS side, and how to fill in the destination in WCH.
Aliyun OSS: Basic Implementation An Aliyun OSS destination uploads your published site file by file into an Alibaba Cloud Object Storage Service bucket. Create the bucket, give a RAM user permission to write to it, and enter its AccessKey in WCH.
Allowlisting WCH IP Addresses If your server or firewall only accepts traffic from known IP addresses, allow the addresses WCH production sends from. This page lists them and explains when they change.
Archives An archive is a zip of your whole site exactly as WCH built it. The Archives page lets you create one on demand, download it, and promote any earlier build to production, which is how you roll back a release.
Azure: Basic Implementation Set up an Azure Storage container that receives the WCH archive, choose how WCH authenticates to it, and unpack the zip with an Azure Function.
Cache Cache lets WCH skip pages that have not changed since your last publish, so large sites publish faster. Turn it on from the Cache page, and clear it when you need every page rebuilt from scratch.
Code Components Webflow Code Components load their code from Webflow's servers when a visitor opens the page. Turn on Include Code Components and WCH downloads those files into your build, so the components load from your own site.
Creating a project A WCH project holds one website: where its content comes from, how it is built, and where it is deployed. Create the project, add your Webflow site as a source, and check two settings before your first publish.
Excluded URLs Excluded URLs tell WCH which scripts and assets to leave on their original host instead of downloading a local copy. Use them for third-party scripts that must load from the vendor, such as analytics, consent banners, and chat widgets.
File Prefix and Root directory Three settings decide where your pages and assets land in the build and at your destination: Root directory, File Prefix, and Use full asset path. Use them to serve a site from a subfolder, share a bucket with other content, or avoid clashing file names.
GitHub: Basic Implementation Connect a GitHub repository as a destination and WCH commits your published site to it. Every publish becomes one commit and one tag, so your repository history doubles as a publish history.
Localization and hreflang WCH publishes a site built with Webflow Localization as-is, with each language in its own folder. It points canonical and hreflang links at your live domain, lists locale versions in sitemap.xml, and leaves the root redirect to your host.
Members, roles and sign-in Everyone on your WCH team is either an admin or a member. Admins invite people, set up destinations, and change settings. Members publish and review builds. This page covers inviting people, changing roles, signing in, and resetting a password.
Output path overrides By default WCH writes each page to the same path it has in Webflow. Output path overrides let you publish a page somewhere else on your static site, either at an exact path or inside a different parent folder, using a custom attribute or a CMS field.
Pagination Webflow's CMS pagination and Load more rely on Webflow hosting, so they stop working on a WCH-hosted site. Use Slater Data for a client-side list with load more, search, and filters, or use WCH's legacy static pagination to generate one page per paginated state.
Project Settings Project Settings holds every per-project option: the domain your sitemap and canonical links use, where files land, who can see staging, how WCH finds your pages, and robots.txt. Each field below says when it takes effect and what it inherits from your team.
Publish errors and troubleshooting When a publish stops early, skips pages, or fails to reach a destination, WCH says why in Project Logs. This page lists the messages you are most likely to see, what each one means, and what to do next.
Publishing modes Publishing mode controls how WCH finds the pages on your site when you publish. Most sites use Sitemap and never need to change it, but two other modes give you more control when you work with Webflow CMS content.
Removing Dead Files During an S3 Publish Update a static website in S3 without temporarily breaking pages, while safely removing files that are no longer part of the latest WCH publish.
Rendering The Rendering page lists every page and file WCH has built for your project. Use it to find a page, publish a few pages without a full publish, look at a page's earlier versions and code, and remove pages you no longer want in the build.
Search Webflow's built-in site search needs Webflow hosting, so it stops working on a WCH-hosted site. Use Slater global site search instead: one search box across every CMS collection and static page, wired up with attributes in the Webflow Designer.
Sitemap settings WCH writes a fresh sitemap.xml for your site on every publish, using your live domain and the pages it actually published. Three settings shape it: how the sitemap is split, which pages are left out, and whether URLs end in a slash.
Staging site Every publish to WCH lands on your staging site first, a hosted copy you can review before anything reaches production. Staging visibility decides who can open it: anyone with the link, only people who sign in, or no one.
Steps to Publishing in WCH Publishing takes your Webflow site, rebuilds it inside WCH, and sends the finished files to the hosting you control.
Substitutions Substitutions find a piece of text and replace it with different text every time your project publishes. Use them to swap staging URLs for production URLs, fix a recurring typo, or update a brand name across your whole site at once.
Team settings and templates Team settings set the defaults every project in your team starts from, and team templates let you set up an AWS S3 or Azure destination once and reuse it across projects. Some defaults follow the team live, others are copied when a project is created.
WCH Go-Live Checklist A practical go-live checklist covering staging review, production setup, SEO, redirects, DNS cutover, and post-launch validation. Use it to catch common migration issues before they become production problems.
WCH Overview WCH (Webflow Custom Hosting) turns your Webflow site into a static website and delivers it to hosting you control, such as AWS S3, Azure Blob Storage, Aliyun OSS, SFTP, or GitHub.
WCH Publishing Publishing turns your Webflow site into a static website that WCH hosts on a staging URL and delivers to your own hosting, such as an S3 bucket, an Azure container, or a GitHub repository.
Webhooks Webhooks let a publish in Webflow start a publish in WCH automatically, so you never have to click Publish twice. WCH has two kinds: publishing webhooks for whole-site publishes, and CMS webhooks for single collection item changes.