En staging nuestra primera decisión es de acceso, no de robots.txt.
Usamos autenticación para contenido privado
Password, autenticación, red privada o controles equivalentes protegen información. Disallow: / no es seguridad.
Un preview público puede necesitar noindex
Si debe ser accesible pero no aparecer en Google, usamos noindex y permitimos que el crawler lo lea. Bloquear el mismo URL en robots.txt puede impedir procesar la directiva.
Robots.txt es una capa secundaria
User-agent: *
Disallow: /
Puede reducir rastreo de staging, pero no sustituye autenticación ni noindex.
Separamos staging de producción
No compartimos una configuración manual frágil. Antes de release comprobamos ambos /robots.txt, eliminamos sitemaps de staging y verificamos que Disallow: / no se haya promovido a producción.
Nuestro release gate
Probamos URLs de producción con el tester y abrimos el archivo real con el checker. La separación correcta es: acceso privado → autenticación; exclusión de índice → noindex; control de crawl → robots.txt.
Elegimos el control según la exposición
Un entorno interno o de cliente debe usar autenticación o restricción de red. Una preview pública que necesita seguir accesible pero no aparecer en búsqueda puede usar noindex mientras permanece rastreable. robots.txt queda como control secundario de crawl, no como frontera de seguridad.
El fallo más peligroso es que una política de staging llegue a producción. Un Disallow: / solo es correcto cuando está deliberadamente limitado al origen no productivo. En el release comprobamos de forma explícita robots.txt y directivas de indexación del dominio final.
También retiramos previews antiguas
Tras el lanzamiento, desactivamos hosts de preview que ya no se necesitan o mantenemos su autenticación. Si una URL de staging pública ya entró en resultados, añadir únicamente Disallow: / no es un proceso de retirada: primero decidimos si debe requerir acceso, devolver un estado HTTP apropiado o seguir rastreable para que pueda procesarse una directiva noindex.
