# Testing a module before putting it into production

> Installing a module straight onto the store that sells is the most avoidable cause of weekend outages. A test copy changes everything — provided you know what it proves and what it doesn’t.

- Source canonique : [https://allaux.fr/en/modules/tester-un-module-avant-la-production](https://allaux.fr/en/modules/tester-un-module-avant-la-production)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## What a test copy genuinely shows

A faithful copy of the store, on a separate address, gives three things no product listing can: the module’s real effect on your data rather than on a demo catalogue, its cost in page generation time, and the freedom to do destructive things — disable, uninstall, start again — with no commercial consequence.

It is also the only place to check interaction with modules already installed. A module behaves differently alone and among fifteen others, and that difference is only observable on a copy of the site as it really is.

## The three traps of a staging copy

The domain-locked licence. Many commercial modules check the domain name they run on. On a test address the module may refuse to activate, or activate in a degraded mode. Check first whether the licence covers a test installation: some publishers plan for it explicitly, others don’t.

Production data copied as is. A copy contains real addresses, real email addresses and real orders. Outgoing email must be cut and live payments disabled before the first action, otherwise a test order sends a real message to a real customer.

Environment differences. A module that works in test and not in production nearly always reveals a gap in PHP version, installed extensions or server configuration. A useful staging copy is an identical one, not an approximate one.

## A test copy must be invisible to search engines

> A staging site that is reachable and indexable ends up in search results, competing with your own store on identical content. It is protected by restricted access, not merely by a robot exclusion file, which stops nobody from reaching it.

## Related pages

- **A module broken by its own update** — The problem a test copy avoids in most cases. ([/modules/module-casse-apres-une-mise-a-jour](/modules/module-casse-apres-une-mise-a-jour))
- **Duplicating a site to staging** — The duplication procedure on the WordPress and WooCommerce side. ([/wordpress-woocommerce/migration/dupliquer-en-preproduction](/wordpress-woocommerce/migration/dupliquer-en-preproduction))
- **Preparing a major upgrade** — The full method when the whole platform changes version. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))

## FAQ

### Should staging be permanent or one-off?

A copy created when needed is enough in most cases, and avoids maintaining a second site that drifts out of sync. Permanent staging is justified when work is frequent.

### Does my module licence cover a test copy?

It depends on the publisher. Some licences explicitly cover a development installation, others count each domain separately. Check before creating the copy, not after.

### Can we test without copying the real data?

Yes, but you lose the essential part: the specifics of your catalogue and your orders. A test on demo data reveals neither volume problems nor unusual configurations.

### How long should the copy be kept after the work?

Long enough to confirm the production release went well, then it is deleted. A forgotten staging site becomes an un-updated site, and therefore a way in.