WordPress SEO audit checklist: what to check, in order, and how to check each item

This is the technical SEO audit of a WordPress site, as a list you can work through yourself. Each item says what to check, where to look and what a pass is, and links to the page that fixes it. Every item rests on something Google or WordPress documents.

The order is deliberate. Google names three technical requirements for a page to be eligible for its index: Googlebot is not blocked, the page answers with an HTTP 200, and the page has indexable content. The first section tests those, because one setting there can shut out every page.

Google's page on hiring help says an audit "should be about giving you realistic estimates of improvement, and an estimate of the work involved". This list finds what stands in a search engine's way and stops there. You need a browser, an administrator login and, for several checks, a verified Search Console property.

1. Can Google reach the site at all

• "Discourage search engines from indexing this site" is unticked. It is under Settings, then Reading, in the row "Search engine visibility". While it is ticked, WordPress puts a noindex robots tag on every page and switches its sitemap off, and nothing on the front of the site shows it. See what the box does and how to turn it off.
• robots.txt blocks nothing you want found. Open /robots.txt. With no such file on the server, WordPress answers the address itself, with rules that keep crawlers out of /wp-admin/ and a Sitemap line. A pass is no Disallow rule that covers a public page. The robots.txt tester tries one address against the rules. See where robots.txt is.
• No page you want found carries a noindex. It can sit in the page's source or in a header the server sends. The page indexing check reads both from outside, with the page's status. Run it on the home page, a post, a page and a category. A pass is a 200 and no noindex.
• No page is hidden with robots.txt alone. Google calls robots.txt "not a mechanism for keeping a web page out of Google". A blocked crawler never sees a noindex on the page, so the page "can still appear in search results".
• No coming soon or maintenance page is still on. Open the site in a private window, where you are not logged in. A pass is the real pages. See coming soon pages and search.
• A staging copy asks for a password. WordPress's documentation says of the box above that "it is up to search engines to honor your request", and Google's advice for keeping a page out is to "block indexing with noindex or password-protect the page". See a staging site indexed in Google.

2. One address for each page

Google treats a redirect and a rel="canonical" link each as a strong signal of which address to list. It requires neither, and picks an address itself where a site names none.

• The four forms of the home address end at one. Enter http:// and https://, each with and without www, in the redirect checker. A pass is three of them reaching the fourth, which is the "Site Address (URL)" under Settings, then General. Google advises redirecting the other forms to one preferred address, and prefers HTTPS over equivalent HTTP. See www or non-www.
• Each redirect arrives in one hop. The checker lists every hop. Google's guide to moving a site advises "redirecting to the final destination directly". A request sent from http to https, then to www, then to the trailing slash, takes three hops. See how to set up redirects.
• The trailing slash goes one way. Ask for a post with and without its final slash. With "Post name" permalinks, WordPress redirects the form without the slash to the form with it. A pass is one form answering 200 and the other redirecting to it.
• Each post and page names itself as canonical. WordPress prints a rel="canonical" link on posts, pages and a static home page, and none on archives, search results or a home page that lists the latest posts. The page indexing check shows the address a page names as its own. A pass is the page's own address, in the form the redirects end at. A missing canonical on an archive is not a fault.

3. The sitemap

• You know which sitemap the site has. WordPress makes its own at /wp-sitemap.xml, and an SEO plugin that makes a sitemap can switch WordPress's off, as Yoast SEO's changelog records. The Sitemap line in /robots.txt names the one in use. The sitemap checker finds it and reads it.
• It answers and lists what it should. A pass is a 200, addresses in the form section 2 settled on, and nothing you would not want found. Google asks for "the URLs in your sitemap that you want to see in Google's search results". If it answers 404, see the guide to wp-sitemap.xml.
• Search Console has it, once. Submit the one address in the Sitemaps report. Google's help gives the status of the last read as "Success", "Couldn't fetch" or "Sitemap had X errors". Your report may word these differently. Google calls a submitted sitemap "merely a hint".

4. Pages that should not be in the index

Google's help for the Page indexing report says: "Don't expect every URL on your site to be indexed." These are the WordPress addresses it fits.

• Attachment pages are off. These are the pages WordPress made for every uploaded file. Since WordPress 6.4 a new site has them off, and a site upgraded from an earlier version still has them on. To check, open an image in the Media Library. The link in its details reads "View media file" when they are off and "View attachment page" when they are on. See attachment pages in Google.
• Internal search results carry noindex. WordPress has added it to its search result pages since version 5.7. Run a search address from your own site, such as /?s=test, through the page indexing check. A pass is a noindex. See WordPress search pages in Google.
• Each archive in the sitemap is a page you want found. WordPress's sitemap lists categories, tags and author archives. On a site with one author, that author's archive holds the same posts as the blog's own list. Google's help calls it fine for a duplicate not to be indexed, so this is a choice, not a fault.
• On a store, the filter and sort addresses are accounted for. WooCommerce answers at extra addresses for one list of products, such as ?orderby= and ?filter_. See WooCommerce filter URLs in Google.

