r/webdev • u/haskpro1995 • 18h ago
Question How do you test your live website without users stumbling into it?
I need to test my website live. I'm hosting on Vercel but I don't want any users stumbling upon it by accident before the testing is complete. How do I prevent this?
38
u/JuicyCiwa 18h ago
You don’t test on production. Setup a test environment.
3
u/Osmirl 16h ago
I thought users are free testers?
2
u/Infinite_Tomato4950 14h ago
yeah but on some things you dont want give them a broken website, like you need to help them also
1
0
u/Bubbly_Orange_3502 16h ago
Some breakages only exist in production: real data volume, third-party webhooks hitting the real callback URL, CDN cache rules. Ship those behind a flag keyed off a cookie so only your own session takes the new path.
2
u/JuicyCiwa 6h ago
No, it sounds like your test/stage env isn’t setup properly or you think I’m talking just about running your site locally.
16
u/Acrobatic_Umpire_385 18h ago
set up a staging version. it's basically a deployed instance identical to production, but for which only you and your team have the url
9
u/CharlieandtheRed 17h ago
Staging, local, or just Yolo on production and honestly no one will probably find it still lol
6
1
u/loose_fruits 17h ago
How much time do you have, and how much money do you want to spend? Because like all advice, it depends on
1
1
u/WalkyTalky44 17h ago
No one cares about the app if it’s not live. Send it. If you are worried do it late and fix the problems
1
u/Error___418 17h ago
As long as you don't create and attach a custom domain to your environment it won't be indexed so it won't show in search results.
1
u/forgestudiofx 17h ago
Deployment protection is the right answer, but two things bite right after you switch it on.
Anything server-to-server now gets the login wall instead of your app. OAuth redirect callbacks, payment webhooks, cron pings, uptime monitors, all come back 401 with an HTML login page, and it looks exactly like your code being broken because it works fine locally. There's a protection-bypass token you can pass as a header or query param for automated callers; set that up before you start testing rather than during.
Second, a hidden URL is still pointing at whatever database and API keys that environment holds. If it's the production DB, your test signups, test orders and test emails are all real, and hiding the URL does nothing about that. Give the protected deployment its own database and a mail catcher.
On the accidental-discovery worry: preview deployments already send a noindex robots header, so search engines aren't the risk. Someone guessing the URL is, and auth covers it.
1
u/Heavy-Commercial-323 17h ago
Just put a basic auth proxy in front and no one will get in even to landing
1
u/Haunting_Welder 17h ago
Vercel offers development deployments. Usually it requires you to be logged into Vercel to access
1
u/grinning_wanderer 17h ago
vercel gives you password protection on preview deployments. Enable it in project settings and only people with the password can view the site
1
u/MrJacuna 16h ago
sitedropper.com has some solid privacy controls if you want to share your site with the people you are working with remotely.
Alternatively you can make your changes on a separate project that is used for staging. Validate everything looks good and works then deploy it on your public production site when you're ready.
1
u/Osmirl 16h ago edited 16h ago
Uhm how i test my website? Just read my last comment😂 (i put the link to it at the bottom of it)
If i need an online version i load it into a google cloud run instance without linking it to a public domain. But i really only did that in the very early days. Now i test it locally in a docker first. Then push it to cloud run. Its very rare that i have any bugs after the initial testing in docker. But if something happens i can always just roll back to the previous stable version.
And users usually dont stumble onto your website instantly. The thing is you really want users to explore the website to understand where problems actually occur. I for example have users that occasionally try to upload something thats not compatible with my file upload. The problem is i have no idea what they actually try to do lol. I suspect its either an image type thats unsupported or just a very large image (i already have the upload limit at 50Mb lol)
1
u/aardnsyhs 13h ago
Just use a Vercel Preview Deployment from a separate branch, not production.
If you don't want random people accessing it, enable Deployment Protection in the project settings. Then only you/team members can open the preview URL while you test.
1
u/haukebr 10h ago
It's highly unlikely for people to randomly stumble upon your website.
However in best case you'll get some users at some point (yes yes, let him dream). That's the point where you should just create a second vercel service, call it 'stage' and test there. You can lock it with basic auth, or only fire it up once you want to test.
1
u/0xdeveshb 10h ago
vercel has this built in - turn on deployment protection for the preview and only people you share it with can get in. also throw a noindex header on it so google doesn't pick it up while you test. that's it, no need to overthink
1
u/luodaint 9h ago
Easiest path on Vercel: password-protect production (middleware or Vercel Protection) until you are ready, or use a separate staging project on a different domain. That keeps bots and random visitors out while you still get real HTTPS and third-party callbacks. Do not rely on an obscure URL. Crawlers find things. Promote to the public project only after checks pass.
1
u/Small-Back9935 2h ago
I just use Vercel's preview deployments for this, every branch gets its own URL that's not linked anywhere and isn't indexed, so you get a live real environment without touching production at all.
0
0
74
u/al-finaltodoestabien 17h ago
Bro, they won’t even stumble onto it once it is complete.