We’ve been dealing with multiple high level incidents around protecting the Clinical Enrollment sites (graves.freshy.dev, cle.freshy.dev, dlbcl.freshy.dev, evommunebio.freshy.dev) to ensure they’re completely pw protected/content gated and not indexed by search engines. Their client, who we are building the site for, found out today that one of the sites (graves.freshy.dev) was not password protected was quite upset as this is the 2nd time this has happened. In troubleshooting this, I found other issues as well with robots.txt not blocking search engines – outlining everything below:

Password Protection Issues: The Password Protect plugin conflicts with Pressable’s Edge Caching, causing inconsistent behavior and intermittently allowing access without requiring a password. This was resolved temporarily by disabling Edge Caching on all dev sites, and disabling wp-rocket too for good measure, but the plugin itself remains unreliable and we should replace with another solution.
Search Engine Indexing: In addition to this, I found that robots.txt was not properly blocking search engines despite being configured to do so in the site options. This looks to be an part of the known issue with how Pressable’s staging sites handle robots.txt that I will escalate with them.. not our fault here as we had everything configured correctly in the dashboard. I resolved by creating and uploading custom robots.txt files for each site blocking search engines.
Next Steps:

All PM’s and Build team members need to know to always check robots.txt as the source of truth to see if search engines are truly blocked
All PM’s and team members working on this site need to know not to enable Edge Caching or WP Rocket on these sites, and to stop using the Password Protect plugin going forward
Dev needs to implement an alternative solution for locking these sites down Potential code here for whoever is on build/dev team for these sites

Let me know if there are any questions.