Site Launch Checklists & Info
This is your how-to and checklists for launching sites.
If you are unfamilar with any of the items on this list, DO NOT ATTEMPT.
You risk taking down our clients email and website which can cause issues that potentially cannot be undone. If you have any questions, please ask.
Launch Checklist
DNS Glossary
Subdomains
Launching W/O Updating Nameservers
Site Launch Checklist
- Make sure all landing pages are added
- Start by setting up 5 landing pages (if the client services less than 5 cities, just set up with the cities provided). We give clients up to 10 landing pages for free, but typically only launch with 5 to start. We let clients know it's best to start with 5 and add the remainder over time as it's best for their SEO.
- If a client already has a site with us, we need to build out all landing pages that they had on their previous site. If they do not service one of those areas anymore, delete the page and make sure to redirect it back to the main PM page. The 10 landing page limit does not apply in this case if they had the pages previously.
- Make sure all advanced features are added. You must send out email from donotreply@kohva.com account in regards to their Advanced Features or package.
- Make sure open graph is added and working properly here: https://www.opengraph.xyz/
- Add redirects
- Add main contact as a user to Nesthub
- Make sure to add the username/email & password to Monday for client's Nesthub access
- Check to make sure domain is properly set in Monday for when auto email gets sent out -- No “/” at the end of the domain, otherwise the link getting sent out to the client to log into their backend will be wrong.
- Get domain logins, or delegate access if you do not have it already
- Once logged into their Domain Registrar:
- Add the domain(s) to Nesthub under Domains --> DNS by putting the non-www version of the domain in
- Ensure the www domain is set as the primary domain for whichever domain they want the site to live on under Domains --> Site Domains
- If they want to use multiple domains, we either need to forward them within the domain registar, or in most cases, pull them into Nesthub and under Domains --> Site Domains, you will need to edit and set the redirect type appropriately to ensure ALL DOMAINS forward to the www version of their primary domain.
- Copy over all the DNS records into Nesthub. Also put a copy in their Nesthub notes just in case we need to refer back to them
- Always leave the default CNAME www record that is generated in Nesthub when you add the domain to DNS. If there is another one in the records you are pulling over, don't pull that over into our system, but keep a note of it with the others in the nesthub notes.
- Look them up on MXToolbox to ensure nothing is being missed and check where their nameservers are currently
- Go back to the registrar and update the nameservers
- Once MXToolbox shows our nameservers under "DNS Check", you can go back into Nesthub and apply for the SSL using the www and non-www domains (and any other domains you needed to pull in). DO NOT apply for SSL until you see the nameservers change in MXToolbox.
- Change Monday status to SSL to trigger the “Your Site Is Almost Ready” email to the client so they know the website will show not secured for a few hours until SSL is deployed
- Keep an eye on the SSL. If after 15 minutes you don't see it switch over to "Created" something is wrong. Please let Mikayla know.
- Once the SSL shows "Deployed" go into the domains you applied for it for and check "Enable https". DO NOT do this before the domain is deployed.
- Once SSL is applied in Nesthub, set the Launch status in Monday to “Done”.
- Change ownership in Pastel to the support team – mitch@kohva.com
- If you are changing url on launch, make a note for Reporting to add a Search Console property for both domains, old & new
- If you are migrating a site, please make sure that old pages are either updated to the proper template, or make sure that you delete them and redirect them accordingly
- If it was a pleasant experience with the client, upload their contact info into Grade.us to trigger drip campaigns for PMW reviews
CHECKLIST WHEN MIGRATING A SITE FOR LAUNCH
- Create a backup of the old website
- Ensure the emails on the forms of the old site match the ones on the new site unless specified otherwise by the client
- Ensure you have redirects done. If there are old pages we are not keeping, they need to be redirected and deleted to not clutter the site.
- Start by deleting all old templates
- Then delete old snippets
- Now you can delete old pages
- Ensure you have copied over items that you set up this new site and transfer them over to the old site (which will now become the new live site). This includes:
- AMP
- Blogs, authors, blog posts
- Forms
- Any property plugins, pages, or widgets that were set up
- Users
- Copy over all tracking information from the old site to the new site.
DNS
Glossary of Terms
- Nameserver: A nameserver is a server on the Internet that answers DNS queries. A nameserver may be authoritative (providing answers) or recursive (asked questions on behalf of a third-party). A domain may be delegated to authoritative
DNS servers that are subordinates to that domain. Nesthub nameservers are the following
- ns1.nesthubdns.com
- ns2.nesthubdns.com
- ns3.nesthubdns.com
- ns4.nesthubdns.com
- Canonical Name (CNAME): A resource record in the DNS that specifies a domain name is an alias for another domain name and not for an IP address. For instance, [blog.cira.ca CNAME dog. cira.ca]. It allows the running of multiple services (i.e. web server and FTP server) on different ports but sharing the same IP address.
- A Record: A resource record in the DNS that specifies a domain name is an alias for an IP address.
- MX Record (Mail Exchange): Resource record(s) used to connect the domain to a specific email provider (Google, Outlook, Godaddy, etc.)
- TXT Record: The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some
machine-readable data into TXT records. One domain can have many TXT records. Common types of TXT records are as follows:
- SPF records: SPF TXT records list all the servers that are authorized to send email messages from a domain.
- DKIM records: DKIM works by digitally signing each email using a public-private key pair. This helps verify that the email is actually from the domain it claims to be from. The public key is hosted in a TXT record associated with the domain. (Learn more about public key encryption.)
- DMARC records: A DMARC TXT record references the domain's SPF and DKIM policies. It should be stored under the title _dmarc.example.com. with 'example.com' replaced with the actual domain name. The 'value' of the record is the domain's DMARC policy (a guide to creating one can be found here).
- Hostname: Also known as the subdomain of the DNS record. Example www. is used as a host record on most websites.
If a new client DNS records should be provided by their old provider, if email is set up after the site is launched the client will need to provide all the DNS records (MX, CNAME, and TXT/SPF) from their email provider.
Example of Records
Please note these are examples and they should not be used directly on the site, but used as a guide
Google Apps for Business
MX Records
Name/Host/Alias | Time to Live (TTL*) | Record Type | Priority | Value/Answer/Destination |
---|---|---|---|---|
Blank or @ | 3600 | MX | 1 | ASPMX.L.GOOGLE.COM |
Blank or @ | 3600 | MX | 5 | ALT1.ASPMX.L.GOOGLE.COM |
Blank or @ | 3600 | MX | 5 | ALT2.ASPMX.L.GOOGLE.COM |
Blank or @ | 3600 | MX | 10 | ALT3.ASPMX.L.GOOGLE.COM |
Blank or @ | 3600 | MX | 10 | ALT4.ASPMX.L.GOOGLE.COM |
TXT/SPF Record
Name/Host/Alias | Time to Live (TTL*) | Record Type | Priority | Value/Answer/Destination |
---|---|---|---|---|
Blank or @ | 3600 | TXT | 0 | v=spf1 include:_spf.google.com ~all |
Common CNAME Records
Name/Host/Alias | Time to Live (TTL*) | Record Type | Priority | Value/Answer/Destination |
---|---|---|---|---|
calendar | 3600 | CNAME | 0 | ghs.googlehosted.com. |
drive | 3600 | CNAME | 0 | ghs.googlehosted.com. |
3600 | CNAME | 0 | ghs.googlehosted.com. |
Microsoft Outlook/GoDaddy Email
MX Records
Name/Host/Alias | Time to Live (TTL*) | Record Type | Priority | Value/Answer/Destination |
---|---|---|---|---|
Blank or @ | 3600 | MX | 0 | domainname-com.mail.protection.outlook.com |
TXT Records
Name/Host/Alias | Time to Live (TTL*) | Record Type | Priority | Value/Answer/Destination |
---|---|---|---|---|
Blank or @ | 3600 | TXT | 0 | MS=ms######## (unique ID from the admin center) |
Blank or @ | 3600 | TXT | 0 | v=spf1 include:spf.protection.outlook.com -all |
SRV Records
Some hosting providers impose restrictions on field values within SRV records. Here are some common workarounds for these restrictions.
Name
If your hosting provider doesn't allow setting this field to @, leave it blank. Use this approach only when your hosting provider has separate fields for the Service and Protocol values. Otherwise, see the Service and Protocol notes below.
Service and Protocol
If your hosting provider doesn't provide these fields for SRV records, you must specify the Service and Protocol values in the record's Name field. (Note: Depending on your hosting provider, the Name field might be called something else, like: Host, Hostname, or Subdomain.) To add these values, you create a single string, separating the values with a dot.
Example: _sip._tls
Priority, Weight, and Port
If your hosting provider doesn't provide these fields for SRV records, you must specify them in the record's Target field. (Note: Depending on your hosting provider, the Target field might be called something else, like: Content, IP Address, or Target Host.)
To add these values, create a single string, separating the values with spaces and sometimes ending with a dot (check with your provider if you are unsure). The values must be included in this order: Priority, Weight, Port, Target.
- Example:
100 1 443 sipdir.online.lync.com
Subdomains
Launching a site on a subdomain that has a domain that IS hosted with us:
- On the main site, add a DNS record as follows:
- Record Type: CNAME
- Host: whatever you need the subdomain to be. Example: if you want it to be ads.customersite.com then add "ads" to that field
- Value: @
- On the site that will be living on the subdomain:
- Go to Domains --> Site Domains --> Add Site Domain
- Add your full subdomain -- Ex. ads.customersite.com and set as primary domain
- Create an SSL certificate for just the subdomain: ads.customersite.com. Once SSL is deployed, mark as https
Launching a site on a subdomain that has a domain that ISN'T hosted with us:
- Log into the domain registrar and point subdomain CNAME record to our load balancer: slb1.nesthubdns.com
- Go into the backend of the site in Nesthub and add a site domain using the full subdomain
- ex. ads.mywebsite.com
- Add the full subdomain to apply for the SSL
Launch a Site Without Changing the Client's Nameservers
WARNING: THIS IS NOT RECOMMENDED AND WE DO NOT WANT TO PROMOTE THIS TO CLIENTS. THIS IS A VERY RARE OCCURANCE AND SHOULD ONLY BE DONE IF YOU AND THE CLIENT UNDERSTAND THE RISKS OF THIS. If the IP address of the server were to change, the client's site would go down.
- Start by adding the client's domains just like you normally would into Nesthub and setting the primary domain to the www version.
- Domains --> DNS --> Add Domain
- Go to Domains --> Site Domains --> Set the www version as the primary domain
- No DNS records will need to be copied over because we are not updating the nameservers.
- Within the client's registrar, you or the client will need to point the www CNAME to our Load Balancer.
- Record Type: CNAME
- Host: www
- Value: slb1.nesthubdns.com
- Ensure the non-www version of the domain is forwarding into the www version within the registrar as we will be unable to do that in Nesthub on our end as we don't manage the non-www version of the domain.
- Once this is done, you will be able to apply for the SSL
- Create an SSL certificate for just the subdomain: www.customersite.com. IT WILL NOT WORK FOR THE NON-WWW VERSION.
- Once SSL is deployed, mark as https