WordPress SEO Audit: A Step-by-Step Checklist

A WordPress SEO audit is a check of what your WordPress site serves to search engines against what you meant it to serve. Most of it is the same as auditing any site: indexing, titles, links, speed. The rest is specific to WordPress, because WordPress creates URLs, sitemaps and settings by itself, and a theme or plugin can change any of them without telling you. This checklist runs in the order that saves the most time, starting with the one setting that makes every other finding irrelevant.

For the general version that applies to any platform, see the technical SEO audit checklist. This post covers what is different about WordPress.

What you need before you start

Three sources, because each one sees something the others cannot.

• Google Search Console shows what Google has actually crawled and indexed, and why it left pages out. Open the Pages report under Indexing.
• A crawler fetches the live site from the outside the way Googlebot does, and reports what the server really returns: status codes, redirects, titles, canonicals and links. It sees the final HTML after the theme, page builder, caching plugin and CDN have all changed it.
• Your SEO plugin's settings (Yoast SEO, Rank Math, SEOPress or All in One SEO) explain why the output looks the way it does. Most WordPress SEO problems trace back to one template or one toggle in there.

An SEO plugin's built-in audit is useful, but it reads the site from inside the database. Use it to fix things and use the crawl to find them.

Step 1: Make sure WordPress is not hiding the site

Go to Settings, then Reading and look at Search engine visibility. If "Discourage search engines from indexing this site" is ticked, WordPress adds a noindex, nofollow robots meta tag to every page. It is often ticked while a site is being built and is easy to forget at launch.

In a crawl, it shows as a noindex finding on every page at once. If you see that, clear the box before you look at anything else. The excluded by noindex tag post covers what happens in Search Console afterwards and how long recovery takes.

While you are here, check for a staging copy that Google has found. Search for site: followed by your staging hostname. A staging site cloned from production often has the box unticked and canonicals pointing at the live site. Crawling a staging site behind a login covers what to check on the staging copy itself.

Step 2: Read indexing in Search Console

In the Pages report, the "Why pages aren't indexed" table tells you where to look:

• Excluded by noindex tag on pages you want indexed points back to Step 1, or to a per-post noindex toggle in the SEO plugin.
• Discovered, currently not indexed on a large share of posts usually means Google sees too many low-value URLs (Step 4) or the site is too slow to crawl. See discovered, currently not indexed.
• Duplicate without user-selected canonical on WordPress is often a paginated archive, a ?replytocom comment link or an attachment page competing with the post it belongs to.
• Page with redirect after a permalink change is expected for the old URLs. It is only a problem if your sitemap or internal links still point at them.

Step 3: Check you have one sitemap, not two

WordPress has published its own sitemap at /wp-sitemap.xml since version 5.5. Yoast SEO, Rank Math and most other SEO plugins switch the core one off and publish their own, usually at /sitemap_index.xml.

Check three things:

1. Open both URLs. Only one should return a sitemap. If both do, a plugin conflict has left the core sitemap on, and Google may be reading two lists that disagree.
2. Look at which post types the sitemap includes. Tags, authors, attachments and custom post types from plugins (portfolio items, form entries, page builder templates) often end up listed when nobody asked for them.
3. Check that the sitemap URL in Search Console and in robots.txt is the one that works.

A crawler that reads the sitemap as well as the links will also show pages that are in the sitemap but not linked from anywhere, and linked pages missing from the sitemap. The XML sitemap validator checks a single sitemap file for free.

Step 4: Find the URLs WordPress made for you

This is the step that a general audit misses. WordPress creates an archive or a page for almost everything, and each one is a URL Google can crawl:

• Tag archives. A tag used on one post creates a page that lists one post. A site with 300 tags has 300 thin pages.
• Author archives. On a single-author blog, /author/name/ repeats the main blog index.
• Date archives. /2026/10/ pages duplicate the blog index sliced by month.
• Attachment pages. Every uploaded image can have its own page with nothing on it but the image. WordPress switched these off by default for new installs in version 6.4, but older sites keep them unless the SEO plugin redirects them to the file or the parent post.
• Paginated archives and comment pages. /page/2/ and /comment-page-2/ are normal, but they should carry their own self-canonical and should not be in the sitemap.

Sort the crawl by URL pattern and count each type. If tag, date and attachment URLs outnumber your posts, use the SEO plugin to noindex the thin archive types and redirect attachment pages. Keep category pages that represent real topics; see the FAQ below.

