Read more of the post "The ultimate checklist for pushing a WordPress site live (2020)"
When launching a website, you can often forget a number of things in your eagerness to make it live, so it’s useful to have a checklist to look through as you make your final touches and before you announce your website to the world.
This article reviews some important and necessary checks that Drupal websites should be checked against before the official launch — little details are often forgotten or ignored, but – if done in time – may sum up to an overall greater user experience and avoid unnecessary costs after the official site release.
Those checks assume you have a local, development and live environment.
We use a very handy module to install and make sure the favicon is perfect in all tablet, phones and desktops: The Real Favicon Generator module.
You don’t want to go live without an up-to-date codebase. This applies to any CMS, not just Drupal.
We have a subscription with BrowserStack which allow us to check how your website looks on the major browsers and viewports.
Do you need an editor role for the client? Check that permission are correct. Masquerade as the client and try adding/removing content. Make sure the client has enough privileges to update the site!
Does it work? Is it themed properly? If you don’t use a search on the site, make sure it’s disabled.
If you publish information or advice on your site (blog) then you need a Website Disclaimer. Grab one from Disclaimer Generator.
If you sell goods or services, then you need Terms and Conditions.
Make sure they match the old URLs and when not possible, use meaningful patterns for each content type.
Go to the report page and make sure it’s all smooth there.
You want to make sure there is a meaningful 404 page, ideally performing a search on the site with the terms in the URL. Search 404 is the perfect module for it.
Revision can be a lifesaver to go back to an earlier version of a page. Make sure all content types have revision turned on by default.
Clean up after yourself. Have a look at the module list – is there anything that can be removed?
If your content type node is not a page, but is used to create a view, a report or simply should not be seen through the node URL, then block it in your robots.txt file or use the Rabbit Hole Module
Make sure all settings are packaged up and ready to be moved into code and then pushed to the dev and live environment.
Make sure your titles and meta-data are optimised for SEO. In both Drupal 8 and Drupal 7 the Metatag module is a great way to select your patterns and automate your titles, but also make sure your content is shareable on Social Media. You want to make sure there is a meaningful description and ideally image when you share any page of your website – not only the homepage!
We usually don’t need to worry about it as we use Pantheon as hosting platform, but in any other case, make sure your settings.php is read-only!
Make a list of all URLs from the old website. Where possible, match Pathauto patterns with the old paths, keeping them the same. Where not possible, create 301 redirects either through the .htaccess file, or with Redirect module.
Chances are, few of your links won’t work. Run the site through the W3C Link Checker and make sure it’s all looking smooth.
The website should have a sitemap generated and you should tell Google Console about it. Here you can see if any content is blocked by robots and if you have any other issues on your website. For Drupal, it is important to always check pages created by Views. This is often missed on Drupal sites I’ve seen.
Make sure all your test content, views, contexts, users are removed from the site. Do you have installed any modules that you are not using? Disable it and remove it. What about site information? Do we have the right site name, email etc? Clean up after yourself!
Have you tested all web forms? Is the email being sent and received? Clean up any test submissions and make sure the success message is correct. Also, make sure validation works in every field.
Now that your site is live, if you use Pantheon is a good practice to password protect your test and dev environment. This will make sure the client doesn’t keep updating the wrong environment. (Yes, it happens.)
Use the core functionality on admin/config/development/performance
Devel, Devel generate, or any other UI modules should be disabled on live
Do you have any third party that need API key and domain authorisation updated? (Eg. Lockr, Google Captcha, Google Map etc) Usually they have different values for dev, test and live. Make sure it’s all good.
Only admin can create accounts unless it’s a site where registrations are part of the functionality.
And make sure errors aren’t shown for production sites – just write to the log.
Have been scheduled? We use Pantheon for most of our projects, and their backup schedule it’s just fantastic.