First Site and the Dashboard

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page walks a new user from an empty browser tab to a first site that is live on a free address. Every fact was checked on 2026-10-28. Nothing here needs a paid plan: an account, a Starter Workspace and a site that is published only to the free webflow.io staging domain are free. Where a step or setting does need a paid Workspace plan or a Site plan, the text names the plan by tier (Starter, Core, Growth, Freelancer, Agency, Enterprise for Workspaces; Starter, Basic, Premium, Team and Enterprise for the sites of the May 2026 plan lineup, plus Ecommerce Standard, Plus and Advanced), never by price. The developer example uses the Data API v2 and a Developer workspace, the free sandbox for developers, so it can be run without paying anything.

The page follows Plans, Workspaces, Seats and Roles, which explains who pays for what, and comes before Designer Tour, which opens the editor that this page only launches. The running example is Fernbrook Gardens, a fictitious botanical garden: its first site is named "Fernbrook Gardens" and is created, configured and published to a staging address in the sections below.

Accounts, Workspaces and the dashboard

A Webflow account is a login (email and password, or Google or Facebook single sign-on). An account owns nothing by itself; sites live in a Workspace, which is the container that has members, a plan, billing and a set of sites. Signing up creates a first Workspace automatically, on the free Starter Workspace plan. The same account can belong to many Workspaces: its own, a client’s, an employer’s. The Workspace switcher in the top-left corner of the dashboard changes which one is shown.

The dashboard is the web page at webflow.com/dashboard that lists the Workspace’s sites and manages everything around them. Its main areas are:

Area What it does

Sites

One card per site, showing a thumbnail, the site name, the publish status and the last edit time. Each card has buttons to open the Designer, open the Editor, copy the site, move it to a folder and open its site settings. Folders group related sites inside a Workspace.

Workspace settings

Plan and billing, members and seats, roles, the Workspace-wide libraries, apps installed for the whole Workspace and the Workspace’s API access.

Assets and libraries

Shared libraries of components and variables that sites of the same Workspace can install (the Designer Tour shows how they are used).

Templates and apps

Shortcuts to the template marketplace and the apps marketplace, covered below and in the apps pages of this sub-section.

Account settings

Personal details, notification preferences, two-step verification and the account’s own API access (personal tokens used by tools, for example the command line).

Who touches the dashboard depends on the role. A site owner or Workspace admin buys plans and invites people. A designer opens the Designer from a site card. A content editor opens the Editor, the lightweight editing view, from the same card. A marketer usually lands directly in a site’s settings or analytics. A developer uses the dashboard to create the Developer workspace, to register apps and to create site tokens.

Vocabulary: "site", not "project"

Webflow’s earlier interface and a lot of printed material call a website a project, and the site settings Project Settings. The dashboard and all current help articles use site and site settings; the word "project" survives only in old tutorials, in a few legacy URLs and in third-party tutorials built around the pre-2023 interface. A book that introduces "creating a new project" and "Project Settings" is describing the same objects: a project is a site and Project Settings are the site settings described later on this page. The Data API has always used "site" (/v2/sites). This sub-section uses site throughout.

Creating a site

The Create new site button on the dashboard starts the flow. It offers four starting points; all of them produce an ordinary site that you can edit freely afterwards, and all of them count against the Workspace plan’s limit on the number of sites (a Starter Workspace allows only a couple of them, a Freelancer or Agency Workspace is meant for many).

Starting point What you get Typical user

Blank site

An empty home page with a body element and no styles. Nothing is pre-built, so every class, variable and breakpoint setting is yours.

A designer who follows a design system, or a learner who wants to see every step.

Template

A copy of a design from the template marketplace. Free and paid templates exist; the paid ones are a one-off purchase made by the Workspace. The copy includes pages, styles, interactions, CMS Collections with example items and, sometimes, a Webflow Ecommerce setup.

A site owner who wants a finished look quickly.

Made in Webflow clone

A copy of a site that its author published as cloneable in the Made in Webflow gallery (see Cloning a cloneable).

A learner studying real production sites; a designer who wants a starting structure.

