Create a Github copy of the code if it doesn't already exist. Start your first commit with everything exactly the way it is before you start. If the project already has git, do perserve the git history.
Name and Date the backup. Do this before you change anything. Just in case.
The QA Plan should include the highest traffic pages and at least one or two pages of the admin UI including saving a node.
Run a speed test with Pingdom 5 times from the same data center. Throw away the first result and average the remaining 4. http://tools.pingdom.com/fpt/
Run through the QA Plan from the previous step and note anything that looks obviously broken before you start.
All Site Audit work should be done on a local copy of the website so that you can edit the local site and test freely without changing production. Setting up the site locally may take time. Do include building the CSS from Sass.
When you build a theme from SASS, be careful to see if there are any edits to the CSS that aren't in SASS.
This provides a generally useful broad overview that you will use later to see which content types and taxonomies are unused.
Free certs from either Lets encrypt or Cloudflare.
Deleting modules requires a seperate uninstall step BEFORE you remove the code from the website. You cannot uninstall a module after you delete it.
You may have to search the database for <? and move any code found to a custom module or theme hook.
Check the last time it was run. If it's been more than a year, rerun the QA plan after you finish this step.
This double checks that all the contributed modules and core match what comes from Drupal.org. If there are any patches, you may need to make .patch files for them.
Make sure the user/1 email is set to the correct person. Reset it to yourself if needed.
Check permissions screen for any hidden admin roles
A hacked website may have had new roles added to it.
It's common for previous employees to still have active accounts. Go ahead and deactivate anyone who hasn't logged in for more than a year. They can be turned back on later.
Remember that PHPCS can often fix many easy problems for you. Full details are here: https://www.drupal.org/node/1587138
Put custom modules into a /custom folder. Consider moving features into /features so that generated code isn't mixed in with custom code. This makes custom code much easier to search through and learn when you use many small features.
Make sure all modules and custom functions are name spaced with the project name
It's probably best to just check everything here. You can't be sure what's been configured and what hasn't. So, put everything in features and then regenerate the feature and remove anything like last updated date that changes on each feature update.
Check the page cache and aggregate CSS/JS. For Pantheon, Do not check the gzip option. Set the minimum time out to 0 and the maximum to at least 15 or 30 minutes.
Make sure all the home page images are the correct file type, compression, and sizes needed for the home page. Consider removing any image styles for Hero images and upload the correct size hero images to avoid having them double compressed by Drupal.
CSS should be in the header. JavaScript should be async or just above the closing body tag.
I like Cloudflare, but Max CDN, and Fastly are good too. A CDN will geo-locate the static content close to the end user. This should not be considered optional.
Block caching is key for logged in performance. If a module has disabled it, consider removing that module.
This is Pantheon specific. It's nice to have, but important for logged in site performance.
Use Views Content Cache to cache the views query and html for 6 days. Expire it based on the type of content in the view. For block views, set the block cache to the type that makes sense for the view (global, per page, per role, etc.)
Drupal 404 pages are super, super slow. So, use Fast 404.
The home page should have a good title. Titles should be unique, they should describe the content of the page. They, ideally should contain an actual keyword phrase that people do type into Google.
Redirect makes sure /node/1 redirects to the human friendly URL. Metatag gives pages metadescriptions. The Metadescription should describe the content of the page and it should contain search keyword phrases. They should always be unique.
Search API Facets are a common culprit of bad No Follow. No Follow is bad. It costs the site link juice and should never be used on internal links. It should almost never be used on links at all. If the site contains any untrusted, spam, external links, those links should be deleted. No Follow doesn't fix bad content.
No one likes broken links. Use the Drupal broken_link module to fix them.
We don't have a standard tool for this yet. There are several popular web-based ones.
Primarily, you want to ensure that images have alt tags, that H tags are used correctly and that there is good color contrast on all key pages.
Drop down mega menus are bad for new visitors. Consider simplifying them by removing the drop down.
Slideshows a poor user experience. Instead, pick a good hero and stick with it. No one sees any of the other slides anyway.
Anything with zero terms can be deleted. You can readd it later if needed. Also consider disabling any free tagging widgets.
If a content type has zero pages, delete it. You can put it in a feature, commit it, push it, then delete it and remove the feature if you want to save a copy of it just in case.
No sense in having unused content sitting around published.
Sort the content oldest first and see if there's any test or development only content still hanging around published.