Check a SuiteCommerce release in your sandbox before it ships
Audit the release where it already runs — the storefront on your NetSuite sandbox — then compare that audit with production’s latest. The release check lists the findings the release introduces, the ones it fixes, and what the two audits cannot compare, so a regression is fixed in the sandbox instead of on the live site.
Updated · By Martin Clavell
Why audit the sandbox
A NetSuite sandbox is a separate account: a copy of production where changes are tried before they go live. A new theme, an extension, a SuiteCommerce update or a configuration change reaches the sandbox’s storefront first, so an audit there sees the release while it can still be changed.
A sandbox storefront is also a public website. A secret in its configuration is exposed exactly as it would be on production, and a code defect found there is a defect in the coming release.
1. Link the sandbox to its production domain
- Verify your production domain, if you have not already.
- On that domain’s page, add the sandbox’s hostname under Sandboxes. If our last audit of production saw your storefront refer to a sandbox host, it is offered there to fill in.
- Verify the sandbox. A host under the same domain as production can use production’s verification when that covers the whole domain — an email address at the domain, or a DNS record or tag on the bare domain. Otherwise verify it with a DNS record, which never visits the site.
A sandbox on a different domain from production is checked by a person before it is audited, usually within a working day, and we email you either way. A linked sandbox uses no domain slot: the Pro and Enterprise plans include a sandbox with each production domain (pricing).
2. Audit it like production
Run the sandbox audit at the depth of production’s latest audit, so the two read comparable samples of pages. It costs the same credits as a production audit; what a sandbox saves is the domain slot, not the audit.
A sandbox is usually kept out of search engines on purpose, and the report knows it is a sandbox. Your audit of it overrides robots.txt like any audit by a verified owner (our crawler page says what that means). The checks about reaching the live shop — robots.txt, the sitemap, a site-wide noindex, HSTS and the http redirect, the bare domain, published URLs and verification tags — are listed as not checked on a sandbox rather than reported as defects. Its score is shown, labeled as a sandbox and never benchmarked against other storefronts.
3. Read the release check
The release check sets the sandbox audit against production’s latest. Open it from the sandbox report’s header, or from Release check beside the sandbox on your domain’s page; the email that says a sandbox audit is ready leads with its counts.
- Introduced by this release: on the sandbox and not on production — what ships if nothing changes.
- Fixed by this release: on production and gone from the sandbox.
- Unchanged: on both.
- Not comparable: a check the sandbox does not run, a page measurement, and a finding the other audit could not have reported, with what each audit said.
A finding is matched across the two hosts by its check and what it is about — for a finding on pages, the pages’ paths with the host left out. A finding is never listed as fixed by an audit that did not check for it. No score is compared and no alert is sent: a sandbox is not the live storefront.
Some differences are expected on a sandbox and are not reported as defects: its own host and account, production’s domain keys in its configuration, and a canonical that points at production.
4. Before the release ships
- Nothing under Introduced that you did not mean to ship.
- No exposure finding on the sandbox: it is public now, not only after the release.
- Fix in the sandbox and audit it again; the next release check reads the new audit.
- After the release, audit production and compare it with its previous audit to see what changed on the live site.
Questions
- Does auditing a sandbox cost credits?
- Yes, the same as a production audit at the same depth. A sandbox uses no domain slot, but its pages are fetched and rendered exactly as production’s are.
- Does a sandbox audit change production’s history or score?
- No. The sandbox is its own host with its own history, its score is labeled as a sandbox and never benchmarked, and the release check compares findings, not scores.
- What if another account has already linked my sandbox?
- Prove it is yours. Adding the host on your production domain’s page then offers to prove it with a DNS record, and that proof ends any link from an account that never proved the host and links it to your production domain in the same step. It uses a sandbox slot, not a domain slot, so it works with every domain your plan holds in use.
- Can you audit a password-protected sandbox?
- Not yet. Verify it with a DNS record, then let our crawler through or open the sandbox while it is audited. An audit that meets a password stops, says so and refunds its credits.