Staging Site Best Practices: How Freelancers Should Set Up Client Review Environments

A staging site for client review should be a private, password-protected copy of the client's website on a separate URL — never a hidden page on the live site, never indexed by Google, and never shared as a raw link without context. The job of staging is simple: give the client one safe place to look at the work, click around, and leave feedback that you can actually act on. Most freelancers get the first part right and the feedback part completely wrong, which is where every painful revision cycle starts.

This guide covers how to set up staging properly, how to share it without confusing your client, and how to collect feedback in a way that doesn't end with you scrolling through 47 WhatsApp messages on a Sunday night.

The problem with how most freelancers handle staging

Picture this. You finish a homepage redesign on Thursday night. You push it to a subdomain like staging.clientsite.com, send a one-line email — "here's the link, let me know what you think" — and go to bed feeling productive.

Friday morning the messages start coming in. The client texted you a screenshot with a red arrow pointing at "the bit with the picture." Their colleague replied to your email with a numbered list, but it's numbered wrong because she's looking at the about page instead of the homepage. The client's boss saw the staging URL appear on Google because you forgot to noindex it, and is now asking why the new site is "live before approval." Someone left a comment in a Google Doc about the footer that you didn't see until Monday.

By the end of the weekend you have feedback from four people, in four formats, on three different pages, half of which contradicts the other half. You haven't written a line of code. The "two-day revision round" has already cost you a day before it even started.

The staging site itself wasn't the problem. The problem was treating staging like a finished website instead of treating it like a controlled review process. A proper staging setup is half technical (separate environment, password, no indexing) and half communication (one feedback channel, clear instructions, version awareness). Skip either half and you end up where most freelancers end up — buried in unstructured comments, defending decisions you already made, and rebuilding things that were never broken.

Staging vs. preview vs. live: what the words actually mean

Before we get into best practices, three terms get confused all the time. Get them straight and your client conversations get easier overnight.

Environment  ·  Purpose  ·  Who sees it  ·  Indexed by Google

Local / dev  ·  You build and test on your own machine  ·  You only  ·  No

Staging  ·  Client reviews work before launch  ·  You + client (password-protected)  ·  Never

Preview  ·  A quick share of a single page or change (often via Webflow, Figma, Framer)  ·  You + invited reviewers  ·  No

Production / live  ·  The real public website  ·  Everyone, including search engines  ·  Yes

Staging is not a preview link. A preview link from Webflow or Framer is fine for showing a single change ("does this hero look better?"), but for a full review where your client clicks through pages, fills forms, and decides whether to launch, you want a real staging environment that mirrors production.

The 10 staging site best practices for freelancers

Here is the checklist I run through on every project before sharing a staging URL with a client.

1. Use a separate environment, not a hidden live page. Build on a staging subdomain (staging.clientsite.com), a temporary domain you own (clientname.yourstudio.com), or a hosted preview from your CMS (Webflow's webflow.io URL, Framer's framer.website URL, WordPress staging via WP Engine or Kinsta). Never paste a half-finished design onto the real live site under /new or /v2.
2. Password-protect everything. Bare minimum is HTTP basic auth, but a proper login (Webflow Site Password, Cloudflare Access, .htpasswd, plugin-based on WordPress) is better. The password should be different from anything the client uses elsewhere and should be in the same email as the staging link.
3. Block search engines completely. Add a sitewide <meta name="robots" content="noindex, nofollow"> and a Disallow: / in robots.txt. Most CMSs have a "discourage search engines" toggle — turn it on. If staging gets indexed before launch, you create duplicate content issues with the live site later.
4. Mirror production data, not lorem ipsum. Use the client's real copy, real images, real product data wherever possible. Reviewing a site full of placeholder text leads to feedback like "the text is weird" — useless. Real content surfaces real problems (long product names that break a card layout, a CEO bio that's three times longer than the design assumed).
5. Match the production environment as closely as possible. Same hosting tier, same CDN setup, same redirects, same form handlers. If staging is on Netlify free and production is on a $200/month Pantheon plan, your staging tests don't tell you much about how the real site will perform.
6. Use one feedback channel, not five. Decide before you share the link: feedback comes in via dotts comments, or via a shared doc, or via email — pick one. If your client tries to text you a screenshot, redirect them. "Hey, can you add that as a comment on dotts? That way nothing gets lost."
7. Version the staging build before each review round. Tag releases (review-1, review-2) so when a client says "I commented on the version from Tuesday," you know exactly what they were looking at. Tools like Webflow have a backups history; with code, use Git tags.
8. Send a review email, not a link in a message. A bare URL in a chat is asking for chaos. A short structured email (what to look at, how long they have, where to leave feedback) sets expectations and gives you something to refer back to.
9. Set a feedback deadline. "Take a look when you can" guarantees you'll be chasing feedback for two weeks. "Please leave all feedback by Friday at 5pm" gets you everything in three days. Always set the date in the review email.
10. Close the loop between rounds. When you push the next staging build, mark every previous comment as resolved or addressed, and tell the client which page changed. Otherwise round two becomes round one again, with the same comments re-surfaced because the client doesn't know what's been done.

