How to audit a website, in the order that matters

What a site audit is, and why the order of the checks changes everything#

A site audit is an ordered inventory of what stops a site from being found, read, then used. It covers three distinct layers, and confusing them is the first cause of wasted work.

The technical layer decides what search engines can reach: the pages they crawl, the ones they index, how fast they get there. The editorial layer decides what the site says and what it puts forward: the topics covered, the pages internal links support, the ones nothing points to any more. The usage layer decides what comes next: what a visitor understands on arrival, and whether they do the thing the page exists for.

Most audits deliver a list sorted by category. A hundred points to fix, filed by family, each with a severity. That is useful for taking stock and not enough for acting. A list does not say where to start, and a business owner opening a hundred-line report usually starts with what they understand best, not with what weighs the most.

The principle that restores order is simple: each layer depends on the one before. A page that is not indexed cannot rank badly, it does not exist in the ranking at all. A page that is indexed but that no internal link supports will be crawled rarely, and its fixes will be taken into account late. A page that is indexed, well linked, well ranked and still does not convert is the only case where working on the page itself makes immediate sense.

This is why the common question, how to audit a website, calls for an answer in steps rather than in categories. Here is the order we apply, and the sections below take it one at a time.

What blocks indexing, before anything else#

An indexing block is a special case: it does not degrade a performance, it cancels it. The page may be excellent, it will appear in no result while the block holds. That is why this family comes before all the others, including before fixes that are more visible and more satisfying.

Blocks sit in a small number of places, always the same ones. The robots.txt file can forbid a whole directory, sometimes a leftover from a launch where the site was closed to search engines. A noindex tag can survive on pages moved into production. A status code can return a server error on part of the site without anyone noticing, because visitors do not go there. A misplaced canonical tag can name another page as the reference version, and make the original disappear from the index. A sitemap can list dead addresses, which spends the robot's attention for nothing.

An audit finds these cases by crawling, not by reading the source code of one page picked at random. The crawl starts from the home page, follows the links, collects status codes, directives and canonicals, then compares them with the declared sitemap. The gap between those two inventories, what the site says it publishes and what a robot actually reaches, is the first number to look at in a report.

These blocks rarely appear in steady state. They show up at moments of change: launch, migration, change of hosting, redesign. That is exactly what our checklist before redoing your site covers, listing the points to freeze before switching to a new version.

What buries pages: click depth#

The second threshold concerns pages with no technical defect at all. They respond, they are indexable, and yet they receive almost nothing. The cause is most often their position in the site.

Click depth is the number of clicks separating the home page from a given page, following internal links. A robot works the same way: it starts from the pages it knows and discovers the rest step by step. That journey is not unlimited. A page far from the home page is therefore visited less often, its updates are seen later, and its indexing takes longer when it is published.

The criterion to watch is not the maximum depth of the site, which means nothing on its own. It is the share of pages sitting beyond three clicks, and above all which pages those are. A site with deep archives is doing fine. A site whose service pages are deep has a structural problem, even if its total count of buried pages is small.

The extreme case is the orphan page: no internal link leads to it. It exists, it is sometimes excellent, and the whole site behaves as if it were not there. The detail of the measurement, the thresholds and the fixes is covered in our article on click depth and buried pages. What matters here is where this check sits in the order: it comes after indexing, and before any rewriting.

What fails to convert: pages with no traffic and content debt#

Once indexing is cleared and the link structure is back in order, the most uncomfortable question remains: what to do with the pages that bring nothing in. On a site a few years old, they often run into the dozens. Old news items, pages created for a campaign that ended, articles published to keep up a rhythm.

That set is a debt. It costs the robot's attention, it dilutes the topic of the site, and it gives an impression of abundance that hides the fact that only a handful of pages carry the business. The reflex answer, rewriting, is almost always the wrong one: it spends the scarcest resource for an uncertain gain.

Four decisions exist, and only one of them is right for each page. The sorting criterion is the same everywhere: what the page already receives in impressions, and whether its topic still has commercial value.

The detail of each decision, and how to settle it when two of them look possible, is covered in our article on content debt and pages with no traffic. What matters at the level of the method is that this step comes last of the three. Settling pages with no traffic while an indexing block still holds is like tidying a room whose door is sealed.

Why audit a website regularly#

An audit describes a state on a date. That description goes stale, for three reasons independent of one another.

The first is the site itself. It lives: pages are published, menus change, a plugin is installed, a form is replaced. Each of those gestures is minor on its own, and their accumulation changes the structure without anyone having decided to change it. An article published today pushes last year's down a notch in the list pages, and the click depth of part of the site rises without a single line of code being touched.

