SEO Audit: How I Audit a Website Step by Step

An SEO audit is a decision about what to fix first on a site, with evidence behind every recommendation and a way to check it after implementation. A list of errors from a tool is only material for an audit. A technical audit is the part of it that checks whether the bots of search engines and AI assistants can fetch and read the site, and whether a search engine can index it.

I do an audit in eight steps:

1. I establish the goal and the situation of the site before I run a crawler, that is, a program that walks through a site the way a search engine bot does.
2. I check whether bots get the site at all.
3. I collect data from several sources and check what each of them does not see.
4. I research keywords and Google results before I deal with the technical side.
5. I go through the site against a catalog of issues with priority conditions.
6. I show evidence for every issue.
7. I set the order, the effort and the variants.
8. I hand the result to a cross-check, and after implementation I verify every issue.

What is an SEO audit, and how does a technical SEO audit differ?

An SEO audit says what state a site is in and what limits its visibility, while a technical audit checks whether a search engine can fetch, render and index the site. In a full audit I check the technology, the architecture and the content on the pages, the keywords, external links and the competition, and at the end I lay out the order of actions. A technical audit is enough when the question is technical: a drop after a deployment, a migration, pages falling out of the index.

An audit is the input to a strategy, not a strategy. A strategy says what demand you compete for and what you give up, and an audit says what stands in the way today. In the post on SEO strategy I described how one turns into the other.

How do you do an SEO audit step by step?

The order of the steps matters, because the earlier steps decide whether the numbers from the later ones can be trusted. In two places I stop the process for a decision: after the first step I set the scope, and after the cross-check, before sending to the client, I check the priorities and the theses.

Step 1. The goal and the situation of the site, before I run a crawler

The first question is whether the site is losing traffic or not building it, because the whole audit depends on the answer. A site with no visibility first needs a map of keywords and of the pages that are to answer them. A site that has visibility first needs protection for what already holds positions, before anyone starts improving it.

Before the start I ask about things that no tool will show. Which products or services earn money, whether a change of content management system or a redesign is planned, who will implement the recommendations and how much time they have. The answers set the scope of the audit and the list of things I do not write up, because nobody would implement them.

You have to go through this stage yourself, although many specialists hand it to a language model today. A language model can be helpful, but it will not understand the client's business. Nor will it bring the creative, unique perspective that an experienced SEO specialist has.

Step 2. Whether bots get the site at all

Before I read any number from a tool, I check whether the server lets bots in, because a blocked bot produces data that looks like SEO problems. In one week of July 2026 three “SEO problems” on three different sites turned out to be blocks of bots:

1. A site “lost” more than 2,200 links, because the pages that linked to it sat behind a firewall that turned away the bot of the link analysis tool.
2. A store had a site health score of 0 in a tool with almost 42 thousand errors, because instead of pages the tool's bot received Cloudflare firewall responses.
3. On the third site a block stopped the crawler at the first URL, and for three weeks nobody noticed.

I fetch the same URL as an ordinary browser and as the bots of Google, Bing, OpenAI, Perplexity and Anthropic, and then compare the response codes and the page size. A difference between a browser and a bot is the first thing to explain before I start counting anything. Such a test sends requests from my IP address under a bot's name, and firewalls recognize real Google and Bing bots by the address they come from. A block of “Googlebot” in the test therefore does not prove a block of the real Googlebot. Search Console, Google's free panel for site owners, shows how the real Googlebot sees the site.

I read the robots.txt file to the end with a parser, that is, a program that applies the rules the way a bot does, not by eye. Google's bot applies only one group of rules, the one with the best-matching bot name, and ignores the others. A Disallow: rule with no path blocks nothing (Google Search Central). In August 2026 a fragment of one site's robots.txt suggested that it blocks Google. The parser showed that Googlebot had full access and that the bots of Bing and AI assistants were the ones blocked. The diagnosis was therefore different: the problem concerned Bing and AI bots, not Google.

A missing robots.txt file does not block Google, but after every deployment I check that the file has not disappeared. Google treats a 4xx error on robots.txt (other than 429) as if the file did not exist, that is, with no restrictions (Google Search Central). My own site returned a 404 error on robots.txt in August 2026, before I fixed it.

Step 3. Data from several sources and what each does not see

Every number from a crawler is a hypothesis until a second source confirms it. I collect a crawl with and without JavaScript and speed data from real users from the CrUX report. I add the link profile and the Google results for important keywords from the day of measurement. In the post on link building I described how I check the link profile before planning a campaign. For every file I record the source, the date and the scope, so that a month later every number can be reproduced.