How to choose a staging URL that doesn't confuse the client

The staging URL itself sends a signal to your client about how official the work is. There are three options that work well for freelancers, in rough order of professionalism.

Option A — Subdomain on the client's domain. staging.clientsite.com or new.clientsite.com. Looks the most professional, requires DNS access (which you should have anyway by this point in the project), and feels real to the client. Add a basic auth password and you're done.

Option B — Subdomain on your own studio domain. clientname.yourstudio.com. Useful early in a project when you don't have DNS access yet, or for clients who don't have a domain at all yet. Make sure your studio domain is something professional, not your personal twitter handle.

Option C — CMS-hosted preview URL. clientname.webflow.io, clientname.framer.website, clientname.myshopify.com/?preview_theme_id=.... Fastest setup, no DNS needed, perfect for early review rounds. Some clients see the platform name in the URL and get nervous ("why does it say webflow?") — explain upfront that this is a temporary review URL.

What you should never do: drop a half-built page onto the live site at /new-homepage or /v2, even temporarily, even password-protected. It pollutes analytics, risks indexing, confuses anyone who stumbles onto it, and creates real legal exposure if the client has a privacy policy that says everything on the site is current.

The feedback layer: where staging actually fails

You can do all ten of the practices above, set up the cleanest staging environment of your career, and still end up drowning in revision chaos. Why? Because the staging site itself is just the venue. The feedback method is the actual product of a review round.

The default for most freelancers — "click around and email me your thoughts" — is the worst feedback method ever invented. It puts the burden of structure on a client who doesn't know what structure means. They reply with paragraphs. They forget which page they were on. They mix up the homepage and the about page. They send three follow-up emails over two days, each with a single comment. By the time you have everything, you've done the work of compiling the feedback yourself — and you've probably missed some of it.

The fix is to put the feedback layer directly on top of the staging site. Tools like dotts, MarkUp.io, BugHerd, and Ruttl all do versions of this. The client clicks anywhere on the page — a button, a paragraph, a hero image — and leaves a pinned comment that stays exactly where they put it. You see the comment in context. The client sees their comment in context. Nobody has to write "the second image from the top, the one with the woman holding the laptop, the bit on the right." They just click on it.

For freelancers specifically, dotts is built for this exact situation: solo designer, busy client, no time for a tool tutorial. The client doesn't need an account. You send them the staging link with the dotts overlay, they click and comment, you get a clean feed of structured feedback by Friday afternoon. No WhatsApp screenshots. No 12-message email threads. No "wait, which version were you looking at?"

If you want a deeper dive on this side of the workflow, see our website feedback tool guide for freelancers — it goes through how the feedback layer changes the staging review process end-to-end.

How to write the staging review email

Here's the template I use. Adapt the language to match your usual tone with the client.

Hi [Name],

>

The new homepage and about page are ready for your review on staging:

>

URL: https://staging.clientsite.com

Password: seeyou-soon-2026

>

Please leave all feedback directly on the page using the dotts overlay (just click anywhere you want to comment). I'll see your comments as they come in.

>

A few things to look out for specifically:

- Is the headline clear about what you do?

- Does the order of the sections feel right?

- Are there any photos that should be swapped?

>

Please leave all feedback by Friday at 5pm. Once I have everything, I'll roll the changes into one revision round next week.

>

Quick note: this is a private review version, not the live site. Please don't share the URL with anyone outside the team.

>

Let me know if you have any questions.

