Diagnostic engagement
A fixed-scope technical review of a live store, delivered as a written document with findings ordered by what they are costing you. It is deliberately a small piece of work, it ends with a recommendation rather than a proposal, and the recommendation is occasionally that you do not need the project you were about to commission.
Straight answer
A review of the parts of a store that decide whether it performs: the platform architecture and data model, page and checkout performance on real devices, the checkout and search journeys, the integrations that carry orders and stock, the analytics you are making decisions from, and crawlability and indexation. The output is a written document listing what is wrong, what it is plausibly costing, and what to do in what order. It is not a proposal, and about a third of the findings are usually things a business can fix without hiring anyone.
Usually commissioned when
- Revenue flat while traffic is not
- A replatforming proposal you cannot independently evaluate
- A store nobody has technically owned for a while
What it covers
Architecture and data model
Whether the catalogue, attribute and store structure matches how the business actually trades, and where it will stop scaling.
Performance, on field data
Core Web Vitals from real devices rather than a lab score, the caching layers, and the front-end weight accumulated over years of additions.
Checkout and conversion path
Where people leave, which steps are doing damage, and which of the usual suspects are actually the problem on this store rather than in general.
Integrations
ERP, PIM, CRM, OMS and fulfilment: what the source of truth is per field, what fails silently, and what nobody is reconciling.
Analytics you can trust
Whether the numbers being used to make decisions are correct. Double counting, missing conversions and untracked steps are common and quietly expensive.
Crawlability, indexation and structure
Whether search engines can read the catalogue, and whether the URL, canonical and structured data decisions are working or fighting each other.
The unexpected one is analytics. A surprising number of stores are being steered by numbers that are wrong, and every decision made from them inherits the error.
What arrives
A written findings document
Every finding with its current state, why it matters commercially, and a specific recommendation. Written to be read by a business owner and actioned by a technical team.
A priority order
Ranked by the combination of business impact and effort, so the list can be worked from the top rather than argued about.
A walkthrough conversation
A call to go through it, challenge it and decide what happens next. Bring whoever will do the work.
An honest verdict on the platform
Including when the platform is fine and the problem is elsewhere, which is a common and unwelcome finding.
When not to
A store that has not launched
There is nothing to measure. That conversation is an architecture review before the build, which is a different and cheaper piece of work.
A business that has already decided
If the platform decision is made and the budget is committed, an audit is a formality. Spend the money on the delivery instead.
Anyone wanting a number to justify a decision
The findings go where the evidence goes. If the honest answer contradicts the plan, that is what the document will say.
Straight answers
- What does an eCommerce technical audit include?
- Architecture and data model, performance on real device data, the checkout and search journeys, the integrations carrying orders and stock, the analytics behind your decisions, and crawlability and indexation. The output is a written, prioritised document rather than a call.
- How is this different from a free consultation?
- A consultation is a conversation and produces an opinion. An audit is a piece of work and produces a document you keep, which your team can action whether or not anything else follows. It also ends with a recommendation rather than a proposal.
- What access do you need?
- Read access to the platform admin and analytics, and a conversation with whoever knows the integrations. Nothing is changed on the store during an audit.
- Will this turn into a sales pitch?
- The document ends with what to do, not with what to buy. A reasonable proportion of findings are usually things an in-house team can fix without hiring anyone, and those are marked as such.
- Which platforms can be audited?
- Magento 2 and Adobe Commerce, Shopify and Shopify Plus, WooCommerce, and headless storefronts. The commerce questions are largely the same across them; the mechanics differ.
- What if the audit finds nothing serious?
- That is a valid and useful outcome, and it gets written up as plainly as any other. Knowing the platform is sound redirects the conversation to where the problem actually is, which is usually merchandising, acquisition or pricing.
Next step
Send the store URL, the platform and the symptom that prompted this. I will say whether an audit is the right thing before either of us scopes one.