I pull Search Console data through the API, that is, an interface for downloading data automatically, because the export from the panel cuts the list to 1,000 rows. The API returns up to 50 thousand rows a day per result type, for example separately for web, image and video results (Google, Search Console Help). In the post on AI tools for SEO I showed how a truncated export inflated the CTR on one site.

A crawler can understate the size of a site, so I check the number of pages and products in a second source. In two stores the crawler reached the first page of the product list in a category and went no further, although the next pages of the list worked and were not blocked. In one store it found fewer than half of the products, in the other fewer than a third. Had I given these numbers as the state of the stores, the audit would have described gaps in the offer that did not exist.

I describe sudden changes in daily data before I assign a cause to them. I do this for clicks, impressions, positions, sessions and Googlebot requests. I look for days from which the median of the next seven days differs by at least 25% from the median of the fourteen days before. For every such date I write down an explanation: a deployment, a Google update, an outage, a change in measurement, or “cause unknown”. Describing the dates gives hypotheses, and I name a cause only after checking the other possible explanations.

Step 4. Keywords and Google results before the technical side

First I look for opportunities, then I fix errors. Some technical problems can be assessed only against keywords: whether a filter in a store should be indexed, whether a tag deserves its own page, whether two pages really compete for the same thing. In the catalog, 32 issue types are marked as impossible to assess without an analysis of keywords and Google results.

A missing page for an important keyword is one of the more frequent problems in my audits: 15 of 63 audits, 14 of 50 sites. A crawler will not report it on its own, because it fetches only the pages that exist. It becomes visible only when I put demand next to the list of URLs and next to which competitors' pages appear in the results.

Step 5. A review against the catalog with priority conditions

The same error has a high or a low priority depending on where it occurs. An internal link to a URL with a redirect in a template that repeats on thousands of pages has a high priority. The same link in the body of a single post has a medium priority, and in archived posts a low one.

Every issue type in the catalog has a detection rule, a reporting condition, a required piece of evidence, a priority with conditions and a way to check after implementation. Of the 256 types, 86 start the priority rule with “high”, but almost always with a condition: when the keyword has demand, when the page has traffic, when the error is in a template.

That is why a site health score from a tool does not set priorities. A tool counts errors, not the traffic that depends on them. A recommendation about pages with unknown traffic does not get a high priority until I check the data.

Step 6. Evidence for every issue

An issue without evidence stays in the audit as “to be verified”, not as a recommendation. The evidence is a screenshot of the place in the code, or the HTML from the server next to the version after JavaScript runs. It can also be a chart from Search Console or a speed measurement with the name of the element that spoils it. An element that worsens loading or shifts the layout of the page I name as the measurement points to it, not as suits my hypothesis.

I describe every issue in four parts, from the problem to checking the fix. I write what the problem is, why it hurts and what it affects, how to fix it step by step, and how we will check that the fix worked. I copy the code to be fixed from the site verbatim, so that the developer sees exactly the place to change.

This is a short version of one report about links to redirects:

• Problem: links in the menu lead to URLs without a trailing slash, which redirect to the version with a slash.
• Why it hurts: the menu is on every page, so every click and every bot fetch goes through an extra redirect. In tool reports, thousands of such links make it harder to find more important errors.
• Fix: in the menu template, replace the URLs with the target ones, with a code fragment before and after the change.
• Check: after implementation a crawl shows no links to redirecting URLs in the template.

Step 7. Order, effort and variants

The result of an audit is an order, not a number of findings. At the start of the document there is a table of all the issues with priority and effort. I describe effort in four categories: a few hours, a day or two, a week, or a whole project. A team with fewer resources gets a minimal variant next to the full one, with a clear description of what it loses by taking the shorter route.

Implementation follows the audit exactly. If a cheaper variant appears when the implementation is quoted, the client chooses it and I record that explicitly, instead of swapping the recommendation behind their back.

Step 8. Cross-check and verification after implementation

Before an audit reaches the client, someone who did not write it checks it. I do two rounds of checking: the first on the whole document, the second only on what changed after the first. The check recalculates the numbers from scratch and looks for theses that cannot be defended with evidence. At the end I check the priorities and theses that depend on the client's situation myself.

After implementation I check every issue on the live site and mark it as implemented correctly, partly or not implemented. This check is included in the price of the audit. Without this step an audit ends with a document, not with a change on the site.

What do I check in a technical SEO audit?

In a technical audit I go through a dozen or so areas, and I report problems most often in redirects, site architecture and content. The last column shows in how many of the 63 audits in the archive the author reported at least one problem in a given area. The “What I check” column gives examples, not the full scope of an area. The table shows selected areas, and the catalog splits the problems into 22.

