What does a good accessibility monitoring baseline look like for a new Shopify store?

A monitoring baseline is the clean scan that every future alert gets compared against. Set it up wrong and you spend months chasing noise. Set it up right and the first real regression stands out immediately, with the context to fix it fast.

Fix first, then freeze the baseline

A baseline captured on a broken store is worse than no baseline, because every alert inherits the noise. Before freezing it, fix the known issues on the core templates or at least triage them into a punch list with owners. The baseline should represent the store as it is supposed to be, not as it happened to be on launch day.

This does not mean waiting for perfection. It means the team agrees the remaining issues are known, documented, and scheduled. A baseline with 12 documented exceptions beats a baseline with 200 undifferentiated failures. The exceptions become the first entries in the exception log described below.

Cover every template, not just the homepage

Homepage-only baselines miss most of a store. The baseline scan set should include the homepage, a collection page, a product page with options, the cart, the search results page, the blog article template, and the policy pages. If the store has a custom landing page template or a quiz, include those too.

Checkout deserves special handling on Shopify, since the platform controls most of it. Baseline what you can observe: the cart drawer, the checkout entry point, and any checkout extensions the store uses. Note clearly which checkout surfaces are platform-owned, so a future alert on them routes to the right conversation instead of a panic.

Record known exceptions with owners and dates

Every baseline has exceptions: a third-party review widget with imperfect markup, a platform limitation nobody can change, a decorative carousel the team plans to replace next quarter. Write each one down with the reason, the owner, and a revisit date. An undocumented exception is just a failure you decided to ignore.

The exception log is also what keeps alerts trustworthy. When the monitoring flags a known exception, the team should be able to see in one click that it was already triaged, instead of re-investigating it every time. Alert fatigue is the number one killer of monitoring programs, and the exception log is the main defense.

Set alert routing before the first alert fires

Decide now who gets woken up and who gets a morning email. Critical template regressions, like the product page or cart, should page whoever can roll back a theme or disable an app. Lower-severity findings can wait for the weekly review. Write the routing down and test it once with a synthetic alert.

Include the client or stakeholder in the plan if an agency runs the monitoring. Nothing erodes trust like a client learning about a regression from a customer tweet when the agency knew for three days. Agree in advance what gets communicated, how fast, and in what words.

Re-baseline on purpose, never by accident

A baseline goes stale the moment a theme update, redesign, or major app change ships. The discipline is to re-baseline deliberately after intentional changes, with a note about what changed and why, rather than letting the old baseline silently stop matching reality. Schedule the re-baseline as part of the deploy checklist for big changes.

Keep the old baselines. They are the history that proves diligence over time: this is what the store looked like in March, this is what changed in June, this is what we fixed in September. If a demand letter ever references a past state of the site, the baseline archive is the evidence.

What the baseline report should contain

The baseline report is one document: the date, the templates scanned, the tool and configuration used, the exception log with owners, the alert routing, and the sign-off. Store it where the business can find it without asking the developer who set it up. A baseline that lives in one person's head is not a baseline.

Review the baseline document itself once a quarter. Exception revisit dates arrive, alert routing goes stale when people change roles, and templates get added. Fifteen minutes a quarter keeps the foundation solid, which is the whole point: monitoring is only as good as the baseline it compares against.