That email does five things at once: gives the link and password in one place, sets the expected feedback channel, gives the client three things to look at (so they don't get overwhelmed by "review everything"), sets a deadline, and reminds them this isn't public. Five minutes to write, saves you a week of chaos.

A real example: the staging site that almost broke a launch

Maya is a freelance Webflow designer in Berlin. Last winter she finished a redesign for a small e-commerce client — a candle brand with about €400k in annual revenue. The site was on staging.candlebrand.com, password-protected, all good.

Then the client's marketing manager forwarded the staging link to two friends "just to get their opinion." One of those friends ran a marketing agency. The agency friend sent back a five-page document with 73 comments — most of them stylistic preferences, a handful of them actual issues. Half of them contradicted the brand guidelines Maya had been given at the start of the project. The client, panicking, asked Maya to "address all the feedback before launch."

Maya did three things that saved the project. First, she replied to the client with a calm summary: "Here's what's a real issue, here's what's a stylistic preference, here's what contradicts what we agreed on in the brief. Want to talk through it?" Second, she scheduled a 30-minute call to walk through her summary on screen. Third — and this is the one that actually changed how she works — she added a clause to her contract for the next project: "Staging review is limited to two named stakeholders. Additional reviewers require a scoped feedback round at €X."

The launch happened a week later than planned. The client paid in full. And Maya hasn't had a "smuggled-in agency review" since, because her staging emails now explicitly say "this link is for [named people only]."

The lesson: staging is a process, not a URL. The technical setup matters, but the rules around who reviews and how they feed back matter more.

Staging tools by CMS

A quick reference for which staging setup works best per platform.

CMS / Stack  ·  Recommended staging approach  ·  Password protection  ·  Notes

Webflow  ·  Use the webflow.io preview URL or a staging subdomain  ·  Site Password (Webflow plan required)  ·  Easy to version with Webflow Backups

Framer  ·  Use the framer.website preview URL  ·  Site Password (paid plans)  ·  Limited form-handling differences vs production

WordPress  ·  WP Engine / Kinsta / Flywheel staging environment  ·  Built-in password or .htpasswd  ·  Push-to-live makes review rounds cleaner

Shopify  ·  Use a development store or password-protected theme preview  ·  Built-in password page  ·  Test checkout in dev store, not production

Static / Jamstack  ·  Netlify or Vercel preview deployments  ·  Branch deploys + basic auth  ·  Cleanest workflow for code-first freelancers

Custom backend  ·  Separate subdomain on identical infra  ·  Cloudflare Access or HTTP basic auth  ·  Mirror env variables carefully

If you're a freelancer working across multiple platforms, the actual feedback layer (dotts, MarkUp, etc.) sits on top of any of these — pick the staging environment that fits the project, and use the same feedback tool every time so your client doesn't have to learn a new process.

The mistakes I see most often

Eight years of building websites and reviewing other freelancers' workflows, here are the mistakes that come up most often. If you do nothing else, fix these.

• No noindex on staging. Two months later, a duplicate version of the homepage shows up in Google. The client emails you in a panic.
• Sharing the password in chat, separately from the link. The client loses one, asks again, you re-send, they save the wrong one. Always send link + password in the same email.
• Forgetting to disable contact forms or analytics. Real conversion data ends up in the client's analytics from staging clicks. Worse: the contact form actually emails the client every time you test it.
• Letting the staging URL leak. Set basic auth even if you also have a CMS-level password. Belt and braces.
• Treating staging as "v1, ship-ready." Staging is for review. The fact that it's online doesn't mean it's done. Be explicit with the client that nothing is final until you push to production.
• Skipping the feedback channel rule. "Send me feedback however is easiest" is not a feedback channel. Pick one and enforce it gently.
• Not versioning between rounds. When the client says "I commented on the version from last Tuesday," you should be able to point to that exact build.

Bottom line

A good staging site for client review is private, password-protected, never indexed, and paired with a single structured feedback channel. The technical setup takes 20 minutes. The communication setup — review email, feedback channel, deadline, scope — is what separates one calm revision round from a two-week WhatsApp meltdown.

Set up staging like the controlled review process it actually is, and the rest of your client work gets a lot quieter.

FAQ

What is a staging site for client review?

A staging site for client review is a private, password-protected copy of a website that lives on a separate URL from the live site. It exists so clients can see and comment on work-in-progress without affecting the live site, search rankings, or analytics. Freelancers use staging during the build and revision phases of a project, and remove or repurpose it after launch.

How do I password-protect a staging site?

The simplest options are HTTP basic auth (set on the server or via Cloudflare Access), a CMS-level site password (Webflow, Framer, Shopify, and most WordPress hosts have this built in), or a plugin (Restricted Site Access for WordPress is reliable). Always send the password to your client in the same email as the staging link, and use a password that isn't reused anywhere else.

Should I host staging on a subdomain or a separate domain?

A subdomain on the client's domain (staging.clientsite.com) is the most professional option once DNS is in your control. Before that, a subdomain on your own studio domain (clientname.yourstudio.com) or the CMS-hosted preview URL is fine. Avoid putting the staging build on the live site under a path like /new — it pollutes analytics and risks accidental indexing.

How do I stop Google from indexing my staging site?

Add a sitewide <meta name="robots" content="noindex, nofollow"> tag and put User-agent: * and Disallow: / in your robots.txt. Most CMSs have a "discourage search engines" toggle (Webflow, WordPress, Framer all do) — turn it on. Combine this with HTTP basic auth so search engines can't even reach the page.

What's the best way to collect feedback on a staging site?

Use a visual feedback tool that sits on top of the staging site so the client can click anywhere on the page and leave a pinned comment. Tools like dotts, MarkUp.io, and BugHerd do this. The benefit is structured feedback in context — no more "the third section, the bit with the picture" — and one place to track every comment instead of email plus chat plus screenshots.

How long should clients have to review a staging site?

For a single page review, 2–3 working days is usually enough. For a full site review, give 5 working days and set a hard deadline in the review email. Open-ended timelines guarantee you'll be chasing feedback for two weeks; a clear deadline tends to bring everything in within three days.

What should I do if the client shares the staging URL with other people?

Decide upfront how many stakeholders are allowed to review and put it in your contract or scope. If extra people get added, treat their feedback as a new scoped round (with extra time and possibly extra cost). Be polite but firm — uncontrolled review groups are the single biggest cause of project blowouts for freelancers.

Do I need a staging site for small projects?

Yes — even for a single landing page. The cost of staging is minimal (a subdomain, a password, 20 minutes of setup), and the alternative is editing on the live site or sending screenshots back and forth. Staging plus a structured feedback channel pays for itself in time saved on the first revision round.

Tired of staging review chaos? [Try dotts free →](https://dotts.se)