WordPress Website Audit Checklist

WordPress powers a massive share of the web, but its flexibility is also its weakness. Themes, plugins, and configuration options create countless opportunities for things to go wrong in ways that are invisible to site owners but perfectly visible to search engines and attackers. This checklist covers the WordPress-specific audit items that a generic website audit does not address.

You do not need expensive tools for most of these checks. WordPress admin access, a browser, and a few free online tools cover the majority. Work through each section systematically and document your findings. The goal is a clear picture of your WordPress installation's health and a prioritised list of fixes.

Core and Updates

WordPress core updates include security patches, bug fixes, and new features. Running outdated versions exposes your site to known vulnerabilities.

• WordPress version is current. Check Dashboard > Updates. Your WordPress installation should be running the latest stable release. Minor security releases (6.4.1 to 6.4.2) should be applied immediately. Major version updates (6.4 to 6.5) should be applied within a week of release after checking plugin compatibility.
• Automatic updates are enabled for minor releases. Navigate to wp-config.php and verify that automatic background updates are not disabled. WordPress enables minor version auto-updates by default, but plugins or hosting configurations can override this. The constant WP_AUTO_UPDATE_CORE should be set to true or minor.
• PHP version is current. Check your hosting control panel or use a PHP info page to verify your PHP version. WordPress requires PHP 7.4 minimum but recommends PHP 8.2 or higher. Older PHP versions are slower, lack security support, and may be incompatible with current plugins.
• MySQL/MariaDB version is adequate. WordPress requires MySQL 5.7 or MariaDB 10.4 minimum. Older database server versions lack performance optimisations and security patches. Check via your hosting panel or phpMyAdmin.
• Debug mode is disabled in production. Check wp-config.php for WP_DEBUG. This must be set to false on your live site. Debug mode displays error messages to visitors, exposing server paths and internal information that attackers can exploit.
• File editing is disabled. The DISALLOW_FILE_EDIT constant in wp-config.php should be set to true. This prevents anyone with admin access from editing theme and plugin files directly through the WordPress dashboard, reducing the damage potential if an admin account is compromised.

Plugins

Plugins are the most common source of security vulnerabilities, performance problems, and SEO issues on WordPress sites.

• All plugins are updated. Check Dashboard > Updates for plugin updates. Update all plugins, testing your site after each update (or in a staging environment first). Outdated plugins with known vulnerabilities are the primary attack vector for WordPress sites.
• No abandoned plugins. Check the WordPress.org plugin page for each installed plugin. If a plugin has not been updated in over two years, it may be incompatible with current WordPress versions and is unlikely to receive security patches. Find actively maintained alternatives.
• No redundant plugins. Review your plugin list for overlapping functionality. Common redundancies include multiple caching plugins, multiple SEO plugins, multiple security plugins, and image optimisation plugins that duplicate functionality in your CDN or hosting. Each redundant plugin adds code execution time and potential conflicts.
• Deactivated plugins are deleted. Deactivated plugins still exist on your server and can contain exploitable vulnerabilities. If you are not using a plugin, delete it entirely rather than leaving it deactivated.
• Only one SEO plugin is active. Running Yoast SEO alongside Rank Math, All in One SEO, or any other SEO plugin creates conflicting meta tags, duplicate sitemaps, and contradictory robot directives. Choose one SEO plugin and remove the others completely.
• Plugin source verification. Every installed plugin should come from the official WordPress.org repository, a reputable commercial vendor, or a known developer. Plugins from unknown sources, nulled premium plugins, and plugins distributed through forums or file sharing sites frequently contain malware.
• Performance impact assessment. Install the Query Monitor plugin temporarily to identify which plugins add the most database queries and load time. Focus on plugins that add significant overhead to every page load, even pages where their functionality is not needed.

Theme

Your theme controls the HTML output, visual presentation, and a significant portion of front-end performance.

