Chapter 32: How to Do an SEO Audit

Last updated: November 1, 2026.

When people hear “SEO audit,” most of them picture a long list of errors:

• 500 404s
• 300 missing meta descriptions
• 120 duplicate titles
• 40 canonical issues

Then a report gets prepared, handed to the client, and the message is “You need to fix all of these.”

I think a good SEO audit is much more than that. The real goal is not to find as many errors as possible.

It is to find the problems that are actually holding the site’s growth back, put them in the right order, and then make sure they don’t break again.

Because not everything that technically looks like an error is equally important. Some things may not be a problem at all.

1. What is an SEO audit?

An SEO audit is a systematic analysis of a site’s current state from an SEO point of view. But you shouldn’t think of it as just a technical crawl.

A good audit should look at least at these areas:

• Technical SEO
• Crawling and indexing
• Site architecture
• Content
• Keyword targeting
• Internal linking
• Backlink profile
• Competitors
• User behavior
• Conversion
• Site performance
• Measurement setup

So an SEO audit is not just a “site errors” report. I think a more accurate definition is this:

Trying to understand what is holding back the site’s organic growth.

2. Start the audit from goals, not tools

Opening Screaming Frog and crawling the site is easy. Running Semrush Site Audit is easy too. But those shouldn’t be the first questions.

First you need to understand:

• What does the site sell?
• What is the target market?
• What is expected from SEO?
• Which are the main commercial pages?
• What are the most important products or services?
• What is the client’s problem?
• Do they want more traffic?
• Leads?
• Sales?
• Brand visibility?

Because the same error carries different weight on different sites. For example, a 404 problem can have one outcome on a news site, another on an e-commerce site, and another on a small corporate site.

3. I look at the data first

Before starting an audit, I’d like to have access to these sources if possible:

• Google Search Console
• Google Analytics
• Google Tag Manager
• Semrush or similar SEO tools
• Screaming Frog
• Sitemap
• robots.txt
• Server logs, if needed
• CRM or sales data

Because if we only look at the crawler, we see a technical snapshot of the site. But we can’t see how the site is actually performing.

For example, a category page that looks technically flawless may get no traffic at all. Or a page with a few technical gaps may be the site’s best-selling page. That difference matters.

4. What do I look at in Search Console?

Search Console is one of the most important sources for an audit. I especially look at:

• Organic click trend
• Impression trend
• Average position
• Branded / non-branded queries
• Strongest pages
• Declining pages
• Opportunities in positions 5–15
• Indexing problems
• The canonical Google selected
• Country and device differences
• Core Web Vitals

The basic question here is:

How does Google see the site right now?

5. What do I look at in Analytics?

Search Console shows the search side. Analytics helps us understand what happens after the user lands on the site. These matter most:

• Organic sessions
• Landing page performance
• Conversions
• Revenue
• Engagement
• Device differences
• Country differences
• User journey

A page may get a lot of traffic but produce no conversions. Another page may generate very high revenue on low traffic. If we don’t know this during the audit, we can prioritize the wrong things.

6. Technical crawl

This is where crawlers like Screaming Frog come in. Some of the things you can check:

• 3xx
• 4xx
• 5xx
• Canonical
• Noindex
• Title
• Meta description
• H1
• H2
• Internal links
• External links
• Orphan pages
• Redirect chains
• Redirect loops
• Images
• Alt text
• Page size
• Server response time
• Sitemap comparison

But again:

A crawler report is not an SEO audit.

The crawler shows us raw data. We decide whether it’s really a problem and how important it is.

7. We saw a 404. Is it an error right away?

No. If a URL was really removed and has no replacement, a 404 can be normal.

Instead of saying “There are 500 404s” in the audit report, you need to look at:

• Are there internal links to these URLs?
• Were they getting traffic?
• Do they have backlinks?
• Do they have a new equivalent?
• Are they in the sitemap?
• Are users still reaching them?

If it’s an old campaign page with no value, it can stay a 404. But if an important product page with strong backlinks has accidentally become a 404, that’s much more critical.

Same status code. Completely different priority.

8. Missing titles and meta descriptions

Tools love this. “Meta description missing on 1,200 pages.” Red warning.

But I don’t immediately write “1,200 meta descriptions need to be written” in the audit report. First, what are these pages?

• Are they noindex?
• Does the canonical point somewhere else?
• Do they get traffic?
• Are they commercial?
• Do we want them to appear in Google?

