Technical SEO audit: what blocks access, and in what order to fix it

Published pages that never show up, rankings that move after a release, a tool report thousands of lines long: these situations raise a question of access first.

This page is for the executive, the marketing or IT director and the SEO lead who commissions or reads a technical SEO audit. It helps you decide what to check, how to sort what the audit surfaces and in which order to fix it.

What a technical audit checks, and how you sort what it surfaces

A technical audit checks what determines the ability of search engines to crawl, render and index your pages, without replacing content, authority or business analysis. The overall scope of an SEO audit sets the frame; at URL level, this layer prevents three costly scenarios:

• The page is not discovered (no internal links, excessive depth, inaccessible pagination, JS that hides the links);
• The page is discovered but poorly understood (duplicates, inconsistent canonical, competing versions, contradictory markup);
• The page is understood but “too expensive” to process (slowness, server instability, heavy JavaScript rendering), which delays indexing.

The opportunity cost is immediate: a page relegated to page 2 of the SERPs only gets a click-through rate of 0.78% (Ahrefs, 2025), a benchmark collected in the SEO statistics. The right objective is not “zero alerts”, but technical stability that lets Google process your important pages.

The external crawl: what it shows, what it does not tell you

A technical audit relies on an external crawl: you observe the site as a robot does, without depending on the CMS. It reveals what the eye does not see:

• redirect chains;
• pages that sit too deep;
• non-indexable URLs linked internally;
• inaccessible pagination.

Its limit decides what comes next: a crawl shows what the robot can explore, not what Google does. Hence the mandatory cross-check with Search Console, whose reports have their own latency: a fault established by a crawl is real before it appears there.

Blockers, amplifiers, marginal optimizations

10 prioritized decisions are worth more than a backlog of 500 unsorted tickets. Classify the findings at three levels:

Within each level, sort using the SEO audit's reference grid, impact × effort × risk, applied in batches (templates, directories, business segments): a global redirect rule comes before a handful of missing titles.

Crawling and indexing: access directives, sitemap and crawl budget

Worthless URLs, redirects and duplicates consume crawling at the expense of strategic pages. Two files decide most of it: robots.txt and the sitemap.

Robots.txt: the three checks and the safeguard

The file lives at the root and steers crawling. Badly set, it can forbid a whole directory, or the whole site. Check three things:

• strategic directories are not caught by an over-broad rule;
• the resources needed for rendering (CSS, JavaScript, critical images) are not blocked;
• the file in production is not a copy of the staging one, which happens at every migration.

The consistency rule is simple: an area closed to crawling should not be fed by internal linking, or you create dead ends. And blocking an area does not settle the reason it was generated in the first place.

Above all, blocking in robots.txt is not deindexing. A URL closed to crawling can remain indexed without its content, and a noindex only works if the robot can read the page: a blocked page will never leave the index that way.

Sitemap and volume: the gap between submitted URLs and indexed URLs

A sitemap reflects your indexing strategy, not the inventory of existing URLs. Three rules make it useful:

• leave in it only URLs that answer 200, indexable and canonical;
• watch the “submitted vs indexed” gap, more instructive than an “OK” status;
• read a high volume of pages “crawled, currently not indexed” as a problem of perceived quality, duplication or architecture, not as a fault in the file.

What the robot discovers, and how often it comes back, belongs to SEO crawling. Past a certain volume, the point is to be crawled usefully: the trade-off between server capacity and crawl demand then belongs to the crawl budget.

Architecture, depth and orphan pages

The deeper a page sits, the harder it is to discover and the less internal weight reaches it. A practical rule aims for important pages reachable in around three clicks, through topical hubs and contextual links. Three points are checked:

• Crawlable links: present in the HTML and reachable without complex interaction.
• A consistent distribution: the pages that carry the business receive more links.
• Explicit handling of the non-indexable areas: basket, account and checkout remain reachable; it is their indexability that gets settled, not their presence in the internal linking.

An orphan page no longer has an internal link from the rest of the site. Its treatment depends on its value:

“Orphan” describes the absence of internal links, not the absence of links altogether: the page can receive inbound links and generate revenue while remaining isolated for the robot. The case is classic after a migration: re-crawling degrades without traffic announcing it.

URLs, redirects, canonicals and pagination: one version, one path

A large share of the problems comes from URL conflicts: when several paths lead to the same content, the engine chooses in your place, and it chooses badly.

Redirects: chains, loops and internal links that point elsewhere

