Technical SEO audit: what is checked and in what order

Imagine a mid-sized company whose website has been growing for ten years. There are service pages, a blog, an archive of press releases, two retired campaigns and a product catalogue with filters. Several service providers have worked on it, each with their own habits. The CMS was changed twice, and at neither change was every old address redirected cleanly.

This starting point is typical, not an isolated case. Under “Pages” in Search Console there is a long list of non-indexed addresses whose reasons are hard to interpret. At the same time, important service pages are missing from the search results, while insignificant filter combinations show up. The team suspects a content problem, because content is what is visible.

A technical SEO audit begins with a sober question: what does Google know about this website, and does it match what the company wants to offer? Only once you know this difference can you decide whether technology, structure or content is the bottleneck. This is exactly the separation the audit achieves, and it is the real value of the exercise.

The status “Discovered – currently not indexed” means that Google knows the address, for example from the sitemap or a link, but has not yet fetched it. Often a prioritisation is behind it: Google considers fetching on this website not worthwhile and postpones it. With “Crawled – currently not indexed”, by contrast, Google has read the page and decided against including it.

Both messages look similar and have different causes. In the first case the problem often lies in structure and signals, such as a deeply buried page or a flood of addresses with no value of their own. In the second case it is more about the page itself: very thin content, duplicates or a canonical that points to another address.

On top of that come error patterns that overlap. A noindex tag set by mistake during development, a robots.txt that blocks a directory, redirect chains, soft 404 pages that report status 200 although there is nothing on them. If you fix them one by one without respecting the order, you often correct symptoms and leave the cause in place.

Before you plan measures, you need three data sources that check each other. The first is Search Console with the page indexing report, the crawl stats and the sitemap reports. The second is your own crawl, for example with Screaming Frog, which shows what a crawler finds when following the links. The third is the server logs, where available, because they document what Googlebot actually fetched.

Every source has blind spots. The crawl only finds what is linked, Search Console provides samples and delayed states, and logs are missing at many hosting providers or not easily accessible. When two sources contradict each other, that is often the most revealing finding. A page that is in the sitemap but does not show up in the crawl is orphaned.

Crawl budget needs some context: for small websites with a few hundred pages it is rarely a bottleneck. It becomes relevant with large inventories, many automatically generated addresses or slow server responses. Then it helps determine how quickly new and changed pages are picked up. Whether this applies to your website is shown by the crawl stats, not by a rule of thumb.

The obvious method would be to work through the crawl export from top to bottom. That leads you astray, because the error list is sorted by frequency, not by impact. A hundred images without alt text weigh less than a single line in robots.txt that blocks the services directory. The order of checks should therefore follow the chain Google goes through: reach, fetch, understand, include.

We would proceed in this sequence: first accessibility and status codes, then control via robots.txt and meta tags, then canonicals and duplicates, then sitemap and internal linking, and finally rendering and presentation. Each stage presupposes the previous one. A clean canonical is useless if the page may not be fetched at all because of robots.txt.

An alternative is auditing by page type: first all service pages, then the blog, then the catalogue. This is worthwhile for very heterogeneous websites, because every template produces its own errors. We combine both by using the chain as a grid and grouping by template within each stage. After all, an error in a template affects every page that uses it.

Fully automated audit tools are a third way, and they have their place: they quickly deliver an inventory. Their weakness is weighting, because they do not know your target list and report warnings with equal urgency. We use them as a data source, not as a verdict, and interpret the results in the context of the website.

The check chain yields a grid of topic areas that is worked through per template. It prevents individual findings from being discussed in isolation in conversation with the development team. At the same time, it helps answer the question of what was not checked. An audit that names its limits is more reliable than one that claims completeness.

The grid deliberately stays technical and does not assess text. Content questions, such as whether two pages serve the same search intent, appear in the audit as a note but are explored in a separate content analysis. This distinction keeps the audit readable and responsibilities clear, because technology and editorial work are often in different hands.

What matters is the order within the grid, not just its completeness. A finding in the status codes changes what is still worth assessing for canonicals and sitemap at all. That is why the grid is run through twice per template: once for the inventory, once after the first corrections, to rule out follow-up errors that only become visible once the fix is made.

It starts with a crawl of the live website with a mobile user agent, supplemented by a comparison with the sitemap and the Search Console export. The raw data is grouped by directory and template. This makes it visible that 40 addresses of the same error class often trace back to a single cause, such as a filter function that creates a new URL after every click on a value.

We check the control files with the robots tester and in the source code. Typical errors are a Disallow carried over from the staging system, a noindex in the template that only applies to some page types, or an X-Robots-Tag that the server sets for PDFs and that accidentally covers entire directories. For canonicals we check whether the target address is actually reachable, indexable and identical to the one in the sitemap.

For rendering, we compare the raw source code with the rendered DOM and use the Search Console URL Inspection tool to see what Google rendered. If navigation or main text are missing in the raw source and only appear through JavaScript, that is not automatically an error, but it is a risk that we assess. What matters is whether links exist as real references with href, because Googlebot does not follow click handlers.

