A normal hosted website is usually public by default
Standard web hosting is designed to make a website available to anyone who can reach its URL. Once DNS points a domain or subdomain at the host, a visitor normally needs no account or invitation to load the page. That is ideal for a marketing site or public product, but not for a client review, unfinished prototype, internal tool, or a site containing information that should stay within a small group.
- An obscure URL is not access control. Anyone who receives, guesses, indexes, or forwards the link may be able to open it.
- Keeping a site on localhost avoids public access, but makes it difficult to show the working version to remote teammates or clients.
- A private sharing plan should decide who can enter, how they prove it, and how access is removed when it is no longer needed.
Password protection is a common first layer
Many hosts let you add a shared password through a control panel, web-server configuration, or a reverse proxy. Teams can also build their own application login system. Password protection is useful for a short-lived review when everyone who should have access can safely use the same secret, but it introduces another system to configure and maintain alongside hosting.
- HTTP basic authentication can be configured in a web server such as NGINX or Apache, but you need to manage the server and credential file.
- A hosting provider may offer a password gate, which can be convenient but may be specific to that host or plan.
- Application logins offer more control, but require user accounts, password resets, sessions, and security maintenance in the application itself.
- A shared password is difficult to revoke for one person: when it changes, every remaining visitor needs the new value.
Use Sitedropper visibility instead of assembling the gate yourself
Sitedropper puts sharing choices next to deployment instead of asking you to configure a server or modify the application. New projects start as Draft, which keeps the deployment for the owner or account users while it is being tested. When it is time to share, choose the visibility that matches the audience rather than exposing the site by default.
- Draft keeps a work-in-progress deployment restricted to the project owner or account users.
- Password Protected lets you set a shared access password for visitors; Sitedropper stores the password as a hash and creates a visitor session after successful verification.
- Private lets you grant exact email addresses access. Each visitor requests and verifies a one-time password sent to that email address before opening the app.
- Public removes the visitor gate when the site is ready for an open launch.
A simple private-sharing workflow
Deploy and test the site as Draft first. Then select Private for a people-specific review and add the email addresses that should be allowed to visit. Send those people the Sitedropper URL. When they open it, they verify access with a short-lived code sent to their approved email. You can remove an email grant when the review ends. Choose Password Protected instead when a shared password is genuinely the better fit for the group.
- Use Private for client approvals, internal tools, and reviews where access should map to individual email addresses.
- Use Password Protected for a lightweight shared gate when individual email verification is not required.
- Keep sensitive data out of a preview unless the application, audience, and your organization’s security requirements are appropriate for it.
- Make the project Public only after checking the live URL and confirming it is ready for anyone to access.
Share the site, not the infrastructure chores
With Sitedropper, you can move from a local project to a shareable URL and choose how that URL is protected without separately operating a VPS, editing web-server authentication files, or building a login flow into a prototype. The deployment stays under your control while the right audience gets the access method that fits the review.