Proteger los entornos de prueba en pocas palabras

Evita situaciones embarazosas asegurándote de proteger adecuadamente tus entornos de prueba.

La mejor manera de hacerlo es mediante la autenticación HTTP.

¿Tu entorno de prueba ya ha sido indexado por los motores de búsqueda? No te preocupes. Con esta guía, aprenderás cómo revertirlo de forma rápida y efectiva.

Lo vemos todo el tiempo: entornos de prueba o de desarrollo que contienen sitios web que están aún en proceso y están disponibles para que todo el mundo los vea. ¡Y a menudo también son indexados por motores de búsqueda!

¿No me crees?

Échale un vistazo a esta consulta, inspirada en el tuit de Peter Nikolow’s tweet (síguele en Twitter, ¡es listo y divertido!).

¿Por qué tener entornos de prueba accesibles es una mala idea?

O mejor dicho, doblemente mala: desde el punto de vista del SEO, y desde el punto de vista de los negocios.

El punto de vista de los negocios

¿Quieres que otros vean tu contenido de "lorem ipsum" y se rían, o incluso que, Dios no lo quiera, lean sobre un gran anuncio acerca de una adquisición o un cambio de marca que debería haberse mantenido en secreto hasta qel lanzamiento del nuevo sitio?

Es poco profesional y, además, no es muy inteligente. Es incluso una táctica de ventas para ciertas agencias: buscan otras agencias que cometen estos errores y luego se lanzan a sus clientes, aprovechando la situación embarazosa.

El punto de vista del SEO

Además del mal rato, tener un entorno de prueba que ha sido indexado por los motores de búsqueda puede generar problemas de contenido duplicado si el entorno de prueba y el de producción son muy similares.

Tener entornos de prueba accesibles e indexados es totalmente innecesario, ya que es muy fácil de prevenir. En este artículo explicamos cómo hacerlo, qué métodos puedes utilizar y qué hacer si tu entorno de prueba ya ha sido indexado.

De aquí en adelante, cuando hablemos de entornos de prueba, nos podemos referir a ambos el entorno de prueba y el de desarrollo.

¿Qué son los entornos de desarrollo y de prueba?

Cuando estás trabajando en un sitio web completamente nuevo o una nueva función, no lo deberías haces en tu sitio web en vivo (a menudo llamado "entorno de producción"), ya que los sitios web son muy fáciles de romper. Es mejor trabajar con diferentes entornos separados donde desarrollar y probar nuevas funciones.

Entonces, ¿qué otros entornos existen además del entorno de producción?

  • Entorno de desarrollo: aquí es donde los desarrolladores prueban inicialmente su código. A menudo, lo hacen en sus propios ordenadores, de forma local, por lo que, en este caso, no existe ningún riesgo de que este entorno sea accesible para los demás o indexado por los motores de búsqueda. Si en lugar de manterse local se realiza, por ejemplo, en un subdominiodev.example.com, existe el riesgo de que otros usuarios puedan acceder a él e sea indexado.
  • Entorno de prueba: aquí es donde se organizan los nuevos lanzamientos y se prueban las nuevas funciones antes del lanzamiento. El nuevo contenido a menudo se publica aquí de forma que se pueda comprobar que se vea como estaba previsto. Los entornos de prueba no se suelen ejecutar localmente: diferentes miembros del equipo deben poder acceder a ellos fácilmente, por lo que generalmente se ejecutan en un subdominio o un dominio separado.
Consejo experto: como estás leyendo sobre la protección de los entornos de prueba, es probable que estés pensando en realizar una migración. Para migrar un sitio web sin cometer ningún fallo, ¡échale un vistazo a nuestra guía para la migración de sitios web para asegurarte de que no te olvidas de ningún paso crucial en el proceso de migración!

La seguridad por oscuridad no es una estrategia factible

No contarle a nadie nada sobre tu entorno de prueba "secreto" es un tipo de "seguridad por oscuridad". No es una estrategia factible. Y menos como la única capa de protección.

