Testing checklist for a Drupal website launch

Testing checklist for a Drupal website

Posted by JD Collier on July 09, 2013

When building a Drupal website, you need to ensure you have thoroughly tested the site before you turn it over to your client. If a client discovers a significant issue, it degrades their trust and can cost sales if the problem is enough to block a website visitor's ability to interact with the site.

At Digett, we thoroughly test every site we build. Over the years, we have built a checklist of items to test on a site before going live. 

I have filtered this list for items we test specifically for Drupal. We have another list of items that are tested even for a one-page static HTML site. 


These first items are just to ensure we've planned for a few items that have caught me off guard before on a Drupal site.

  • Test what happens when you add a level of navigation lower than planned — what if the client wants a page under a page you planned as the deepest you could go? Not that you have to allow for it in the drop down header navigation, but at least there is a plan. 
  • Ensure css takes into account html tags outside initial site content. No tables when launching the site, it doesn't reflect well if a client has to report a problem later when they try to add a simple table of data and the style is completely off because we forgot to plan for it. 
  • 301 redirects are in place to redirect old site paths to new Drupal site paths. We do these in the Redirect module.
  • WYSIWYG on main content pages provides a way for clients to align images left or right and css provides appropriate padding for each.
  • WYSIWYG image and file uploads work as expected and the client has appropriate permissions to upload.

Before launch 

  • Privacy policy link is in place if there are comments on the site (required since we use Mollom).
  • 404 (not found) and 403 (forbidden) display appropriate information and are customized appropriately.
  • Drupal Content Type settings: we turn off preview, we ensure revisions are turned on for all content types and we ensure the correct menu is available. 
  • Ensure Pathauto patterns are set appropriately for each content type. 
  • Xmlsitemap is configured and updating properly when content changes.
  • Meta descriptions/titles are in place and available for home page and views as well as normal content pages. For Drupal, it is important to always check pages created by Views. This is often missed on Drupal sites I've seen.
  • Robots.txt file correctly blocks nodes that should not be indexed (rotators, sidebar block promos, etc). We prefer to do this in the RobotsTxt module.
  • Client has enough permissions but not too much (based on your ongoing support with client). 
  • User passwords are set to strong passwords before launch.
  • If not a community site, ensure only admins can create accounts.
  • Ensure test content has been removed.
  • Ensure Google Analytics is in place and working (use real time function to ensure anonymous users are tracking); block your IP and client (if desired).
  • Disable development and unused modules.
  • Enable appropriate css and js aggregation (do this before testing site). Javascript aggregation can be especially problematic in some cases so ensure you test any pages with custom functionality.
  • Turn on Drupal cache (if not using Varnish).
  • Check error log and resolve issues.
  • We like to set error reporting to NOT show on screen for production sites — just write to log.
  • Ensure site search works as expected and that it is themed properly.

Right after launch

  • Clear all Drupal caches.
  • Run broken link checker to ensure production site has no broken links. We use the Link Checker module to assist with this process.
  • Ensure any staging or dev url paths are set to production (we use Pathologic to help catch these)

What else do you test for Drupal?

There are lots more items on our production testing checklist. The items above are just the main things we check for Drupal sites; SEO, browser testing and lots more are involved in launching any website.

Are there other pieces you test in Drupal when launching a site? Do you have questions about anything I listed? Let me know in the comments below. 

Check List designed by Stephane Thomas from The Noun Project


Get thought-provoking and actionable insights to improve how your firm makes a connection with your customers.


The content of this field is kept private and will not be shown publicly.

Plain text

  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
Submitted by mathieu on Wed, 07/10/2013 - 7:58am

Thanks for your share ! printed it already ... will be very useful :)

Submitted by Amy Peveto on Wed, 07/10/2013 - 8:19am

Glad it came in handy!

Submitted by Craig Hyatt on Thu, 07/11/2013 - 7:34am

Great list! Thanks for blogging it.

>>> Javascript aggregation can be
>>> especially problematic in some
>>> cases so ensure you test any
>>> pages with custom functionality

Would you be willing to elaborate on this? What are some examples of problems you've seen?


Submitted by artis @ d.o on Thu, 07/11/2013 - 8:48am

Good List! One that tripped me up recently and is now on our list... Check that all Webforms and/or Rules-based notifications are in-place and set to go to the client's email address. We set them to our email address during development.

Submitted by Amy Peveto on Thu, 07/11/2013 - 9:14am

Ooh, good one. That's actually already on our list, but JD didn't include it here. We don't use Rules frequently, but when we do it's very easy to forget to adjust email addresses.

Submitted by JD Collier on Thu, 07/11/2013 - 9:15am

@Artis: That one has caught me too!

@Craig Hyatt: I've not taken the time to really dig deep on the issue, but I have several sites where if I turn on js aggregation, various jquery functions break. It isn't every site ... but I do have several that are this way. For this reason, I just check every new site to ensure this won't be a problem.

Submitted by Greg on Thu, 07/11/2013 - 2:30pm

A big one that is often missed is to ensure that all theme images are correctly compressed And that all pngs are compressed with a service like www.tinypng.org because default Drupal only handles jpegs.

Submitted by Ben on Tue, 07/23/2013 - 10:58am

Put credit card processor in production mode.

Submitted by Amy Peveto on Tue, 07/23/2013 - 11:12am

Good one. That's one of those sneaky ones, especially when you don't do commerce sites often.

Submitted by tom on Mon, 08/12/2013 - 3:30pm

@Craig Hyatt - as one recent example, on a site running the Adv Agg module (advanced aggregation and minimization) and the JQ Multi (allows you to run different versions of JQuery b/c this is a D6 site that the client wanted themed using Bootstrap), the Adv Agg module stops JQMulti from doing it's magic (the libraries don't get included at all), so anything depending on it dies. It works fine with no aggregation or the in-built aggregation.

We also found that Adv Agg killed the Rubik admin theme functionality. So though you get some nice features with Adv Agg over standard aggregation, it wasn't enough to warrant the hassles.

Submitted by Micah on Wed, 02/05/2014 - 9:11am

Clearing caches often sets off new changes, so after "Right after Launch: clear cache" I would recommend that people do a final QA walkthrough to catch new/different/broken functionality.

I also like to clear the drupal logs after clearing the cache and before QA so that I have a clear(er) record of anything that went wrong.