Serving the snippet in staging only – the three usual routes
The simplest route is an environment flag at build time: in React, Next.js, Nuxt or Astro the snippet only renders when the environment variable says "staging" or "preview". In classic CMS setups, condition it on the hostname (`staging.example.com`) instead, or add the snippet only in the staging instance, which usually has its own configuration anyway. On Vercel or Netlify previews, reading the context variable is enough: every deploy preview gets the snippet, production does not.
Basic auth: what clients get and what they don't
Because the snippet is served inside the protected environment itself, existing access restrictions apply unchanged. With basic auth that means the client needs the staging username and password or they see nothing at all. Hand those out once, scoped to the project – never your CMS credentials. Note that basic auth does not stop search engines from learning the hostname; add `X-Robots-Tag: noindex` on the staging domain as well.
VPN, IP restrictions and external clients
IP allowlists and VPN work well for internal teams but block exactly the people whose approval you need. A password-protected preview domain reachable from outside is far more practical. If the client must use VPN, schedule the review as a guided session – otherwise sign-off slips on a network hurdle instead of on actual content.
Keeping staging out of the index
Review environments must not rank. Set `noindex` via HTTP header on the staging domain, keep `robots.txt` restrictive and never emit canonicals pointing at staging. Also make sure the staging instance's sitemaps are not publicly reachable – the same content served on two hosts is one of the most common self-inflicted SEO problems during relaunches.
Cleanly separated environments
Create one project per environment (staging, live). Sign-off feedback and live reports stay separate and status lists stay meaningful. At go-live you close the staging project instead of mixing both data sets, which keeps the sign-off history intact as evidence.
Notes across deploys
Notes are attached to a URL and an element. As long as path and markup stay stable, you find them in the same spot after a deploy. If the structure changes fundamentally – new template, different class names – the note keeps its screenshot crop and URL, but the anchor to the element can be lost. Before larger rebuilds it pays to clear the open items first.
Before go-live: hand feedback over as tasks
Shortly before launch, prioritisation is what counts: open items per page, split into "blocks launch" and "after launch". Every note can be handed to Trello, Asana, Jira or GitHub as a task – with URL, element and screenshot, so nobody in the sprint has to guess what was meant.