¿Qué pasa si alguien publica accidentalmente un enlace al entorno de ensayo? ¿O inserta algún código en producción que accidentalmente incluye referencias canónicas o hreflang al entorno de ensayo?

Esto no solo crea problemas en tu entorno de producción, sino que también hace que los motores de búsqueda puedan captar la esencia de tu entorno de prueba. Y se pondrán a la cola para rastrearlo, a menos que les impidas acceder al entorno de prueba, o les des reglas a seguir.

¿Cómo proteger tus entornos de prueba y de desarrollo?

Ahora está claro por qué tienes que proteger tus entornos de prueba y desarollo. Pero, ¿cómo? Existes varias formas de hacerlo, pero, ¿cuál es la mejor?

Vamos a discutir los pros y contras de cada método, teniendo en cuenta lo siguiente:

  • Facilidad de uso: el grado en que el método no agrega inconvenientes adicionales.
  • Acesso de terceros: el grado en que el método impide que terceros accedan a un entorno.
  • Compatible con el SEO: el grado en que el método evita que los motores de búsqueda indexen un entorno.
  • Compatible con la monitorización: el grado en que el método te permite monitorizar los entornos protegidos con fines de SEO.
  • Riesgo de error humano: el grado en que el método puede conducir a errores humanos, lo que afecta el SEO.
Método Facilidad de uso Acceso de terceros Compatible con el SEO Compatible con  la monitorización Riesgo de error humano
Autenticación HTTP  yes yes yes yes yes
VPN yes yes yes no yes
Directivas robots  yes no no no no
Robots.txt yes no no no no
Enlaces canónicos yes no no no no
Lista blanca de usuarios-agentes específicos no   ⚠️ yes yes yes

Método 1: autenticación HTTP: tu mejor opción 🏆

La mejor manera de evitar que tanto usuarios como motores de búsqueda tengan acceso a tus entornos de desarrollo y de prueba es mediante la autenticación HTTP. Mientras tanto, asegúrate de implementarlo utilizando HTTPS, ya que no quieres que los nombres de usuario y las contraseñas viajen en texto sin formato por la red.

Recomendamos incluir en la lista blanca las direcciones IP de tu oficina y proporcionar acceso a partes externas y miembros de equipos remotos a través de una combinación de nombre de usuario y contraseña.

De esta manera, los motores de búsqueda no pueden acceder a nada y tienes todo el control sobre quién puede ver qué. Puedes preparar tu entorno de prueba con el mismo robots.txt que usarás para el entorno de producción, así como las directivas robots y enlaces canónicos correctos. Esto te permite obtener una imagen representativa detu entorno de prueba cuando lo estás monitorizando en busca de problemas y cambios antes del lanzamiento.

Otra ventaja de esto es que ayuda a que los desarrolladores no se olviden de publicar el robots.txt, directivas robots y enlaces canónicos correctos en el entorno de producción.

Este es un enfoque mucho mejor que el uso de robots.txt y/o directivas robots no index y enlaces canónicos, ya que no impide que otras personas accedan a ellos, y los motores de búsqueda no siempre respetan estas directivas.

Además, cuando se utiliza la autenticación HTTP, todavía es posible utilizar las herramientas de prueba de Google, como la Herramienta de prueba de AMP, la Herramienta para evaluar optimización para dispositivos móviles y la Herramienta de pruebas de datos estructurados. ¡Utiliza la tunilización!

¿Cómo lo configuro?

Abajo encontrarás algunas fuentes acerca de cómo configurar la autenticación HTTP en Apache, nginx, y IIS:

Dean Cruddace
Dean Cruddace

Protege tu entorno de prueba con contraseña, eso es todo. Nada especial, solo protégelo con contraseña. Google no puede ver el otro lado de la protección con contraseña (a menos que configures un túnel con el fin de realizar pruebas). Incluso cuando se utiliza un archivo robots.txt Disallow: / y meta robots noindex, es posible que las páginas se indexen si hay suficientes enlaces y/o cualquier otra señal que dirigan hacia ellas.

Método 2: acceso VPN