If half of the pages are worthless anyway, writing meta descriptions for them can be a waste of resources. So:

A list of errors and a list of actions are not the same thing.

9. Crawling and indexing analysis

Here I look at these questions:

• Can Google discover the important pages?
• Is the sitemap correct?
• Are there unnecessary URLs in the sitemap?
• Is robots.txt blocking the wrong areas?
• Is noindex used correctly?
• Are canonical signals consistent?
• Have “Crawled – currently not indexed” pages increased in Search Console?
• Is there a “Discovered – currently not indexed” problem?
• Are parameter URLs multiplying?
• Is there index bloat?

As we discussed in Chapter 25:

More indexed pages is not always better.

The goal of the audit is not to send Google more pages, but to send it the right pages.

10. Comparing the sitemap with the real URL structure

This is a very simple but useful check. For example:

• Sitemap: 20,000 URLs
• Crawler: 85,000 URLs
• Google knows: 120,000 URLs

That gap is telling us something. Where are the extra URLs coming from? Possible sources include:

• Filters
• Parameters
• UTMs
• Old URLs
• Archives
• Internal site search
• Tags
• HTTP / HTTPS
• www / non-www

This comparison is especially valuable on large sites.

11. Sometimes the sitemap looks fine but the problem is still in the sitemap

The news site example we mentioned in Chapter 2 fits perfectly here. Our problem was this:

New articles were getting indexed late in Google.

Screaming Frog wasn’t saying “The sitemap is broken.” Search Console wasn’t warning “The sitemap is cached for 10 minutes.” Technically, the sitemap loaded, the XML was valid and the server returned no errors.

But new article URLs were entering the sitemap about 10 minutes late. On a normal corporate site, 10 minutes may not matter much. On a news site, it does.

We didn’t find this error with a tool. First we saw the problem:

Why are the articles getting indexed late?

Then we analyzed the possibilities:

• How does Google discover the URL?
• When is the internal link created?
• When does the URL enter the sitemap?
• Is there a delay on the server side?
• Is there caching?

In the end we found that the sitemap was being cached. When we reduced the cache time to seconds, the late indexing problem largely went away.

I think this example explains what an SEO audit is really well.

A tool not showing an error doesn’t mean there is no problem.

12. Sometimes the starting point of an audit is not an error but a symptom

I find this distinction important. For example:

• Traffic dropped.
• Indexing got slower.
• Category visibility disappeared.
• Mobile conversions dropped.
• Google is choosing the wrong canonical.
• Traffic from one country suddenly fell.

These don’t tell us the cause. These are symptoms.

During an audit, the process sometimes goes like this:

Symptom → possibilities → data → test → cause → solution

SEO tools are very good at ready-made error lists. But for some problems in real projects, we need to ask “Why might this be happening?”

13. Site architecture

During an audit I don’t just look at individual pages. I also look at how the site is organized. For example:

• Are the main categories right?
• Do the subcategories make sense?
• How many clicks does it take the user to reach a product?
• Are important pages buried too deep?
• Are there breadcrumbs?
• Is the internal link network balanced?
• Are there orphan pages?
• Is the same topic scattered across multiple places?

Sometimes the problem isn’t the content.

It’s the architecture.

Google may find good content but not fully understand its importance within the site.

14. Internal link analysis

During an audit it’s very useful to look at:

• Which pages get the most internal links?
• Which important pages get very few internal links?
• Are internal link anchors meaningful?
• Are users being directed to related content?
• Are there orphan pages?
• Is the relationship between categories and products correct?
• Does blog content link to commercial pages?

As in the basketball shoe example in Chapter 31, content can get traffic. But if it doesn’t direct users to the product, it may not be doing its job commercially.

Technically the page works. Strategically it doesn’t. The audit should see this too.

15. Content analysis

Even if the technical side is fine, the site may not rank. Then you need to look at the content side. For example:

• Is the search intent right?
• Does the content answer the user’s question?
• Is it up to date?
• Are there very similar pages?
• Is there content overlap?
• What is the competitor doing better?
• Was the page written only for a keyword?
• Is there real experience?
• Does it help the user make a decision?
• Does the content lead to commercial pages?

I don’t just look at word count here. A very good 300-word page can be more valuable than a bad 3,000-word page.

16. Content decay

During an audit you need to look specifically at old content.

