Ecommerce Store Health Check

The code and theme live in an account your company owns.

If the repository sits in an agency's account, the history and the way to deploy leave when they do.

You hold the owner logins for the domain registrar and DNS.

Whoever controls DNS can take the store offline or point it somewhere else.

Every former agency and freelancer has had their access removed.

Access granted for an old project is the most common door nobody remembers is open.

Every admin account uses two-factor authentication.

A stolen admin password is enough to change prices, payments or customer data.

You know whose every SSH key and hosting login is.

An unknown SSH key is server access you cannot account for.

The Shopify store owner account belongs to your company, not to an agency.

The store owner account can remove everyone else, including you.

Security updates go live within a set number of days of release.

Attacks on a published vulnerability can start within days of the fix.

Someone reviewed the installed extensions or apps in the last 12 months.

Every extension or app is someone else's code running inside your store.

A named person reads the security alerts for your platform.

An alert nobody reads is the same as no alert.

You keep a list of every script that runs on your payment pages.

Card-skimming code hides in scripts on the payment page, and PCI DSS now asks merchants to track them.

The store runs a release line that Adobe still supports.

A line out of support stops getting security fixes in its regular releases.

Every installed app is still maintained by its developer.

An abandoned app keeps running with the permissions it was given.

A recent copy of products, customers and orders exists outside the live store.

If the platform or host has a bad day, this is what you rebuild from.

Someone has restored from a backup at least once, to prove it works.

An untested backup is a hope, and restores fail more often than backups.

Monitoring alerts a person when the site or checkout goes down.

Without it, customers find the outage before you do.

There is a written plan for who does what in an outage.

In an outage, the first hour goes on working out who to call.

A staging copy of the store exists and matches production.

Without staging, every change is tested on paying customers.

Theme changes are made on a copy of the theme, never on the live one.

An edit on the live theme is visible to customers the moment it is saved.

All custom code is in version control.

Code that is not in version control has no history and no way back.

Releases pass tests or a written checklist before they go live.

Most broken checkouts come from a release nobody tested end to end.

A bad release can be rolled back in minutes.

A fast rollback turns a broken release into a few minutes instead of a lost day.

More than one person knows how to release the store.

If one person holds the steps, their holiday is your release freeze.

Deployments run without taking the store offline.

Every minute of maintenance page is a minute of lost orders.

The theme is connected to a Git repository, so every change has a history.

Without history, nobody can say which change broke the theme.

Product and category pages pass Core Web Vitals on mobile.

Slow mobile pages lose shoppers and are measured by Google in search.

Analytics and conversion tracking were checked after the last release.

A release that silently breaks tracking makes every report after it wrong.

Tracking waits for consent wherever your visitors' laws require it.

Tracking that fires before consent is a legal risk in many states and countries.

Someone bought something on a phone, end to end, in the last month.

A real purchase is the only test that proves the whole path still works.

Cron jobs and indexers run on schedule without errors.

Stalled cron or indexers mean stale prices, stock and order emails that never send.

You know which apps load scripts on every page.

Every app script loads on every page and slows the store for every visitor.