You send the client a staging URL. They reply that the page is asking for a username and password, or it just spins and times out, or they get a blank 403. On your machine it loads instantly, so the first instinct is to blame their browser. It is not their browser. Staging environments are deliberately walled off, and the wall is doing exactly its job by keeping your client out.
Why the client hits a wall you never see
Three mechanisms keep search engines and strangers away from an unfinished build, and all three trip up an outside reviewer.
Basic auth. Many staging setups add an HTTP basic-auth prompt at the server level. You typed the credentials into your keychain weeks ago and forgot. The client sees a raw browser dialog with no styling and no instructions, assumes the link is broken, and gives up.
IP allowlisting. The staging server only answers requests from a short list of addresses: your office, your VPN exit node, maybe the hosting provider. The client's home connection is not on the list, so their request is refused before a single pixel renders. Nothing they do on their end changes that.
VPN-only access. Some agencies put staging behind a corporate VPN. Getting a client onto that VPN means provisioning an account, sending a config file, and walking them through a client app they will use once. Most clients will not do it, and you should not ask.
Each of these is a security decision, not a bug. Poking holes in them so one reviewer can look at one page is how staging sites end up indexed by Google or scraped before launch. The fix is not to open the wall. It is to stop sending the client through it.
Capture the screens, share a link that opens for anyone
You already have access. Your machine renders staging fine. So put the reviewing burden where the access already exists: capture what you see, and hand the client output that lives on the public web instead of behind the wall.
Open a browser tab, click Capture screen, and pick the staging window. The current frame is drawn to a canvas. Crop to the part that matters, then type or dictate a comment about it. Each captured screen becomes an item. Add a numbered pin to point at the specific field or button you want the client to weigh in on. Repeat for every page you need signed off. When you Publish, the whole set gets a short public URL of the form /r/<slug> that anyone can open with no login, no VPN, and no basic-auth prompt.
That is the core of a staging site review the client can actually reach: the protected environment stays protected, and the client reviews stills of it on a link that behaves like any other page. No install, no browser extension, no account required on their side.
Cobalt Capture is free, and you can start a new review without signing up. An anonymous review is kept for 30 days; if you sign in later, it becomes yours permanently.
What the client does with the link
They click it and read your captures top to bottom. On any item, they can post a comment: "the promo banner copy is wrong here," "this CTA should say Get started, not Sign up." You mark each comment resolved as you work through them, so both sides can see what is still open without a bug tracker or a project board in the mix.
Because the review is stills rather than a live page, the client cannot accidentally submit the test checkout or trigger a staging email blast. They are looking at a frozen frame you chose, with the context you cropped in and the noise cropped out. If you have ever watched a client wander off the page you asked about and start reporting issues on an unrelated screen, a cropped still keeps the conversation where you put it.
If your client is spread across time zones and you are rarely online together, this works better than a call. They review when they can, comment on the items, and you pick up the thread later. That is the whole point of feedback that does not require you both to be awake at once.
When developers need to see it too
The same published review exports as plain-text markdown at /r/<slug>/markdown, and as a PDF or Word document. So the client gets the readable link, and your developer gets a version they can paste into a ticket or an editor. If the fixes go to an AI coding agent, the markdown is the format it reads cleanly, which means one capture pass serves the client and the developer from the same source.
For the full sequence of walking a build page by page before launch, the staging review walkthrough covers what to capture and in what order. And if your reviewer is on Firefox, dictation will not work there, so they type comments instead; that path still ends in the same published link.
Next time the client says the staging URL is broken, do not open a firewall port. Capture the pages you want signed off, publish, and send the link. The wall stays up and the client still gets to review.