VPN significa "virtual private network". Básicamente, conectas tu ordenador local para formar parte de la red de la empresa. Una vez que eres parte de la red de la empresa, puedes acceder al entorno de prueba. Alguien que no sea parte de la red no podrá acceder a él. Esto significa que ni terceros, ni los motores de búsqueda son capaces de acceder al entorno de prueba.

Tener acceso a través de una VPN ofrece la mayoría de los beneficios de la autenticación HTTP. Sin embargo, tiene una gran desventaja: es posible que las herramientas de monitorización SEO que no se ejecutan localmente no funcionen de manera inmediata, o no funcionen en absoluto. No poder ver el progreso de tu equipo de desarrollo es poco práctico, y se vuelve realmente problemático cuando se trata de sitios web muy grandes.

Método 3: directivas robots

Las directivas robots se utilizan para comunicar tus preferencias acerca de los procesos de rastreo e indexación. Por ejemplo, puedes pedirle a los motores de búsqueda que no indexen ciertas páginas, y no sigan (ciertos) enlaces.

Puedes definir directivas robots en el encabezado HTTP de una página (encabezadoX-Robots-Tag), o a través de las directivas meta robots en la sección <cabezera>. Como tendrás otro tipo de contenido además de solo páginas en tu entorno de prueba, es reconmendable utilizar el encabezadoX-Robots-Tag para asegurarte de que, por ejemplo, los archivos PDF no son indexados.

Las directivas robots, como su nombre indica, están destinadas a robots ("rastreadores"). No impiden que terceros accedan. Envían una señal moderadamente fuerte a los motores de búsqueda para que no indexrn páginas. Digo "moderadamente" porque los motores de búsqueda aún pueden decidir ignorar las directivas robots e indexar tus páginas. Tampoco es una solución compatible con la monitorización, ya que, como los robots.txt, puede dar lugar a que las herramientas de SEO detecten falsos positivos.

Además, existe un gran riesgo de error humano, ya que las directivas robots del entorno de prueba se transfieren frecuentemente al entorno de producción por error.

Método 4: robots.txt

El archivo robots.txt establece las reglas de participación para los rastreadores, por lo que al utilizar robots.txt, puedes pedirle a los motores de búsqueda que se mantengan al margen de tu entorno de prueba. La forma más común de hacerlo consiste en incluir los siguientes contenidos en el archivo robots.txt:

User-agent: * Disallow: /

Esto evita que los rastreadores de los motores de búsqueda rastreen el sitio web, pero es posible que lo indexen si encuentran enlaces hacia él, lo que da lugar a listados como los siguientes:

Google description not available robots.txt

Algunos incluyen la directiva no oficial Noindex en su archivo robots.txt. Nosotros no recomendamos hacerlo ya que es una peor forma de evitar que tu entorno de prueba sea accesible que utilizando la directivaDisallow, ya que es realmente una directiva no oficial.

Tu archivo robots.txt no ofrece ninguna protección real contra el acceso de terceros al sitio web, y también despista a las herramientas de monitorización de SEO, lo que potencialmente podría dar lugar a falsos positivos. Además, estárías creando un gran riesgo de error humano: aquí también es posible que el archivo robots.txt del entorno de prueba se traslade accidentalmente al entorno de producción.

Método 5: enlaces canónicos

El enlace canónico informa a los motores de búsqueda de la versión canónica de una página. Si el entorno de prueba referencia al entorno de producción, todas las señales deben consolidarse con el entorno de producción.

De lo contrario, los enlaces canónicos se asemejan a las directivas de robots, especialmente en sus desventajas:

  • Dejan que terceros accedan al entorno de prueba.
  • No son compatibles con la monitorización, ya que pueden dar lugar a que las herramientas de SEO informen de falsos positivos.
  • Existe riesgo de error humano,  ya que las directivas canónicas del entorno de prueba se trasladan accidentalmente al entorno de producción.

Método 6: poner en la lista blanca agentes de usuarios específicos