Step 5: Check permalinks and redirects

Under Settings, then Permalinks, a site on the Plain setting serves posts at /?p=123. These URLs tell a reader and a search engine nothing. Switching to Post name is the usual fix, but every old URL then needs a 301, and the default permalinks page explains how to do it without losing links.

Then look at redirects in the crawl:

• Chains. A post renamed twice redirects through two hops. WordPress tracks old slugs on its own, and redirect plugins add their own rules on top, so chains build up quietly. Point every internal link at the final URL. Redirect chains and loops covers finding and collapsing them.
• HTTP and www variants. After an HTTPS migration, old http:// links stay in post content because WordPress stores absolute URLs in the database. They still work through the redirect, but each one is an extra request for every crawler.

Step 6: Fix titles and meta descriptions at the template

Crawl the site and sort by title. On WordPress, title problems almost always come from a template rather than from individual posts:

• Duplicate titles across archives, because the SEO plugin's template for categories or paginated pages leaves out the page number or the term name.
• Two <title> tags on one page, when an older theme writes its own title and the SEO plugin writes another. Google picks one and you cannot predict which.
• Missing or duplicate meta descriptions, because the plugin's default description template is empty or repeats the site tagline.

Fix the template in the SEO plugin once, then re-crawl. The posts left over after that are the ones that need editing by hand. Fix duplicate titles and meta descriptions walks through both cases.

Step 7: Check images

Three checks, in order of impact:

• Width and height attributes. WordPress adds them to images inserted from the media library, but images from a page builder, pasted HTML or a theme setting often lack them, and the page jumps as they load, which counts against cumulative layout shift. See images missing width and height.
• Alt text. Missing alt text is common on sites where images were bulk-uploaded. The image alt text audit post covers which images need a description and when alt="" is correct for a decorative one.
• The uploads folder. Open /wp-content/uploads/ in a browser. If you see a list of files, anyone can browse every file ever uploaded, including ones never published. See open uploads directory listing.

Step 8: Measure speed on real templates

Run PageSpeed Insights on one page of each template: the homepage, a post, a category archive and, on a shop, a product page. WordPress speed problems are usually template-wide, so four tests tell you more than forty.

The two metrics WordPress sites most often fail:

• Largest Contentful Paint, often because the hero image is lazy-loaded by a theme or optimisation plugin. See largest contentful paint.
• Interaction to Next Paint, usually from plugin JavaScript loaded on every page whether it is used there or not. See interaction to next paint.

Look at the plugin list while you are here. Each plugin you can remove is code that no longer runs on every request.

Step 9: Close the security settings a crawl exposes

Two WordPress defaults are security issues rather than ranking factors, but they show up in a crawl, so they belong in the same report:

• XML-RPC. /xmlrpc.php answers on almost every install and is a common target for password-guessing and pingback abuse. Most sites do not use it. See disable xmlrpc.php.
• The generator tag. A <meta name="generator"> tag tells anyone the exact WordPress version. Removing it is free. See WordPress generator tag.

Neither one moves rankings. A hacked site does, and both are signals automated scanners use to choose targets.

Step 10: Check internal links and broken links

Last, the links. Look for:

• Broken internal links, usually to posts that were deleted or had their slug changed after the link was written. Find and fix broken links covers the process.
• Links in widgets, menus and footers. These repeat on every page, so one broken footer link becomes hundreds of findings. Fix it once in Appearance, then Menus or Widgets.
• Orphan posts, published but linked from nowhere except the sitemap. Add each one to a related post or a category page.

How Crawl Cove handles the WordPress part

Crawl Cove is a desktop crawler, so it fetches the live site from your own machine and runs the general checks on every site. When the pages it crawled show WordPress markers (a wp-content path or the generator tag), it also runs five WordPress checks. It sends a few extra GET requests, including /xmlrpc.php, /wp-content/uploads/ and /?p=1, and these follow robots.txt too. It never sends a POST. The results are the XML-RPC, generator, uploads listing, default permalinks and image dimension findings linked in the steps above, listed together on the WordPress issues page. A site that is not WordPress gets none of them.

For the title and meta description fixes in Step 6, the free Crawl Cove Connector plugin writes the values you approve in the app into Yoast SEO, Rank Math, SEOPress or All in One SEO. It has a dry-run mode and a one-click revert for every change.

Each crawl is saved as a separate run, so the next quarterly audit shows what is new, fixed and still open since the last one.