We look at internal linking as a graph. How many clicks lie between the home page and a service page, which pages have no incoming internal links, and where does internal weight flow? A rule of thumb that important content should be reachable in three to four clicks works as a guide, but it is not a limit set by Google.

Parameter URLs are the most common special case. A catalogue with sorting, colour, size and page number can turn a hundred products into thousands of addresses. Choosing the tool is a trade-off: a canonical to the base page allows crawling but consolidates the signals. A block via robots.txt saves crawl effort but prevents Google from reading the canonical at all. A noindex should not be combined with a block, otherwise it is never seen.

A second special case is multiple paths after CMS changes: the same page under http and https, with and without www, with and without a trailing slash. What counts here is a single canonical form enforced on the server side and a redirect that leads to the target in one step. Chains of three hops waste fetches, and with many hops crawlers abandon the trail.

Third, the pages you deliberately keep thin: thank-you pages, internal search results, print versions. They do not belong in the sitemap and are usually given noindex, but are not blocked in robots.txt if Google is to read the noindex. For multilingual sites, hreflang relationships come into play, which must be confirmed reciprocally. Such special cases are why an automated report alone is not enough.

A fourth case concerns pages behind logins, cookie prompts or country switches. If the website redirects crawlers to a single version based on IP address or language, other variants remain invisible. We therefore check what a fetch without cookies and without a language setting returns, because that is exactly how Googlebot sees the page.

A technical audit improves the preconditions, not the result. If Google has so far not included important pages because a block or a wrong canonical was in the way, the correction can lead to those pages being indexed. Whether they then rank well depends on content, competition and authority. The audit ensures that these factors can come into play at all.

The benefit can be measured with indicators close to the cause. These include the number of indexed pages compared with the target list, the ratio of valid to excluded pages in the indexing report, the crawl stats with response times and status codes, and the share of sitemap addresses that are actually indexed. Impressions, clicks and positions for the affected page groups come only after that.

Expect weeks, not days. Google processes corrections with a delay, and for deeply buried pages it can take several weeks until a new status appears. There is no guarantee for particular positions or gains, and anyone who promises one is selling something other than an audit. What is realistic is the aim of removing obstacles and documenting the development traceably.

An example of interpretation: if the number of indexed pages rises while the number of sitemap addresses falls, that is a good sign, provided the target list explains the difference. If the number of indexed pages falls after a clean-up, that can also be intended, for example when filter pages without search value drop out of the index. Numbers alone say little as long as they are not read against the target list.

An audit does not end with the list of findings but with a sequence. We rank each finding by two questions: how many important pages does it affect, and how great is the effort to fix it? A wrong noindex in the template affects many pages and costs one line of code, so it goes right to the top. A complete restructuring of the navigation has a strong effect but ties up weeks and belongs in a project of its own.

It is important to make dependencies visible. Cleaned-up canonicals and a clean sitemap should be delivered together, otherwise the signals temporarily contradict each other. Redirects belong before internal relinking, so that no links point to chains. The measures are therefore bundled into packages, each of which results in a consistent state on its own.

Deliberately doing nothing is part of it too. Some findings, such as missing alt text on decorative images or non-indexed archive pages, are not a defect but a defensible decision. Documenting them saves the team future discussions. A new crawl is worthwhile only after the first wave of measures, because then you can check whether the corrections work as intended.

Technical errors rarely arise from negligence, but from change. A release sets the noindex again, a new plugin creates archive pages, a relaunch changes paths. An audit is therefore a snapshot. It makes sense to derive a few checks from its findings that run with every major change: a crawl of the most important templates and a look at the indexing report.

Two insights go furthest. First, the target list and the sitemap are the same document, just in different forms, and should come from the same source. Second, Search Console is more of an early warning system than a verdict. A slowly growing block of excluded pages often shows a structural problem weeks before rankings react.

The audit has limits. It says nothing about the quality of the texts, the strength of the brand or the competition, and it replaces neither content work nor link building. Checking the technology removes obstacles. Anyone who wants visibility must then deliver content that justifies inclusion. The two belong together, and the order is rarely reversible.

A technical SEO audit is worthwhile if your website has grown and you are no longer sure what Google includes from it. It provides no guarantee for positions, but a reliable picture: which pages are indexed, which should be, and which technical reasons lie in between. This spares you measures that start in the wrong place.

The next step is small. In Search Console, open the page indexing report and compare the number of indexed pages with the number of pages you really want to see in the index. If the difference is large or unclear, a closer check is worthwhile. We are happy to look at it together, with a first crawl and an honest assessment of whether a full audit pays off.

An honest estimate of effort is part of the picture. For a website with a few hundred pages, the analysis is doable in a few working days; for catalogues with tens of thousands of addresses and several systems it is considerably more work. We give the range after the first crawl, not before.