• Theme is updated. Check for available theme updates. Outdated themes can contain security vulnerabilities and compatibility issues with current WordPress versions.
• Child theme is used for customisations. If you have modified any theme files, check whether changes were made in a child theme or directly in the parent theme. Direct parent theme modifications are overwritten during updates. If customisations exist in the parent theme, migrate them to a child theme before the next update.
• Clean heading hierarchy. Use a browser extension or online tool to check the heading structure of your key page templates. There should be exactly one H1 per page, followed by a logical H2-H6 hierarchy. Some themes, particularly those with widget areas and complex footers, output additional H1 or H2 tags in sidebars or footers.
• Minimal DOM depth. Inspect the HTML output of your pages. Page builder themes (Elementor, Divi, WPBakery) often generate excessive wrapper divs, resulting in DOM trees with 1,500+ nodes. High DOM complexity slows rendering and JavaScript execution. If your DOM node count exceeds 1,500, investigate whether the theme or page builder is generating unnecessary markup.
• Responsive design verification. Test your site on actual mobile devices, not just browser dev tools. Check for horizontal scrolling, text that requires zooming, touch targets that are too small, and images that overflow their containers. Browser emulation does not always reproduce real device behaviour accurately.
• No hardcoded SEO elements. Check whether the theme hardcodes meta tags, canonical URLs, or structured data that conflict with your SEO plugin output. Common offenders include themes that add their own Open Graph tags alongside Yoast's, or themes that output Article schema that duplicates the SEO plugin's schema.
• Font loading efficiency. Check how your theme loads web fonts. Fonts should use font-display: swap to prevent invisible text during loading. Self-hosted fonts are faster than Google Fonts requests. Check that you are only loading the font weights and character sets actually used in your design.

Database

WordPress databases accumulate bloat over time that directly affects page generation speed.

• Post revisions are limited. WordPress stores every saved version of every post by default, with no limit. A post edited 100 times has 100 revisions stored in the database. Add define('WP_POST_REVISIONS', 5); to wp-config.php to limit stored revisions to the most recent five.
• Expired transients are cleaned. WordPress uses transients (temporary cached data) that should be deleted when they expire, but expired transients sometimes persist. Use WP-CLI (wp transient delete --expired) or a database optimisation plugin to clean expired transients regularly.
• Spam and trashed comments are purged. Navigate to Comments and delete all spam and trashed comments. Large comment spam tables slow database queries even though the comments are not displayed. Set up regular automated cleanup.
• Orphaned post meta is cleaned. When posts are deleted, their associated metadata sometimes remains in the wp_postmeta table. Over time, this orphaned data accumulates. Use a database cleanup tool to identify and remove metadata that no longer corresponds to existing posts.
• Database tables are optimised. WordPress database tables fragment over time as data is added, modified, and deleted. Run OPTIMIZE TABLE on all WordPress tables periodically (monthly is sufficient for most sites). Most database management plugins include a one-click optimisation feature.
• Unused plugin tables are removed. When you delete a plugin, WordPress removes the plugin files but does not delete the database tables the plugin created. Over time, deactivated and deleted plugins leave behind dozens of unused tables. Identify and remove these using phpMyAdmin or a cleanup plugin. Back up your database before deleting any tables.
• Autoloaded options are reasonable. The wp_options table includes an autoload flag. Data marked as autoload is loaded into memory on every single page request. Check the total size of autoloaded options using a query: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'. If this exceeds 1MB, investigate which options are contributing and whether any can be set to not autoload.

Security

• Login URL is protected. The default wp-login.php URL is targeted by automated brute force attacks. Implement at least one protective measure: a login limiting plugin (Limit Login Attempts Reloaded), server-level password protection on wp-admin, or a URL change plugin. Two-factor authentication provides the strongest protection.
• Admin username is not "admin". The default "admin" username is the first one automated attack tools try. If your administrator account uses "admin", create a new admin account with a different username, transfer content ownership, and delete the original account.
• File permissions are correct. Verify directory permissions are set to 755 and file permissions to 644. wp-config.php should be 400 or 440. Permissions of 777 on any file or directory are a critical security risk that must be fixed immediately.
• wp-config.php is protected. Verify that wp-config.php is not accessible via a browser by navigating to yourdomain.com/wp-config.php. The server should return a 403 Forbidden or redirect, not display or download the file. Some hosting configurations also support moving wp-config.php one directory above the WordPress root.
• XML-RPC is disabled if not needed. XML-RPC (xmlrpc.php) enables remote publishing and is sometimes exploited for brute force attacks and DDoS amplification. If you do not use remote publishing tools, the Jetpack app, or pingbacks, disable XML-RPC via a security plugin or .htaccess rule.
• Security plugin is active and configured. A security plugin (Wordfence, Sucuri Security, or iThemes Security) should be installed and configured with file integrity monitoring, login attempt limiting, and malware scanning enabled. Review the security log weekly for suspicious activity.
• Backups are automated and tested. Automated backups should run daily and be stored offsite (not on the same server as your website). Verify that you can actually restore from a backup by testing the process in a staging environment. Backups you cannot restore from provide false confidence.

