Connecting a domain to a website

What is actually happening

Your domain has a set of records that say where things live. One says which server answers for the website, another says where email goes, and others handle verification and services.

Connecting a site means changing the website record so it points at the new host. Nothing about the domain itself changes, and nothing else in the record set should be touched.

That last point is the one that causes trouble. Changing more than the website record is how a site connection accidentally takes email offline for a day.

The records also carry things you did not set up. Verification entries for services, mail security settings and anything a previous provider added. Leave all of them alone unless you know exactly what they do.

Two ways to do it

The first is changing individual records at your current provider, usually an address record and a subdomain alias. This leaves everything else exactly where it is and is the safer option.

The second is handing the whole record set to your host by changing nameservers. That is simpler and it moves every record, including the ones controlling email.

If anything else uses your domain, prefer the first. Nameserver changes are convenient and they are where the email failures come from.

Order of operations

Build and check the site first, at whatever temporary address the host provides. Then connect the domain. Connecting first and building afterward means the public sees an unfinished site.

Write down the current records before changing anything. A photograph of the existing settings is enough, and it is what lets you put things back if something breaks.

Then change only what needs changing, and wait. Our page on the launch checklist covers the surrounding steps and what to test afterward.

What to check before you change anything

The list below is the preparation that prevents the two bad outcomes: a site that is down and an email system that stopped without anybody noticing for a day.

• A record of every existing record, saved somewhere
• Whether email uses this domain, and which records serve it
• The exact values your new host requires
• The new site already built and working
• A secure certificate that will cover the custom address
• A time of day and week that is not Friday afternoon
• Somebody available to check afterward

Waiting for it to spread

Changes do not apply everywhere at once. Different networks hold the old answer for different lengths of time, which is why the site can work for you and not for a customer an hour later.

Most changes settle within a few hours and some take a day. Checking from a phone on a mobile connection is a useful second opinion, because it uses a different path from your office.

Do not change things again while waiting, and expect a search engine or an answer engine to take longer than your own browser to notice. Most emergency second changes are made during the normal settling period and they make diagnosis considerably harder.

Certificates and the secure address

A secure certificate has to cover your custom address, not only the host's default one. Most hosts issue it automatically once the domain points at them, and it can take a short while.

Until it issues, browsers may show a warning. That is expected during the first hour and a problem if it persists, and the usual cause is a record that is not quite right.

Our page on secure connections covers what the certificate does. Check both the address with and without the leading subdomain once it has issued.

Afterward

Test the site on the real address, from a device that has never visited it. Then test every form, because form delivery frequently depends on the domain and is the thing most often broken by a move.

Check email still works, both sending and receiving, from an outside account. Email problems are silent and they are the expensive failure in this whole process.

Then update anything pointing at a temporary address, including profiles, listings and printed material waiting to go out.

Check the site from a device that has never visited it before. Your own browser holds a cached answer, which is why a site can look connected to you and broken to the first real customer.