A 301 signals a permanent move; a 302, a temporary state. Kept in place for a long time, a 302 generally ends up treated as permanent: the problem lies in the ambiguity of what is declared, with the switch remaining in the search engine's hands. Three fixes are needed:

• Shorten: a redirect must be direct (A→B), never A→B→C.
• Fix the internal links: internal linking that points to redirected URLs slows down crawling and rendering.
• Break the loops: an A→B→A redirect blocks crawling.

A redirect that affects a whole template comes before an isolated anomaly.

Canonicals and competing versions: the four-point alignment

A canonical becomes dangerous as soon as it contradicts reality: pointing to a non-indexable page, applied globally to the home page, or inconsistent with a redirect. Duplicates almost always come from competing versions: http and https, www and non-www, trailing slash, parameters. Treat duplication as a matter of system consistency: four versions must match.

• the version served;
• the version linked internally;
• the version listed in the sitemap;
• the indexed version observed in Search Console.

Consolidating on HTTPS is part of it. On a multilingual site, add the reciprocity of language declarations and their consistency with the canonical.

Pagination and infinite scroll: reaching page 3

Pagination must lead the robot all the way to deep content. The common faults are well known:

• AJAX pagination that cannot be detected;
• noindex on paginated pages;
• blocking in robots.txt;
• a systematic canonical to page 1.

The last one says that pages 2 and beyond exist, but do not count: the engine crawls less and you lose the items on page 3. The configuration that holds is a self-referencing canonical on each page, with crawlable pagination links.

Infinite scroll carries the same risk if the additional content has no reachable URL. Three remedies apply:

• provide a paginated alternative or dedicated URLs;
• make sure internal links lead beyond the first screen;
• check that what appears to the user is reachable by the engine.

HTTP statuses: what the server really answers

The useful sorting separates cases that are often confused:

• Internal 404s: a priority, because they create crawl dead ends; fix them at source (template, menus, “related products” modules).
• External 404s: decided case by case; redirecting them all to the home page is rarely a good idea.
• Soft 404s: either the page does not exist and returns a real 404 or 410, or it offers real, indexable content.
• 5xx errors: an availability incident with an SEO effect; quantify frequency and scope, look for a coincidence with traffic peaks, batch jobs, deployments or external dependencies, and check the effect on indexing.

5xx errors come early, because they condition everything else. The table sums up the decision per finding:

Performance and JavaScript rendering: the processing cost of a page

Fetching, executing and understanding a page has a cost, and that cost decides how quickly it enters the index.

When slowness becomes an indexing problem

A heavy, unstable page is expensive to process: the engine comes back to it less often and indexing falls behind. The signal to watch is less a score than a conjunction: a heavy template, and pages discovered but not indexed on that template.

Spotting and compressing oversized images remains a quick win. Weight thresholds, measurement and the trade-off between cost and gain belong to the website performance audit.

JavaScript rendering: what the robot actually gets

JavaScript is not bad by nature. The risk appears when the content, the internal links or the metadata depend on fragile rendering: the engine then indexes incomplete content, is slow to index, or misses whole pages.

The question to ask is not “is there JavaScript?” but “are the essential content and links present in the rendered HTML?” Compare the raw HTML with the rendered HTML: if links or blocks appear only in the second, you have a rendering dependency. Single-page applications and filter pages are checked first.

Extractability: structured data and the readability of rendered HTML

A page is also read by answer systems that extract fragments from it: the more readable it is on the HTML side, the simpler it is to cite. A technical audit removes the obstacles. Three types of markup recur:

Since 2023, Google no longer shows HowTo as a rich result, so it drops out of the recommendations, and it reserves FAQ rich results for authoritative government and health sites. FAQPage remains useful to describe a visible FAQ.

Two checks come first: the validity of the JSON-LD and its alignment with the visible content. The frequent faults are a template that injects inaccurate properties and a FAQ that is marked up but not displayed. Hence a rule: a piece of data that changes in the content is modified in the same flow as its structured equivalent.

The readability of the HTML matters just as much: a clear heading hierarchy, and two warning signals to note in the crawl. Very little visible content relative to the complexity of the rendering can indicate partial indexing; content hidden through CSS to add volume should be removed.

From finding to ticket: recommendation, acceptance testing and non-regression

A technical audit is judged by what it triggers: an executable backlog, then checks after deployment, whose effects are rarely visible within a few days.

Writing a recommendation a developer can take as a ticket

Impose a repeatable format, in four fields:

• Hypothesis: why this point may hold visibility back.
• Evidence: a crawl extract, a Search Console report, an analytics segment.
• Fix: a redirect rule, a template correction, a robots.txt or sitemap adjustment, a rendering change.
• Acceptance criteria: what must be true after deployment.

