Why three pages instead of one
Almost every free store audit measures the homepage and stops. That is the least representative page on a store. Your homepage is hand-built and heavily optimised; your product template is what ranks, what converts, and what carries the review widgets, variant scripts and upsell apps that actually slow a store down. Auditing only the homepage tells you about the one page you were already paying attention to.
So this audit finds three pages — your homepage, a real collection page and a real product page — and measures each on both mobile and desktop. That is six measurements, which is why speed scores take about a minute to fill in while the findings appear immediately.
Core Web Vitals, per page and per device
Speed comes from Google’s PageSpeed Insights API — the same engine behind pagespeed.web.dev. You get Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint for each page and device, scored against the web.dev thresholds, plus the specific opportunities Lighthouse identifies with the estimated saving attached to each.
Mobile and desktop are reported separately because they usually disagree, and mobile is the one that counts — it is what most of your traffic uses and what Google indexes.
SEO and crawlability
Per page: title and meta description presence and length, canonical URL including whether it is self-referencing, noindex directives, viewport and charset, language and hreflang, heading hierarchy including skipped levels, and Open Graph and Twitter card completeness.
Across pages: duplicate titles and duplicate meta descriptions between templates, which is a problem you cannot see by looking at any single page and is one of the most common findings on a store using default theme metafields.
Images and layout stability
Missing alt text, images served without width and height
attributes (each one a layout-shift risk), lazy-loading coverage,
srcset usage, and whether modern formats like WebP
or AVIF are being served at all.
Scripts and third-party load
Render-blocking scripts, async and defer coverage, how many
third-party scripts are running and which domains they come from,
inline CSS weight, font-display, and preconnect and
preload hints. Third-party script load is usually the single
largest speed cost on a Shopify store, and it is almost always
apps.
Structured data
Every JSON-LD type found on each page, plus a field-level check
of Product schema — name, image, SKU, brand, offers, price,
currency, availability, rating and reviews. Product schema that
exists but is missing availability or
price will not produce a rich result, and that gap
is invisible unless something inspects the fields individually.
Theme and app layer
On Shopify stores the audit also reports the detected theme and version, fingerprints the apps loading on the storefront, and estimates monthly app spend from their published pricing. That estimate is deliberately rough — it reads public prices against detected apps and cannot see your plan or discounts — but it is usually enough to start a conversation about which apps are earning their place.
What this audit doesn’t check
It cannot see anything behind the checkout, anything requiring a login, or anything rendered only after user interaction. It does not test your actual purchase flow, your email and SMS flows, your inventory logic, or your app configuration — only what a browser receives on a public page.
It also samples one collection and one product, not your whole catalogue. If your templates vary a lot, treat the result as a representative sample rather than a full crawl.
Deeper CRO work — friction analysis, upsell placement, checkout economics — is in the CRO Practical Audit playbook and is scoped separately. A full multi-template audit is included in scoping on theme development engagements.