AI site builder

A generated starting site: you describe the business, answer a few questions, and the builder proposes pages, copy and a style, which it assembles in the Designer. The result is ordinary Designer content (elements, classes, variables), not a locked output. Usage is metered in AI credits, which every Workspace plan includes.

A marketer or owner who wants a first draft to edit.

Creating the site also asks for a name, which is only a label in the dashboard and in the Designer’s title bar. It is not the public title of the pages and it does not appear to visitors. The name can be changed later in the general site settings. For Fernbrook Gardens the first site starts from the blank option: an empty canvas makes the generated HTML and CSS easiest to read in the following pages.

What a new site contains

A blank site is not empty on the server. It has:

  • a Home page, with a single <body> and the w- base styles Webflow loads on every site;

  • a site ID, a 24-character hexadecimal string that identifies the site everywhere in the platform (URLs of the dashboard, the Data API, webhooks);

  • a short name, derived from the site name, that becomes the staging subdomain;

  • default site settings: no custom domain, no analytics, no custom code, forms enabled and an English locale;

  • an automatic first backup point once the site is first edited.

The part that readers who care about output should know is what the published page looks like. Webflow publishes a standard HTML document whose <html> element carries identification attributes, and it links one stylesheet and one script bundle served from its CDN. The following sketch shows the shape of a published blank page, shortened for reading; file names and hashes differ for every site.

<!DOCTYPE html>
<!-- Last Published: Wed Oct 28 2026 09:00:00 GMT+0000 (Coordinated Universal Time) -->
<html data-wf-domain="fernbrook-gardens.webflow.io"
      data-wf-page="PAGE_ID_PLACEHOLDER"
      data-wf-site="SITE_ID_PLACEHOLDER"
      lang="en">
<head>
  <meta charset="utf-8">
  <title>Fernbrook Gardens</title>
  <meta content="width=device-width, initial-scale=1" name="viewport">
  <link href="https://cdn.prod.website-files.com/SITE_ID_PLACEHOLDER/css/fernbrook-gardens.webflow.shared.HASH.css"
        rel="stylesheet" type="text/css">
</head>
<body>
  <script src="https://cdn.prod.website-files.com/SITE_ID_PLACEHOLDER/js/webflow.HASH.js"
          type="text/javascript"></script>
</body>
</html>

Source: Data API: Get Site

The data-wf-domain, data-wf-page and data-wf-site attributes are how Webflow’s own script, the Editor and custom code tell pages and sites apart. Custom scripts can read them, which is a handy way to detect that code is running on the staging domain rather than on the production domain. Because the stylesheet and the script are fingerprinted and served from a CDN, a visitor’s browser caches them for a long time and fetches new ones only after the next publish.

Site settings tour

Open the settings from the gear on a site card in the dashboard, or from the settings button in the Designer. Each tab configures one concern. They are listed here in the order they appear; which are available depends on the Workspace plan and on whether the site has a Site plan.

Tab What it controls Plan notes

General

Site name, a favicon and a webclip (the icon for a home-screen shortcut), the dashboard thumbnail, the site’s language and time zone, the date format and, where available, the toggle that makes the site cloneable. Also holds the button to transfer the site to another Workspace or to delete it.

Transferring and deleting require an owner or an admin role.

Publishing

Where the site is published: the webflow.io staging domain, and, once a Site plan and DNS are in place, custom domains. Also holds the default-domain switch, the SSL status, the publishing options (minify HTML, CSS and JavaScript; disable the webflow.io subdomain when a custom domain is live) and, on Enterprise, publishing to custom hosting.

Custom domains need a Site plan. The staging domain is free.

SEO

Site-wide title and description defaults, the default Open Graph image, the automatic sitemap, a robots.txt editor, the setting that keeps the whole site out of search results, and the canonical-URL helpers.

The robots.txt editor and sitemap are available on all sites, but a noindex staging domain is applied automatically (see below).

Forms

