Checklist de traspaso de un sitio web: todo lo que hay que transferir cuando un sitio cambia de manos

Una lista de traspaso para agencias que terminan un proyecto, personal que deja un puesto o clientes que cambian de proveedor: cuentas y propiedad, dominio y DNS, código y contenido, formularios y datos, integraciones, documentación y una hoja de cierre. Incluye las trampas de plazos en la transferencia de dominios.

Un sitio web cambia de manos más a menudo de lo que se cree: una agencia termina un proyecto, un freelance pasa a otra cosa, se va la única persona del equipo que "llevaba la web", un cliente cambia de proveedor. Cada vez se pierde algo. Normalmente no es el sitio en sí, sino lo que lo rodea: el dominio registrado con la tarjeta personal de alguien, el formulario que envía correos a un exempleado, la cuenta de analítica en la que nadie puede entrar. Un traspaso solo está completo cuando el nuevo responsable puede gestionar el sitio, arreglarlo y dejarlo, sin llamar al anterior. Esta lista está construida en torno a esa prueba.

La regla que evita la mayoría de los problemas de traspaso

Las cuentas pertenecen a la organización, no a las personas. Cada servicio del que depende el sitio debe estar registrado con un correo de la organización (web@, it@, admin@) que sobreviva a los cambios de personal, con la organización como titular de la cuenta y la facturación en un medio de pago de la organización. Si solo arregla una cosa durante un traspaso, que sea esta.

Para las agencias, el corolario es: construya en las cuentas del cliente desde el primer día siempre que pueda, o planifique explícitamente en el contrato la transferencia de cada cuenta. "Lo entregaremos todo al final" es como los dominios acaban en el limbo durante meses.

1. El inventario de cuentas

Enumere cada cuenta que toca el sitio web. Copie esta tabla y rellene una fila por servicio.

Servicio	Proveedor	Titular de la cuenta (organización)	Correo de acceso	Quién paga	Fecha de renovación	¿Transferida? (fecha)
Registrador del dominio
Proveedor de DNS (si es distinto)
Plataforma web o alojamiento
Correo del dominio
Analítica
Search Console / Bing Webmaster
Perfil de empresa en mapas
Pagos
Email marketing / boletín
Reservas, chat u otros elementos incrustados
Repositorio de código
Licencias de imágenes de stock o fuentes

En las herramientas que lo permiten (analítica, Search Console, perfiles de empresa), la transferencia más limpia es: añadir al nuevo responsable como propietario o administrador completo, confirmar que puede entrar y verlo todo y, después, quitar al anterior. Nunca quite primero.

2. Dominio y DNS

El dominio es el único activo que puede llevarse consigo todo el sitio y el correo. Trátelo con especial cuidado.

Compruebe el titular. El titular registrado (el registrante) debe ser la organización. Si el titular es una agencia o un exempleado, cámbielo.
Conozca las reglas de plazos antes de empezar. Según la Transfer Policy de ICANN, un registrador puede rechazar una transferencia a otro registrador dentro de los 60 días posteriores al registro del dominio o a una transferencia anterior. La política también exige un bloqueo de transferencia de 60 días tras un cambio de titular, del que los registradores pueden permitir que el titular se excluya. En la práctica: si va a cambiar tanto el titular como el registrador, pregunte al registrador por la exclusión antes de cambiar el titular, o haga primero el cambio de registrador.
Mover la cuenta puede ser más sencillo que mover el dominio. Muchos registradores permiten pasar un dominio a otra cuenta de cliente en el mismo registrador, lo que suele ser más rápido que una transferencia entre registradores.
Exporte la zona DNS (o haga captura de cada registro) antes de cambiar nada. El correo, las verificaciones y los servicios de terceros suelen depender de registros que nadie recuerda haber añadido.
Active la renovación automática con un medio de pago de la organización y anote la fecha de vencimiento en el inventario.

Nuestras guías sobre registros MX, SPF, DKIM y DMARC y qué pasa cuando vence un dominio cubren los registros que más se rompen durante un traspaso.

