Password-Protect A Website
A site you are still building should not be readable by the public or indexed by search engines. The cleanest way to stop that is to put the whole thing behind a password, so a visitor is asked to sign in before anything loads at all.
This works on any environment: your production website, a staging site or a dev site. It takes about thirty seconds to turn on and the same to turn off.
What Protection Actually Does
When a website is protected, the server asks for a username and password before it will serve anything. The request never reaches WordPress. The visitor gets the browser’s own sign-in box, the small grey dialogue that appears at the top of the window, not a WordPress login screen.
Because nothing is served without the password, there is nothing for a search engine to index and nothing for a visitor to stumble into. It also means no plugin, no theme and no setting inside WordPress can leak the content past it, which is what makes it more trustworthy than a “coming soon” plugin.
| Approach | What a stranger sees | Can search engines index it |
|---|---|---|
| Password protection | A browser sign-in prompt | No, nothing is served |
| A coming-soon plugin | A holding page, usually | Sometimes, depending on the plugin |
| WordPress page password | The rest of the site, normally | Yes, everything else |
| Nothing | The whole site | Yes |
Step 1: Open The Password Protect Tab
In the members area at my.oxyforge.com, open the website you want to protect, then open its Password Protect tab.
This tab protects your live site. A staging copy has its own password on the Staging tab, and a dev site is a separate website with a tab of its own.
Step 2: Turn Protection On And Set A Password
Switch protection on. The username is the site name, which is filled in for you, and you choose the password.
Choose a password you can send to a client in a message without worrying, but do not reuse a password you use anywhere else. This one gets shared, forwarded and pasted into chats, and anyone who has it can read the site.
Write it down somewhere you will find it again. The password is there to let people in, so losing it is only an inconvenience, but it is an inconvenience you can avoid.
Step 3: Check It From Outside
Open the site in a private browser window. You should get the sign-in prompt immediately, before any of the page appears. Enter the site name as the username and the password you chose.
Test in a private window rather than your normal one, because once you have signed in your browser will keep sending the credentials and the site will look open to you.
Step 4: Turn It Off When You Launch
Go back to the Password Protect tab and switch it off. The site is public from the next request. Then clear the cache from the Tools tab, because a visitor’s browser or the page cache may still hold the protected response.
Do this as part of going live, not after. A site that launches still protected looks broken to everyone except you, and the sign-in prompt is easy to miss when your own browser is remembering the password.
Where It Is Already On
Dev sites and temporary sites are always protected and cannot be opened to the public. You cannot accidentally expose one, and you do not need to remember to turn it on. While a site is protected, search engines are also told not to index it.
Staging sites are always password protected and cannot be opened to the public, because a staging copy of a real site would otherwise be a second public copy of your content. Their password is on the Staging tab, not here. See staging sites.
Common Problems
The prompt appears but the password is rejected. Check the username. It is the site name as shown on the Password Protect tab, not your email address and not your WordPress administrator name. Also check for a trailing space if you pasted the password.
The site still loads without asking. Your browser is remembering a successful sign-in. Try a private window, a different browser or your phone. If it genuinely loads with no prompt in a private window, reload the Password Protect tab to confirm the setting saved on the environment you expected.
A protected page is showing instead of the real site after you turned protection off. Clear the cache from the site’s Tools tab, then reload in a private window. See clear the cache.
An uptime monitor or a tool is reporting the site as down. A protected site answers with a 401, which means the site is alive and asking for a password. Most monitoring tools read that as an error. Either pause the monitor while the site is protected, or give it the credentials if it supports them.
Something that connects to the site has stopped working. Anything that reaches the site over HTTP without a browser is affected, because it is asked for a password too and cannot answer. That includes some search console verifications, some payment callbacks, external cron services and feed readers. If you need one of those to work, finish the build and turn protection off, rather than trying to work around the prompt.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket