Staging environments and testing before release

Why staging matters

• Safe testing of new features, updates and integrations.
• Client review of work in progress without exposing it publicly.
• Reproducing bugs reported by users without touching the live site.
• Rehearsing launches and migrations, including data transfers.

Setting it up

• A separate address, such as a subdomain, protected by a password or restricted to certain networks.
• noindex directives and blocked crawling as a second layer — but do not rely on robots.txt alone, which is public and not a security measure.
• Separate credentials for payment providers (test mode), email (test inboxes) and integrations, so staging never charges real cards or emails real customers.
• Configuration that clearly indicates it is staging — for example, a visible banner — so nobody confuses it with the live site.
• Deployment from the same code and process as production. See CI/CD.

Data on staging

Copying the production database to staging is convenient but can expose personal data to more people and systems. Options: anonymise personal fields when copying, generate realistic test data, or restrict staging access strictly. This is part of meeting data protection obligations. See personal data law.

What to test before each release

Functional

• Forms submit and deliver; confirmation messages appear.
• Payments complete in test mode, including failures and refunds.
• Accounts: registration, login, password reset.
• Integrations: CRM, 1C, delivery services receive and send data correctly.
• Search, filters, booking and other interactive features.

Content and languages

• Every language version displays correctly, with no untranslated strings.
• Long words and phrases do not break layouts.
• Dates, numbers and currency are formatted correctly.

Devices and browsers

• Recent versions of major browsers on desktop and mobile.
• At least one mid-range Android phone and one iPhone.

Technical

• No errors in the browser console or server logs.
• Speed of key pages has not regressed.
• SEO settings: titles, descriptions, canonical tags, structured data.
• Analytics events still fire.

Security

• New features respect permissions: users cannot see others' data.
• Inputs are validated on the server.
• Dependencies updated and scanned for known vulnerabilities.

Acceptance testing by the client

Acceptance testing checks that the result matches what was agreed. Prepare real scenarios — "a customer orders two items with delivery and pays by card", "a manager changes the price of a product" — and walk through them on staging. Record issues with steps to reproduce and screenshots. See software testing for clients.

Deployment

After testing, the same version is deployed to production, ideally automatically, with a way to roll back quickly if something goes wrong. Smoke tests after deployment confirm that key functions work on the live site.