The free store audit: what a senior engineer actually looks at

It is a sample. You give an agency a URL, they spend an hour or two on your store, and you find out whether they notice things you had not — and whether they can explain why each one matters without reaching for a pitch. That is a low-risk way to judge whether the people are any good, which is genuinely hard to establish from a case study.

It is not a diagnosis of your business. An audit from the outside works with public evidence only: the pages anyone can load, the scripts they request, the markup they emit, the checkout as a shopper experiences it. That is a lot more than people expect and considerably less than a full engagement, and being straight about the boundary is the first thing worth looking for in one.

Our own audit promises a prioritised list of fixes within three business days, written so any developer can act on it. The word doing the work there is *prioritised*. A crawler will hand you four hundred findings in twenty seconds. Deciding which six matter is the part that requires somebody who has fixed this before.

Not a score. A score is a summary of a measurement someone else chose to take, and optimising it directly produces work that is hard to defend later.

What gets looked at instead is the shape of the load on a mid-range phone on a throttled connection, because that is the device most of your traffic is using and the one your team is least likely to be testing on. Specifically: what renders first and how long the shopper stares at nothing; which resource is the largest content paint and whether the theme has told the browser it matters; what blocks parsing before any content appears; and how many separate third-party origins the page connects to before it is usable.

The last of those is the most useful number on the list, and it is not a performance metric — it is an inventory. A store connecting to fourteen third-party domains has fourteen relationships, most of which nobody in the building remembers agreeing to. That finding alone routinely accounts for the largest available win, and it costs nothing to act on.

What an outside audit cannot see: your field data. Shopify reports real-visitor performance inside the admin, and that is the version that reflects your actual traffic mix rather than one engineer’s test. An external audit is a lab measurement — directionally right, and worth confirming against the field data once anybody has access.

This is the part that a tool cannot do and the part clients most often find surprising, because it consists of somebody actually trying to buy something.

The route is the obvious one: a search result or an ad, a collection page, a product page, add to cart, checkout, up to the payment step. On a phone, first, and preferably as a new visitor with an empty cart and no prior session. What gets noted is anything that made the buyer hesitate, work, or wonder — a variant selector that does not make clear what is out of stock, a delivery promise that appears for the first time at checkout, a discount field that invites hunting for a code that does not exist, a cookie banner that covers the add-to-cart button on a small screen.

None of these are bugs. That is why they survive: everyone internal has a session, a saved address and the muscle memory to get past them. An audit’s advantage here is ignorance, and it is a wasting asset — the second time somebody visits your store they have lost it.

What an outside audit cannot see: whether any of it costs you money. That needs analytics, and preferably a funnel someone has already been watching. An honest audit says "this is friction and here is where to check whether it is expensive", not "this is costing you X per cent".

The public-facing signals are all in the markup, so this part is fully checkable without access, and it is the area where an audit most often finds something with real money attached.

Structured data is first, because it is both high value and easy to get subtly wrong — product markup that disagrees with the visible price, review markup pointing at nothing, a breadcrumb trail in the schema that differs from the one on the page. Then canonicals and pagination behaviour, particularly on filtered collection URLs, which is where Shopify stores most commonly generate crawl paths nobody intended. Then the basics that are embarrassing rather than difficult: robots.txt, the sitemap, whether staging is indexable, whether internal links point at redirects.

What an outside audit cannot see: Search Console. Coverage, queries and the history of what changed when all live behind your login, and they are where a ranking problem is usually diagnosed rather than merely suspected.

Two things come up often enough to say in advance, because both point away from a project rather than towards one.

The first is that the fix is usually configuration, not development. A meaningful share of what an audit finds is an app setting, a theme setting or a piece of dead code, and none of it needs an agency. If your team can action the whole list, that is a good outcome and we would rather say so than pad it.

The second is that a rebuild is rarely the answer to the symptom people ask about. A store that is slow because of eleven apps will be slow after a redesign, because the business still wants the eleven things. A store with a confusing product page does not need a new theme; it needs the product page fixed. Where the honest answer is a smaller piece of work, we will say so — the ongoing relationships worth having start that way more often than they start with a large first invoice.

And if the list turns out to be short, that is also a result. A store that has been looked after well should audit well, and being told so by somebody with no incentive to say it is worth an hour of anyone’s time.

• Shopify support and store management
• The product page audit: twenty things worth checking
• Loading strategy: what to defer, what to inline, what to drop