WordPress Website Audit Checklist

A WordPress audit checks supported core and runtime versions, maintained extensions, theme output, database behaviour, account controls, search settings and performance. Back up the site and use a staging environment before changing plugins, themes or database records.

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 supported. Record the installed release, security advisories and available updates. Prioritise known vulnerabilities and unsupported branches, then test updates against the site's theme, plugins and recovery plan.
• 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 supported. Compare the production version with current WordPress hosting requirements and PHP's supported-version table. Test theme and plugin compatibility in staging before upgrading.
• MySQL or MariaDB version is supported. Compare the server with current WordPress requirements and the database vendor's support policy. Avoid exposing a public PHP information page.
• Debug output and logging are configured safely. Check WP_DEBUG, WP_DEBUG_DISPLAY, WP_DEBUG_LOG and PHP display/log settings together. Production can retain controlled logging while preventing errors and sensitive paths from being shown to visitors.
• 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 extend the site's code and can affect security, performance and generated markup. Audit the components actually installed and exposed.

• Plugin update risk is assessed. Record installed versions, known vulnerabilities, support status, exposure and compatibility. Test supported updates before deployment and prioritise fixes from verified risk rather than age alone.
• Unmaintained plugins are reviewed. Check vendor notices, repository activity, compatibility and security advisories. A long update interval is an investigation signal, not proof that a component is unsafe.
• 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.
• DOM work is measured. Inspect representative templates with browser performance tools. Investigate costly style recalculation or layout work instead of treating a fixed node count as a universal failure.
• 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. Choose and test a font-display strategy against readable fallback text, layout shifts and loading conditions. Compare self-hosted and third-party delivery with actual request evidence. Check that you are only loading the font weights and character sets actually used in your design.

Database

Measure database work before planning maintenance. Row counts and storage size alone do not establish a page-speed problem; preserve editorial history and plugin data needed by the site.

• Revision retention fits the workflow. Check current settings, editorial recovery needs and measured storage or query impact. Agree any retention change and test cleanup on a backed-up staging copy rather than imposing a fixed revision count.
• Transient expiry is investigated when relevant. Check the responsible plugin, object-cache behaviour and measured database cost. Use supported maintenance procedures only when needed, with a tested backup and rollback plan.
• Comment retention is intentional. Review spam and trashed comments against moderation, recovery and retention needs. Confirm a measured operational reason before scheduling destructive cleanup.
• Metadata ownership is verified. Investigate apparent orphan rows with the owning plugin and data model. Do not delete records solely because a generic cleanup tool labels them unused.
• Database work is measured before maintenance. Inspect slow queries, table size and engine behaviour. Back up and test any optimisation on staging rather than running a universal monthly command.
• Retired plugin data has an owner decision. Uninstall behaviour varies by plugin. Confirm whether retained tables support another integration, recovery or an obligation before removing them through a backed-up and tested procedure.
• Autoload cost is measured. Use current WordPress diagnostics and profiling to identify large or unnecessary options. Autoload values and behaviour vary by WordPress version; do not rely on a fixed size threshold or change a plugin's options without checking its requirements.

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 follow least privilege. Compare ownership and permissions with the host, deployment model and WordPress hardening guidance. Confirm that the web process cannot modify code or read secrets it does not need; do not apply 755, 644 or 400 blindly across every installation.
• wp-config.php content is not exposed. Inspect server configuration and an authorised response for disclosure or download of the file. A PHP-handled request can return an empty 200 without exposing content, so status alone is not the test.
• 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 monitoring covers the risks. Verify rate limiting, change detection, vulnerability alerts and incident logging at the appropriate plugin, host or external service. A security plugin is one option, not a universal requirement.
• Backups meet recovery objectives. Check automated jobs, isolated copies, retention and restore tests against documented recovery-point and recovery-time objectives.

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-page behaviour is intentional. New WordPress 6.4 installations disable attachment pages by default, while older or changed sites may retain them. Inspect the live behaviour and keep, redirect or disable pages according to their user value and existing signals.
• 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 matches content behaviour. Inspect cache headers and repeated requests for cacheable logged-out pages. Exclude personalised and sensitive responses and measure the actual change.
• 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 measured under a defined workload. Compare cached and uncached response time, capacity and error rate from target locations. Attribute delays before changing providers.
• CDN behaviour is verified when used. Inspect cache headers and cache status for versioned static assets. Set a project target from traffic and asset patterns rather than assuming every site needs a CDN or a 90% hit rate.

Check version requirements in the official WordPress requirements and use the WordPress hardening guide. Continue with the performance audit when a WordPress finding needs runtime evidence.