WordPress SEO audit: a practical walkthrough

The most damaging setting in WordPress is a single checkbox under Settings → Reading: “Discourage search engines from indexing this site”. Since WordPress 5.3 it adds a noindex, nofollow robots meta tag to every page (WordPress core announcement), and it also switches off the core XML sitemap. It exists for staging sites, and it regularly survives the move to production.

This WordPress SEO audit walks through the admin screens in the order problems usually show up, then maps common audit findings to their WordPress causes. Keep a browser tab open on your site’s page source as you go; the admin screens tell you what is configured, the source tells you what is output.

Settings → Reading: search engine visibility

1. Go to Settings → Reading and confirm the “Discourage search engines” box is unchecked.
2. Open your home page, view the source and search for noindex. If it is still there, a plugin, theme or the server is adding it.
3. Request the page headers with your browser’s developer tools and check for an X-Robots-Tag header; staging setups sometimes add one, and it can be carried over to production with the server configuration.

Our audit reports this under the Indexability check as an error, because a noindex directive keeps the page out of search results entirely.

Settings → Permalinks: URL structure

Go to Settings → Permalinks. WordPress’s own documentation says the default on a new install is Plain, which produces URLs like /?p=123, and describes it as not optimised for search engines (Customize permalinks). Most sites should use Post name or a custom structure built on %postname%.

If the site is already established, changing the structure is a migration, not a setting. Before you save a new structure:

1. Export a list of current URLs from your sitemap.
2. Change the structure on a staging copy and test old URLs with the redirect checker.
3. Make sure each old URL reaches its new address in a single 301, with no redirect chains through intermediate formats.

Check trailing slashes while you are here. WordPress redirects the non-slash version to the slash version (or the reverse, depending on the structure), so internal links should match the format you chose.

Plugins: one SEO plugin, checked in the source

WordPress core has no field for meta descriptions, so most sites rely on an SEO plugin. Our view: the brand matters less than three rules.

• Run exactly one. Two SEO plugins, or a plugin plus a theme with built-in SEO features, often print two descriptions, two canonicals or two sets of structured data.
• Check the output, not the settings. In the page source, confirm one <title>, one meta description, one canonical pointing to the page itself and JSON-LD that parses.
• Fill in the entity details. Organization or Person markup with your logo and sameAs links to official profiles, and Article markup with an author and dates on posts. Our audit checks both under Entity markup and Article authorship markup.

Write unique titles and descriptions for your most visited pages first. The meta tag checker shows how each one appears in results.

Sitemaps: core or plugin, never both

According to the WordPress core team, core has published a sitemap index at /wp-sitemap.xml since version 5.5, covering public post types, taxonomies, author archives and the home page, with up to 2,000 entries per sitemap page; it is disabled when the site discourages search engines (WordPress 5.5 sitemaps). Most SEO plugins replace it with their own.

1. Find which sitemap is live: try /wp-sitemap.xml and your plugin’s sitemap path.
2. Submit only that one in Search Console.
3. Make sure it excludes URLs you have set to noindex, such as tag archives or thin author pages.
4. Check that /robots.txt contains a Sitemap: line pointing to it.

That last step matters for automated tools. Our audit looks for sitemaps declared in robots.txt and at common paths such as /sitemap.xml and /sitemap_index.xml. A site with a physical robots.txt file that omits the Sitemap: line, and a sitemap at a non-standard path, will be reported as having no sitemap. The sitemap checker validates the file itself.

robots.txt: virtual file, plugins and AI crawlers

WordPress serves a virtual robots.txt unless a physical file exists in the web root. If a file exists, it overrides whatever your SEO plugin or AI-blocking plugin claims to write, so always check the live /robots.txt rather than the settings screen.

Several plugins now offer one-click blocking of AI crawlers. Before using one, understand what each bot does (the AI crawlers guide has the full list):

User agent	What blocking it does
GPTBot	Opts out of OpenAI model training; does not affect ChatGPT search
OAI-SearchBot	Removes your pages from ChatGPT search results
ClaudeBot, Claude-SearchBot	Training and Claude search respectively; both honour robots.txt
Google-Extended	A token, not a crawler: limits use in Gemini training and grounding without affecting Google Search
PerplexityBot	Removes pages from Perplexity’s search index
Perplexity-User	Fetches pages when a user asks; does not follow robots.txt

