Try risky changes on a test copy of the shop first
Risky changes are tried on a test copy first, with the same checks every time, so the live shop doesn't break.
What it replaces: fewer emergency hours after deployments
What you write to Claude
„Same change in two shops: first the test copy staging.client-shop.com, then production. Apply the fix, run a health check and check the affected pages on the test copy, wait for my OK, then repeat on production with a fresh preview.”
The problem
Our rule is 'never on production first', but in practice someone always forgets. We need the same steps every time.
What Claude does
- Claude checks the test copy of the shop before the change.
- It makes the change there, after your approval.
- It checks again and reports what changed.
- After your OK it repeats the change on the live shop with a new preview.
What you get
Every risky change is tried on the test copy first, with the same checks before and after.
You stay in control
You see every change before it is saved, nothing happens without your yes, and you can undo it later. Changes to the shop's look use a separate, extra-protected connection, usually set up by whoever looks after your shop. Every file is backed up before it changes.
Related use cases
- Fix data in bulk, tried on a test copy first
- Fix an error page after an update, with a developer's safety net
- Monthly audit report for an agency client
- Check your add-on customisations before updating the add-on
For developers
- Area
- 3 · Appearance & deployments
- Connector
- service connector
- In the free Audit
- no, paid version only
- For
- Agency / freelancer, Developer
- Tools
- ps_check_shop_health, ps_inspect_page, ps_write_theme_file, ps_list_changes, ps_list_file_backups
Step by step
- Uses two service connectors in Claude: one for the free staging domain, one for production.
- Runs ps_check_shop_health and ps_inspect_page on staging as a baseline.
- Applies the theme change on staging with ps_write_theme_file, after preview and approval.
- Re-checks staging and reports what changed (ps_list_changes, ps_list_file_backups).
- After your OK, repeats on production with a new preview; nothing carries over automatically.
Safety
Block 3 works only through the service connector: a separate token accepted only from allowlisted IP addresses, off after installation. Each connector has its own token and IP allowlist. Staging subdomains of the licensed domain (staging., dev., test., ...) and up to 3 custom dev domains are free. The same staging-first routine applies to Modules (block 4) and Service mode (block 5: files, database, settings), each with its own preview on staging and again on production.
Last updated: 2026-10-05