Form submission notifications, the Workspace-wide spam protection setting (Cloudflare Turnstile, reCAPTCHA), the honeypot behaviour and the list of recipients. Submissions are stored in the site, up to the plan’s limit (a free Starter site stores 50 submissions in total).

Higher limits and file upload need a paid Site plan.

Fonts

Google Fonts added to the site, custom font files you upload (WOFF2 recommended), Adobe Fonts through a connected Adobe account, and the fallback list. Fonts added here become choices in the Style panel.

None.

Custom code

Code added to the head and the end of the body of every page, the way to load analytics or consent scripts site-wide. Per-page code lives in each page’s settings, not here.

Custom code requires a paid Workspace plan or a Developer workspace.

Backups

The list of automatic and manual restore points, each of which can be previewed and restored. Restoring creates a new restore point first, so the action itself can be undone.

Retention depends on the plan.

Apps & integrations

Apps installed on this site, the integrations connected to it (analytics, email marketing, e-commerce add-ons) and the authorisation each one has been granted.

Some apps are paid on their own.

API access

Site tokens: keys generated for one site and scoped to chosen areas (CMS, forms, pages, e-commerce and others), used by scripts and automations that call the Data API for this site only.

Data API rate limits are 60 requests per minute on Starter and Basic sites and 120 on paid plans and Developer workspaces.

Additional tabs appear when the matching feature is active: Localization when locales are set up, Search when the built-in site search is enabled, and the hosting and ecommerce tabs for sites with a Site plan or an Ecommerce plan. Later pages cover them in depth: SEO and indexing in the SEO page, forms in the forms page, fonts in Typography and Fonts, and custom code and backups in the pages on custom code and backups.

Two tabs concern security and privacy directly. API access creates credentials: a token is a password for the site, so it belongs in an environment variable or a secrets manager, never in a Git repository or a Webflow custom-code field, which is public to every visitor. Custom code runs on every page in every visitor’s browser, so a script that is added there runs with full access to the page, including form fields. Add scripts only from sources you trust, and prefer a single reviewed tag to pasting a copy of third-party code.

Reading the site settings from the Data API

Everything the tour above shows in the dashboard also exists as data. The Data API lists the sites a token can see and returns each site’s identifiers and publishing state. This is a safe first call on a Developer workspace: it only reads. It requires a site token or an OAuth token with the sites:read scope; the token below is a placeholder that must come from an environment variable.

export WEBFLOW_API_TOKEN="<paste-a-site-token-here>"

curl --request GET \
  --url https://api.webflow.com/v2/sites \
  --header "Authorization: Bearer $WEBFLOW_API_TOKEN" \
  --header "accept: application/json"

Source: Data API: List Sites

The response is a JSON object with a sites array. Each entry shows the identifiers and the staging domain, which is what the rest of this page is about:

{
  "sites": [
    {
      "id": "SITE_ID_PLACEHOLDER",
      "workspaceId": "WORKSPACE_ID_PLACEHOLDER",
      "displayName": "Fernbrook Gardens",
      "shortName": "fernbrook-gardens",
      "previewUrl": "https://cdn.prod.website-files.com/…/preview.png",
      "timeZone": "Europe/Madrid",
      "createdOn": "2026-10-28T08:30:00.000Z",
      "lastUpdated": "2026-10-28T08:55:00.000Z",
      "lastPublished": "2026-10-28T09:00:00.000Z",
      "customDomains": []
    }
  ]
}

Source: Data API: List Sites

The fields line up with the dashboard: displayName is the site name from the General tab, shortName is the part before .webflow.io, and an empty customDomains array means that only the staging domain is live. The same API can publish: POST /v2/sites/{site_id}/publish with a body that lists the domains to publish to, and a limit of one publish per minute per site.

Source: Data API: Publish Site

The webflow.io staging domain