For example, if a “Best SEO Tools of 2023” page is still trying to get traffic, you need to review how current it is. You need to decide what happens to the content:

• Will it be updated?
• Will it be merged?
• Will it be redirected?
• Will it be removed?

Sometimes fixing old content brings faster results than writing new content.

17. Keyword cannibalization

Five very similar pages may be competing for the same query. For example:

• Best coffee machines
• Best home coffee machines
• Coffee machine recommendations for home
• Coffee machine advice

If they target the same search intent, you may need to re-evaluate the pages. Solutions like these can be considered:

• Merging
• Repositioning
• Canonical
• Internal links
• Redirects

18. Competitor analysis

Competitor analysis is an important part of an audit. But not in the sense of “Let’s do whatever the competitor does.”

I look at:

• Which queries is the competitor strong in?
• Which content types get traffic?
• What category structure do they have?
• Which of their pages get backlinks?
• Which topics are they better than us at?
• Which topics are we better at?
• What content gaps are there?
• What link gaps are there?

Sometimes the site has no major technical problems at all. The competitor is simply much stronger than us. That is also an audit finding.

19. Backlink analysis

Here I look at these areas:

• Referring domains
• Link quality
• Topical relevance
• Linked pages
• Anchor text
• Follow / nofollow
• New links
• Lost links
• Competitor link gap
• Suspicious links

But I don’t write “12,000 toxic backlinks found, disavow immediately” in an audit report.

As we discussed in Chapter 30, Toxic Score is not an official Google metric. The real risk needs to be evaluated separately.

20. Core Web Vitals and site performance

We covered this in detail in Chapter 24. During an audit you can review:

• LCP
• INP
• CLS
• TTFB
• Images
• JavaScript
• Third-party scripts
• Cache
• CDN

But again, the same rule: seeing a PageSpeed score of 72 doesn’t on its own mean “Big SEO problem.” Real user data, the importance of the page and the business impact should be evaluated together.

21. Mobile experience

Since Google uses the mobile version as the basis, the mobile side is critical. You can check:

• Is content missing on mobile?
• Are the internal links the same?
• Can users reach the menu?
• Do the buttons work?
• Does a pop-up cover the screen?
• Is checkout easy?
• Is mobile speed poor?
• Is structured data consistent?

We still come across sites that look great on desktop but have problems on mobile.

22. Structured data and schema

During an audit I also look at the schema side:

• Is the right schema being used?
• Are there errors?
• Does it match the information on the page?
• Are there missing fields?
• Does it pass the Rich Results Test?
• Does Google actually support this type?

But more schema is not success. The right structured data on the right page is what matters.

23. Additional checks for international sites

If it’s an international site, the audit gets a bit broader. In particular, these should be reviewed:

• Hreflang
• Language codes
• Country codes
• Reciprocal links
• x-default
• Relationship with canonicals
• Subfolder / subdomain
• Currency
• Content localization
• Performance by country

For example, if a wrong code like en-EN is a template error, it can affect thousands of pages at once.

24. The audit should also look at conversion

I think this is where I depart a bit from the classic SEO audit.

Everything may be technically correct. But situations like these can happen:

• The user can’t find the product
• The user can’t see the CTA
• The form is too long
• The phone number isn’t visible
• There’s no price information
• There’s no link to the product

In the client example I described earlier, traffic dropped by about 10% while revenue rose by about 180%. Because the goal wasn’t just to bring more users, but to direct the right users to the right product.

So for me, an audit doesn’t just look at the question “Can Google understand the site?” It also looks at the question “When users arrive, can they get to what we want them to do?”

25. The measurement setup needs to be part of the audit too

Sometimes a change that seems to have nothing to do with SEO can break measurement.

With one of our clients, we noticed that the Google Analytics code had been completely removed from the site. Normally you’d think, “Why would anyone delete the Analytics code?” But it happened. And until we noticed, we got no data. Worse, you can’t recover lost data afterward.

That’s why during an audit you also need to run checks like these:

• Is Google Analytics working?
• Is Google Tag Manager working?
• Are conversions being tracked?
• Are the basic events coming in?
• Are the Search Console connections correct?

SEO you can’t measure is much harder to manage.

26. Is the site up? Checking this once a month isn’t enough

An audit can be done monthly. But for some things, a monthly check isn’t enough. The most important of these is the site’s availability.

