How to Launch a Webflow Site Without Breaking Everything

ook at you go. You’ve built a whole website in Webflow and now you need to launch that sucker. Though Webflow makes it super easy to launch a website on their platform, there are still a bunch of things that you’ll want to be aware of when you’re getting ready to launch a new site, especially if you are working with a client’s domain. You don’t want to accidentally break their email and not have a backup plan to restore it, which can totally happen if you’re not careful. We’ll cover how to launch a website in Webflow without breaking everything and looking like an idiot. This post will be geared toward launching client websites.

DNS/Registrar Nonsense

To start with launching a site, you’ll need the client’s registrar logins. Common registrars include:

1. Godaddy
2. Google Domains
3. Namecheap
4. Bluehost

Some registrars will also allow you to “delegate access” to the account which would essentially allow you to manage their account from your own account. GoDaddy created a simple guide that you can share with a client to walk them through delegating account access to your own GoDaddy account. 

If the client doesn’t know where their domain is registered, use who.is to find out. Simply run a search of the domain and who.is will tell you where the domain was purchased. 

Once you have the logins to the client’s domain registrar, we need to modify their DNS. Here’s a helpful article on what even is DNS. To launch the site on the client domain, follow the steps in this video.

Avoiding Email Quagmires

Sometimes, if the client has an existing site, you won’t be able to edit the DNS in order to launch the site. In this case, you’ll need to migrate the domain back to the original reigstrar. The big thing here is the client email will go down when you do this, but this is only a problem if the client email is tied to the domain (their email address is name@clientdomainname.com) This will NOT be an issue if the client is using a generic email (clientemail@gmail.com or @yahoo, @aol etc). 

If the client email is tied to their domain, you’ll want to check what type of email service they’re using. 

• Go to https://securitytrails.com/dns-trails and plug in their domain
• Click on historical data
• Click on MX records
• Copy down their most recent MX records (“Last Seen” will ben within the last 24 hours)
• Check the MX record priority on https://dnschecker.org/ and make sure you add in the MX records in the order listed on DNS Checker.
  

Once you’ve migrated the domain back to the original registrar by resetting the nameservers back to default, you’ll need to plug in those MX records you copied down back into the DNS in order to make the email active again. Luckily, most email services have standard MX records, so you can just bookmark these and have them handy:

• Gmail MX records
• Microsoft Outlook MX records (Office 365)
• Rackspace MX records
• Protonmail MX records

You can also do a quick google search of “{Client Email Service} MX records” and they’ll likely come up. Once you’ve got the MX records in, do a quick test to make sure it’s up and running. Plug their email into this tool: https://hunter.io/email-verifier If you get an error code, there’s trouble in Chinatown. Double check your work and make sure you’ve plugged everything in correctly.

The Parachute

Let’s say you’ve reset the nameservers, tried to plug back everything on the original registrar, but everything is still broken and you’re sad. Don’t worry. The easiest way to fix the problem is to simply change the nameservers back to the custom servers you reset from. Go back to Security Trails and run another DNS historical record search on the domain. Get the nameservers and plug them back in. The old site will go back up as well as the client email. This should buy you some more time to figure out what needs to be done, and the client won’t be super pissed they can’t send any emails.

Tips and Tricks:

• Use https://dnschecker.org/ to see if a recently launched site is propagating. Plug in the non www domain and check the A record. Plug in the www version and check the CNAME. If Webflow’s records come up, it’s set up correctly and is just propagating. If you get records that are not Webflow, action is needed.
• Try and launch a website during off hours like nights or weekends, that way if things break the client won’t miss out on peak traffic and emails. 

Those are some of the most common issues that can occur when launching a new website. Hopefully this guide will help you work through the enigma that is DNS and email crap. If this all sounds too spooky and you’d rather not deal with it, we can do it for you. Give us a ring why dontcha.