A rarely reported problem need not be a rare one. Speed and JavaScript have few reports in this table, but the audits in the archive had different scopes. A low number of reports therefore does not say how often these problems occur on sites.

How do I check how a site is indexed?

I check indexing on three lists: what is in the sitemap, what Google has indexed and what a crawler finds through links. A mismatch between these three lists shows a problem better than any one of them alone. A sitemap with URLs that return a redirect, an error or are excluded from the index was reported in 20 of 63 audits, in 18 of 50 sites. For single URLs I use URL inspection in Search Console, which also shows the page after JavaScript runs.

Do Core Web Vitals affect rankings?

Core Web Vitals are part of Google's ranking systems, but they do not beat relevance of content. Google says plainly that its ranking systems use Core Web Vitals. It also says that it always tries to show the most relevant content, even when the page experience is poor (Google Search Central). In an audit I use data from real users from the CrUX report, not a single test in a lab tool. Where Google has such data for individual types of pages, I give it separately. I describe the gaps in this data in the audit. Since March 12, 2024, the measure of responsiveness is INP, which replaced FID (web.dev).

What issues do I find most often in SEO audits?

The most frequent errors are housekeeping ones, that is, those that tools detect easily: links to redirects and to 404 errors, sitemaps with wrong URLs and duplicate page titles and descriptions. Internal links to URLs with a redirect appeared in 24 of 63 audits, in 20 of 50 sites. Tools detect them well, and the cost of fixing depends on the template and the site's system.

Less frequently reported structural problems can affect traffic more than housekeeping errors. A missing page for an important keyword was reported in 15 of 63 audits, and so was a blog that does not link to offer and category pages. The catalog gives a missing page a high priority when the keyword has demand and competitors hold positions with separate pages. A blog without links gets a high priority when the target pages have traffic or revenue and the blog has authority. I check these conditions on data before I assign a priority.

• 938findings in 63 audits across 50 sites, from which I built a catalog of 256 issue typesAudit archive 2020-2026, catalog of October 11, 2026
• 38%of audits with internal links to URLs with a redirect, the most frequently reported problem in the archive (24 of 63)Catalog of October 11, 2026
• 15 of 63audits with a missing page for an important keyword, which a crawler will not report on its ownCatalog of October 11, 2026
• 14types of recommendations that the catalog marks today as outdated, and another 30 as changed practiceCatalog of October 11, 2026

What has changed in SEO audits since 2020?

In the audits of 2023-2026 structured data and pagination appear more often than in 2020-2022, and redirects, canonical URLs and indexing less often. Structured data problems were reported in 23 of 33 newer audits against 16 of 30 older ones. Redirects and response codes: 23 of 33 against 27 of 30. Blocks of AI bots appear only in audits from 2026. The year of an audit is the date of the file in the archive, so not always the year the work was done.

The decline does not prove that problems with redirects have disappeared. The mix of audits changed: the newer ones more often concerned structured data, content and visibility in AI, and the way of working changed too. What this chart shows is what the audits dealt with, not how sites in Poland changed.

Which SEO recommendations are outdated today?

Some recommendations still appear in audits and guides, although they are not worth implementing today. Some of them worked a few years ago, and others Google has discouraged or ignored for a long time. In the table, for each practice, I give the reason and what to do instead.

Sources for the table: Google on pagination, Google on five mistakes with rel=canonical, Google on FAQ and HowTo results, Matt Cutts on nofollow and the distribution of link power, John Mueller on redirects to the home page, via Search Engine Roundtable, Google on robots.txt, Google on unsupported rules in robots.txt, Google on sitemaps, Google on the lastmod, changefreq and priority fields, web.dev on INP, Google on the search box in results.

That is why every recommendation in my catalog has a currency field with a justification. The catalog marks 14 types of recommendations as outdated and 30 as changed practice today. A recommendation that was correct a few years ago will not make it into an audit just because it once worked.

How do you check AI bot access in an audit?

I check AI bot access in the same step as Googlebot access, because the same firewall or CDN setting can block them. A CDN is a network of intermediary servers, for example Cloudflare. In September 2026 I checked 12 of my clients' domains that run behind Cloudflare. The robots.txt file alone showed:

