Set up one proxy rule, build multiple pages in one project
With this approach, you can create one proxy rule and then your team can build one page at a time and as soon as the site is published the route is live in production.
Setting up the proxy
The way most of our customers approach this is by setting up a rule in their proxy for an entire directory.
If the directory that you're proxying can be dedicated to just Webflow projects, you can configure your proxy so that any request to yourdomain.com/us/some-directory/{some-page} would serve up the corresponding page from the Webflow project by default.
So, for example, if someone requests yourdomain.com/us/some-directory/some-page they would be served yourdomain.webflow.io/some-page. Or if they request /us/some-directory/new-directory/new-page they would be served yourdomain.webflow.io/new-directory/new-page. If the page doesn’t exist in the Webflow project, then they would receive a 404 that you can customize in Webflow.
Obviously, you can customize this directory to whatever works best for your team, but this would allow your team to move at speed without putting a lot of work on the IT team every time a page launches.
Considerations
What are the considerations and things we should keep in mind with this approach?
- CSS and JS files in Webflow are global
- You can have unique styles and components across brands and campaigns, but the CSS and JS for the entire site is served with each page. This may have a small impact on performance, but if the target is to ship ten different pages/microsites I don’t see this as an issue
- Multiple teammates working in the same project
- This feature allows you to have multiple people working in the project simultaneously
- To merge branches and publish Designers would need to request Design control, but again, with the small amount of pages I don’t think this is a blocker
- Teammates can still spin up projects that aren’t being proxied to explore concepts and play with designs before copying/pasting to or rebuilding in our prod site
- Managing updates to the site
- One thing that was surfaced by other customers was how using one site could impact things if the Marketing team was updating the site after launch.
- Here’s a video of our roles/permissions and how the Editor works:
- If you have two folks working in the Designer and a few Marketers making changes at the same time you could have some collisions if you don’t communicate with each other, but given the volume mentioned above I think this is easily avoidable
- Another option as mentioned is to just pass on any changes to the team doing the development work
This approach remains feasible as long as the number of sites/pages you are shipping remains low and you don’t see a lot of maintenance happening (daily updates, etc.)
But, if you’re thinking about shipping a higher volume, there is another approach to think about.
Set up multiple proxy rules in a batch, add domains when needed
With this approach you can batch set up proxy rules, and then they’re available when or if you need them.
Setting up the proxy
With this approach you can provision a batch of domains up front. Here’s an example:
- some-subdomain-one.yourdomain.com
- some-subdomain-two.yourdmain.com
- some-subdomain-three.yourdmain.com
- some-subdomain-four.yourdmain.com
- some-subdomain-five.yourdmain.com
- etc.
Once those exist, you can set up your proxy rules in one batch. You can follow the same approach as above, but you can map the subdomains created to directories. For example:
- /us/some-directory/dir1 => maps to: some-subdomain-one.yourdomain.com
- /us/some-directory/dir2 => maps to: some-subdomain-two.yourdomain.com
- /us/some-directory/dir3 => maps to: some-subdomain-three.yourdomain.com
- /us/some-directory/dir4 => maps to: some-subdomain-four.yourdomain.com
- /us/some-directory/dir5=> maps to: some-subdomain-five.yourdomain.com
- etc.
Once this is setup, the team can choose one of the projects where the subdomains that have been provisioned are added, design, and push the publish button. Once published, the site is live.
Then any request to that directory is live and working. So, a request to yourdomain.com/us/some-directory/dir1/some-page would originate from yourdomain.com/us/some-directory/some-page.
Again, this allows the team to move at speed, and minimizes the impact on IT. Instead of having to create everything on demand, they can do it up front and then only need to provide maintenance.
Considerations
- This would require you to add the domains to multiple sites ahead of time. You would need to organize the space well so that the team doesn’t accidentally work in a prod site and publish sample pages to your prod environment.
- This removes the friction of:
- Global CSS and JS
- Multiple teammates working in a single site
- Managing updates to the site
- You wouldn’t have as many people working on the same site, but you would need to add folks as collaborators to multiple sites