Distintas formas SEO de bloquear una página en desarrollo.
Cuando se trabaja en cualquier proyecto web profesional, es recomendable tener una versión web de prueba/desarrollo, también conocido como staging o testing.
Esto nos permite tener una réplica de la propia web, donde poder aplicar cualquier tipo de cambios sin que estos afecten a los usuarios, previniendo errores y malas experiencias.
Generalmente, esta práctica se realiza con un dominio o subdominio distinto que utiliza la misma configuración del servidor para evitar errores, un subdominio como: https://test-carlos.sanchezdonate.com/
Toda web profesional o semiprofesional debería tener una versión de testing con la misma configuración de servidor para evitar que los errores que puedan surgir en el desarrollo o cambio de implementaciones afecten a los usuarios de la web en producción.
Sin embargo, esto a nivel de SEO nos puede producir varias problemáticas. En muchas ocasiones debido a un error con algún enlace o por cualquier otro motivo, Google puede llegar a acceder a esta versión de prueba.
Por diversas razones, no es recomendable que un usuario pueda llegar a una web de prueba. Pero Google o cualquier otro motor de búsqueda deberían tener bloqueado el acceso con más motivo. Ya que esta versión de prueba tiende a (o debería) ser un duplicado exacto de la web en producción (la que produce, la que ven todos los usuarios).
Donde suele haber varios problemas es en la implementación que se decide hacer para evitar el rastreo o indexación de la web de prueba.
Lo ideal sería evitar tanto el rastreo como la indexación. Por lo que de facto, descartaríamos prácticas como el noindex, el robots.txt o el canonical.
Lo correcto para estas situaciones sería realizar una implementación por medio de servidor, ya sea bloqueando los user-agents, por ip o por contraseña, pero voy a explicar por qué y que diferencias tiene cada una.
La mejor implementación SEO para una web de prueba es impidiendo a los motores de búsqueda rastrear la web por medio del servidor, arrojando un código de respuesta 4xx. De esta forma se puede auditar el proyecto correctamente, previniendo errores, y la web no será rastreable ni indexable.
Se puede incluso utilizar solo un usuario y una contraseña y que lo empleen todos los involucrados en el proyecto, y garantiza que nadie ajeno a esos datos pueda acceder. Un motor de búsqueda cuando intenta acceder a alguna web o directorio con esta implementación, recibe un código de respuesta 401, por lo que ni rastreará ni indexará dicha web.
¡Aprende a bloquear una web con contraseña!Herramientas como Screaming Frog permiten insertar los datos de autentificación, por lo que se puede rastrear la versión testing para auditarla antes de hacer el deploy a la versión de producción.
Esta opción a nivel de SEO tiene el mismo resultado que el bloqueo por contraseña, podría decirse que es de hecho una opción más segura, pero a su vez también demasiado restrictiva. Ya que esta opción impide rastrear la página con VPN en el caso de que sea una web multilingüe (hay webs donde es necesario a nivel legal ciertas implementaciones automáticas).
Realmente la mayor pega de ese método es que muy poca gente tiene una IP estática, y aunque se pueda emplear un noip, resulta una práctica tediosa en un proyecto a largo plazo, más aún si el equipo trabajando en el proyecto es grande.
Se podría intentar la locura de buscar todos los user-agents correspondientes a motores de búsqueda, o una opción más sencilla que es la de inventarse un user-agent y que todos en el proyecto trabajen con el mismo.
A la práctica es como el de la contraseña, e incluso combinable y ciertamente original, pues acaba teniendo el mismo efecto. Pero admito que esto es una bizarrada mía que se me ocurrió, que he probado probado en distintas webs con bastante éxito. Pero no he visto esta práctica realizada por otras personas.
En cualquier caso, de esta forma bloqueamos la web para todos los user-agent menos el nuestro personalizado.
¿Por qué no se deben implementar las otras prácticas más comunes?
El problema principal que representa el noindex es que se sigue rastreando la página, y que se corre el riesgo de que se cuelen esos noindex a la hora de hacer el deploy a producción. Además de que esto no impide el rastreo de la página, consumiendo recursos de la página de cualquier bot que entre de gratis. También puede suponer un problema a la hora de auditar el entorno en desarrollo. Impidiendo diferenciar entre que páginas serán indexables y cuales no.
El canonical no supone problema alguno en el caso de hacer deploy, ya que de hecho es conveniente tener un self-refering aunque eso probablemente indique que está puesto de forma estática y no de forma dinámica.
Pero la realidad es que el canonical es una indicación, no una directiva. Por lo que (y más si no existe esa página en producción) podríamos acabar teniendo versiones de la web en desarrollo indexadas, lo cual puede ser un caos, porque el cliente no va a ver fácilmente por qué no le funcionan los servicios o la compra de productos (entre otros muchos posibles problemas de que el usuario encuentre la web en desarrollo).
Esta sería la peor opción, porque reúne todos los problemas del noindex, y salvo en imágenes y vídeos, no impide la indexación.
Además todas estas prácticas menos la del canonical, impiden hacer una auditoría correcta de SEO Técnico del staging. Ya que se acabarían ignorando estas directivas e indicaciones, pudiendo suponer un problema grave en desarrollo.
A veces pueden surgir problemas bastante graves como los que sufrieron unos grandes medios por bloqueos con el robots.txt.
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!Si te ha gustado esta publicación, siempre me lo puedes agradecer dándome like en esta publicación de LinkedIn sobre este mismo artículo.