Un panel de dominios en un editor web que invita al propietario a conectar un dominio que ya tiene — En We.Inc, el propietario de un sitio conecta un dominio suyo. El dominio sigue en su registrador, a su nombre.

3. El sitio en sí: código, contenido y medios

Una copia completa y actual del sitio que el nuevo responsable pueda conservar de forma independiente: una descarga del código, un repositorio de su propiedad o una exportación completa, según la plataforma.
Los originales de los medios (imágenes en alta resolución, logotipos en formato vectorial, vídeos), no solo las versiones comprimidas del sitio.
Licencias de temas, plugins, fuentes e imágenes de stock de pago, con prueba de que están a nombre del cliente y no de la agencia.
Una lista de páginas, incluidas las landing pages ocultas o sin enlazar que aún usan anuncios o materiales impresos.
Las redirecciones activas y su motivo.

Un panel de código con el árbol de archivos de un proyecto web y el código fuente de un componente — El código de cada sitio de We.Inc se puede ver en el editor (si la marca lo permite) y descargar.

Un cuadro de diálogo Export Project con pestañas GitHub, ZIP, Vercel y Domain y un campo para el nombre del repositorio — Exportar a un repositorio de GitHub que controle el nuevo responsable es una forma de traspasar el código.

4. Formularios, datos y notificaciones

Aquí es donde los traspasos fallan en silencio. Un formulario que envía correos a un empleado que ya se fue parece correcto desde fuera durante meses.

Enumere cada formulario, a dónde se envían por correo sus envíos y dónde se guardan.
Cambie las direcciones de notificación a buzones compartidos.
Exporte los envíos guardados que la organización deba conservar y acuerden quién borra las copias antiguas.
Anote los datos personales que recoge el sitio y dónde los describe la política de privacidad, para que la política siga coincidiendo con la realidad tras el traspaso.
Envíe una prueba desde cada formulario después del cambio y confirme que llega.

5. Integraciones y claves

Conexiones de pagos, reservas, boletín y chat: quién es titular de cada cuenta y si la conexión sobrevive a un cambio de propietario del sitio.
Claves de API y webhooks: enumérelos y luego rote cualquier clave que conociera la parte saliente. Rotar es barato; la clave operativa de un excontratista no lo es.
Códigos de seguimiento y píxeles: confirme que cada uno informa a una cuenta que controla el nuevo responsable; elimine los que no.

6. Personas y accesos

Enumere a todas las personas con acceso a cualquiera de las cuentas anteriores.
Quite el acceso de la parte saliente después de que el nuevo responsable haya confirmado el suyo, y anote la fecha.
Cambie las contraseñas compartidas. Páselas al gestor de contraseñas de la organización.
Active la autenticación en dos pasos donde se ofrezca, con los códigos de recuperación guardados por la organización.

7. La documentación que de verdad necesita el nuevo responsable

Un documento de traspaso no tiene por qué ser largo. Tiene que responder a las preguntas que tendrá el nuevo responsable en la primera semana mala.

Pregunta	Respuesta en el documento
¿Cómo cambio el horario / los precios / la página del equipo?	Paso a paso para las cinco ediciones más comunes
El sitio no funciona. ¿Qué reviso?	Renovación del dominio, DNS, página de estado de la plataforma, contacto de soporte
Han dejado de llegar los formularios. ¿Por qué?	Dónde se configuran las notificaciones, cómo probar, carpeta de spam
¿Qué se renueva, cuándo y a qué coste?	La columna de renovación del inventario
¿Qué acordamos no cambiar?	Reglas de marca, textos legales que son responsabilidad de otra persona
¿A quién llamo?	Soporte de la plataforma, cualquier desarrollador contratado, responsable interno

8. Cierre

Termine con una breve hoja de cierre que conserven ambas partes. Cada línea la marca quien recibe, no quien se va.