The second is what happens on the other side. The pages ahead of you on a query are rewritten, expanded, sometimes abandoned. Your position can slip while your page has not moved by a word, and the reverse is true as well.

The third has to do with measurement. Search Console data is available over a rolling window: what is not recorded eventually falls out of the history. A one-off audit takes stock; a series of audits compares, and it is the comparison that says whether a fix produced an effect. It is also the only honest way to know, since nobody can isolate the effect of one action on a ranking.

A reasonable rhythm is to audit at launch, then at regular intervals, and systematically after a redesign or a migration. Connecting the Google accounts is what makes that repetition useful, because it brings the history a crawl alone does not know: our page on your Google data explains what is read and what is not.

Visibility in AI answer engines: the check missing from classic audits#

The widespread audit grids date from a time when only one question was asked: is this site correctly understood by a search engine. A second question has been added. Part of searches no longer end in a list of links but in a written answer, in a conversational assistant or in an AI Overview placed above the results. That answer cites sources, and a site can rank perfectly well without ever appearing among them.

The check therefore splits in two. On one side, how readable your pages are for these systems: factual information that can be located, answers stated directly rather than buried, a structure that lets a passage be extracted without distorting it. On the other, the measurement: on your queries, who is cited today, and is it you.

These two parts are not handled together. The first is editorial work, fixed page by page. The second is a repeated observation, and no technical audit yields it. We have documented the measurement itself in our observatory of AI citations, and how to run it over time in our protocol for tracking AI visibility.

One clarification, to avoid false hope: a citation cannot be ordered and cannot be guaranteed. It is observed, over a series of readings, and an absence of citation at a given moment means nothing until the measurement has been repeated. It is an audit check in its own right, with its own rules, and it replaces none of the three thresholds above.

Auditing on your own, or bringing in help#

The objection deserves to be put plainly, because it is legitimate. A business owner can do a good part of this work themselves. Crawling tools exist, Search Console is free, and the method described here is no trade secret.

What tips the answer is not skill, it is the shape of the problem. Three criteria are enough to decide, and they are read together.

A fourth element weighs more than the other three and shows less: arbitration. Producing a list of problems is within reach of a tool. Deciding which one to handle first, on a given site, with a given team and a given budget, is an owner's decision that gains from being discussed with someone who has seen other sites. It is also what separates a report from a work plan.

There is a fairly reliable sign that it is time to open the question. If the fixes identified at the last review have not been applied, the problem is no longer the diagnosis: it is execution, and one more audit will not trigger it. Conversely, if you already know which pages carry your business and the list of fixes fits on one page, doing it yourself remains the right call.

The choice is not limited to two options either. Between working alone and delegating entirely, there is a middle position where the tool produces the plan and your team applies it. We have set out that trade-off, including the case where the right answer is to redo the site rather than optimise it, in our article tool, agency or redesign.

How the workshop applies this method on screen#

This method is not theoretical on our side: it is the very structure of the tool we use for our clients.

The Atelier SEO audit runs more than ninety checks on a site and files them into four families: the technical side, page content, internal linking, and readability for AI systems. Each family carries a score and a number of open points. That organisation reproduces the order described above: the families are not four equivalent lists to be handled in parallel, they are four floors where the first governs the ones above.

Crawl data alone is not enough to decide. Connecting Search Console and Analytics adds what the site does not know about itself: which pages already receive impressions, on which queries, and what visitors do next. Competitor analysis adds the outside context. A buried page already getting impressions and a buried page nobody searches for call for opposite decisions, and that distinction does not exist without the crossing.

Iris, the workshop's assistant, works on the same data. Its role is not to produce one more list, but to put it in order: which problem to tackle first, on which pages, and why those rather than others. The demonstration on a real case shows the difference between a generic answer and an answer grounded in a site's data.

The output is a prioritised action plan, page by page, with the reason for each rank. That plan is read and applied in your own publishing tool, with no dependency on the platform, or by our team if you prefer to delegate execution: the sequence is described in our working method. Three routes exist depending on who executes, and they are set out on our offers page: apply the plan yourself, take the package with a redesign included, or have the fixes implemented on your current site.

It is worth saying what this screen does not do. It publishes nothing, rewrites no page for you, and knows nothing of your internal constraints: a fix that is technically top priority can wait because another deadline comes first, and that is legitimate. Nor does it predict a position, a timeline or a citation in an answer engine. What it brings is more modest and more useful: the certainty that you are not working on layer three while a defect in layer one cancels the effect. The audit is free and access is by invitation, with no credit card, which lets you see that ordered reading on your own site before any decision.