Security and firewall plugins can also block crawlers by user agent, which robots.txt will not show. Our audit’s fetch-as-crawler check compares a normal request with requests identifying as AI crawlers to catch that. Test your rules with the robots.txt tester, and see robots.txt for AI bots for copy-ready examples.

Media library: attachment pages, alt text and image size

• Attachment pages. The WordPress core team says version 6.4 disabled attachment pages on new installs, redirecting them to the file, while existing sites keep them enabled after upgrading (attachment page changes). On older sites each uploaded image may still have its own thin page. The option is wp_attachment_pages_enabled; setting it to 0 turns them off.
• Alt text. Fill it in the media library for informative images; leave it empty for decorative ones.
• Image size. Upload images close to the largest size they display at. WordPress generates smaller versions for srcset, but it cannot rescue a 6,000-pixel original used as a thumbnail.
• Lazy loading. WordPress adds loading="lazy" automatically. Check that your hero image, usually the Largest Contentful Paint element, is not lazy-loaded by the theme or an optimisation plugin.

Appearance: theme and plugin weight

Our view: the number of plugins matters far less than what each one loads on public pages. Page builders and multipurpose themes often load their full CSS and JavaScript on every URL, whether the page uses those features or not.

1. Run a mobile test on three templates (home, post, contact) with the Core Web Vitals checker.
2. In the opportunities list, note which scripts and stylesheets belong to which plugin.
3. Deactivate plugins you no longer use, and limit others to the pages that need them.
4. Re-test and keep the before and after numbers.

Hosting: caching and server response

Google says, in its web.dev guidance, that most sites should aim for a Time to First Byte of 0.8 seconds or less (TTFB). WordPress builds pages with PHP and database queries on every uncached request, so full-page caching (from a plugin or the host) and a CDN make the largest difference. Our audit marks a TTFB over 600 ms as worth investigating and over 1.2 seconds as a problem.

While you are looking at the server, check for mixed content. Sites moved from http to https often keep http:// image URLs inside old posts; a database search-and-replace fixes them in one pass.

Audit findings and their usual WordPress causes

Audit finding	Usual WordPress cause	Fix
Indexability: noindex on every page	Reading setting left on after launch	Uncheck it and re-test
Meta description missing	No SEO plugin, or the field left empty	Write descriptions for key pages
Several H1 headings	Theme wraps the site title or logo in an H1	Edit the header template
Images missing alt text	Uploaded without alt text	Add it in the media library
Mixed content	Hardcoded http:// URLs in post content	Search and replace in the database
Version disclosure	X-Powered-By header showing the PHP version	Remove it in the server or host settings
Redirect chain	Separate rules for https, www and trailing slash	Combine into one rule
No sitemap found	Physical robots.txt without a Sitemap: line	Add the line
No Article author or dates in JSON-LD	Schema output switched off in the SEO plugin	Enable Article markup

What to do next

1. Run the free audit on your home page, one post and one page; WordPress problems usually live in templates, so three URLs cover most of the site.
2. Fix any indexability or robots errors before anything else.
3. Work through the remaining sections above, re-scanning after each batch so you can see which change moved which check.
4. Use the technical SEO checklist for the site-wide items that are not specific to WordPress.

Frequently asked questions

Which SEO plugin should I use for WordPress?

Any of the established SEO plugins can produce correct titles, descriptions, canonicals, sitemaps and structured data. What matters is running only one, configuring it deliberately and checking its output in the page source. Two SEO plugins at once usually means duplicate tags.

Is the built-in WordPress sitemap good enough?

For many small sites, yes. Since WordPress 5.5 core publishes a sitemap index at /wp-sitemap.xml covering public posts, pages, taxonomies and author archives. SEO plugins usually replace it with their own; either is fine as long as only one is submitted and it lists only indexable URLs.

Should I block AI crawlers on WordPress?

That is a business decision. Blocking training crawlers such as GPTBot does not affect search visibility, but blocking OAI-SearchBot removes your pages from ChatGPT search results. Decide per crawler, then confirm the result at /robots.txt rather than trusting the plugin screen.

How many plugins is too many?

There is no meaningful number. One badly built plugin that loads scripts on every page can cost more than twenty that only run in the admin. Measure what each plugin loads on the front end instead of counting them.