Before the new page goes live
Test Testimonial Widgets on Staging Sites
A staging copy of your site is where a testimonial widget should fail, not the launch morning. The awkward part is that the testimonials themselves are live data: approve a test entry to see it on staging and it can appear on your real site too. This checklist sets up a safe test, covers what to look at on the preview domain, and makes sure what you tested is exactly what ships.
- Keeps test testimonials away from live pages
- Covers preview domains, phones and launch day
- Ends with a copy of the exact code to ship
The problem, solved
What goes wrong when a widget is tested on staging
Situation 1 of 5
Our test quote showed up on the real site
Someone approved “This is a test, lorem ipsum” to see it on staging, and the same widget was already embedded on a live page.
How StoryProof solves it
Each widget shows only the approved testimonials you choose for it. Build a separate test widget for staging, so anything picked for testing never reaches a widget that live pages use.
Situation 2 of 5
The staging widget is empty
The new site is ready, but the testimonials you collected are still waiting for review, so the preview shows a box with nothing in it.
How StoryProof solves it
Only approved testimonials can appear anywhere. Approve a handful of real ones and choose them for the widget before the review meeting, rather than inventing filler.
Situation 3 of 5
We filled the form ten times to test
Every submission through your collection link is a new testimonial, and repeated test runs quietly use up the month’s allowance.
How StoryProof solves it
Collected testimonials count toward the monthly allowance on your plan. Send one or two test submissions, leave them unapproved so they never go public, and test the display with real approved entries.
Situation 4 of 5
Staging works, production blocks the script
Production sends security headers that staging does not, so the widget passes every test and disappears at launch.
How StoryProof solves it
The script loads from app.storyproof.io, so copy production’s Content Security Policy to staging, or check in advance that it allows that host for scripts and connections.
Situation 5 of 5
Nobody checked it on a phone
The layout looked right on the designer’s wide monitor and wraps badly in a narrow column on a real handset.
How StoryProof solves it
Try the layout you chose against the actual column it sits in. There are several layouts, from walls and carousels to compact badges, so a cramped slot can switch to a smaller one before launch.
Pre launch checklist
Test your testimonial widget before launch
Run it on the staging or preview domain first, then the last group on launch day against the live domain.
Your ticks stay in this browser tab and are not sent anywhere.
Reuse the live widget on staging, or build a test one?
In StoryProof
From staging to launch without surprises
- 1
Decide test widget or live widget
Use the table above. If any live page already shows the widget, build a test one so your experiments stay off the current site.
- 2
Fill it with real approved testimonials
Choose existing approved entries of different lengths, including a video if you have one, so the test matches what visitors will see.
- 3
Embed it on staging the way production will
Paste the div where it belongs and load embed.js once per page in the same template slot you will use on the live site.
- 4
Run the checklist on every screen size
Phone, tablet and desktop, with the real column widths. Swap the layout now if the slot is too tight.
- 5
Ship the same code, then test live
Copy the code across, swap in the live widget id if needed, and run the launch day group against the production domain.
What happens next: Write down which widget id serves which live page. The next person to touch the site will need it.
Before you start
Limits worth knowing before you test
Testimonial data is not split by environment
Staging and live read from the same StoryProof account. Separation comes from using different widgets, not from a sandbox copy of your testimonials.
A test widget uses an allowance slot
Widgets are counted per workspace, so a spare test widget may not fit on a smaller plan.
Test submissions still count
Anything submitted through your collection link is a new testimonial for the month, even if you never approve it.
Staging settings can differ silently
Hosts often add password protection, caching or security headers only on one environment. A pass on staging is strongest when the two are configured alike.
This is a functional check, not a conversion test
It proves the widget works and looks right. Whether it persuades visitors is a question for a test on live traffic.
FAQ
Questions people ask
Short answers to what usually comes up next.
Can I use the same embed code on staging and on the live site?
Yes, the snippet is the same two lines on any page: a div with the widget id and the embed.js script. The only thing you might change between environments is the widget id, if you tested with a separate widget.
Will testimonials I approve for testing appear on my live site?
They appear in any widget they are chosen for. If the widget you test with is also embedded on a live page, yes. A separate test widget avoids that.
Our staging site is password protected. Will the widget still load?
The script runs in the browser of whoever is viewing the page, so a logged in reviewer usually sees it. If it stays blank, compare the console errors on staging and production before assuming the password is the cause.
Should I delete my test submissions afterwards?
Leave them unapproved and they never go public. They have already counted toward that month’s allowance, so the main thing is to keep test runs few.
Still have a question? Ask the StoryProof team or book a demo.
Launch with proof that already works
Build your widget, test it on staging and ship the same two lines to the live site.
Last updated 2026-11-12.