SEO Settings

• Permalink structure uses readable URLs. Navigate to Settings > Permalinks and verify the structure uses /%postname%/ or a similar readable format, not the default ?p=123 structure. Changing permalinks on an established site requires redirects from old URLs, so document any changes carefully.
• Search engine visibility is enabled. Check Settings > Reading and verify that "Discourage search engines from indexing this site" is NOT checked. This is the most common accidental SEO disaster on WordPress sites, often enabled during development and forgotten at launch.
• XML sitemap is generated and submitted. Verify that your SEO plugin generates an XML sitemap (usually at /sitemap.xml or /sitemap_index.xml). Check that the sitemap is submitted in Google Search Console and Bing Webmaster Tools. Open the sitemap URL in a browser to confirm it loads correctly and includes your important pages.
• Category and tag archive handling. Check your SEO plugin's settings for category and tag archives. If you have thin tag archives (tags used on only one or two posts), consider noindexing tags entirely. Category archives should be indexed if they contain unique descriptive content; noindexed if they are just post listings with no added value.
• Author archives are handled correctly. On single-author sites, author archives duplicate the main blog listing and should be noindexed or redirected to the main blog page. On multi-author sites, author archives can be valuable if they include author bios and unique content.
• Attachment pages are disabled or redirected. WordPress creates a separate page for every uploaded media file by default. These attachment pages contain only the media file with no additional content, creating thousands of thin pages. Your SEO plugin should redirect attachment pages to the parent post or the media file itself.
• Open Graph and social meta tags. Verify that social sharing meta tags are generated by your SEO plugin and that each page has a relevant og:image. Share a test page on Facebook and Twitter (using their debug tools) to confirm that the correct title, description, and image appear in the share preview.

Speed

• Page caching is active. Verify that full-page caching is enabled for logged-out visitors. Test by checking response headers for cache indicators or by measuring TTFB (cached pages typically respond in under 200ms, uncached WordPress pages often take 500ms-2000ms). WP Super Cache, W3 Total Cache, WP Rocket, or hosting-level caching are common solutions.
• Object caching is configured. For sites on hosting that supports Redis or Memcached, verify that object caching is enabled. Object caching stores database query results in memory, reducing database load on every page request. This is particularly impactful on WooCommerce sites and membership sites with many logged-in users.
• Images are optimised on upload. Check whether an image optimisation plugin (ShortPixel, Imagify, Smush) is active and configured to compress and convert images automatically on upload. Verify that existing images in the media library have been bulk-optimised. Check that WebP versions are being generated and served.
• CSS and JavaScript are minified. Verify that your caching or optimisation plugin minifies CSS and JavaScript files. Check by viewing the page source and confirming that stylesheet and script files are minified (no whitespace, single-line format). Also check whether CSS and JS files are combined to reduce HTTP requests, though this is less important with HTTP/2.
• Render-blocking resources are deferred. Use Lighthouse or PageSpeed Insights to identify render-blocking CSS and JavaScript. Non-critical CSS should be loaded asynchronously. Non-essential JavaScript should use defer or async attributes. Your optimisation plugin may handle this automatically, but verify the implementation.
• Hosting is adequate. Run a simple load test (GTmetrix, Pingdom, or WebPageTest from multiple locations) during peak hours. If TTFB exceeds 600ms consistently, your hosting may be the bottleneck. Shared hosting plans that worked for a small site often become inadequate as traffic and complexity grow. Consider managed WordPress hosting if performance is consistently poor.
• CDN is configured. A Content Delivery Network serves static assets (images, CSS, JavaScript) from edge servers close to your visitors. Verify that your CDN (Cloudflare, StackPath, KeyCDN, or similar) is active and serving assets correctly. Check that CDN caching headers are set appropriately and that cache hit rates are high (above 90% for static assets).