Frequently asked questions

Yes, you can use Cloudflare Workers with Webstudio-hosted sites. Set your main domain's CNAME to 'proxied' in Cloudflare to enable Workers, while keeping subdomain CNAMEs (like those pointing to Webstudio) as 'DNS only'. This allows you to reverse-proxy different subdomains or paths through your Worker without creating double-proxy issues.

Patterns:

1. Main domain proxied -> Worker routes traffic to a Webstudio project subdomain
2. Worker maps /blog or /app path segments to a Webstudio project
3. Avoid chaining (nesting) a proxied CNAME behind another proxied CNAME

Only the domain terminating at the Worker should be orange-cloud (proxied); project CNAMEs stay DNS-only.

To create different navigation styles for different pages, you need to unlink the navigation from the global slot. Copy the navigation out of the 'navbar transparent_home' slot which synchronizes navigation across all pages. Once copied out of the slot, you can style each navigation independently without affecting other pages.

When working with CMS data that isn't in slug format, you can use JavaScript in an HTML Embed to format the links. Create click event handlers that process the text (convert 'Door Hardware' to 'door-hardware'), then navigate to the formatted URL. Remember to use event.preventDefault() to stop the original link behavior before applying your custom navigation logic.

When a Radix Sheet component doesn't close automatically after clicking a link that redirects to a different section on the same page, this typically requires custom JavaScript to handle the sheet closing behavior. The Radix Sheet component doesn't automatically close for same-page anchor links, so you'll need to add JavaScript to detect the navigation and trigger the sheet close event manually.

If Webstudio is automatically setting canonical URLs to include query parameters (causing duplicate content issues in Google Search Console), you can configure the canonical URL in the page settings. Set it to exclude query parameters and normalize trailing slashes to avoid SEO issues. This setting is available in the page's SEO configuration panel.

This is a limitation with the current router used for Docker deployments. Assets in _image/** routes can be incorrectly handled by root dynamic pages like :slug. As a workaround, use more specific paths like /blog/:slug instead of just :slug for your dynamic pages. This issue is recognized and may be addressed in future releases.

For forms that need to both submit data and perform actions (like scrolling or redirecting), you have several options:

1. Use Webstudio's built-in webhook forms for data submission,
2. Combine with custom JavaScript in HTML Embed for additional actions,
3. Set up proper redirect URLs in your form settings,
4. For complex workflows, consider using external automation tools like n8n or Make.com to handle form processing and subsequent actions.

To scroll to the top when a button is clicked, you have two options:

1. Use a link with href pointing to the top of the page (like href='#top' and add an element with id='top' at the top),
2. Use custom JavaScript in an HTML Embed to handle both form submission and scrolling. For smooth scrolling, you can also add CSS property 'scroll-behavior: smooth' to your page.

To set up a custom 404 page:

1. Create your custom 404 page,
2. In the page settings, set the path to '/*' (catch-all),
3. Set the status code to 404 (important for SEO - prevents search engines from wasting crawl budget on non-existent pages),
4. This will make your custom 404 page handle all unmatched routes instead of showing the default blank 404 page.

Webstudio requires CNAME records for custom domains. If your DNS provider converts CNAME to ALIAS for root domains (like Hostinger), this won't work because Webstudio only supports CNAME.

Solutions:

1. Use 'www' subdomain with CNAME pointing to Webstudio,
2. Move to a DNS provider that supports CNAME flattening (like Cloudflare),
3. For unsupported TLDs (.de domains), register a .com equivalent on Cloudflare and redirect. The 'www' approach is recommended if CNAME flattening isn't available.

While you can use any domain registrar, Cloudflare is recommended for DNS management because it supports CNAME flattening, which allows you to use root domains (without www) properly. Other registrars like Namecheap have limitations that can break email services and other domain-connected features.

403 Forbidden errors in Google Search Console are often caused by bot protection settings in Cloudflare. Check your Cloudflare account for bot protection features that might be blocking search engine crawlers. If you're using Cloudflare nameservers, ensure the security settings allow legitimate bot traffic. You can also manually trigger a crawl in Google Search Console to test if the issue is resolved after adjusting your Cloudflare settings.

In Docker deployments, dynamic routes like ':slug' can intercept image asset requests (like '_image/**' routes), causing 404/302 errors when the slug is connected to a CMS. This is a limitation of the current router used for deployment. The workaround is to use more specific paths like '/blog/:slug' instead of root-level dynamic routes.

Your DNS provider likely lacks CNAME flattening at the apex. Adding 'www' ensures reliable CNAME mapping without breaking other records (email, etc.). To use the root cleanly, switch nameservers to a provider (e.g. Cloudflare) that supports flattening.

Root domain setup is non-standard and broken with some providers like Namecheap. It can break other services connected to your domain (like email). The solution is to use CNAME flattening by migrating your domain to Cloudflare nameservers, which properly supports root domain hosting and gives you additional options and protection.

If the publish button is disabled after adding a custom domain, check for error messages displayed in red text in the domain configuration dialog. Common issues include DNS record errors or domain verification problems. The publish button remains disabled until all domain configuration errors are resolved. Make sure your DNS records are properly configured and the domain status shows as 'Active' before publishing.

This was a known issue where Webstudio's redirect validation was too strict and didn't allow question marks and other URL characters in redirect paths.

The validation has been updated and this issue has been fixed in GitHub PR 5348. You can now use query parameters and special characters in your redirects. The new validation uses URL parsing to properly validate redirect paths instead of character-by-character checking.