Free Shopify CRO Audit
Eleven questions, then a senior reviewer reads your store personally and writes back. Not a score - an actual review of your conversion path before peak.
Request the CRO audit ↗Twelve checks across four parts, published in full below - the same sequence a senior engineer works through in a paid audit. Read them, run them on your own store, or take the PDF with you. Peak week is rarely lost on creative.
Until Black Friday, 27 November 2026.
checks in the playbook, across speed, stack, checkout and data - every one of them something you can verify yourself this week.
Black Friday 2026. Cyber Monday follows on the 30th, and the trading window opens around three weeks earlier.
the code freeze we recommend before Black Friday. After that, only provable revenue bugs get touched.
Nothing is held back for the PDF - the PDF is just the same thing in a form you can send to your developer. Each check is small enough to verify this week and specific enough to argue with.
Every store is fast in August. Peak week is decided by what your product and collection templates do on a mid-range phone, on a congested network,…
Read part 01 →Apps get installed for a test, a campaign, or a previous agency, and then keep injecting storefront JavaScript long after anyone remembers why. Individually each one…
Read part 02 →Discount logic behaves differently once it meets a real cart: stacked codes, gift-with-purchase, bundles, subscriptions, free-shipping thresholds and a second currency. Most stores validate the offer…
Read part 03 →A consent change, a duplicated pixel or a broken server-side event does not throw an error. It moves revenue into "direct" - and you spend the…
Read part 04 → Mobile field data, 28-day rolling window
Every store is fast in August. Peak week is decided by what your product and collection templates do on a mid-range phone, on a congested network, at four hundred sessions an hour - measured on real visitors rather than a lab run from an empty office.
Lab scores flatter you: a synthetic run on a fast connection from a nearby server is not the experience you are shipping. Field data from actual Chrome users is the only number that predicts peak behaviour, because it already contains the slow phones and the bad networks.
Almost everyone optimises the homepage, and almost nobody lands there during a sale. Your paid and email traffic arrives on product and collection pages. Those are the templates that decide the week, and they are usually the heaviest ones in the theme.
Hero media that is lazy-loaded, fonts that arrive after the text, and third-party scripts sitting on the critical path. Each is individually defensible and collectively the reason a well-built theme measures badly.
Apps get installed for a test, a campaign, or a previous agency, and then keep injecting storefront JavaScript long after anyone remembers why. Individually each one is small. Together they are the single most common reason a fast theme measures slow.
List every app that injects JavaScript into the storefront, what it does, who asked for it, and what it costs in main-thread blocking time. Then decide, per app, whether it earns its place through peak. Most stores find at least three that do not.
A dated freeze, a published theme you can revert to in one action, and one named person allowed to break the freeze. On the day, the plan matters more than the code: the question is never whether something will go wrong, it is how fast you can undo it.
Cache hit rate under load, image formats and weights, and how much of your peak traffic is bots, scrapers and monitoring rather than shoppers. That last number surprises people, and it changes what your infrastructure has to survive.
Discount logic behaves differently once it meets a real cart: stacked codes, gift-with-purchase, bundles, subscriptions, free-shipping thresholds and a second currency. Most stores validate the offer in a spreadsheet and discover the edge cases live, from customer emails.
Not a preview, not a staging approximation: real carts, real combinations, on a throttled mobile connection. Include the combinations you did not design for, because your customers will find them within the first hour and post them.
Your sync interval was set for a normal week. At peak velocity the gap between sold and synced is where oversells live, along with ERP, 3PL and marketplace webhooks that retry silently, or not at all.
Any remaining legacy checkout customisation, plus the express wallets, local methods and B2B terms that only some of your customers use. These fail quietly for a segment rather than loudly for everyone, which is why they survive until November.
A consent change, a duplicated pixel or a broken server-side event does not throw an error. It moves revenue into "direct" - and you spend the most expensive week of the year making budget decisions from numbers that are quietly wrong.
Place a single test order and follow it. It should appear once in GA4, once in the Meta conversions API and once in Klaviyo, with the right value and the right currency. Duplicates inflate ROAS, and inflated ROAS is how brands overspend into a bad week.
Most tracking is verified once, by someone who accepted every cookie. Test the other path too: the visitor who declines, the visitor in a stricter region, and whatever your server-side layer does when the browser sends nothing.
Peak is the cheapest list growth of the year and the easiest week to burn a sending domain. Capture has to be live and tested, core flows switched on, and the volume ramp planned rather than discovered on the second send.
Twelve checks, what "ready" looks like for each, and the freeze timeline - formatted to hand to a developer or forward to whoever signs off the work.
The same twelve checks you have just read, plus the freeze timeline and a one-page summary your developer can work from. Free, and we send it straight to your inbox.
On its way. If it has not landed in a few minutes, check promotions or spam. You can also grab it directly:
Download the PDFThe same finding gets a different recommendation in September than it does in November. Any audit that ignores the date is selling you a project rather than a peak week.
The only month where structural work is still safe: theme refactors, app removals, template rewrites, migration decisions.
Change freelyTargeted fixes, promotion logic built and tested end to end, tracking verified, load and fulfilment paths rehearsed.
Change carefullyFreeze roughly two weeks before Black Friday. After that, only provable revenue bugs get touched, and every change has a rollback.
Change rarelyMonitoring, not building: conversion by device, checkout errors, sync failures, sending health, and a named person on call.
Do not changeBuilt by our own specialist agencies - ForgeCRO for audits and CRO, RetentionControl for retention. Between them they cover a real share of this playbook before you spend anything. See the full toolkit.
Eleven questions, then a senior reviewer reads your store personally and writes back. Not a score - an actual review of your conversion path before peak.
Request the CRO audit ↗The other half of peak week: whether your flows, segments, capture and sending reputation can carry the volume you are about to add to them.
Run the retention audit ↗Crawls your storefront and checks Core Web Vitals against real Chrome user data - the same field numbers Part 01 is about, for your own URLs.
Run the SEO audit ↗Tests your store against 13 real AI shopping agents. Increasingly the first place a customer asks what to buy, and invisible in every analytics tool you own.
Run the AI visibility audit ↗What another point of repeat rate is worth on your numbers. Useful in November for deciding what the December programme has to earn.
Calculate your ROI ↗If peak proves the platform is the ceiling rather than the pages, this prices the move honestly before anyone commits to it in January.
Price a Plus migration ↗One engineer, three to five working days, your actual store rather than a sample of it. No junior handoff, no template report with your logo dropped in the corner. If we find nothing that threatens your peak week, we will tell you that too - it is a cheaper answer than finding out in November.
Ten slides on what the audit covers, what you get and what it costs - for whoever signs off the work.
Tell us where the store is and what you are worried about. A senior engineer replies within 12 hours - not a form autoresponder.
Seventeen slides on how we build: the architecture decisions, two case studies, the process, and how scope and price are fixed before anything starts. Read it here or take the PDF.
Black Friday falls on Friday 27 November 2026 and Cyber Monday on Monday 30 November 2026. In practice the trading window is wider: most brands open early access in the first half of November and keep discounting into the first week of December, so the traffic profile your store has to survive starts roughly three weeks before Black Friday itself.
That the store keeps working when the variables all move at once: more concurrent sessions, a heavier mobile traffic mix, discount logic that only fires during the sale, inventory moving faster than your sync interval, and paid traffic that has to be attributed correctly to be worth buying. A store can look perfect in August and still fail on any one of those. Readiness is about the failure modes, not the design.
No. It is written for Shopify and Shopify Plus, and most of it applies equally to both. Plus-specific areas - Functions, checkout extensibility, Flow, B2B catalogs, multi-store - are covered where they exist. If you are on another platform we will tell you honestly whether the audit is worth your money before you pay for it.
A tool tests a page. A senior engineer tests a path. Automated scans are genuinely useful for what is measurably wrong - Core Web Vitals, missing tags, render-blocking scripts - and we give four of them away free. What they cannot do is put three items in a cart with a stacked discount and a gift-with-purchase, on a throttled mobile connection, and tell you the promotion breaks. That is the part that costs stores their peak week.
Three to five working days from receiving store access. You get a written report of what we found, each item ranked by revenue risk and by how long it takes to fix, a recommended code-freeze date for your specific stack, and a prioritised fix list your existing developer can work from. A 45-minute walkthrough call is included so you are not left interpreting a PDF alone.
Yes, and the honest answer changes with the date. In September there is time to rebuild things properly. In October there is time to fix and test. In November the right advice is usually to stop changing things, fix only what is provably breaking revenue, and freeze - and a good audit will tell you that rather than sell you a project you cannot safely land before peak.
Either. The audit is a standalone deliverable and plenty of brands hand it to their in-house team or their existing agency - a perfectly good outcome, and the report is written to be usable that way. If you would rather we implement, we scope that separately at a fixed number after the audit, so you are never approving work before you know what it is.
Every problem in this playbook is cheaper to fix now than it is to discover live. Send us the store and a senior engineer will tell you, in plain terms, what would break.
Every call ends with a written plan and a fixed number, whether or not we work together.