Tech for Retail 2025 Workshop: From SEO to GEO – Gaining Visibility in the Era of Generative Engines

Back to blog

SEO audit: what it covers, when to run it, what it delivers

SEO

Discover Incremys

The 360° Next Gen SEO Platform

Request a demo
Last updated on

7/10/2026

Chapter 01

Example H2
Example H3
Example H4
Example H5
Example H6

CEO, marketing director or SEO lead: you have to launch, commission or read an SEO audit, then turn it into decisions. This page sets out the reference markers: what an audit covers, when to launch it and how often to repeat it, how to prioritize with the impact × effort × risk grid, who runs it and how to check the effect of the fixes.

 

What an SEO audit covers — and what it does not deliver

 

An SEO audit analyses, in a structured way, what shapes a site's organic visibility: technical foundations, content, authority and experience. The goal is not to list every alert, but to understand why a site has plateaued, is losing rankings or fails to convert, then to turn that into a prioritized action plan whose effects are measured over several months.

 

In practice, it is a deliverable that connects three things:

 

  • Observable findings: crawling, indexing, performance, content.
  • Evidence: Search Console and Analytics data, crawl extracts.
  • A prioritized roadmap: what to do, where, in what order, against which validation criteria.

 

An audit therefore starts with a decision, not with a tool: naming the objectives and the pages that carry the value, then examining only what concerns them.

 

The approach is justified by where the clicks concentrate. In position 1, the average click-through rate is 27.6% (Backlinko, 2026). On page 2 of the SERPs, it falls to 0.78% (Ahrefs, 2025): gaining a few places on queries close to the first page has a real effect on qualified traffic.

 

The share of searches ending without a click (zero-click) also reaches 60% (Semrush, 2025): a diagnosis that looks only at traffic misses part of the visibility. The SEO statistics bring these benchmarks together.

 

What is measured, and what should not be over-interpreted

 

A reliable audit combines three families of signals:

 

  • "Engine" signals: crawling, indexing, HTTP statuses, canonicals, internal linking, performance, mobile compatibility.
  • "Content" signals: search intent, keyword-to-page alignment, topical coverage, duplication, cannibalization, editorial structure.
  • "Outcome" signals: impressions, clicks, CTR, rankings, conversions, and how they move over time.

 

Conversely, avoid over-interpreting isolated alerts with no observable impact. Crossing the crawl with Search Console separates noise from signal and lets you justify, in a steering meeting, why one anomaly comes first.

 

What is committed to, what is announced, what is never guaranteed

 

An audit carries three kinds of promise, and confusing them is the first source of disappointment:

 

  • What is committed to: deliverables and deadlines. Scope, delivery date, report format, roadmap and acceptance criteria are contracted.
  • What is announced: the expected gain. It is a hypothesis with its conditions (search volumes, starting positions, capacity to execute), measured once the fixes are in production.
  • What is never guaranteed: a specific position on a specific keyword on a specific date. That is the sole object of the reservation, which extends neither to the deliverables nor to the measured trajectory.

 

What should alert a buyer is therefore not a refusal to estimate a gain before the diagnosis, a sign of seriousness when data is lacking, but a refusal to commit to deliverables and deadlines.

 

When an SEO audit is triggered, and how often it comes back

 

An audit is not decided by the calendar alone: a reference cadence applies in normal times, and certain events call for a check without delay. As soon as something has moved URLs, changed directives or rewritten page templates, you do not wait for the next scheduled slot.

 

The events that call for a check without delay

 

These situations rewrite what the crawlers had recorded. They call for a targeted reading, with a short deadline and a named owner:

 

Triggering eventWhat you recordDeadlineWho decides
Migration, CMS change or domain changeOld/new URL mapping, indexing of the pages that matterBefore go-live, then at the first re-crawlThe project sponsor, on a written SEO finding
Site structure or page template redesignPages that change level, internal links lost, content not carried overBefore release, then within a fortnightProduct and SEO jointly
Unexplained drop in impressions or clicksThe exact scope of the drop: pages, queries, device, countryWithin the weekThe head of acquisition
Change to crawl or indexing directivesNewly excluded pages, gap between submitted and indexed pagesImmediateThe technical team, with SEO sign-off
Launch of an editorial programmeExisting pages already ranking on the target topicsBefore the first briefEditorial management

 

