WordPress SEO Audit: Archives, Plugins, Themes and Hosting

A WordPress SEO audit checks the site's actual plugin, theme, archive and hosting configuration. Review indexable URL types, rendered metadata, duplicate structured data, caching and security; back up the site and test risky configuration or database changes on staging.

Whether you are running a simple blog, a WooCommerce store, or a complex membership site, the WordPress ecosystem introduces a predictable set of SEO issues that demand dedicated attention. This guide covers every WordPress-specific check you need to include in your audit, from plugin conflicts to database bloat to the hosting decisions that quietly throttle your rankings.

WordPress-Specific Audit Concerns

WordPress generates SEO problems that do not exist on custom-built or static sites. Understanding these platform-specific risks is essential before you begin auditing.

WordPress can expose author, date, category, tag, taxonomy and feed URLs depending on configuration. Inventory the actual URLs and decide which archives serve a distinct purpose before changing index controls.

The second concern is render-blocking resource accumulation. Every active plugin can enqueue its own CSS and JavaScript files on every page of your site, regardless of whether that page actually uses the plugin's functionality. A contact form plugin loading its assets on blog posts, a slider plugin loading on pages without sliders, and an analytics plugin injecting tracking code twice because of a theme conflict — these compound into significant performance degradation.

WordPress can emit feeds, oEmbed and REST discovery links that support platform features. Remove an output only after confirming it is unused and measuring whether it creates a material performance or crawl problem.

Finally, WordPress's auto-update mechanism means your site's technical SEO can change without you doing anything. A plugin update that modifies heading output, a theme update that changes schema markup, or a core update that alters canonical tag behaviour can all introduce SEO regressions that go undetected for weeks.

Plugin Audit

Catalogue the installed and active plugins before judging risk. Plugin count alone does not predict performance or security; maintenance status, permissions, code execution and overlap matter more.

Begin by cataloguing every installed plugin, noting whether it is active or inactive, when it was last updated, and whether it is still maintained by its developer. Then assess each plugin against these criteria:

• Necessity — does this plugin serve an active purpose? Many WordPress sites accumulate plugins for features that were tested once and never used, or for problems that were solved years ago. Deactivate and delete anything that is not actively needed. Inactive plugins still pose security risks and clutter the admin interface.
• Redundancy — are multiple plugins performing the same function? It is common to find two SEO plugins active simultaneously (Yoast and Rank Math, for instance), two caching plugins conflicting, or multiple analytics plugins all injecting tracking code. Identify overlaps and consolidate to a single solution for each function.
• Performance impact — use Query Monitor or browser profiling to measure suspected plugin work. Test changes on staging and compare repeated traces. Prioritise measured bottlenecks by affected templates and business value rather than a universal 200 ms cutoff.
• SEO conflicts — check for plugins that output their own meta tags, schema markup, or canonical tags that conflict with your SEO plugin. Social sharing plugins, review plugins, and page builder plugins are common offenders. View the page source on several pages and search for duplicate meta descriptions, multiple canonical tags, or conflicting Open Graph tags.
• Maintenance status — check each plugin's last update, supported WordPress version, changelog, disclosed vulnerabilities and developer support. Age is a prompt for review rather than proof of insecurity.

Document your findings in a spreadsheet with columns for plugin name, status, last updated, performance impact, and recommended action (keep, replace, or remove).

Theme Performance

Your WordPress theme controls more of your SEO than most people realise. It determines your HTML structure, heading hierarchy, schema output, image handling, font loading strategy, and the baseline CSS and JavaScript that loads on every page. A poorly coded theme can undermine every other SEO effort you make.

Audit your theme by examining these specific areas:

• Heading hierarchy — inspect representative page types and verify that the primary heading and subordinate sections communicate a logical outline. Multiple H1 elements are valid HTML; flag them only when they make structure or page purpose unclear.
• CSS delivery — measure render-blocking and unused CSS on representative templates. Set budgets from the site's actual performance goals rather than a universal kilobyte range.
• JavaScript execution — profile the theme's JavaScript using Chrome DevTools. Check for long tasks that block the main thread, unnecessary jQuery dependencies, and scripts that execute before they are needed. Many themes still load jQuery even when their functionality could use vanilla JavaScript.
• Font loading — check whether fonts are self-hosted or loaded from Google Fonts CDN, whether font-display: swap is set, and how many font files are loaded. Each font weight and style is a separate file. Themes that load six or more font files create noticeable render delays.
• Mobile responsiveness — test representative templates and journeys across the viewport and device mix shown in analytics. Check horizontal scrolling, zoom, input, tap targets, orientation and layout shifts with browser tools and real-device testing; Google's Mobile-Friendly Test was retired in 2023.
• Schema output — inspect combined theme and plugin markup for conflicting or inaccurate entities. Multiple valid blocks can coexist, but duplicates and contradictions should be corrected.