5. What each page says about itself

What WordPress prints with no plugin has the whole inventory.

• Every page has a title of its own. Google asks that every page have a <title> element with "descriptive and concise" text that does not repeat from page to page. WordPress builds it from the page's own title and the "Site Title". To check, read the browser's tab on several pages.
• A missing description is not a fault. WordPress prints no meta description, and a plugin adds the field. Google "primarily uses the content on the page" to write the snippet, and may use the description when it describes the page better.
• Headings serve the reader. Google's Starter Guide says headings in semantic order are "fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order", and that no number of them is ideal. A second h1 is therefore not a search fault. Check the headings for the people who move through a page by them.
• Images that carry meaning have alt text. Google says alt text "helps search engines understand what your image is about". In WordPress it is the "Alternative Text" field in the Media Library.
• Structured data matches the page. WordPress prints none by itself. A plugin or a theme adds it. Run a page through Google's Rich Results Test. A pass is no errors, and everything the markup states can be read on the page: Google's guidelines say not to mark up content that is not visible to readers.

6. Old addresses

This section applies after anything that changed addresses: a redesign that renamed pages, a change of permalinks or a move to https.

• You have a list of the old addresses. An old sitemap has them. So does the "Pages" tab of the Performance report in Search Console, with the date range set to before the change.
• Each old address reaches its replacement with one 301. Run them through the redirect checker. Google's guide to moving a site asks for a mapping from each old address to its new one and for permanent redirects, such as 301 and 308. WordPress forwards a post whose slug was changed. It does not forward a page's old slug, and it keeps no record of a permalink structure you leave. See how to change permalinks safely.
• An address with nothing to replace it answers 404 or 410. Google says to return one of those for content that was not moved, and not to redirect many old addresses to one irrelevant destination such as the home page, which "might be treated as a soft 404 error".

If visits fell after the change, see traffic dropped after a redesign. Before the next one, use the redesign SEO checklist.

7. Speed and mobile, as far as Google documents them

• Core Web Vitals are read from the field. Google's page on page experience says: "Core Web Vitals are used by our ranking systems." Its Core Web Vitals page asks for LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. To check, open the Core Web Vitals report in Search Console, which is built from real-world usage data. The page experience page adds that "trying to get a perfect score just for SEO reasons may not be the best use of your time". See how to speed up WordPress.
• The phone gets the whole page. "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." To check, open your main pages on a phone. A pass is the same text, images and links a wide screen gets.
• Pages are served over https. Google's page experience self-assessment asks it. Google adds that aspects other than Core Web Vitals do not directly help a page rank, so check it for your visitors' sake.

8. What Search Console itself reports

The Page indexing report shows the indexing status of every address Google knows about in your property. Google's help says what to look for: whether your important pages are indexed, and whether the rest are left out for good reasons. Open the table "Why pages aren't indexed" and read each row against this list. The names below are from Google's help page on the day this was written. Your report may word them differently.

For one page, the URL Inspection tool shows the "User-declared canonical" and the "Google-selected canonical". Where the two differ, go back to section 2.

The Performance report shows clicks, impressions, click-through rate and average position, by default for the past three months. In an audit, read its "Pages" tab for a page that matters and has no impressions, and its chart for a fall that begins on the day something on the site changed.

9. A store, a local business, or AI assistants

• A store. Product pages carry price, stock and review data that this list does not cover. The WooCommerce SEO page lists the store guides, and the product data check reads one product page.
• A local business. Work through the local SEO checklist as well.
• AI assistants. The AI crawler access check shows what your robots.txt tells each AI crawler by name. For Bing's own reports, see Bing Webmaster Tools on WordPress.

10. What is not on this list, and why

• A tool's "SEO score". Google says it "doesn't evaluate or endorse third-party SEO tools, and these tools don't have access to Google's internal ranking data".
• Keyword density, the keywords meta tag and a word count. Google's Starter Guide gives no figure for how often a word should appear, and names repeating the same words as keyword stuffing, which is against Google's spam policies. It also says "Google Search doesn't use the keywords meta tag" and "there's no magical word count target".
• Submitting the site to directories. Google's spam policies give "Low-quality directory or bookmark site links" as an example of link spam.
• Buying links. The same policies give "Buying or selling links for ranking purposes" as their first example.

WP Ministry's WordPress SEO audit works through this list as a one-time job: a written report in which each finding names the documentation it rests on, the fixes on the WordPress side done, and each fix tested again.