Elemento	Confirmado por quien recibe	Fecha
Puedo entrar en todas las cuentas del inventario como propietario o administrador
El titular del dominio es nuestra organización y la renovación automática está activa
Tengo una copia completa e independiente del sitio
Los envíos de prueba de todos los formularios llegaron a nuestra bandeja
Se rotaron todas las claves que conocía la parte saliente
Se quitó el acceso de la parte saliente
Tengo el documento de traspaso y las licencias

Traspaso en una plataforma de marca blanca

Cuando una agencia crea sitios en una plataforma de marca blanca, el cliente suele tener una cuenta bajo la marca de la agencia. Eso plantea una pregunta justa para ambas partes: ¿qué pasa con el sitio si la relación termina? Consiga la respuesta por escrito antes de empezar y compruébela en una demo.

En We.Inc, la respuesta es concreta. Cada cliente tiene su propia cuenta bajo la marca de la agencia, entra por el acceso con la marca de la agencia y es dueño de sus sitios en esa cuenta. Si la agencia da de baja a un cliente, los sitios del cliente siguen en línea y su cuenta queda intacta; el cliente simplemente deja de recibir los controles y los correos con la marca de la agencia, y la agencia puede restaurarlos más adelante. El código del sitio se puede descargar como ZIP o exportar a GitHub, y un dominio que conectó el cliente sigue registrado a su nombre.

Panel de control de un cliente con sitios, plan, límite de sitios, interruptores de funciones, notas, etiquetas y opciones para pausar o dar de baja al cliente — La vista de la agencia de un cliente. Dar de baja a un cliente termina la relación con la agencia, pero mantiene sus sitios en línea y su cuenta intacta.

Una página de acceso con los colores y el logotipo de la agencia, sin mención de la plataforma que hay detrás — Los clientes entran por el acceso con la marca de la agencia con su propia cuenta, que es suya y no un usuario compartido de la agencia.

Si quiere ver ese flujo, incluido lo que el cliente ve y conserva, agende una demo. Para la parte contractual de dejar un proveedor, lea nuestro plan de salida de un proveedor web; para las comprobaciones antes de publicar un sitio nuevo, nuestra lista de lanzamiento de un sitio web.

Fuentes

Última revisión: 2026-10-25.

ICANN, Transfer Policy (rechazo de transferencias en 60 días y bloqueo tras cambio de titular). ICANN ha estado revisando esta política; consulte las reglas actuales de su registrador antes de actuar.

Preguntas frecuentes

¿Qué debe incluir el traspaso de un sitio web?

Un inventario de todas las cuentas de las que depende el sitio, a nombre de la organización, el dominio y los registros DNS, una copia independiente del código, el contenido y los medios, licencias, ajustes de formularios y datos, claves rotadas, accesos retirados a la parte saliente, un breve documento de traspaso y una hoja de cierre validada por quien recibe.

¿Quién debe ser el titular del nombre de dominio?

La organización a la que pertenece el sitio web, como titular, con un correo y un medio de pago de la organización y la renovación automática activada. No una agencia, un freelance ni un empleado concreto.

¿Puedo transferir un dominio justo después de cambiar su titular?

Puede que no. La Transfer Policy de ICANN exige a los registradores aplicar un bloqueo de transferencia de 60 días tras un cambio de titular, aunque pueden permitir que el titular se excluya, y un registrador puede rechazar transferencias dentro de los 60 días posteriores al registro o a una transferencia anterior. Consulte antes con su registrador.

¿Cómo sé que un traspaso está completo?

Cuando el nuevo responsable puede gestionar, arreglar y dejar el sitio sin contactar al anterior: entra como propietario en todas partes, tiene una copia independiente, recibe los envíos de formularios y ya no existen los accesos ni las claves de la parte saliente.

¿Qué pasa con el sitio de un cliente si una agencia deja de usar We.Inc para él?

Si la agencia da de baja a un cliente, los sitios del cliente siguen en línea y su cuenta queda intacta; deja de recibir los controles y correos de la agencia. El código se puede descargar o exportar a GitHub.