Who can access your staging website before launch?

Define the preview boundary in writing

An address that is difficult to guess is not access control. The agency and client should agree who may view the draft and when their access should end. If confidential prices, customer lists or real user records are present, ask why they are needed in the preview at all. Avoid copying live information simply because it is convenient.

Early design reviews can often use clearly labelled sample data. Assign someone to ensure sample names and prices do not reach the final release. Before distributing the preview widely, check what a browser without an authenticated session can see. Your own logged-in view is not enough evidence of the access boundary.

Separate access from search visibility

A password or appropriate authentication restricts access by unauthorised visitors. A noindex rule tells supporting search engines not to index content; it does not make the page private. Google’s guidance on controlling shared content treats access protection as a separate option for private information.

Google also explains that its crawler must be able to encounter a noindex rule. Blocking crawling through robots.txt is not equivalent. Discuss the implementation with the responsible developer rather than assuming one search setting protects a confidential draft. The practical objective is to give reviewers the access they need while keeping the publication boundary explicit.

Identify controls that perform real actions

List forms, email destinations, payments, bookings and notifications separately. Record whether each connects to a test or live environment. A visible “test” label does not prevent a real notification behind the scenes. Ask the integration owner to verify which account and destination are actually configured.

If review activity should not appear in the sales team’s queue, plan a test destination or suitable sandbox. Start with checks that do not create payments or real customer records. This article is not a payment setup guide; it is a way to make responsibilities and side effects visible before colleagues begin exploring the preview.

Open a preview handover note

Treat the live release as another verification step

Preview approval does not prove the production environment works correctly. After launch, check content, form destinations, canonical addresses and intended indexing settings on the real domain. Verify that a staging noindex rule has not accidentally reached the public site, while avoiding indiscriminate removal of access protections.

Keep a rollback copy and a record of changed files. Our Gerhman project page is portfolio context only; this article discloses no access configuration for that website. Include separate responsibilities for preview review, approval and live verification in the website handover scope. Complement these checks with the practical tasks in our usability-session guide.