¿De quién es tu sitio web? Propiedad del código, accesos y traspaso de proveedor

El problema aparece el día que querés cambiar de proveedor

Casi ninguna empresa pregunta por la propiedad de su sitio web cuando firma un presupuesto. La pregunta llega dos años después, cuando el proveedor no responde, cuando el costo de mantenimiento se volvió impagable o cuando aparece una agencia que promete lo mismo por la mitad. Ahí se descubre el problema: el repositorio está en una cuenta personal, el dominio figura a nombre de un tercero y nadie tiene la clave del hosting.

No es un caso raro. En las auditorías previas a asumir un proyecto es habitual encontrar sitios productivos sin repositorio accesible, con plugins premium licenciados a nombre del proveedor anterior y con la base de datos corriendo en un servidor que solo administra él. Técnicamente el sitio funciona. Comercialmente, estás atado.

Qué significa ser dueño de tu sitio web

La propiedad digital no es un documento: es un conjunto de activos y accesos que tenés que poder ejercer sin depender de nadie.

• Dominio y DNS: registrado a nombre de tu empresa (CUIT), con acceso al panel del registrador y a la zona DNS.
• Hosting o cloud: cuenta propia (AWS, DigitalOcean, Cloudflare) con facturación a tu nombre y acceso de administrador.
• Repositorio de código: GitHub, GitLab o Bitbucket de la empresa, con historial completo de commits.
• Base de datos y backups: acceso, política de respaldo y una copia restaurable probada.
• Certificados y CDN: posibilidad de emitir y renovar TLS sin pedir permiso.
• Licencias de terceros: plugins, temas, fuentes y APIs contratadas a tu nombre.
• Cuentas de medición: Analytics, Search Console, píxeles y tag manager bajo tu propiedad.
• Documentación: arquitectura, integraciones, variables de entorno y procedimientos de deploy.

Si alguno de esos puntos vive en una cuenta personal del proveedor, la respuesta a «¿de quién es el sitio?» es incómoda.

Las tres trampas más comunes

1. Código que solo existe en producción. Se edita por FTP o por el panel del hosting. No hay repo, no hay historial, no hay forma de reconstruir el sitio si el servidor falla.
2. Licencias a nombre del proveedor. El sitio depende de una suscripción que se corta cuando se corta la relación comercial.
3. Accesos compartidos sin control. Una casilla de correo con la misma contraseña en cinco personas y sin doble factor. Cuando alguien se va, nadie sabe qué revocar.

Checklist de traspaso en diez puntos

Antes de firmar con cualquier proveedor, pedí por escrito:

1. Titularidad del dominio y del DNS a nombre de tu empresa.
2. Repositorio propio con permisos de administrador para tu equipo.
3. Hosting y servicios cloud en cuentas de tu empresa.
4. Entrega de backups completos al menos una vez por mes.
5. Inventario de licencias y quién paga cada una.
6. Documentación de arquitectura e integraciones.
7. Procedimiento de deploy reproducible.
8. Accesos nominales, con doble factor y gestor de contraseñas.
9. Cláusula de salida: qué se entrega y en cuántos días si terminás la relación.
10. Verificación técnica de que el sitio se puede levantar en un entorno nuevo.

Ese último punto es el único que vale: si el código no se puede desplegar en otra infraestructura sin ayuda del proveedor anterior, la propiedad es teórica.

Cómo lo trabajamos en Codit Digital

En nuestros proyectos el repositorio, el dominio, el hosting y las cuentas de medición quedan a nombre del cliente desde el día uno. Trabajamos con Codit Suite, nuestro motor modular, que separa el núcleo de los módulos de negocio: si mañana querés cambiar de equipo, te llevás el código documentado, no una caja negra. Cuando asumimos un proyecto heredado, arrancamos con una auditoría de propiedad y accesos antes de tocar una línea.

Un sitio que no podés mover no es un activo: es una dependencia. Y las dependencias se pagan todos los meses.

¿Querés saber si tu web realmente es tuya? Auditamos la propiedad técnica de tu sitio y te entregamos el checklist de traspaso completo, o escribinos por acá.