Site Launch Checklists & Info

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:
  1. Add the domain(s) to Nesthub under Domains --> DNS by putting the non-www version of the domain in
  2. 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.
  3. 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.
  4. Look them up on MXToolbox to ensure nothing is being missed and check where their nameservers are currently
  5. Go back to the registrar and update the nameservers
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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

TXT/SPF Record

Common CNAME Records

Microsoft Outlook/GoDaddy Email

MX Records

TXT Records

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

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