It’s the big day! The development is done, the content is in, and your pre-launch requirements are all met. It’s time for a smooth and painless launch.

Day-of Launch Checklist

Launching WordPress sites is a fairly painless process when the right precautions are taken.

Something Old, Something New

  • Migrate the database — WordPress databases will often have arrays of data stored as serialized strings. If you’re migrating “dev.example.com” to “example.com” by running a find and replace on the database, any serialized values that include the old domain will break. This usually results in broken slideshows and empty widgets. To avoid this, we use the excellent WP Migrate DB plugin, which handles the details of re-serializing automatically.
  • Migrate the files – Easy peasy. If you’ve been working along and you’ve soft-launched onto the production server, you’re already there. If you’ve yet to move your files to the production server, and you’re using (S)FTP, do yourself a favor and zip everything first. The file transfer will be much quicker this way. You can unpackage the files on the server with SSH or the panel management software.
  • Throw the lever – We like to get as close to zero-downtime as we can for site launches. The process involved varies tremendously depending on what kind of hosting plan the client has. In many cases, A-record changes in the DNS are the most painless way to point a domain to a completely different server. As an added bonus, there’s very little waiting compared to changing nameservers, and other domain services keep working (email, validation, and other custom records). In a shared hosting setup, we stick to some old-fashioned techniques. With the new database ready and the files uploaded into a “new” folder, we stuff the old site into an “old” folder and move the new files out. It may sound like a rough process, but it takes less than a minute and the new site should start working instantly.
  • Backup the old site – Often, clients will come to us with hosting already arranged. If you’re replacing an existing content-managed site in an environment like this, you’ll want to back it up  and remove it from the server once the new site is live. Having out-of-date software on the server, even if it’s hiding in an “old” folder, is never a good idea.

Congratulations! You’ve launched a brand new website. Before you call it a day and kick back with your hard earned money-bags, you’ll want to take care of some loose ends.

Post-Launch Checklist

Links

  • That Old Link – With your browser’s web inspector, make sure that your new site isn’t referencing any assets from the testbed. Though you’re a mindful developer, and you try to always use relative links, it can be easy to forget a hard-coded link or AJAX call in one of your templates.
  • Those Old Assets – Make sure that if you’re removing old image and file libraries, external sites aren’t depending on them. Google+, for example, relies on live image assets for its postings. Either leave these files in your directory structure or 301 redirect everything to their new equivalents.

Integrations

  • Analytics and conversion tracking – If your client had existing analytics packages, they likely want them running on the new site. Do your duty as a developer to try to curb overuse of on-page Javascript packages (for both speed and privacy), but do be mindful of your client’s needs.
  • Verification and Google’s Search Console – Any social verification meta-tags or HTML pages should also be brought over. If your client wants you to manage their Google Search Console entry, run through the steps to verify their domain.
  • XML Sitemap and submission – We use the Google XML Sitemaps plugin to generate and configure this bit of functionality. It allows us to adjust page priorities and update frequencies very easily by post type, manage exclusions, and submit to the major search engines all from one place.

Technical

  • Email testing – Make sure that emails are being sent from appropriate forms and notification systems. Different servers and hosts have drastically different email policies. It may be necessary to route your client’s website emails through SMTP.
  • Security – If you’re not relying too heavily on plugins and you’re keeping to best practices, it’s probably best to have your site automatically upgrade plugins and major WordPress versions. This will make your site much more secure in the long-run. Installing a security or file-monitoring plugin can help mitigate any attacks as well.
  • Uptime Monitoring – We like Uptime Robot for easy and responsive site monitoring. Knowing a site is down even before your client does can be a very powerful tool in instilling confidence among your clients and preventing disasters.

Hey, I think we’re done! I hope you find these lists useful and we wish you the best in all your web launching endeavors.

Leave a Reply

Your email address will not be published. Required fields are marked *