GoDaddy (domaincontrol.com)

Webflow hosts and serves a published site, but the records that tell the internet where that site lives sit wherever your domain’s DNS is managed. Webflow cannot write them for you. One wrong IP address or hostname and the root domain resolves nowhere, the certificate never provisions, and the site stays reachable only on its webflow.io address.

A domain registered with GoDaddy uses GoDaddy’s own DNS by default, so the records Webflow needs go into GoDaddy’s DNS panel. You add one A record, one CNAME, and one TXT verification record there, add the same domain in your Webflow Site settings, and publish. GoDaddy keeps the registration and the zone file while Webflow serves the site.

This matters most when the domain already exists and already has traffic on it. A freelancer launching a client site on a domain the client bought years ago, or an agency inheriting a GoDaddy account full of records nobody documented, will spend more time auditing the existing zone file than adding Webflow’s three records.

How to integrate GoDaddy with Webflow

What is GoDaddy? GoDaddy is a domain registrar and DNS host. Domains registered there use GoDaddy’s nameservers by default, whose hostnames sit under domaincontrol.com, and the zone file is edited in the GoDaddy account that holds the domain. GoDaddy has no Webflow Marketplace app, so the two products connect through DNS records rather than an install.

Teams pair the two when a Webflow-hosted site needs to answer on a domain GoDaddy registered. Nothing syncs between the platforms and no data moves between them. The whole integration is three DNS records on the GoDaddy side and a domain entry on the Webflow side.

Three paths cover almost every GoDaddy setup:

• Editing GoDaddy DNS records keeps GoDaddy’s nameservers in place and is the default path for a single site.
• A nameserver change hands the zone to a different DNS host, where you create the same records instead.
• The GoDaddy Domains API writes those records programmatically, which suits portfolios rather than one-off launches.

Most launches use only the first. The API path earns its setup cost once you are connecting domains in batches.

Add Webflow’s DNS records in GoDaddy

This is the default path: keep GoDaddy’s nameservers and edit the zone file in your GoDaddy account. Copy the values from your Webflow Site settings before you start, because the TXT value is unique to your site and is shown only there.

To add them in GoDaddy:

1. Sign in to your GoDaddy Domain Portfolio and select the individual domain to reach its Domain Settings page.
2. Select DNS to view your DNS records.
3. Select Add New Record, choose A from the Type menu, enter @ in Name and 198.202.211.1 in Value, leave TTL at its default of 1 hour, and select Save.
4. Add another record, choose CNAME from the Type menu, enter www in Name and cdn.webflow.com in Value, then save.
5. Add a TXT record with _webflow in Name and the verification string from Site settings in Value.

Delete or correct anything in the zone that competes with those records, such as a parked A record on @ or a forwarding rule on www. Domains with Domain Protection ask for identity verification before a change saves, either a 2-step verification code or a one-time password sent to the email address on the account. GoDaddy states that most DNS changes take effect within an hour and can take up to 48 hours to update globally.

If your DNS still shows Webflow’s retired records

Replace them, because a domain still pointing at them will not connect. Three values that older setup guides continue to publish are retired: the A records 75.2.70.75 and 99.83.190.102, and the www CNAME target proxy-ssl.webflow.com. Webflow blocked publishing to that configuration from January 13, 2026 and began shutting the legacy hosting down on June 1, 2026.

To repair an existing zone, select Edit next to the record you are changing, set the A record on @ to 198.202.211.1, and delete the second A record so only one remains on the root. Change the www CNAME value to cdn.webflow.com, and add the _webflow TXT record if it was never created. Sites created before April 21, 2025 are the older-site exception where Webflow may still list two A records; when Site settings shows two, use exactly what it shows.

Register the domain in your Webflow Site settings

Webflow verifies nothing until the same domain exists on its side, so the GoDaddy records alone will not bring a site online.

1. Open your site’s settings and go to the Publishing tab.
2. Under custom domains, add both the root domain and its www version.
3. Set one version as the default domain, and Webflow redirects the other to it.
4. Publish the site so the connected domain starts serving.

Once Webflow reads the expected records, it provisions an SSL certificate automatically and marks the domain as connected. Connecting a custom domain requires a paid Site plan. When verification fails, compare each value in GoDaddy character by character against the values Webflow lists, and check the TXT record separately, since a missing verification record is the most common reason a correct-looking setup stalls.

Nameservers or DNS records: which one to change

Change the records, not the nameservers, unless you are deliberately moving DNS hosting. Nameservers decide which company answers DNS queries for your domain, and the records decide what those answers are.

GoDaddy’s default nameservers put the zone file in your GoDaddy account, which is why a lookup on a GoDaddy domain usually returns hostnames under domaincontrol.com. Pointing the nameservers somewhere else moves the zone: GoDaddy stops serving DNS for the domain, and you recreate the A, CNAME, and TXT records at the new provider. Teams do that on purpose to put a proxy or CNAME flattening in front of the root domain, which is the usual reason to move a zone to Cloudflare DNS hosting.

In GoDaddy the switch sits under DNS and then Nameservers, where the GoDaddy Nameservers option keeps DNS management in your account and the custom nameservers option hands it off. Webflow does not care which company hosts the DNS, only that the published records match the values in Site settings.

Automate records with the GoDaddy Domains API

Agencies and platform teams that connect domains in batches can write the same records over HTTP instead of clicking through the panel for each one.

GoDaddy’s Domains v3 API includes a DNS Records group that lists, creates, replaces, and deletes records in a GoDaddy-managed zone, and GoDaddy documents those record changes as applying synchronously. Requests go to api.godaddy.com under the /v3/ prefix and authenticate with a bearer personal access token. Nameserver updates run through the same API’s domain management endpoints and return an operation you poll until it completes.

Publishing stays a Webflow action, so a full pipeline pairs GoDaddy record creation with the Webflow API. One constraint is easy to miss: API zone edits work only while the domain uses GoDaddy nameservers, because once it points elsewhere the records belong to the other provider’s API.

What you can build with the GoDaddy Webflow integration

A connected domain is the prerequisite for most of what you ship on Webflow hosting, and it decides what the rest of your stack can be pointed at.

With the domain connected, you can run these setups:

• A live site on the domain you already own: Serve a Webflow-built site on the domain your customers already type, while GoDaddy keeps the registration, renewals, and zone file.
• Email and website on separate providers: Leave the MX, SPF, DKIM, and DMARC records in GoDaddy untouched so mailboxes keep working, since Webflow reads only the A, CNAME, and TXT records.
• HTTPS with no certificate to buy: Webflow provisions and renews the SSL certificate once the records verify, so nothing about TLS needs configuring in the GoDaddy account.
• A managed portfolio of client domains: Write the same records across every domain you administer through the Domains v3 API, then publish each site from Webflow.
• Consent and analytics bound to the final hostname: Cookie banners and tag setups register a specific domain, so getting the custom domain live first saves reconfiguring them afterwards.

Do the domain first, then the layers that depend on it. Set up Cookiebot consent for the piece most teams configure right after a domain goes live.