Poner en la lista blanca agentes de usuarios específicos para acceder a un entorno de prueba puede utilizarse para permitir que especialistas de SEO controlen un entorno de prueba, siempre que sus herramientas de SEO admitan la configuración de agentes de usuario personalizados. Podrían crear un agente de usuario inventado y usarlo, mientras que bloquean todos los demás agentes de usuario (incluidos los navegadores).

Sin embargo, este no es un enfoque muy fácil de usar, ya que la verificación manual a través de tu navegador se vuelve más difícil. Tampoco es un enfoque especialmente seguro: si alguien sabe que estás trabajando para o en una empresa X, y está al tanto de tu agente de usuario (quizás porque se trata un cliente descontento), es posible que pueda acceder al entorno de prueba.

¿Cómo puedes saber si tu entorno de prueba está siendo indexado?

Hay varias formas de saber si tu entorno de pueba está siendo indexado. Aquí están las dos formas más comunes:

Opción 1: consulta del sitio

Si sabes que tu entorno de prueba se está ejecutando en un subdominio, puedes probar una consulta como:: sitio:ejemplo.es-inurl:www

Esta consulta devuelve todas las páginas indexadas por Google para el dominio ejemplo.es, excepto las que contienen “www”.

Aquí tienes un enlace a un ejemplo de consulta

Opción 2: Google Analytics

Si no conoces la URL de tu entorno de prueba, puedes intentar comprobarlo en Google Analytics:

  • Dirígete a Audiencia > Tecnología y eligeRed.
  • SeleccionaNombre de host como dimensión primary.
  • Busca nombres de host que tengan un dominio diferente, o contengan subdominios tales comostaging, testdev.

Eliminar tu entorno de prueba indexado del índice

Uh-oh. Your staging environment has already been indexed by search engines, and you’re the one who has to fix it. Well, the good news is: if you follow the steps below, you’re good. And they’re easy.

Vaya, tu entorno de prueba ya ha sido indexado por los motores de búsqueda, y tú eres el que tiene que arreglarlo. Bueno, la buena noticia es que si sigues los pasos a continuación, estás a salvo. Y son fáciles.

Paso 1: ocultar resultados de búsqueda

Verifica el entorno de prueba con herramientas para webmasters como Google Search Console, Bing Webmaster Tools y URL Removal (entra en la documentación de Google y de Bing para esto). Con Google, esta solicitud se resuelve en cuestión de horas (Bing tarda un poco más), y tu entorno de prueba no aparecerá en ningún resultado de búsqueda. Pero aquí está el truco: todavía está en los índices de Google y Bing; simplemente no se muestra. En el caso de Google, el entorno de prueba solo está oculto durante 90 días. Por lo que en este tiempo, tendrás que asegurarte de que solicitas la eliminación de tus páginas de los índices de los motores de búsqueda de la forma correcta: a través de la directiva robots noindex.

Paso 2: aplicar la directiva noindex

Asegúrate de aplicar la directiva robots noindex en cada página de tu entorno de prueba. Mira los registros de tu servidor para conocer las solicitudes de los rastreadores de motores de búsqueda de tus páginas anteriormente indexadas (y ahora "no noindexed"), para asegurarte de que han "recibido el mensaje".

En la mayoría de los casos, estos 90 días son suficientes para indicar a los motores de búsqueda que deben eliminar las páginas del entorno de prueba de sus índice. Pero si no, simplemente repite el proceso.

Una vez que está todo hecho, protege el entorno de prueba utilizando la autenticación HTTP para asegurarte de que no vuelve a pasar.

Otras fuentes útiles

Aquí hay algunas otras fuentes útiles donde se habla de cómo proteger los entornos de prueba:

¡Ahora sigue leyendo!

Ahora que yas has aprendido acerca de la mejor manera de proteger tu entorno de prueba, continua aprendiendo con estos artículos:

Comenzar tus 14 días de prueba gratuita

Comience en tan solo 20 segundos

Ponga un nombre de dominio válido, por favor (www.ejemplo.es).
  • No se requiere ninguna tarjeta de crêdito
  • No hay que instalar nada
  • Sin compromiso