WordPress SEO Audit: What to Check and Fix First

A WordPress SEO audit is a review of a WordPress site that checks the problems specific to the CMS (search visibility settings, SEO plugin output, auto-generated archives, attachment pages, theme markup and plugin bloat) along with the usual crawl, index and content checks. The goal is a short, ranked list of fixes, starting with anything that blocks indexing.

WordPress runs a huge share of the web, and most of its SEO problems come from defaults, plugins and themes, not from the core software. This guide covers what to check, where WordPress usually goes wrong, and what to fix first.

Why does a WordPress site need its own SEO audit?

A WordPress site needs a WordPress-specific audit because the CMS creates URLs, tags and files you never wrote by hand. Tag archives, author pages, attachment pages, a virtual robots.txt and an auto-generated sitemap all exist out of the box. Plugins and themes then add their own output on top of that.

A general audit still applies. You need the basics from our technical SEO audit guide: crawlability, indexing, redirects and speed. On WordPress, though, the cause of a finding is usually a setting or a plugin, so the fix is a checkbox, a plugin swap or a theme change. You rarely need to touch code.

Typical WordPress findings look like this:

• The whole site is noindex because a box was left ticked after launch.
• Two SEO plugins each output a canonical and a meta description.
• Hundreds of thin tag pages sit in the index.
• Image attachment pages show up in search instead of the posts.
• A page builder theme ships heavy JavaScript and fails Core Web Vitals.

WordPress SEO audit checklist: what to check first

Check things in order of impact. If Google can't index the site, nothing further down the list matters yet.

For the full cross-platform list, see the SEO audit checklist. The sections below explain the WordPress-specific items.

Is the "Discourage search engines" setting blocking your site?

Check this first. When Settings → Reading → Discourage search engines from indexing this site is ticked, WordPress outputs a noindex,nofollow robots meta tag on every page. According to the WordPress Reading Settings documentation, this has been the behavior since version 5.3. Before that, WordPress served a Disallow: / robots.txt instead.

This checkbox is often ticked on a staging site and then carried over when the site goes live. The result is a launched site that never appears in Google. The same documentation notes that the option is only a request, so it is not a way to keep a staging site private. Use password protection for that.

The setting also switches off WordPress core sitemaps. The WordPress 5.5 sitemaps announcement says core sitemaps respect the "discourage search engines" option. So if /wp-sitemap.xml returns nothing on a site with no SEO plugin, this checkbox is the first thing to suspect.

How to verify: open any page, view the source and search for name="robots". Then run a few key URLs through URL Inspection in Search Console.

How do you audit robots.txt and the sitemap on WordPress?

WordPress serves a virtual robots.txt unless a real file exists in the site root, and SEO plugins can edit it. Fetch /robots.txt in a browser and read what it actually serves. Don't rely on what the plugin settings screen says.

What to look for:

• Blocked theme or plugin assets. Old advice told people to disallow /wp-content/ or /wp-includes/. Google's robots.txt introduction warns against blocking resources that crawlers need to understand the page. CSS and JS under /wp-content/ usually fall into that group.
• Using robots.txt to hide pages. Google says robots.txt is "not a mechanism for keeping a web page out of Google." Blocked URLs can still be indexed without a description. Our robots.txt guide covers the rules in detail.
• Disallow plus noindex on the same URL. Google's noindex documentation says a page with noindex must not be blocked by robots.txt, or Googlebot never sees the directive.

A typical safe WordPress robots.txt looks like this:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Sitemap checks

WordPress core has generated sitemaps at /wp-sitemap.xml since version 5.5. They cover public post types, taxonomies, author archives and the homepage, with up to 2,000 entries per sitemap file by default (WordPress core announcement). SEO plugins can turn the core sitemap off and serve their own.

Things to audit:

1. Exactly one sitemap source, and it's the one submitted in Search Console and referenced in robots.txt.
2. No noindexed, redirected or 404 URLs in the sitemap. A common case: tag archives are set to noindex but still listed in the sitemap.
3. No empty or private post types (forms, page-builder templates, membership content) exposed as sitemap entries.

Which WordPress pages create duplicate and thin content?

WordPress automatically creates several kinds of archive pages. Many of them repeat content found elsewhere, or hold one or two posts each. That's where most index bloat on WordPress comes from.

Attachment pages deserve a closer look on older sites. In WordPress 6.4, core added the wp_attachment_pages_enabled option. According to the WordPress 6.4 attachment pages note, it is off by default on new installs, so attachment pages redirect to the file. Sites that existed before the update keep the pages turned on. An older site can therefore still have thousands of image-only URLs that Google can index. Search Console reports such as Crawled – currently not indexed often fill up with these URLs.

Category archives are different. A well-written category page with an intro and a curated set of posts can rank, so give it real content and keep it indexable.

Are two SEO plugins fighting over your tags?

