Most ecommerce website audits are sold as a score. You get a number out of 100, a PDF of red and green dots, and a vague sense that something is wrong. Then nothing changes, because nobody told you which problem is costing you orders and which one is just untidy.
A good audit does one thing: it ends in a ranked list of fixes, each with a reason, a rough effort, and the part of your revenue it protects. If the report you are looking at does not do that, you have bought an inventory, not an audit.
Checkout is the first place to look, and the evidence is not subtle. Baymard Institute puts the average documented cart abandonment rate at 70.22%, drawn from 50 studies and last updated in September 2025. In its survey of US shoppers who abandoned a checkout, the top reason was extra costs that were too high, at 40%. Slow delivery came second at 20%, and distrust of the site with card details came third at 19%. Only some of that is a design question. Shipping cost surprises and trust signals are things an audit can find in an afternoon, and our write-up on conversion as an engineering problem goes deeper on why the fix usually sits in the code, not the copy.
Speed is the second leak. Google publishes the thresholds it considers good: the main content of a page should load within 2.5 seconds, a page should respond to a tap in 200 milliseconds or less, and layout should not jump by more than 0.1. Those are measured on the 75th percentile of real visits, mobile and desktop separately, which is Google's own definition on web.dev. An audit that tests your homepage once on a fast office connection tells you nothing. Ask which real-user data it used.
Five areas, in this order of urgency for most stores.
Checkout and payments. Every step from cart to confirmation, on a phone, with a real card and a real address in a country you ship to. Where does a shopper hit a surprise fee, a forced account, or an error with no explanation?
Speed on real devices. Field data first, lab tests second. The audit should name the three or four heaviest things on your slowest pages, not list forty warnings.
Search visibility. Whether Google can reach and index the pages that earn money: category pages, product pages, filtered views that should or should not be indexed. This is the area owners most often assume is fine.
Security exposure. Out-of-date platform versions, scripts running on payment pages, admin access nobody has reviewed. Checkout skimmers are the classic example, because they steal card data without breaking anything you would notice.
Data and integrations. Whether stock, prices and orders agree between your store and the systems behind it. Quietly wrong inventory is a conversion problem wearing a back-office disguise.
Here is the part most owners miss: the biggest finding is rarely the one the checklist leads with.
In July 2026 we found that the paginated pages of our own blog all declared the first blog page as their canonical address. To Google, that meant the page links leading to older posts were not worth following. Twenty-three of our thirty-two posts were effectively orphaned. After the fix, the number of indexed pages went from 43 to 66 in six days. One configuration error had cost us more than all the content we had written put together.
No speed score would have flagged it. It took someone asking whether Google could actually reach each page.
Run three quick checks on any report you are handed or any quote you receive.
Does it mention your platform and version by name, or could the same words describe any store? Does every finding carry a severity and an estimated effort? And can the author show you one finding that surprised them, something specific to your store that a crawler would not produce on its own?
If the answer to all three is no, you are paying for a tool's output with a human cover page. The reports worth paying for read like the work behind our rescue of an inherited Adobe Commerce store: specific, ordered, and uncomfortable in the right places.
Free tools have their place. Run one before you hire anyone, so you can tell whether the paid report tells you anything new.
Ask for four things. A ranked fix list, with the top five items marked as the ones to do first. A plain statement of what each fix is worth, even as a range. A split between what your own team can do and what needs a developer. And a recheck date, because an audit that is never repeated just becomes a snapshot of how your store looked one spring.
For most stores a full audit makes sense once a year, with a lighter check on speed and indexing after any big release or platform upgrade. That is a rhythm, not a rule, and a store that ships changes weekly needs the lighter check more often.
An internal developer can run the technical half of an audit, and should. What they struggle with is the verdict: they built or maintain the thing, and a fair assessment of checkout or architecture decisions is awkward to write about your own work. An outside reviewer has no such history, which makes the ranking more honest. The cheapest setup that works is a split. Your team gathers the field data and access, and someone independent, whether an IT consulting partner or a trusted developer from another shop, does the ranking and writes the list.
Whatever route you take, give the reviewer read access to analytics and search data before day one. Most of the delay in audits comes from waiting for logins, not from the analysis itself, and a reviewer without that data falls back on guesses and generic advice.
If your team is stretched and you suspect the answer sits somewhere between checkout and the server, this is the sort of problem we help with at Encomage. Our work usually starts with an honest look at the store as it stands, before anyone proposes a rebuild.
Let’s build something powerful together - with AI and strategy.
