A company store should be public only when its merchandise, prices and program details are approved for a public audience. If the information is employee-only, require appropriate access controls. If it is safe to share but should not appear in search, use an indexing policy—not a claim that the store is private.
Those are different decisions. A link omitted from your corporate navigation can still be forwarded. A page excluded from search can still be opened directly. A storefront with a sign-in button may still serve product details before anyone signs in. The useful buying question is not simply “Can you hide our store?” It is “Which information may each audience receive, through which routes?”
This guide turns that question into a visibility specification and launch acceptance card. Brand Sauce publishes it from a company-store planning perspective. The proposed controls are requirements to discuss and verify with your provider, not a statement that every Brand Sauce configuration includes them.
Separate discovery, browsing and purchasing
Start by agreeing on three independent outcomes. Discovery concerns whether people should find the store through public search or links. Browsing concerns who may receive the assortment, images, pricing and campaign details. Purchasing concerns who may place an order and whose money they may use.
A public alumni merchandise shop might welcome search traffic while keeping personal order records protected. An employee appreciation program might allow a public welcome page but reveal neither the assortment nor the employer-funded allowance until eligibility is checked. An unadvertised event collection might be safe for anyone to view, even though the organizer does not want it appearing in search.
| Program intent | Appropriate visibility decision | What it does not settle |
|---|---|---|
| Public supporter merchandise | Approved assortment may be publicly discoverable | Protection of individual orders and accounts |
| Safe-to-share event collection | Direct access permitted; indexing discouraged with supported controls | Whether forwarded visitors can buy |
| Employee-only gifting | Restricted content delivered only to authorized recipients | Which recipient may spend which allowance |
| Unreleased rebrand merchandise | Restricted preview until the approved release | Approval to expose artwork through images or downloads |
Write these decisions before selecting a platform setting. “Private” is too ambiguous to serve as a purchase requirement. Your specification should say whether an anonymous visitor may see a product name, a price, a photograph or only a neutral sign-in page.
What noindex and robots.txt actually do
Google documents noindex as an instruction supplied through a page meta tag or an HTTP response header. Google must be able to crawl the resource to see that instruction; blocking the same resource in robots.txt can prevent that. A supported header can also apply to non-HTML files. See Google's noindex implementation guidance.
That is useful for a harmless collection you want to distribute by direct link. It is not a permission check. Google's content-sharing guidance distinguishes excluding a page from search from password-protecting confidential information. A directly accessible noindex page remains accessible to someone with its URL.
Robots.txt manages crawler access. Google's robots.txt introduction explicitly warns that a blocked page URL can still appear in results when discovered through links, and that crawlers are not universally bound to obey its rules. Do not buy “private store” functionality whose only evidence is a robots.txt entry.
Ask the provider to name the intended outcome in plain language: public and discoverable, public but excluded from supported search indexing, or access-restricted. For restricted information, have the technical owner verify the access boundary. Do not temporarily expose confidential material just to help a crawler read an indexing instruction.
Build a seven-field visibility record
Use a small inventory of information surfaces rather than a single checkbox for the storefront. This is a proposed working template; it is not a certification or platform feature list.
- Surface: product page, product image, downloadable guide, allowance display, order record or public welcome page.
- Content: what the surface reveals, including filenames and page titles.
- Approved audience: anyone, all enrolled employees, one campaign group or one recipient.
- Direct-link result: what an anonymous visitor should receive when opening the exact address.
- Search intent: discovery welcome, exclusion requested, or content inaccessible without authorization.
- Owner: who approves changes and who verifies implementation.
- Review trigger: launch, rebrand release, collection change, provider migration or a scheduled review.
For example, the company logo on an already-public navy polo might be approved for public display, while a limited anniversary award and its eligibility description might not be. Neither decision needs to dictate the visibility of a recipient's delivery address, which belongs in a separately protected order workflow.
Keep the record short enough for merchandise and IT owners to maintain together. A technically precise configuration attached to an outdated audience decision is still the wrong configuration.
Check images, documents and data—not just the front door
A useful acceptance review follows the information. If the store page requires login, ask whether its artwork files, downloadable size guide, product-data responses and alternate provider address follow the intended policy too. Some content may deliberately remain public; the important point is that the choice is explicit.
OWASP's authorization guidance recommends default-deny permissions, checks on every request and appropriate protection of static resources. Applied here, the technical review should establish that restricted files and data do not depend solely on the visitor entering through the homepage.
Have the provider demonstrate representative routes using approved test content. Do not use a real employee's order or an unreleased design as the test fixture. A generic image and invented recipient record are enough to establish the expected behavior without spreading sensitive material during review.
Include generated exports in the conversation. A product worksheet for a program administrator is a different deliverable from a shopper's size guide. If both are downloadable, they need separate audience decisions. Do not assume that a file inherits protection merely because someone linked it from a protected page.
Make the restricted entrance useful
A restricted store still needs a clear arrival experience. Use a recognizable company identity, a concise explanation of who the program serves, a supported sign-in route and a help option. Avoid displaying the very campaign detail you intended to protect in a page title, preview image or error message.
Plan what happens when an eligible employee follows a saved product link. After signing in, they should reach the intended destination or receive an understandable explanation if that collection is no longer available. The public-facing page need not reveal a private reward tier to explain that authorization is required.
The choice between corporate SSO, email-based access and separate accounts is covered in our company-store sign-in guide. Here, the decision is what sits behind that mechanism. A smooth authentication experience does not, by itself, prove that the product image or order endpoint is protected.
Also decide how an authorized guest gets help. Contractors and event recipients may not have the same company identity as permanent employees. Give support a documented exception route rather than making the whole collection public when one person has trouble signing in.
When a public showcase and private store belong together
Marketing may want to show the merchandise program to candidates, customers or partners. HR may want the gift assortment and funding rules limited to employees. These goals can coexist through a deliberately approved public showcase and a separate restricted shopping experience.
Illustrative scenario: a company approves photographs of two standard branded items for its careers page, but keeps a service-anniversary collection and individual allowances behind access checks. The careers page tells the program story without reproducing a live employee cart, recipient name or reward balance. This is a design example, not a Brand Sauce client result.
Give the showcase its own approval owner and update trigger. Otherwise, a replaced product or retired logo can remain in recruitment materials after the store changes. Do not automatically mirror every new private collection into a public gallery.
A custom domain does not resolve this separation. It provides an address, not an audience policy. Our custom-domain decision guide covers ownership and continuity; apply the same visibility specification to every supported address that can reach the store.
Compare the operating burden before committing
Ask for quote-needed line items covering access configuration, public/private collection separation, protected media delivery, testing and ongoing change support. Unknown pricing should remain unknown until quoted. Include who handles new templates or added collections, not only who flips the initial setting.
For an ongoing on-demand gift store, persistent access controls can support repeated individual choices, but each assortment change needs to preserve the policy. For a one-day bulk distribution with no online browsing, an employee storefront may be unnecessary. A hybrid program could use public event information, bulk event stock and a restricted reorder collection for eligible staff.
These production models do not determine confidentiality. Bulk merchandise can involve unreleased branding; on-demand merchandise can be intentionally public. Compare the actual workflow and internal maintenance effort rather than assuming one production method makes the information private.
Assign a backup owner. If a provider needs your approval to expose a new collection, a launch should not hinge on one administrator being available. Conversely, a missed response should not default a restricted collection to public.
Use an eight-case visibility acceptance card
Run these checks on your own authorized test environment with the provider. Record the expected result, observed result, configuration and accountable owner. They are buyer acceptance checks, not a substitute for a full security assessment.
| Case | Evidence to retain |
|---|---|
| Anonymous homepage visit | Only the approved public information appears |
| Anonymous direct product link | The agreed public or restricted result holds without homepage navigation |
| Direct image or document link | Each representative file follows its own approved audience rule |
| Signed-in but ineligible test shopper | A different campaign's restricted content remains unavailable |
| Eligible shopper after sign-in | The intended collection is usable, including necessary size and care information |
| Public noindex collection | The technical owner verifies the supported instruction and crawler accessibility |
| Alternate address and added collection | The same agreed policy survives both entry and publishing changes |
| Logout followed by direct revisit | The session and content behavior matches the documented access policy |
Make release depend on the failed case, not the launch calendar. If a private document remains public, correct that boundary before inviting recipients. If a harmless public collection lacks its intended indexing instruction, fix the publishing configuration without describing the issue as an employee-account breach.
After launch, pair this review with employee store-access removal. Visibility describes what an audience may see; offboarding keeps the audience membership current. Record both owners so neither team assumes the other completed the work.
Frequently asked questions
Is an unlisted company-store link private?
No. Treat an unlisted address as a distribution choice. If opening the address returns restricted information without authorization, omitting it from navigation has not established the intended boundary.
Should every employee store use noindex?
Not automatically. Define the audience first. Safe public content may intentionally seek discovery; other public content may be excluded from supported indexing. Restricted content needs access controls regardless of its search policy.
Can a public product page have an employee-only purchase option?
That can be a valid requirement when the product details are approved for public viewing. Ask the provider to demonstrate purchasing eligibility and protection of individual allowances separately. Do not assume those controls from the presence of a login button.
Does passing the launch test mean the store stays private forever?
No. Treat the result as evidence for the tested configuration and date. Recheck after new collections, media-handling changes, templates or migrations. The durable deliverable is a maintained visibility record with a responsible owner.