If your theme audit reveals fundamental problems — broken heading hierarchy, excessive CSS/JS weight, or outdated code patterns — switching to a lightweight theme like GeneratePress, Kadence, or a custom theme may be more efficient than patching the problems individually.

Database Optimisation

WordPress stores posts, settings and other application records in its database while files such as uploaded media remain in the filesystem or external storage. Database work can contribute to server response time, but table size or age does not establish a TTFB or Core Web Vitals problem; profile representative requests before recommending maintenance.

Your database audit should check for:

• Post revisions — measure revision rows, storage and query impact before changing retention. Revisions support editorial recovery; choose a limit from the publishing workflow and test any cleanup on a backed-up staging copy before production.
• Transients — inspect expired transient volume and measured option-query cost. Let WordPress and the responsible plugin manage routine expiry; schedule manual cleanup only when evidence, backups and ownership justify it.
• Autoloaded options — profile option loading and identify large or obsolete entries that contribute materially to server work. Back up first and avoid deleting rows by size alone.
• Orphaned metadata — identify rows whose parent objects no longer exist and quantify their operational effect. Confirm plugin ownership and referential assumptions before cleanup, then use a backed-up, tested procedure.
• Database maintenance — use slow-query evidence, table statistics and host guidance to identify a database bottleneck. Do not run OPTIMIZE TABLE or bulk-delete metadata as a routine SEO fix; agree backups, locks, rollback and a maintenance window first.

Back up the database and files before maintenance and test changes on staging. Record the restore method and verify the backup before running destructive queries.

WordPress SEO Settings

WordPress and SEO plugins expose settings that can change public URLs, discovery and indexing signals. Record the intended behaviour first, then compare it with rendered output and crawler or Search Console evidence.

Start with WordPress core settings:

• Search engine visibility — compare Settings > Reading with the intended public and private URL sets, then inspect the directives WordPress actually renders. On a public production site, investigate an unintended discourage-indexing setting; do not assume the setting always produces one directive on every URL or cite an unsupported prevalence claim.
• Permalink structure — document the current route pattern and whether it remains clear, stable and supported by internal links. Post-name and date-based structures can both be valid; change an established structure only for a demonstrated user or maintenance need, with a complete redirect and verification plan.
• Category and tag base — check whether the default /category/ base is appropriate for your URL structure. Some sites remove it for cleaner URLs, while others keep it for clarity. Consistency matters more than the specific choice.

Then audit your SEO plugin configuration (Yoast, Rank Math, or equivalent):

• XML sitemap — verify the sitemap is generated, accessible, and includes only indexable pages. Check that post types and taxonomies you want indexed are included, and those you do not (tags, author archives, media attachment pages) are excluded.
• Archive indexing — decide the intended state of author, date and tag archives from their navigation and search purpose. Keep useful archive pages accurate and internally supported; exclude an archive only when it lacks a continuing task, without treating feed excerpts as an automatic duplicate-content defect.
• Breadcrumb settings — if using SEO plugin breadcrumbs, verify they generate correct BreadcrumbList schema and display on all page types.
• Open Graph and Twitter Card defaults — check that default social sharing images and descriptions are set for pages that lack custom entries.
• Redirect manager — review any redirects managed by the SEO plugin. Look for redirect chains, loops, and redirects to pages that have themselves been redirected.

Security Checks

A compromised WordPress site can expose users, inject unwanted content or redirects and trigger browser or search warnings. Review current indicators and controls, but measure the affected URLs and recovery period instead of claiming that every incident destroys rankings for months.

