An SEO audit should end with a short list of fixes, in the order you’re going to make them.
Most audits end with a PDF instead.
There’s a health score out of 100 and a couple of hundred “issues” sorted by color where the site owner reads the first page, panics a little… and then nothing happens.
The SEO audit checklist below is the order I work in on WordPress sites.
I start with the business and with Search Console, because that’s where you find out which pages matter and what Google already thinks of them.
The crawler comes after that, then the WordPress dashboard itself, then speed, content, links and tracking.
By the end I usually have around ten things worth fixing, ranked, and a much longer list of things I’m happy to ignore.
The short version
- Start with the pages that make money and with what changed on the site recently. Every finding gets judged against those pages.
- Open Search Console before any crawler. It’s Google’s own data about your site, and it’s free.
- Crawl the site with Screaming Frog to see what’s there, then compare that with what Google has indexed.
- Spend real time in the WordPress dashboard. Settings, the SEO plugin, the plugin list and the theme are behind most WordPress-specific problems.
- Judge speed on real user data from the Core Web Vitals report, not on one PageSpeed score.
- When you check backlinks, look for the ones you’ve lost and ignore “toxic” scores.
- Make sure tracking works and the site hasn’t been hacked before you trust any of the numbers.
- Turn it all into a short fix list ranked by impact and effort, and ignore most of what audit tools flag.
What an SEO audit is (and what it isn’t)
An SEO audit is a check of everything that affects how a site shows up in search.
That covers whether Google can crawl and index it, whether the pages match what people search for, how the pages link to each other and what links point to the site from elsewhere.
The goal is to find what’s holding back the pages that bring in money and decide what to do about it.
And it isn’t a score, by any means. I don’t know why, but nearly every SEO audit tool gives you one, and scores are handy for spotting changes on the same site over time, but a site can score 95 and still lose traffic every month because its service pages target searches nobody makes.
Another site can score 60 because of a thousand missing alt texts on old blog images and be doing great. All a score tells you is how many boxes the tool could tick.
So in a way, that makes those scores completely useless.
By the way, for a couple of years a big part of my work was SEO due diligence on websites people were about to buy, and that kind of audit asks a very blunt question.
Is this traffic real, and will it still be there in a year? That habit stuck with me. I care a lot less about how many issues a site has and a lot more about which ones are actually costing it something.
The tools I use
You don’t need a big stack for this. I use five tools, and a small WordPress site can get through most of this checklist on free versions.
| Tool | What I use it for |
| Google Search Console | Clicks, impressions, indexing, manual actions, security issues and Core Web Vitals, straight from Google |
| SEO Gets | Search Console data with years of history and page-level trends that are quick to read |
| Screaming Frog SEO Spider | Crawling the site the way a search engine would |
| Ahrefs | Backlinks, competitors and the keywords the site ranks for |
| Claude, connected through MCP | Pulling data from the tools above, cross-checking it and drafting the fix list |
Search Console is the one I’d never skip, because it’s the only tool on that list showing Google’s actual data instead of an estimate.
SEO Gets sits on top of it. Search Console only keeps 16 months of data, while SEO Gets keeps up to five years, which matters a lot when you’re trying to work out whether a drop is seasonal or the start of something worse.
Screaming Frog is my crawler because it gives me the raw data without trying to turn it into a grade.
The free version crawls up to 500 URLs, which covers a lot of small business sites.
Ahrefs gives me the outside view, meaning who links to the site, what it ranks for and what competitors rank for that it doesn’t.
If you don’t pay for Ahrefs, Ahrefs Webmaster Tools gives you its Site Audit and Site Explorer for free on sites you can verify, with 5,000 crawl credits a month per project.
Claude is the newest part of the setup. I have it connected to Ahrefs, Search Console and WordPress, so I can ask it questions across all three at once instead of exporting spreadsheets and matching URLs by hand.
The checklist, in the order I run it
If you start with a crawler, you get a few hundred issues before you know which pages matter, and every one of them looks urgent.
If you start with the business and Search Console, you already know where to look by the time the crawl comes back.
1. Start with the business, not the site
Before I open any tool, I want to know what the site sells, which pages bring in leads or sales, and what changed recently.
The pages that make money are usually a short list. Service pages, product categories, the booking or contact page, maybe a handful of blog posts that actually convert.
Those are the pages every finding later gets measured against.
The “what changed” question saves more time than anything else in the audit. A redesign, a new theme, a move to a new host, a switch from Yoast to Rank Math, a batch of deleted posts, a new cookie banner.
Most sudden drops line up with something someone did to the site, and owners often don’t think to mention it because it didn’t feel like an SEO change at the time.
Access comes next, meaning Search Console, Google Analytics, the WordPress admin and ideally the hosting panel.
And I write down a baseline for the money pages, meaning their clicks, impressions, positions for their main searches and the leads they bring in, so there’s something to compare against once the fixes go live.
2. Open Search Console before any crawler
Search Console tells me what Google does with the site, which is worth more than what any tool guesses it might do.
I go through it in roughly this order.
- The Performance report over the longest range I can get, compared with the year before, then filtered down to the money pages. I’m looking at the shape of the line and where it changed.
- The Page indexing report. How many pages are indexed compared with how many the site should have, and which reasons show up under “not indexed.” A site with 80 real pages and 1,400 indexed URLs has a junk problem. A site where key pages sit under “Crawled, currently not indexed” has a quality or duplication problem.
- Manual actions and Security issues. Both are usually empty. When they aren’t, they go straight to the top of the fix list.
- Sitemaps, to see whether the submitted sitemap is the current one and whether Google can read it without errors.
This is where SEO Gets earns its place.
With years of data instead of 16 months, I can tell a seasonal dip from a real decline, and its view of growing and decaying pages shows me which pages have been sliding for a year.
That kind of slow slide almost never shows up in a site-wide chart, because other pages growing at the same time hide it.
3. Crawl the site with Screaming Frog
Once I know what Google sees, I crawl the site to see what’s actually there.
Screaming Frog follows every link the way a search engine would and gives me every URL with its status code, title, H1, canonical tag, indexability and the number of internal links pointing to it.
The first things I look for are pages returning 404 or server errors, redirect chains where one redirect leads to another, pages set to noindex that shouldn’t be, canonicals pointing somewhere unexpected, and missing or duplicate titles and H1s on pages that matter.
I connect Search Console and the XML sitemap to the crawl too, because that’s how you find orphan pages.
Those are pages that sit in the sitemap or get impressions in Google but have no internal links pointing at them.
Comparing the crawl with the Page indexing report is where it gets useful.
If Google has indexed URLs the crawler never found, something is generating pages that aren’t linked from anywhere, and on WordPress that’s usually archives, attachment pages, URL parameters or a plugin.
The full list of technical checks, from crawl budget to schema and AI crawlers, is in my technical SEO checklist for WordPress.
4. Go through the WordPress dashboard
This is the step most WordPress SEO audits skip, and it’s where a lot of WordPress problems live.
A crawler shows you the symptoms. The dashboard shows you the cause.
I start in Settings, then Reading, and check that “Discourage search engines from indexing this site” isn’t ticked.
Since WordPress 5.3, that box adds a noindex tag to the whole site, and it gets left on after a launch more often than anyone likes to admit.
Then Permalinks, because changing the structure on an established site creates a whole new set of URLs, and if it changed recently I want to see that every old URL redirects properly.
Next is the SEO plugin. Whether it’s Rank Math, Yoast or something else, I check what it does with tag, category, author and date archives and with attachment pages, and whether any of those end up in the sitemap.
WordPress 6.4 turned attachment pages off by default, but only for new installs.
Any site that existed before that update still has them unless someone switched them off, which means every image ever uploaded can have its own thin page.
After that I go through the plugin list, looking for two SEO plugins active at the same time (they fight over titles, canonicals and sitemaps), plugins that haven’t been updated in years, plugins nobody on the team can explain, and anything that adds pages or loads scripts across the whole site.
The theme and the page builder get the same look, because a heavy theme with a builder on top is behind a lot of what comes up in the speed step.
Last, I check whether a staging copy of the site exists and whether Google can reach it.
A public, indexable staging site is a full duplicate of the live one, and it can end up competing with it in search.
5. Check speed on real user data
Speed matters, but most people check it the wrong way.
The score at the top of a PageSpeed Insights report comes from a lab test of one page under one set of conditions.
The Core Web Vitals report in Search Console groups similar pages together and uses data from real Chrome users, so that’s what I look at first.
The three metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and Google’s targets for them are 2.5 seconds, 200 milliseconds and 0.1.
WordPress has a lot of room to improve here.
The 2025 Web Almanac found that only 45% of WordPress sites had good Core Web Vitals on mobile, compared with 74% for Wix and 85% for Duda.
The slow part is rarely WordPress itself, though. It’s the heavy theme, the page builder, the pile of plugins that each load their own scripts, and the cheap shared hosting underneath all of it.
So when a site fails, I look at server response time first, because no plugin fixes a slow host.
Then I look at everything loading on every page that doesn’t need to be there, like sliders, chat widgets, extra font files and builder scripts on pages that weren’t even built with the builder.
Speed on the money pages matters a lot more than speed on a three-year-old blog post, which is one more reason to know which pages those are.
6. Look hard at the pages that make money
Now I go back to the short list from step one and go through each page properly.
The first question is whether the page matches what people searching for its main keyword want.
I search the keyword, look at what ranks, and compare. If Google is showing category pages and comparison guides and the page is a short service blurb, no amount of title tag tweaking is going to fix that.
After intent come the basics.
Does the title say what the page is about, does the H1 match it, is the content easy to read on a phone, does the page answer the questions a buyer would obviously have, and does it make the next step clear?
I also check for cannibalization, which is two or more pages competing for the same search.
On WordPress it’s often a blog post and a service page, or a category archive and a post with nearly the same name.
You can see it in Search Console when you filter by a query and two or three of your URLs take turns showing up for it.
The page-level details, from titles and slugs to images and schema, are all in my on-page SEO checklist for WordPress.
7. Check how the money pages are linked
Internal links are how a site tells Google which pages matter.
On a lot of the WordPress sites I audit, the money pages are linked from the main menu and almost nowhere else, while blog posts pile up with no links between them and nothing pointing to the pages that sell something.
In the Screaming Frog crawl I look at how many internal links each money page gets, how many clicks it takes to reach it from the homepage, and which pages have no internal links at all.
An important page sitting four clicks deep with a handful of links, while a tag archive has hundreds, is worth fixing early. How I approach the fix is in my internal linking guide.
8. Decide what to do with content that’s dragging
Most WordPress sites that have had a blog for a few years have posts that get no traffic, posts that overlap, and posts that were accurate in 2019.
Each of them gets one of four decisions. Update it if the topic still matters and the page is close to ranking.
Merge it into a stronger post and redirect it if two posts cover the same thing. Redirect it if it’s thin and something better already exists.
Or leave it alone if it isn’t hurting anything.
What I don’t do is delete posts just because they’re old. Around the time CNET was deleting thousands of old articles in 2023 to look better to Google, Google’s Search Liaison posted that deleting content because Google supposedly doesn’t like old content is “not a thing!” Old isn’t the problem.
Thin, outdated and overlapping is. When a post does need rewriting, I follow the same process as in how I write SEO content.
9. Check the backlinks you’ve lost
In Ahrefs I check the referring domains trend over the last couple of years, which links were lost, and which pages on the site have backlinks but return a 404.
That last one is the quickest win in a lot of audits.
Pages that got deleted or moved during a redesign often still have links from other sites, and a 301 redirect to the closest live page brings that value back.
What I don’t spend time on is “toxic” link scores.
Google says most sites will not need the disavow tool, and that it’s only for sites with a lot of spammy or artificial links that have caused, or are likely to cause, a manual action.
Every site picks up junk links over time. Google ignores most of them, and so do I, unless Search Console shows a manual action.
If the site needs more good links rather than fewer bad ones, that’s a separate project, and I wrote about how to get backlinks that move rankings.
10. Make sure tracking works and the site is clean
Two quick checks before I trust any of the numbers.
First, is Google Analytics still firing on every page, and are key events like form submissions and purchases being recorded?
Redesigns, cookie banners and plugin updates break tracking all the time, and an audit built on broken data sends you chasing the wrong problems.
Second, has the site been hacked? On WordPress, plugins are where most of the risk sits.
Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, with 91% of them in plugins and 46% still unpatched when they were made public.
Hacked pages are easy to miss, because hackers often cloak them so the owner sees a normal site while Google sees spam.
I check the Security issues report, run a site: search for the domain, and look for indexed URLs nobody on the team recognizes.
The WordPress problems I find over and over
Audits on WordPress turn up the same handful of things again and again. These four show up on most of the sites I look at.
Junk URLs in the index. Tag archives, author archives, date archives, attachment pages and paginated archive pages that Google has indexed, each with a few lines of content or none at all.
A blog with 60 posts can easily produce a few hundred of these.
They rarely get a site in trouble on their own, but they waste crawling and hand Google a lot of low-value pages to judge the site by. The fix is usually a few settings in the SEO plugin.
Plugin and builder bloat. A theme that comes with its own builder, a second builder someone installed later, and thirty plugins, half of which load scripts on every page.
This is where failing Core Web Vitals on WordPress usually come from, and the fix is removing things.
A caching plugin helps, but it can’t make thirty plugins’ worth of scripts disappear.
Indexing mistakes. The “Discourage search engines” box left ticked after launch, a noindex left on pages from development, a staging site that Google found, or two SEO plugins both writing canonicals and robots tags.
These cause the sudden, scary drops, and they’re often a five-minute fix once someone spots them.
Weak internal linking. Money pages linked only from the menu, blog posts that never link to anything that sells, and orphan pages nobody can reach without the sitemap.
Some problems don’t come up on every site but are worth checking every time.
| Problem | Where it shows up | Usual fix |
| Hacked spam pages | Security issues report, site: search, strange URLs in the index | Clean the site, close the hole (often an outdated plugin), request a review |
| Broken URLs after a redesign or migration | 404s with backlinks in Ahrefs, redirect chains in Screaming Frog | Map every old URL to its new one with a single 301 |
| WooCommerce sorting, filter and add-to-cart URLs | Thousands of parameter URLs in the crawl and the Page indexing report | Keep them out of the index and out of crawlable links, as covered in the technical checklist |
| Duplicate schema | Two sets of Product or Article markup in the Rich Results Test | Turn schema off in either the theme or the SEO plugin |
| An old sitemap still submitted | Sitemap errors in Search Console, or a sitemap from a plugin that’s no longer active | Submit the current sitemap and remove the old one |
Turning it into a fix list
By this point I usually have a few dozen findings, and the easy move would be to hand all of them over in one long report sorted by the tool’s severity labels.
That’s how you end up with a developer spending a week on alt text while the main service page is still set to noindex.
A severity label only tells you how the tool rates that type of issue in general. It knows nothing about your site, your pages or where your money comes from.
So every finding gets judged on two things instead. How much it affects the pages that make money, and how much effort it takes to fix.
| Priority | What goes in it | Examples |
| Fix now | Anything stopping money pages from being indexed or found, plus security problems and manual actions | A noindex on a service page, the discourage box ticked, hacked pages, a money page returning 404 |
| Fix this month | Things holding the money pages back | Pages that don’t match search intent, weak internal links to them, failing Core Web Vitals on key templates, 404s that have backlinks, junk archives indexed |
| Fix when there’s time | Real issues on pages that matter less | Redirect chains, thin old posts, duplicate titles on minor pages |
| Ignore | Things tools flag that don’t change results | See the list below |
The ignore list matters as much as the rest of it. These are the things I leave out of almost every fix list.
- The overall health score from any audit tool.
- Missing meta descriptions on archives and old posts nobody visits.
- Text-to-HTML ratio warnings, and “low word count” flags on contact, cart and checkout pages that are supposed to be short.
- Toxic backlink scores.
- Missing alt text on every image in a blog post from 2017.
- “Multiple H1” warnings where the theme wraps the logo in an H1, unless it’s confusing what the page’s main heading is.
Every item also gets an owner. Some fixes are a setting the site owner can change in five minutes, some need a developer, and some need the host.
Writing down who does what is the difference between an audit that gets used and one that sits in a folder.
Once the fixes go live, indexing changes tend to show up in Search Console within weeks, and how long SEO takes covers what the months after that look like.
How often should you do an SEO audit?
A full audit once a year is enough for most WordPress sites.
On top of that, I’d run one any time something big changes, like a move to a new host or domain, a redesign or a new theme, a switch of SEO plugin or page builder, or a traffic drop nobody can explain.
Those are the moments when things break quietly.
Between audits, a monthly look at Search Console does most of the work.
Fifteen minutes on clicks, indexing and the money pages catches problems long before the next full audit would, and I laid out the exact routine in my guide on whether your SEO is working.
How long a full audit takes depends mostly on the size of the site. On a small business site it’s a few days of work.
A big WooCommerce store with thousands of products and filter URLs takes a lot longer, mostly because of the crawl and everything it drags up.
Where AI fits in my audits
AI is useful in an audit when it’s connected to real data, and close to useless when it isn’t.
I use Claude connected to Ahrefs, Search Console and WordPress through MCP, which is a standard way of letting an AI assistant use other tools directly, and Ahrefs has an MCP server for exactly this.
ChatGPT and Gemini can be set up in a similar way.
With that setup, it handles the parts of an audit that used to eat hours.
It can pull every page that lost clicks in the last six months, match them against the crawl and the backlink data, and tell me which ones lost links, which ones were changed, and which ones slipped for no visible reason.
It can read the SEO plugin’s settings in WordPress, go through a few hundred URLs looking for patterns that are hard to spot in a spreadsheet, and turn my notes into a first draft of the fix list.
What it can’t do is decide what matters. It doesn’t know that one service page brings in most of the leads, that the business is about to drop a product line, or that the traffic drop lines up with a redesign nobody mentioned.
And if you paste a URL into a chatbot with no data connected and ask it for an SEO audit, you get a generic checklist with your domain name in it.
So can ChatGPT do an SEO audit? It can do a lot of the data work once it’s connected to your data, but the judgment is still yours. I went into this more in my piece on using AI in SEO.
If you want more like this, I write a newsletter called Built to Rank. It’s occasional emails about WordPress and SEO from the work I’m doing, and it only goes out when I have something worth sending.
A couple more questions
Can I do my own SEO audit?
Yes. On a small site, everything in this checklist can be done with Search Console, the free version of Screaming Frog and Ahrefs Webmaster Tools.
Running the tools is the easy part. Deciding which findings matter is harder, and starting from the pages that make money takes care of most of that.
How much does an SEO audit cost?
Anywhere from free, if you do it yourself with the tools above, to tens of thousands of dollars for a big site.
A proper one-time audit or strategy project usually lands somewhere between $1,000 and $30,000, depending on how big the site is and how broken it is, and I broke down where that money goes in how much SEO costs.
What’s the difference between an SEO audit and a technical SEO audit?
A technical SEO audit only looks at whether search engines can crawl, render and index the site properly.
A full SEO audit includes that, plus content, search intent, internal links, backlinks and how the site performs for the searches that matter to the business. Steps two to five above cover most of the technical side.