One question settles it: are the traffic and impressions that existed before still there, on the same pages, with the same indexing status? Until the answer is documented, the event is not closed.

 

The reference cadence in normal times

 

Outside such events, the reference cadence does not depend on the size of the site. It has three levels:

 

LevelWhat it coversCadence
Monitoring routineIndexing, crawl errors, impressions, clicks, conversionsMonthly
Full auditTechnical, content, authority, experience, prioritized roadmapAnnual
Event-driven auditRedesign, migration, CMS change, unexplained dropWithout waiting for the annual date

 

The monthly routine and the reading of its variations belong to SEO tracking. Size and publishing pace change what you monitor, not the cadence. The number of pages modified and of releases shipped since the last reading tell you whether to bring the annual audit forward. Written into the workload plan, this cadence avoids the crisis audit, launched when the loss has already been taken.

 

Auditing before a redesign or a migration

 

This is when an audit is most often decided, and when it is often launched too late. Check first: can Google crawl and index the pages that matter correctly? If not, rebuilding on top fixes nothing and makes the period after go-live unreadable.

 

What you record before, while the old site is still live, forms the point of comparison:

 

  • the inventory of URLs that carry impressions, clicks and conversions;
  • their indexing status;
  • average positions on a basket of queries defined in advance;
  • the page-by-page mapping between what exists and the target.

 

That inventory cannot be reconstructed after the fact: without it, any variation will remain an impression, not a finding. You replay the same reading after, in the days following go-live and then after a few weeks, to answer four questions:

 

  • Do the inventory URLs respond?
  • Do they point where they should point?
  • Have they returned to the index?
  • Have the basket queries recovered their level?

 

That leaves the trade-off, which is a matter of organization. Before the project starts, separate the blocking findings (those that prevent go-live) from those that can be fixed afterwards, and have that short list approved by the sponsor: the trade-off is made calmly, not on the evening before release.

 

Technical, semantic, generative: the three angles and what each one determines

 

An audit is read along three angles, in the order of dependencies: improving content the engine does not crawl changes nothing, and working on the citability of a page absent from the index changes even less.

 

The technical angle: what crawling and indexing determine

 

This is the angle that decides everything else. A page that is neither crawled nor indexed gains nothing from editorial work, and its lack of impressions reads wrongly as a relevance problem. The angle settles three questions:

 

  • which pages the engine sees;
  • how often it comes back to them;
  • which ones it has chosen to leave out.

 

The detail of the checks and their order belong to the technical SEO audit: crawling, indexing, statuses, canonicalization, rendering, orphan pages.

 

The semantic angle: what the page-to-query match determines

 

Once access is secured, the question becomes: does each page target a clear intent, and does a single page target it? This angle determines the most expensive decision in the plan: create, optimize or consolidate. Its visible symptom is cannibalization, where several pages compete for the same query and the engine chooses in your place.

 

Detection and arbitration belong to the semantic audit. The page-by-page decision on existing content belongs to the content audit. To know which queries your competitors capture and you do not, the SEO competitive analysis measures the gaps with the market.

 

The generative angle: what citability determines

 

A brand can be cited without being visited. AI Overviews citing the organic top 10 account for 99% of cases (Squid Impact, 2025): the organic base remains the entry condition. The click-through rate for the first position in the presence of an AI Overview falls to 2.6% (Squid Impact, 2025): the return on a ranking gain therefore depends on the type of query.

 

The GEO statistics give the other benchmarks; measuring citation (by which engine, on which questions) belongs to the AI GEO audit. It is not to be confused with the LLM audit, which assesses a language model before adopting it.

 

Reading an audit report: evidence, prioritization, acceptance criteria

 

A report is judged on its ability to turn findings into decisions. Every recommendation carries evidence (a crawl extract, a Search Console figure, a URL) and an expected outcome. A usable report contains:

 

  • the findings, attached to the pages or templates concerned;
  • the evidence that establishes them;
  • the recommendations and their expected outcome;
  • prioritization using the impact × effort × risk grid;
  • the owner of each workstream;
  • the risks identified;
  • the acceptance criteria for each fix.

 

