How noindex, No-store, and No-referrer Protections Work
QCUL applies noindex, no-store/private caching, and no-referrer-style protections to reduce unintended indexing, caching, and information leakage from the private laboratory.
What each control is for
| Control | Purpose |
|---|---|
| noindex/nofollow / X-Robots-Tag | Tells search crawlers not to index/follow the laboratory content. |
| robots.txt Disallow | Adds a crawler-visible exclusion rule for the laboratory. |
| no-store/private cache headers | Reduces storage of sensitive lab pages in shared/browser intermediary caches. |
| Referrer restrictions | Reduces disclosure of private lab URLs/path details when navigating away. |
These are privacy layers, not authentication
A crawler directive cannot keep an unauthorized human out. The external gate/access credential is the primary access-control boundary; indexing/cache/referrer controls reduce secondary exposure.
Do not publicly link the lab
Even with these headers, treat the lab URL as sensitive. Avoid publishing it on production content, support posts, analytics campaigns, or external systems.
Defense-in-depth principle
How noindex, No-store, and No-referrer Protections Work is one layer in QCUL’s security model. Keep Joomla ACL, CSRF tokens, private gate/storage, laboratory identity, runtime authorization, side-effect quarantine, production Super User checks, and careful handling of production-derived evidence together rather than weakening another control to make one workflow more convenient.
Community Discussion
Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.