• WordPress core version — is the site running the latest version of WordPress? Outdated core installations are the primary attack vector. Check the version in the dashboard or via the wp-includes/version.php file.
• Admin security — check whether the default "admin" username exists, whether two-factor authentication is enabled for administrators, and whether login attempt limiting is in place. Brute force attacks against wp-login.php are constant and automated.
• File permissions — compare ownership and permissions with the host, web-server user and deployment model. WordPress documents possible schemes, including tighter access for wp-config.php, but one numeric mode is not safe or functional for every environment.
• SSL configuration — verify that HTTPS is enforced site-wide with proper redirects from HTTP. Check for mixed content warnings where some resources load over HTTP on an HTTPS page. Use the site_url and home_url settings to confirm both use https://.
• Malware scan — run a security scanner like Wordfence or Sucuri to check for known malware signatures, modified core files, and suspicious code in plugins or themes. Check Google Search Console for any manual actions related to hacked content.
• XML-RPC — identify integrations that use XML-RPC and review actual abuse evidence and compensating controls before restricting it. Jetpack, remote publishing and other integrations can depend on the endpoint; disabling it is an operational security decision rather than a default SEO fix.

Hosting and Speed

Your hosting environment sets the performance ceiling for your WordPress site. No amount of plugin optimisation or caching can compensate for an underpowered server or a shared hosting plan that places your site on an overloaded machine.

• Server response — measure TTFB across templates and representative traffic periods. Profile application, database, cache and network contributions before attributing delay to hosting.
• PHP version — check the branch against PHP's current support table and confirm compatibility with WordPress, the theme, plugins and host before upgrading. PHP 8.1 is end-of-life; use a currently supported branch and benchmark the site's real workload rather than promising a version-based speed gain.
• Object caching — verify whether Redis or Memcached is available and configured. Object caching stores database query results in memory, dramatically reducing response times for dynamic WordPress pages. This is one of the highest-impact speed improvements for WordPress sites with complex queries.
• Page caching — check that a page caching solution is active and properly configured. Test by loading a page twice and checking for the cache hit header. Verify that caching is not interfering with dynamic functionality like WooCommerce carts or logged-in user experiences.
• CDN configuration — confirm that a CDN (Cloudflare, Fastly, or similar) is active and serving static assets from edge locations. Check that CSS, JavaScript, images, and fonts are all served via the CDN, not directly from the origin server.
• Image optimisation — verify that an image optimisation solution is in place, either server-side (ShortPixel, Imagify) or via CDN (Cloudflare Polish). Check that WebP format is served to supporting browsers and that images are properly sized for their display dimensions.

Choose hosting or infrastructure changes only after profiling identifies the bottleneck. Compare caching, capacity, support, recovery and cost against the site's requirements rather than naming a migration as the default fix.

WordPress Audit Tools

WordPress has a rich ecosystem of tools specifically designed for auditing and monitoring site health. Combining platform-specific tools with standard SEO tools gives you the most complete picture.

• Query Monitor — where authorised, use it in a staging or controlled diagnostic environment to inspect queries, PHP errors, API calls, hooks and asset dependencies. Installing a plugin changes the system under test; agree access, backup and removal rather than treating production installation as required.
• WordPress Site Health — built into WordPress core since version 5.2. Access it at Tools > Site Health. It checks for outdated PHP, missing HTTPS, inactive plugins, and basic security issues. Treat it as a starting point, not a comprehensive audit.
• WP-CLI — the command-line interface for WordPress. Allows you to audit database size, list plugins with their update status, search for specific content patterns across posts, and run database optimisation commands without touching the admin interface. Essential for auditing large WordPress sites where the admin panel is slow.
• Health Check & Troubleshooting — a plugin from the WordPress.org team that lets you switch themes and disable plugins in a troubleshooting mode visible only to you. Invaluable for isolating the cause of SEO issues without affecting live visitors.
• Screaming Frog with WordPress configuration — configure Screaming Frog to crawl your WordPress site with specific attention to archive URLs, feed URLs, and media attachment pages. Set custom extraction rules to pull WordPress-specific metadata from each page.
• Waterfall and field tools — use WebPageTest or a comparable waterfall view for request timing and PageSpeed Insights for available field plus lab data. Record test location, device and date.

Schedule WordPress-specific audits quarterly, with security and update checks monthly. The WordPress ecosystem moves fast — new plugin versions, core updates, and PHP releases mean that what was optimised three months ago may need attention today. Build audit checks into your site maintenance workflow rather than treating them as one-off events.