A document that lists anomalies with no hierarchy and no evidence is not an audit, it is a formatted tool export.

 

The prioritization grid: impact × effort × risk

 

Crawlers surface thousands of items, many with no measurable impact: handling them all ties up IT and delays what changes rankings. Every recommendation is therefore scored on three axes, always the same, from "low" to "high":

 

MarkerImpactEffortRisk
What is assessedEffect on crawling, indexing, ranking, CTR, conversionTime, dependencies, release cycleRegression, side effects, traffic loss
Question askedWhat do we gain on the pages that matter?Which teams and which cycles does it mobilize?What could break, and how do we roll back?
Example: wrong indexing directive on a critical templateHigh: key pages dropped from the indexLow: one rule to fixMedium: to check at re-crawl
Example: tag variations on pages with no trafficLow: no key page concernedMedium: page-by-page fixesLow: limited side effects

 

Add a business filter: the same anomaly does not weigh the same on a page that generates leads or revenue as on a secondary page. The order of handling then follows the dependencies:

 

  • first, what prevents the site from existing in the index;
  • then, what improves understanding: internal linking, structure, intent-to-page alignment;
  • finally, marginal optimizations, on the pages that matter only.

 

At equal impact, the cheapest and least risky action comes first; a high-risk action only enters the roadmap with its rollback procedure. Hundreds of anomalies thus become around fifteen defensible actions.

 

What crawlers often flag, but which rarely changes rankings

 

Without falling into technical denial, it helps to identify the "noise" alerts:

 

  • micro-optimizations on pages that are not indexed;
  • tag variations on pages with no traffic;
  • marginal performance improvements on pages few people visit.

 

Handle them if they pile up on a critical template, otherwise keep them for a later phase. A report that does not do this sorting leaves it to you, and it will happen without method.

 

From report to ticket: acceptance criteria and verification

 

A recommendation that is not turned into a ticket will not be executed. To avoid back-and-forth, every technical recommendation comes with acceptance criteria:

 

  • the expected HTTP status;
  • the presence or absence of a tag;
  • redirect behaviour;
  • indexing rules.

 

The acceptance check means re-crawling, then checking in Search Console that the change has been taken into account. Require these criteria at delivery: written after deployment, they describe what was done rather than what should have been done.

 

Who runs it: in-house, tool-assisted, or outsourced

 

The trade-off is rarely about skill and almost always about bandwidth, schedule and independence of view. Many organizations outsource the diagnosis and run the execution in-house, or the reverse.

 

What is done in-house, what calls for a third party

 

Running the work in-house suits short iteration cycles and the capacity to execute continuously: the diagnosis becomes a routine. Outsourcing the audit becomes relevant in three cases:

 

  • you lack bandwidth;
  • you are preparing a redesign or a migration;
  • you need a view independent of those who built the site.

 

That last case is the most underestimated: a team rarely calls its own decisions into question. The CMS, for its part, plays no part in the trade-off.

 

What to require, whoever runs it

 

The same requirements apply to an in-house team and to a supplier, and they are set before the work starts:

 

  • the scope audited and what is explicitly excluded from it;
  • the data sources that will serve as evidence;
  • the format of the deliverable and its date;
  • the acceptance criteria attached to each recommendation;
  • the named owner for each item on the roadmap.

 

Every fix also states how to roll it back. An audit that does not say who does what, nor how it will be verified, will not be opened again.

 

Checking that the fixes have produced an effect

 

Without measurement after deployment, an audit remains a snapshot. The first question is not "has traffic gone up?" but "has the finding that justified the fix disappeared?". Each question has its indicators and its moment:

 

QuestionHow it is verifiedWhen
Has the finding disappeared?Re-crawl and indexing reportsStraight away: it is a binary fact
Has visibility improved?Impressions, clicks, CTR, rankings on the basket, conversionsOver several weeks, without concluding too early
Can the variation be attributed?Annotated deployment datesAt every release

 

The basket of queries is defined before the fix. Avoid as well deploying several major workstreams in the same week: an architecture redesign run alongside editorial fixes makes both unreadable.

 