This is one of the most common WordPress findings. Two SEO plugins (or an SEO plugin plus a theme with built-in SEO features) each print a title, a meta description, a canonical and schema markup. The page ends up with two canonicals or two conflicting og: tags.

Google's duplicate URL consolidation guide specifically warns against specifying different canonicals for the same page by different methods, and asks for absolute URLs. If the source of one page shows two rel="canonical" lines, you've found the problem. Keep one SEO plugin, switch off SEO output in the theme, and check again. For canonical rules in general, see the canonical tag guide.

While you're in the page source, also check:

• Title and meta templates. Templates like %title% | %sitename% are fine. Missing templates that leave every product page called "Shop | Brand" are not.
• Canonicals point to the final URL: HTTPS, the correct www or non-www version, and the same trailing-slash style as your permalinks.
• Pagination canonicals. Page 2 of an archive should canonicalize to itself, not to page 1.

How do themes and page builders affect WordPress SEO?

The theme controls your HTML: heading structure, whether main content is in the initial HTML, and how much CSS and JavaScript every page loads. Two sites on the same plugins can score very differently because of the theme alone.

What to audit:

• One H1 per page, holding the page title. Some themes wrap the logo in an H1 on every page, or set post titles as H2.
• Content in the raw HTML. Tabs, accordions and sliders that load text only after JavaScript runs can hide that text from crawlers that don't render pages. Compare the page source with what you see in the browser.
• Internal links in real <a href> tags. Mega menus and "load more" buttons built with JavaScript events often leave deep posts orphaned. See internal linking for SEO.
• Leftover demo content. Imported theme demos leave sample pages, portfolio items and "Hello world!" posts in the index.

Why are WordPress sites slow, and what should you check?

On WordPress, slow pages usually come from too many plugins, heavy page builders, unoptimized images and hosting without page caching. Measure first: look at Core Web Vitals field data in Search Console or PageSpeed Insights, since the thresholds (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1) apply at the 75th percentile of real visits. Our Core Web Vitals guide explains each metric.

WordPress-specific causes to look for:

• Plugins loading assets on every page. A contact form, slider or popup script loading on all 500 posts when only one page uses it.
• A large hero image as the LCP element, not preloaded, sometimes lazy-loaded by mistake.
• No page cache, so every visit runs PHP and database queries.
• Several optimization plugins at once, which can break each other's minification and cause layout shifts.
• Third-party embeds (chat widgets, review carousels) slowing interaction and hurting INP.

Remove before you optimize. Deactivating three unused plugins is often worth more than tuning ten settings.

What should a WordPress audit check for AI search?

On WordPress, AI search checks mostly come down to access and clarity. Can AI crawlers fetch your pages, is the main text in the HTML, and is the business clearly identified in structured data? WordPress adds its own risks: security plugins and CDN bot-blocking settings can block AI crawlers without anyone noticing.

Check these points:

• robots.txt and firewall rules for AI search and training bots. A security plugin may block bots that robots.txt allows.
• Organization markup with sameAs links to your official profiles, output once by your SEO plugin.
• Snippet controls such as nosnippet or max-snippet set by a plugin across the whole site by mistake.

The AI search optimization checklist covers each platform's documented crawlers. To check these points on your own site, a free SEORecheck audit reports the indexing settings, duplicate tags, sitemap and archive problems above, plus AI crawler access in robots.txt, snippet controls, JavaScript-only text and Organization/sameAs markup.

How do you prioritize WordPress SEO fixes?

Fix in this order: indexing blockers, then duplicate signals, then index bloat, then speed, then content and structured data. A site set to noindex gains nothing from faster images. A site with 3,000 thin tag pages gains more from cleaning those up than from rewriting one meta description.

A practical plan:

1. Days 1–30: search visibility setting, robots.txt, a single sitemap, one SEO plugin, canonical and redirect fixes.
2. Days 31–60: noindex or remove thin archives, redirect attachment pages, clean up demo content, fix theme headings.
3. Days 61–90: plugin cleanup and Core Web Vitals, internal linking, structured data, AI crawler access.

Then run the audit again to confirm each issue is actually fixed. The sample report shows what a prioritized plan looks like, and the recheck comparison shows how fixed, improved, unresolved and new issues are tracked after a second crawl.

Key takeaways

• Start every WordPress SEO audit with Settings → Reading and the live robots.txt. A single checkbox can deindex the whole site.
• Keep one SEO plugin and one sitemap source. Duplicate canonicals and meta tags come from plugin and theme conflicts.
• Tag, author, date and attachment pages are the main source of index bloat on WordPress. Older sites may still have attachment pages turned on.
• Never combine Disallow and noindex on the same URL. Google can't see a noindex on a page it isn't allowed to crawl.
• Speed problems usually come from plugins, page builders and images. Remove what you don't use before tuning anything else.
• Check that security plugins and CDN settings aren't blocking the AI crawlers you want to allow.