With GDPR dominating the airwaves (and your inboxes) lately, we’ve been getting more questions around how Webflow handles site visitors and form submissions for websites running on Webflow Hosting. I wanted to address some of those concerns here.
First, in regards to general website traffic:
-
As requests come in, our servers record hashed IP address in memory only for up to 24 hours in order to prevent against brute-force attacks (that is, to prevent one computer sending thousands of request to one page per second from crashing our service for all other visitors).
-
These hashed IPs are also used to “guesstimate” how many unique visitors a site receives (using an algorithm called HyperLogLog), without actually needing to store the addresses. The output of this algorithm is a single number (not a database of requests) and is only used to display the “Unique Visits” statistic on a Webflow project’s dashboard (under
General > Site Statistics > Unique Visits). -
Full IP addresses (or any other information that can trace back to a person’s identity) for any hosted site visitor are never stored on disk or in our logs. When we do need to record access and error logs where something like an IP address is useful (for example, to tell which edge server across the world should serve a request), we anonymize the address by removing the last octet. For example, if my IP address is
157.130.212.112and the request is temporarily logged,157.130.212._is written to the logs instead. While you can get some information from this type of address (for example, the country or city of the visitor), it doesn’t contain enough detail to be associated with an individual internet connection or physical address.- When we work with partners like Fastly for speeding up our websites, we make sure to configure our integrations in a way that full IP addresses are never logged.
-
We don’t share or sell any data around user requests or visits, period. We believe doing so would be a breach of customer trust. We would only add any kind of analysis or reporting by customer demand (for example, for a future more robust traffic dashboard), and even in those cases we would bias heavily towards avoiding any processing of personal information.
As a follow up to that, here’s what we do with adding cookies on published sites:
-
We absolutely don’t add any tracking, analytics, or any other kinds of cookies to published sites by default.
-
If you choose to enable Google Analytics for your site, or Typekit, or widgets like the Facebook Like button, then those particular components might add 3rd party scripts or cookies that are outside of our control.
-
If you add custom code that pulls in 3rd party scripts, those scripts may add cookies to your site. But these are all under your control as the site owner, and Webflow is not adding anything behind the scenes to track your users.
-
If you use the Editor via the
?editshortcut, we do set a first-party session cookie in order to facilitate login to the editor, without which logging in would be impossible. This only applies to the site owner and collaborators who know about that URL, and this cookie is not set for actual page visitors.
If you’re also adding forms to your websites, and processing form submissions with Webflow, here’s how we handle that data:
-
Form submissions are sent securely from a site visitor’s browser to Webflow’s servers over HTTPS
-
Our database servers are hosted on the Amazon Web Services cloud within the United States
-
All of our database servers are isolated from the public internet via Amazon’s Virtual Private Cloud, and access to our servers is controlled under strict security protocols
-
All form submission data is stored in an encrypted database.
-
Webflow is certified under the Privacy Shield program, which creates a legal framework for transferring the data of EU/Swiss subjects outside of Europe. We provide more detail about this in the International Transfers section of our EU & Swiss Privacy Policy.
-
We store the IP address associated with that form submission to prevent brute-force submissions (and soon, when we release reCAPTCHA functionality for forms, the IP address will be used to prevent against certain types of CAPTCHA-circumvention attacks by spammers). We’re currently investigating whether it makes sense to place a shorter retention policy on these addresses.
-
Webflow staff does not have direct access to form submission data, and it’s automatically removed for debugging operations (for example, when a customer asks our support team to investigate a bug on one of their sites and we clone that site for analysis, the cloned site does not contain any visitor or form submission data). There are strong access control and security policies in place that prevent access to this data.
-
We only make form submission data available to the site owner so that they can use it for the purpose for which it was collected.
- We ask all site owners to follow certain rules for handling end user data for which they are the data controller.
- We’re also implementing a feature to allow site owners to hide their own access to form submission data in the case where they are not the true Data Controller for the form submission data. This feature will still have some flexibility to see form data during the testing/development of a site (that is, when you’d typically send test submissions to make sure everything works), and revoke it once a site is handed over to a client.
-
We absolutely do not share, pass on, analyze, or sell any form submission data to any other parties. We believe this would be a fundamental breach of the trust you place in us as a website hosting and management platform.
-
We offer the flexibility to completely skip submitting to Webflow’s servers by setting a custom
actionfor forms built in Webflow.- We also have native integrations for sending form submissions directly to MailChimp, so that form submission data never lands on our servers. Here’s a handy guide on how to do that:
Add subscribers to Mailchimp with Webflow Logic - Webflow University Documentation
- We also have native integrations for sending form submissions directly to MailChimp, so that form submission data never lands on our servers. Here’s a handy guide on how to do that:
In a nutshell– while some other companies out there would jump at the chance to analyze, share, and potentially sell the high volume of visitor data, we have no desire or intention to do so. We believe that going in that direction would compromise the trust that our customers and this community has placed in us as a robust and dependable web design platform.
Please let me know if there are any follow up questions that I can answer - I’ll be around! 