One of the first things we do when we start working with a client is add the site to a monitoring system like UptimeRobot. These systems check the site at set intervals. When the site doesn’t respond, they can alert you by email, SMS or push notification.

The site of a client we had recently started working with was down for about an hour.

We do SEO. We run Google Ads. We produce content. We work on backlinks. But if the site doesn’t load, none of that means anything in that moment.

Users come, and there’s no site. We spend money on ads, and there’s no site. Googlebot comes, and the server doesn’t respond.

That’s why some SEO checks shouldn’t be periodic. They should be monitored in real time.

I think there’s a simple order of priority here:

First the site has to work. Then we grow the site.

27. Continuous monitoring and a monthly audit are not the same thing

I think of these as two separate layers.

The first layer is continuous monitoring. For example:

• Is the site up?
• Is the server responding?
• Is there an SSL problem?
• Are critical services working?

Some of these you need to know within minutes.

The second layer is the periodic SEO audit. For example:

• Canonical structure
• Indexing
• Internal links
• Sitemap
• robots.txt
• Content
• Backlinks
• Core Web Vitals
• Analytics
• Conversions

We check these more thoroughly at regular intervals.

One is not an alternative to the other. You need both.

28. Build an impact list before an error list

The audit is done. We have 300 problems. Now the most important stage begins. Which one do we fix first?

I like to classify problems roughly like this:

• Critical
• High
• Medium
• Low

But you shouldn’t do this based only on the size of the technical error. Business impact matters too.

For example, if the site is completely down, that’s one of the highest priorities. If an important category has been set to noindex, that can also be critical. But missing meta descriptions on 20 old blog posts can be a much lower priority.

29. The impact x effort approach

This is one of the most useful methods after an audit. We can think about every task on two axes: impact and effort. You end up with four groups:

The first group is usually the quick wins.

For example, an important category isn’t getting indexed because of a wrong canonical. Fixing it takes 10 minutes. The potential impact is high. There’s no point in letting it wait.

30. Should every error be fixed?

No. I think this is one of the most important answers an audit gives.

A tool can produce 1,000 warnings. But 700 of them may be meaningless from a business point of view.

The quality of an SEO audit should be measured not by how many errors it finds, but by whether it can separate the errors that really matter.

31. Handing the client 5,000 errors is easy, picking the 10 important problems is hard

I think this is where the real value of an SEO specialist shows.

Exporting a crawler report and sending it to the client takes a few minutes. But being able to say “Out of these 5,000 errors, these 8 issues will have the biggest impact over the next three months” takes experience.

Because prioritization requires thinking about all of these together:

• SEO
• Business model
• User behavior
• Technical infrastructure
• Resources
• Competition

32. How should you assign tasks to developers?

Writing “Canonical is wrong” in an audit report isn’t enough. The developer needs to understand:

• What is the problem?
• Which URLs are affected?
• What is the expected behavior?
• What is the current behavior?
• How will we test it?
• What is its priority?

For example, a clear task like “On /product?color=x URLs, the canonical should point to the product URL without parameters” is more useful. If needed, sample URLs and the expected output should be provided too.

33. The client report and the developer report shouldn’t be the same

For the client, you need to explain the problem, its impact, its priority and the business outcome. The developer needs technical detail, URL examples, the expected result and a test method.

Showing the CEO a 200-row canonical table is unnecessary. Telling a developer “Let’s improve SEO” doesn’t work either.

The same audit can have different outputs for different audiences.

34. What should an audit report look like?

I think a good audit report can have this structure:

• Executive summary
• Current state
• The 5–10 most critical problems
• Technical SEO
• Content
• Site architecture
• Backlinks
• Competitors
• Conversion / user experience
• Measurement
• Prioritization
• Roadmap

But it doesn’t have to be a 150-page PDF. The purpose of the report is:

Not to show information, but to get action taken.

35. Every audit must end with a roadmap

The problems have been found. But if there’s no answer to the question “What do we do now?”, the audit is incomplete.

For example, a roadmap like this might come out of it:

Every project is different. But there has to be an order.

36. We do the SEO audit from scratch every month

Our approach here is a bit stricter. With our clients, we don’t do an SEO audit only when we start working together and then leave it.

We check everything again every month.

Because a website is a living system:

• New products are added.
• The theme gets updated.
• The software changes.
• A new category is opened.
• A script is added.
• Campaign codes come in.
• Cache settings change.
• A new deploy goes out.