Continue reading

 

Depending on your situation, the article that takes this diagnosis further is not the same:

 

  • You have decided to audit. The order of operations, from framing to delivery, is set out to perform an SEO audit step by step.
  • You want to see the deliverable before ordering it. An SEO audit example runs it from end to end, with its reusable checklist.
  • You execute in-house. Choosing and assembling SEO audit tools avoids multiplying sources.
  • You are outsourcing the audit. Framing an agency SEO audit sets out what to require from a supplier, deliverables and acceptance included.
  • Your site is a shop. The e-commerce SEO audit covers categories, product pages, facets, variants and stock-outs.
  • Your visibility plays out in one area. The local SEO audit covers local signals, NAP consistency, reviews and the business listing.
  • You suspect external authority. The link building audit examines the inbound link profile and its quality.
  • You are looking for a broader picture. The website analysis looks beyond SEO alone.
  • The traffic is there but does not convert. The CRO audit tackles the conversion rate rather than visibility.
  • The problem lies with the brand's image. The e-reputation analysis examines what the SERP and the platforms say about it.

 

Centralizing crawl findings, Search Console data and Analytics data in a single prioritized reading is precisely the task covered by the audit and mapping module.

 

FAQ on SEO audits and organic search

 

What is the difference between an SEO audit and a GEO analysis?

 

An SEO audit analyses how Google crawls, indexes and ranks your pages, whereas a GEO analysis assesses the likelihood that your content is cited as a source in answers generated by AI. The technical fundamentals are the same, with additional criteria of extractability and verifiability, and the organic base remains the entry condition.

 

Should GEO be built into an SEO audit?

 

Yes, as soon as your objective includes visibility in generated answers. It means adding citability criteria to the classic checks: a structure that is easy to extract, sharp definitions, sourced data, neutrality and freshness. SEO remains the base.

 

What does the scope of an SEO audit cover (technical, content, authority, UX)?

 

An SEO audit covers technical foundations (crawling, rendering, indexing), content (intent, keyword-to-page alignment, quality), authority and links, and user experience where it weighs on conversion. The excluded scope is named explicitly at framing, just like the covered scope.

 

Why is an SEO audit essential before producing content or redesigning a site?

 

An SEO audit is essential because it checks that Google can crawl and index the pages that matter: otherwise, publishing more fixes nothing. Before a redesign, it also provides the point of comparison (URLs, rankings, indexing status) that cannot be reconstructed after go-live.

 

What is the difference between a technical SEO audit and a semantic audit?

 

The technical audit checks that crawlers can read and use the site without ambiguity; the semantic audit checks that each page targets a clear intent with unique, complete content. The first determines the second: working on the relevance of a page that is not indexed produces no measurable effect.

 

What roles do the crawl and Search Console play in an SEO audit?

 

The crawl gives a "machine" snapshot of the site (depth, internal links, indexability, statuses, canonicals), and Search Console connects pages and queries to real metrics: impressions, clicks, CTR, average position. Crossed, they prove or disprove the effect of an anomaly.

 

Where should you start to audit a website?

 

To audit a website, start from real performance (Search Console), then cross it with a crawl. Set the objectives and the pages that carry the value first, look at what they achieve, then use the crawl to explain the gaps. This sequence limits false positives and allows prioritization from the start.

 

Does the audit depend on the CMS in use (WordPress, Shopify, PrestaShop)?

 

No, the audit method does not depend on the CMS: an external crawl analyses pages as a robot sees them, whatever the platform. Only the implementation of the fixes differs; the diagnosis and the priorities remain comparable from one CMS to another.

 

Which deliverables should you expect at the end of an SEO audit?

 

An SEO audit delivers a structured report and a roadmap: findings, evidence, recommendations prioritized by impact, effort and risk, owners and acceptance criteria. These deliverables and their date are contractually committed to, just like the scope audited.

Discover other items

See all

Next-Gen GEO/SEO starts here

Complete the form so we can contact you.

The new generation of SEO
is on!

Thank you for your request, we will get back to you as soon as possible.

Oops! Something went wrong while submitting the form.