• 3 domains blocked the same set of seven bots that collect data to train models, with an identical list of names. An identical list suggests a common source, for example a ready-made setting in the Cloudflare panel. This setting cannot be seen from outside, so it has to be confirmed in the panel itself.
• 1 domain blocked the bots that fetch pages for the answers of ChatGPT, Perplexity and Claude. It did not do so explicitly, but with a general rule for all bots not named. The same domain showed GPTBot a security page without a noindex tag, which excludes a page from the index. Had an indexing bot received such a page, the block page could have ended up in the index instead of the content.
• 8 domains had no blocks in robots.txt.

You decide separately about the bots that fetch pages for answers and the bots that collect data for training. In the post on AI SEO and GEO I described how to tell them apart. Since August 31, 2026 there is also a separate setting in Search Console that excludes a site from AI Overviews, AI Mode and generative features in Discover. According to Google it does not affect the rest of search results (Search Console Help). I check such a setting in an audit the same way as robots.txt, because someone may have switched it on without the knowledge of the person responsible for SEO. Whether the brand appears in answers once access is open is a separate measurement, which I described in the post on brand visibility in AI.

A test from a single IP address shows only part of the picture, and can itself raise a false alarm. In the same review a series of requests reported a block after a limit was exceeded on two domains. That block was triggered by my own earlier requests. A check a few minutes later, with a single bot identifier and single requests, gave five and seven correct responses in a row. Without that check, two clients would have been told about a block that did not exist. Only server logs show whether ChatGPT actually fetches the site. In the post on the llms.txt file I show what can be seen in my site's logs.

A 200 code does not mean the bot received the content. For one client with a JavaScript application, Googlebot and Bingbot received pre-rendered HTML from a prerendering service, while AI assistants' bots received an empty page. The service recognized bots by name and did not have AI bots on its list. My test gave the result “fine”, because it measured the response code, not the content. Since then I compare the content a bot receives with the content after JavaScript runs in a browser.

Is a free SEO audit enough?

A free tool will show a list of errors, but the report alone does not tell you which of them cost you traffic. For the Polish keyword “audyt seo” (“SEO audit”), 7 of 9 organic results on the first page of Polish Google are tools or offers of a free audit (results of October 17, 2026). Such a report counts errors by the tool's rules, not by how much traffic and revenue depend on them. You also have to check that the result does not come from a bot block, as in the case of the store with a health score of 0.

You can do a lot for free if you know where to look. Search Console shows Google's data on indexing, Core Web Vitals and the page after JavaScript runs. The free version of Screaming Frog crawls up to 500 URLs in one crawl (Screaming Frog), which is enough for a small company site. An audit with a consultant makes sense when an error costs a lot (a migration, a traffic drop, a large store) or when you do not have time to put the data together and assess it.

Can ChatGPT do an SEO audit?

ChatGPT or another AI model will not do a full audit on its own, because it does not see a site the way a search engine bot does. It usually sees it through a tool that fetches the page and turns it into text. A model will read the data you give it and suggest what to check. A fetching tool can, however, lose part of a page: in September 2026 I found that the page fetching tool in Claude Code cuts out structured data when it turns a page into text. The model answered that the information was not there, although it was in the markup on the same page. An audit done this way would have reported a lack of structured data that is not missing. In my process AI is a tool, above all for aggregating data from the crawl, Search Console and other sources. I set the scope, the assessment and the priorities myself.

How much does an SEO audit cost?

I bill an audit like a consultation: EUR 70 net per hour of work, with a cap on hours set before the start. The number of hours depends on what has to be checked:

• a diagnostic audit, that is, one or two specific problems (a drop, a migration, indexing), is usually 10-16 hours, that is, EUR 700-1,120 net;
• a full audit with an order of actions is usually 32-50 hours, that is, EUR 2,240-3,500 net;
• a small site of up to 500 URLs is closer to the lower end, and a store with thousands of URLs and filters closer to the upper;
• language versions usually add 3-5 hours, and an ongoing crisis that has to be diagnosed 4-8 hours.

The price includes the analysis, a report with recommendations, a meeting where we discuss it and the check after implementation. The implementation itself is done by your team, or I quote it separately.

Without access to Search Console, the CDN panel and the hosting, I cannot fully check the technical part, and I say so before quoting. I then point out what I cannot verify without those accesses and narrow the scope accordingly. In the post on SEO consulting I described when a conversation about a single decision is enough instead of an audit.

Frequently asked questions about SEO audits

Where to start?

Start with one question: is the site losing traffic or not building it. The answer decides whether you first protect the pages that hold positions or look for keywords that lack pages. Then do the three free checks from the answer about auditing it yourself: robots.txt, the indexing report in Search Console and a crawl with the free version of Screaming Frog. If the result surprises you or you do not know what to fix first, it is a good topic for a consultation.