How to review a staging site: a guide for teams and clients

A staging site is a copy of your website where changes are tested before they go live. It’s where a redesign gets reviewed, where new features are checked, and where clients see the site before the public does. Reviewing it well is the last cheap chance to catch problems.

But staging reviews have their own pitfalls. People review the wrong environment, report “bugs” that are just test data, or approve changes without checking the parts that matter. This guide covers how to review a staging site properly — whether you’re on the project team or a client who’s just been sent a link.

Staging, production and everything in between

A quick vocabulary check, because confusion here causes real problems:

Local / development: the developer’s own machine. Not for review.
Staging (or preview, test, UAT): a private copy of the site, set up to look like the real thing, used for review and testing.
Production (or live): the public website your customers see.

Staging sites usually have a different address — something like staging.example.com, example-preview.hosting-provider.app or a random-looking preview URL. Always check the address bar before you start reviewing, and before you report anything.

What’s different about staging

Staging is meant to behave like production, but it rarely does so perfectly. Know what to expect:

Test content and data. Products, orders, users and blog posts may be samples. Don’t report “Lorem ipsum” as a bug if the team told you content is still coming — but do report it if this is the final review.
Hidden from search engines. Staging sites are (and should be) blocked from search engines, often with a password or a “noindex” tag. That’s correct on staging and a launch-day disaster if it leaks to production.
Integrations in test mode. Payments, emails and CRM connections may be switched off or sending to test accounts. Ask before testing them, and don’t use real card details unless told to.
Slower or different performance. Staging servers are often smaller. Judge speed carefully.
Changing underneath you. Developers may deploy fixes during your review. If something suddenly looks different, refresh and check.

Before you start reviewing

Get answers to these from the project team:

What’s the staging URL, and are there login details?
What’s in scope? Which pages or features changed, and which haven’t been touched?
What kind of feedback is wanted this round? Content, design, functionality, or final sign-off?
What’s known to be unfinished? So you don’t report it.
What should I test, and how? Any test accounts, test card numbers or sample data to use.
Where does feedback go, and by when?

If you’re running the review, send this information with the link. It removes most of the noise from the feedback that comes back.

What to check on a staging site

Tailor this to the scope, but these are the areas that matter most.

The changes themselves

Does each new or changed page match what was agreed (design, copy, functionality)?
Do new features work end to end — including error cases, not just the happy path?
Did the change break anything nearby? Check related pages, shared components like headers and footers, and anything that uses the same template.

Content

Final copy is in place where it should be
Names, prices, dates and contact details are correct
Images are final, sharp and appropriately cropped
No leftover test text in visible places (“test”, “asdf”, sample names)

Layout across devices

Check at desktop, tablet and phone widths — at minimum
Navigation works on mobile
Nothing overflows or overlaps
Long content (big headings, long product names) doesn’t break layouts

Forms and flows

Forms submit and show confirmation
Validation messages make sense
Multi-step flows (checkout, booking, sign-up) work end to end with test data
Emails triggered by actions arrive and look right (if enabled on staging)

How to give feedback on a staging site

Always include the URL

Staging URLs can be long, and the same page may exist on staging and production. Copy the exact address from the browser. If you’re using a tool where comments are pinned to the page, the URL is captured for you.

Point at the exact element

“The pricing box on the right” is ambiguous on a phone. Commenting directly on the element removes the guesswork. With ClientTweak, for instance, you paste the staging URL into a project — nothing needs to be installed on the site — and reviewers click the element they mean and leave a comment pinned to it. Clients can join from a share link without creating an account.

Note what you were using

For anything that looks wrong or doesn’t work, add your device, browser and window size. Problems on staging are often specific to one browser or width.

Separate bugs from changes

A bug is something that doesn’t work as agreed. A change request is something you’d now like to be different. Both are valid, but they’re handled differently — bugs are fixed, change requests are discussed, estimated and scheduled. Label them.

Prioritise

Mark what must be fixed before the changes go live. Everything else can be scheduled.

Running a staging review as the project team

If you’re the one sending the staging link, a few habits make reviews much smoother:

Freeze deploys during a review window, or announce them. Reviewers shouldn’t chase a moving target.
Seed realistic content. Reviews on half-empty pages produce feedback about emptiness, not about the design.
Give test credentials and test card numbers in the review brief.
Keep one feedback channel. If comments arrive in five places, some will be lost.
Triage daily during a review round: confirm, ask for detail, or park each comment.
Resolve visibly. Mark fixed items resolved so reviewers can re-check them.
Send findings to your tracker. If developers live in Jira, Asana, ClickUp or Trello, route review comments there instead of retyping them. ClientTweak can create a task from each comment in all four.

Reviewing a staging site as a client

If you’re a client who’s been sent a staging link, a few extra pointers:

Don’t share the link publicly. Staging sites are private for a reason — unfinished content, test data, sometimes confidential launches.
Expect some rough edges in early rounds. Ask the team what’s finished before you start, so you spend your time on what’s ready.
Bookmark the staging address so you don’t accidentally review the old live site.
Use the feedback method the team asked for. If they’ve sent a review link where you can comment on the page, comment there rather than replying by email; it keeps every comment attached to the right place.
Involve your colleagues early. If someone else at your company needs to approve the site, ask them to review in the same round, not after you’ve signed off.

Keeping feedback organised across rounds

Staging reviews usually happen in rounds: a first look, a round of changes, then sign-off. Between rounds:

Resolve fixed comments so it’s obvious what’s left
Reply to anything you won’t fix, with the reason
Re-check fixes on staging before the next round starts
Keep a short “known issues” list so reviewers don’t report the same thing twice

Before promoting staging to production

When review is done and the changes are approved, a short checklist before going live:

All must-fix issues are resolved and verified on staging
Content is final and approved
Staging-only settings won’t be copied to production: noindex tags, password protection, test API keys, test email recipients
Production-only settings are ready: analytics, live payment keys, real email destinations
Redirects are in place for any changed URLs
There’s a rollback plan if something goes wrong
Someone checks the key pages on production straight after release

For a full launch checklist, see the website launch QA checklist.

Common staging review mistakes

Reviewing production by accident — and reporting that the changes are missing.
Testing payments with real cards on a staging checkout connected to a live payment account.
Approving the homepage only. Changes to shared templates affect every page that uses them.
Treating test data as bugs — or missing real bugs because “it’s just staging”.
Feedback with no location. “The form doesn’t work” — which form, on which page, doing what?

The short version

Confirm you’re on staging. Know the scope, what’s unfinished and how to test. Check the changes, their neighbours, content, devices, forms and links. Give feedback with the URL, the exact element, your device and a priority. And before promoting to production, make sure staging’s settings stay on staging.