Indexing restrictions control search visibility; access protection controls who can open the content.
Google documentation reviewed on 9 November 2026; last updated 21 October 2026. Review and handover steps are CROMBA operational recommendations.
Preventing indexing does not prevent access
Google’s guide explains that the noindex tag asks for content to be excluded from search results, but does not stop people visiting the page if they have its link.
Password protection, by contrast, limits access to authorized users. This is why Google recommends protecting private or confidential content instead of merely hiding it from search results.
The practical distinction is simple: if a preview contains an unannounced commercial offer or client materials, keeping it out of Google is only part of the issue. You need to control who can open it in the first place.
Choose the measure that matches the content
Before asking a developer to “hide the website,” explain what you mean:
| Situation | What is needed |
|---|---|
| A review version intended only for the team and client | Restrict access to authorized people |
| A public page that can be shared but should not appear in search | Configure indexing restrictions and verify they work |
| A website ready for launch and search visibility | Review restrictions and remove those blocking the intended public pages |
These are not three names for the same action. A project may need a protected staging environment and very different settings for its published website.
What should you test before sharing the preview?
At CROMBA, we recommend making staging review a concrete test, rather than accepting a verbal assurance that the site is “hidden”:
- Open the link in a private window without signing in. Can you see the materials before authentication?
- Test an internal page and an uploaded file, not just the homepage.
- Check whether the test environment contains real client data or real requests.
- Identify who has access and how it will be revoked after the review.
- Document who is responsible for checking indexing settings at launch.
The aim is for the project manager to know what has been tested and what still rests on an assumption.
Do not carry staging restrictions into launch
A team may protect the staging site well, then forget to review its restrictions when publishing the final website. Search readiness should therefore be a separate checkpoint from design approval.
Ask the team to verify that pages intended for the public open without a login and are not unintentionally blocked from indexing. At the same time, do not remove protection from private areas or review files simply because the main website is live.
We also recommend recording an explicit decision about the staging environment after launch: will it remain a protected workspace, or will it be closed? Leaving it without a clear owner is not an operating plan.
Complete the user-experience review by understanding how PageSpeed measurements differ from real user experience, then assess the message and form using our landing-page optimization guide.
What if the staging version already appears in search?
Start by identifying the nature of the content. If it is private, address access first: removing a search result does not make a file confidential. Google’s guide also describes procedures for requesting removal of results that already appear, alongside addressing the content itself.
The technical team can then verify the appropriate action and monitor the outcome, without promising an immediate change.
Website readiness means more than a finished design. It means showing the right content to the right audience while keeping working materials within their intended scope.
Developing a new website? Discuss a launch-readiness review with CROMBA, covering user experience, access, and indexing.
Sources and editorial review
Original sources used in this article. Last editorial review: 9 November 2026.
- Google Search Central — Control what you share with Google SearchUpdated 21 October 2026; reviewed 9 November 2026
