Testing Third-Party Widgets on a Staging Site

Staging site testing means adding a widget to a private copy of your store first, checking it carefully, and only then copying the change to the live store. This protects checkout and product pages from a script that breaks your layout or slows your site.

This guide is for owners and developers of WooCommerce, Wix and custom stores who add scripts such as size finders, chat tools or try-on buttons.

What is a staging site?

A staging site is a copy of your store that only you can see. It uses the same theme and plugins, but it does not take real orders or show to shoppers.

Ways to get one include:

• WooCommerce. Many hosts offer one-click staging, or you can clone the site to a subdomain.
• Custom sites. Deploy a preview branch to a separate URL.
• Platforms without staging. If your platform has no copy feature, use a duplicate theme or test site and publish when ready. Check your platform's help pages for the current options.

Block search engines on staging so the copy is not indexed.

Why not test on the live store?

A live test exposes shoppers to your experiment. A broken button, a covered "Add to cart" or a slow script costs sales while you work it out.

Staging also lets you try the worst cases, like removing the widget again, without a rush.

How do you set up the widget on staging?

1. Copy the live store. Make sure the theme, plugins and product templates match production.
2. Use a key that allows the staging domain. If the widget uses a domain-locked key, it must allow the domain you test on. With ZeDaq.ai, the key must be locked to the store's domain in Dashboard → API keys, so check that setting for your staging domain.
3. Add the script. For ZeDaq.ai, you paste <script src="https://www.zedaq.ai/widget/zedaq.js" data-key="…" defer> into the product template. Setup details are in the widget docs.
4. Load a test product. Pick one product for each garment type you sell.

Keep notes on every change, so you can repeat them on production in the same order.

What should you test?

Use a checklist. Test each item on a phone and on a desktop.

• Does it load? The button appears on the right pages only.
• Does it work? Open it, complete a task and close it.
• Does it break anything? Check "Add to cart", variant pickers, image galleries and checkout.
• Is it fast? Compare page load before and after.
• Does the browser complain? Open the developer console and look for red errors.
• Is it accessible? Tab through it with a keyboard. The article on accessibility for product page widgets has the steps.

What commonly goes wrong?

Some problems show up repeatedly with third-party scripts:

1. A blocked script. A content security policy can stop external scripts from loading. See content security policy and third-party widgets.
2. A domain mismatch. The key is locked to one domain, and the request comes from another. The API returns a domain_not_allowed error, as listed in the API docs.
3. A caching issue. A page cache serves the old template without the script.
4. A theme conflict. Another script or style hides the button.
5. A platform limit. Some platforms load scripts through a manager. The guide to the BigCommerce Script Manager shows one example.

How do you check the data and costs?

A staging test still uses real vendor accounts. Check how the vendor counts usage on test calls, because some plans count every request. On ZeDaq.ai, the Free plan includes 3 try-ons a month, which is enough for a small test, and paid plans have a 3-day free trial with no card required.

Use your own photos and products for testing, not shoppers' images. Delete test data when you finish.

Who should sign off before launch?

Ask one other person to run the checklist too, ideally someone who did not build it. They will try things you would not think of, such as using the back button or rotating a phone. Agree on a clear pass mark, such as "no console errors and no change to checkout".

How do you move from staging to live?

1. Write down each setting you changed.
2. Create the production key, locked to the live domain.
3. Add the script to the live product template.
4. Test one product page right away, on mobile and desktop.
5. Watch the console and your store's sales for the next day.

If something fails, remove the script tag. A widget that is added in one line is usually removed in one line.

For developers who want to go further, the virtual try-on API guide shows what you can build beyond the widget.

FAQs

Do I need a staging site for every widget?

Not every small script, but any that touches product pages, cart or checkout deserves a test copy.

Can I test with a live key on staging?

If the key is locked to your live domain, requests from staging will be rejected. Make sure the key allows the staging domain.

Will search engines index my staging site?

They can, if it is public. Add password protection or a "noindex" setting to avoid duplicate content.

How long should I test before launch?

Until your checklist passes on both phone and desktop. For a simple script, that may be one sitting.