Group the actions by template and favour testable actions over vague wording (“improve speed”): “no redirect chain left on /x/”, “every sitemap URL answers 200”.

The deployment sequence: the order follows the blocker observed

The order in which fixes ship is deduced from the blocker observed: what prevents access comes before what improves understanding. The typical sequence:

• Secure crawling: robots.txt and sitemap.
• Stabilize the URLs: HTTP statuses, direct redirects, removal of chains and loops.
• Make the content reachable: JavaScript rendering and paginated journeys, a priority as soon as blocks or links exist only in the rendered HTML; content inaccessible to rendering comes before any markup.
• Make understanding reliable: consistent structured data.
• Reduce the processing cost: dependencies and weight.

On a site with no dependence on JavaScript, the rendering step reduces to pagination. The workload, for its part, depends on five variables on which a budget is framed:

• site size;
• number of templates;
• migration history;
• dependence on JavaScript;
• the expected level of reporting, from a plain report to a backlog ready to develop.

On a fixed fee, on a time-and-materials basis or per project, it is these variables that move, not the prioritization rule.

Validating the fixes, and knowing when to run the check again

After each release, validation comes in three steps:

• a re-crawl targeted on the modified directories;
• a check in Search Console (indexing, exclusions, errors);
• the measurement of the effect on the pages affected.

On cadence, the full technical review comes once a year and on events: redesign, migration, drop in visibility. Between two reviews, a monthly monitoring routine catches regressions before rankings.

Two signals finally say that the limitation is no longer technical: well-indexed pages that plateau despite a mastered intent, and a lasting gap between your perceived quality and your visibility on competitive queries.

Continue reading

Depending on what the audit has brought to light, three reads extend the diagnosis:

• The crawl and Search Console contradict each other: log analysis proves what the robots actually requested, with the visit frequency per section, the statuses returned and the crawl waste.
• You have to write or fix access rules: the syntax and use cases of the robots.txt file detail what it does and what it does not do.
• Your site serves several languages or several countries: international SEO covers language and geographical targeting, language declarations included.

Grouping the findings of an external crawl and the indexing states from Search Console into a single reading, sorted by template, is the task covered by the audit and mapping module.

FAQ: understanding the technical side of an SEO audit

What is a technical SEO audit?

A technical SEO audit analyses what lets search engines crawl, render, understand and index the pages of a site: access directives, sitemap, HTTP statuses, redirects, canonicals, depth, JavaScript rendering. It conditions the effectiveness of content and authority analysis.

How do you run a technical SEO audit, step by step?

A technical audit runs in four stages: map the site with an external crawl, cross-check with Search Console, sort, deploy. The findings are classified into blockers, amplifiers and marginal optimizations, sorted by impact, effort and risk, then deployed in order.

Why is an external crawl essential in an SEO-oriented audit?

An external crawl is essential because it observes the site as a robot does, without depending on the CMS. It reveals traps that are invisible from the admin interface, such as redirect chains or deep pages, and is cross-checked with Search Console, because it shows what the robot can explore, not what Google does.

Which technical problems are the priority “blockers” in an audit?

The priority blockers prevent access: over-restrictive robots.txt, unintended noindex, strategic pages out of reach. Next come recurring server errors, lost or ambiguous signals (404s on useful pages, redirect chains, long-lived 302s) and duplication conflicts. Depth, linking and finishing touches come afterwards.

What is an inconsistent canonical and why is it risky?

A canonical is inconsistent when it contradicts the technical reality: it designates a non-indexable page, points globally to the home page, or does not match the version served. The risk is twofold: accidentally de-indexing useful pages, or diluting the signals across competing versions.

How can an orphan page have links?

An orphan page can have links because the term describes the absence of internal links, not the absence of links altogether. It can receive external links and generate revenue. Without internal linking, however, its re-crawling and the consolidation of its signals degrade.

Why should paginated pages keep their own canonical?

Paginated pages keep a self-referencing canonical because they carry a different listing and give access to the depth of the catalogue. Canonicalizing them to page 1 amounts to saying that they do not count: crawling shrinks accordingly.

Should the technical SEO audit evolve with GEO (Generative Engine Optimization)?

The technical SEO audit should evolve with GEO, by extension rather than by substitution. Crawl and indexing checks are joined by extractability checks: valid structured markup, a consistent heading hierarchy, essential content present in the rendered HTML, so that a page can be read and picked up by answer systems.