Every site has a free address of the form <short-name>.webflow.io, called the staging domain. Publishing from the Designer’s Publish button always offers it, and on a site without a Site plan it is the only target. Four points describe how it behaves:

  • It is real hosting. The page is served from Webflow’s CDN with TLS, so a link to it works for anyone, and it is the address clients and reviewers are sent for approval before the real domain is connected.

  • It is not for search engines. Webflow adds a noindex signal to pages served from the staging domain, so Google does not index them. Moving the same site to a custom domain removes the signal. A custom domain should never be proxied in front of webflow.io, because the signal would travel with the content.

  • It has limits. Free sites on the staging domain have reduced page, CMS item and bandwidth allowances, and a Developer workspace is capped at 1,000 visitors per month and cannot publish to a production domain. Staging pages are publicly reachable, so they are not a place for private content; a password-protected page is the right tool for that.

  • It can be turned off. When a custom domain is live, the Publishing tab lets you unpublish from the webflow.io address, so that the old copy does not stay reachable.

Publishing is explicit: edits in the Designer are saved continuously but are visible to visitors only after Publish. Publishing sends the generated HTML, the shared stylesheet and the script to the CDN. The staging domain is therefore the natural test target: publish, open the address in a private window, check the page on a phone, and only then publish to the custom domain. This is the same loop that a CI pipeline uses with the publish endpoint above.

For Fernbrook Gardens the first publish creates fernbrook-gardens.webflow.io. Whatever the page content, the first check is the address bar: if it shows webflow.io, the staging page is the one being tested.

Cloning a cloneable

A cloneable is a site whose author has turned on cloning in the General tab and then published it to the Made in Webflow gallery. The gallery shows live sites with the author’s name and a Clone button.

To clone one, you need to be logged in. The button asks for the Workspace to receive the copy and then creates a new site there, with the layout, styles, classes, variables, components, interactions and CMS Collections of the original. Facts that surprise people:

  • The clone is independent. Later changes made by the author never reach your copy, and yours never reach theirs.

  • The copy counts as a new site in your Workspace, and so counts against the Workspace plan’s site limit.

  • It keeps the original’s structure, class names and naming habits, which is a good way to study how others work and a poor way to learn good habits: read the class names before you extend them.

  • What is cloned is the Designer content. Domains, paid-plan settings, form submissions, ecommerce orders and licence-bound assets (such as custom fonts) do not come along, and the author’s licence terms still apply to images and text.

  • The gallery was called Showcase in older material. If the Clone button reports a missing requirement, such as a plan or a free site slot, resolve it in the Workspace before retrying.

Cloning a site you did not write is a way to inherit surprises, so audit it before publishing: remove sample forms that still point at the author’s notification address, check the custom code in the site settings, and replace third-party tracking identifiers that belong to the author.

Corrections to older tutorials

Material written before the 2023 interface refresh differs from the current product in places that matter to a first-time user. This page follows the current help articles and the dashboard as it is today.

  • Project is now site. The older vocabulary of projects and Project Settings is replaced by sites and site settings; the tabs documented above are the successors of the old Project Settings tabs.

  • Plans changed names. Older accounts were described as Lite, Pro and Team, and sites as Basic, CMS and Business. The current lineup separates Workspace plans from Site plans, and the May 2026 plans merged the former CMS and Business plans into Premium. The earlier per-site page and item caps no longer apply as they were quoted.

  • Showcase is Made in Webflow. The gallery was renamed, and cloning a site is now governed by the author’s cloneable switch.

  • The Editor changed. Editing through the ?edit suffix was retired; the Editor is opened from the dashboard card or from inside the Designer.

  • Code export is a Workspace feature. Older text ties code export to the Lite plan or to a paid site plan. It requires a paid Workspace plan and is unavailable on a Developer workspace.

  • Webflow University moved. Many university links now redirect to the Help Center.

Pitfalls and checklist

  • Do not treat the webflow.io address as private. It is public, unindexed and shareable, but reachable by anyone who has the link.

  • Do not publish from a freshly cloned site before reviewing its custom code and form settings.

  • Do not paste a site token into custom code or commit it to Git. Rotate it if it has leaked.

  • Remember the one-publish-per-minute limit when scripting publishes.

  • Do pick a clear site name, because the staging subdomain derived from it is used in review emails.

  • Do open the site settings once after creating a site, to set the time zone, the language and the robots rules.

References