And while fixing one thing, you can break something else you never expected. That’s why “We checked it last month” isn’t enough for me.

37. A fixed error can come back

We experienced this with a real client too.

We had a canonical problem. We found it. We fixed it. We checked it. Everything was working correctly.

Later, another update was made to the site. In our next checks, we saw that the same canonical error had reappeared.

If we had said “We already fixed that” and never checked again, it could have gone unnoticed for a long time.

In software development this is called a regression. The same logic applies in SEO.

A fix having been made doesn’t mean it will stay correct forever.

38. A monthly audit is partly an SEO regression test

That’s why during an audit we don’t only look for new errors. We also check whether the critical areas we fixed before are still working correctly. For example:

• Is the canonical still correct?
• Is the sitemap still correct?
• Has noindex ended up somewhere it shouldn’t?
• Is Analytics still working?
• Is GTM still on the page?
• Have any redirects broken?
• Have new 404s appeared?
• Are critical pages still returning 200?
• Has robots.txt changed?

We can think of this as a kind of SEO regression test.

39. The goal of an audit isn’t only to find new errors

Sometimes you do an audit and find no serious new problem. That’s not a bad audit. On the contrary, the result can be “Everything is still working correctly.” That’s valuable too.

Because noticing that the Analytics code was removed within a few days is not the same as noticing it three months later. Catching a canonical error on a few URLs is not the same as noticing it after it has spread to thousands of URLs.

40. Trying to fix everything at once

This is one of the big mistakes made during audits.

500 tasks come out. All of them get added to Jira. The development team looks: “Are all of these urgent?” Result: none of them get done.

I think a better approach is: fix the critical problems first. Measure the result. Then continue.

In SEO, fewer tasks sometimes produce more results.

41. Looking only at technical SEO

This is another big mistake.

The site may be technically perfect. But it may still not rank if:

• The content is bad
• The product is weak
• The search intent is wrong
• The brand is unknown
• There are no backlinks
• There are no conversions

That’s why you shouldn’t treat a technical audit and an SEO audit as the same thing. Technical analysis is only one part of the audit.

42. Not reviewing competitors

The site may look very good on its own. But we don’t compete alone on Google. The competitor:

• May have produced 10 times more content.
• May have a much stronger backlink profile.
• May be meeting user intent better.
• May offer a better product.
• May have much higher brand demand.

By the end of the audit, you need to answer not only “What’s wrong with us?” but also “What is the competitor doing better than us?”

43. Delivering the report and walking away

I think this is the worst audit model.

An SEO audit gets prepared. 150 pages. It’s presented in a meeting. It’s uploaded to Google Drive. Then nobody opens it. Six months later, a new audit is requested.

For an audit to be valuable, this information should be tracked for each task:

• Owner
• Priority
• Due date
• Status
• Outcome

I think what matters more than the audit report is:

Project management after the audit.

That’s exactly what we’ll talk about in the next chapter (33).

44. What do I want to see at the end of an audit?

In its shortest form, answers to these questions:

• Is the site working right now?
• Are the measurement systems working correctly?
• What is the site’s biggest SEO problem?
• What is its biggest opportunity?
• What do we fix first?
• How will we measure its impact?
• What do we do after that?

If there are no answers to these, the audit can still be incomplete, however detailed it is.

To sum up

The goal of an SEO audit is not to turn every red warning green. Its goal is:

To find the problems blocking organic growth, put them in order of importance and regularly verify that the system is still working correctly.

Sometimes the problem isn’t 10,000 missing meta descriptions. It could be a single wrong canonical. It could be a deleted Analytics code. It could be the sitemap being cached for 10 minutes. It could be an error you fixed last month reappearing after another update.

Or the most basic problem is this:

The site doesn’t load.

Even if you spend millions of lira a month on SEO and ads, if users can’t reach the site, that’s the problem you need to solve first.

That’s why some checks are done monthly. Others need to be monitored 24/7.

And for some problems, no tool will tell you directly “The problem is here.” Sometimes we have to start from the symptom and find the cause.

I think this is exactly where the real value of an SEO audit shows.

Not in finding errors, but in finding the right problem.

And maybe even more important:

In making sure that what we fixed yesterday is still working correctly today.

Previous: Chapter 31: How Do We Measure SEO Success? · Contents · Next: Chapter 33: How to Run a Real SEO Project

This chapter was first published in Turkish on X (October 8, 2026).