Comprar un ecommerce que ya funciona: qué comprobar antes

El vendedor abre un portátil, gira la pantalla hacia usted, muestra un gráfico con una curva creciente y dice una cifra, a la que siguen de inmediato el resto de las cifras y las afirmaciones: la tienda funciona, la facturación es esta, el tráfico de compradores es aquel, y el precio es este. Todo parece en orden, y precisamente por eso conviene detenerse, porque casi cada una de esas afirmaciones se puede comprobar, y casi ninguna se comprueba mientras el contrato aún no está firmado.

Este artículo trata de la comprobación técnica antes de comprar un ecommerce que ya funciona, y no de cuánto vale una tienda así, porque la valoración y las cuestiones fiscales son trabajo de otras personas, que aquí no tocamos a propósito. Sobre cómo construir una tienda desde cero hemos escrito aparte, igual que sobre cuánto cuesta crear una tienda online. Aquí se trata de una situación distinta: la tienda ya existe, tiene historia, y la pregunta es qué de esa historia pasa de verdad a usted y qué se queda en el vendedor.

El acceso a la analítica muestra menos de lo que parece

Lo primero que pide todo comprador razonable es un acceso de lectura a Google Analytics, y eso es correcto, pero no basta, porque ese acceso demuestra menos de lo que la mayoría cree. Google Analytics 4 tiene cinco roles, a saber, Administrador, Editor, Profesional del marketing, Analista y Lector, y precisamente el rol de Lector es el que suele asignarse al comprador: el Lector ve la configuración y los datos y puede cambiar lo que aparece en los informes, pero no puede gestionar usuarios ni cambiar la configuración de la propiedad.

La propia asignación ya dice algo, porque solo un Administrador puede añadir un usuario, y a los usuarios se les identifica por la dirección de correo de una cuenta de Google, de modo que un vendedor que no puede conceder un acceso de lectura no es Administrador de esa propiedad, y esa es una pregunta que hay que hacer de inmediato. Una captura de pantalla no es un acceso, y una conversación en la que el vendedor muestra su pantalla tampoco lo es, aunque las cifras parezcan convincentes.

A continuación viene un detalle que poca gente conoce y que puede invertir por completo lo que se deduce de las cifras, porque Google Analytics permite imponer a una propiedad restricciones de datos, y dos de esas restricciones afectan precisamente al dinero: «Sin acceso a métricas de costes» oculta las métricas de costes, y «Sin acceso a métricas de ingresos» oculta las métricas de ingresos. Los valores restringidos no aparecen en los informes, y el usuario ve un cero en su lugar. El comprador que ve ceros en la columna de ingresos, por tanto, no ha visto que la tienda no gana, sino que quizá ha visto una restricción, y la única forma de aclararlo es preguntar si la restricción está puesta.

Hay también un límite más general que conviene tener presente durante toda la comprobación, y toca la propia medición: la analítica muestra lo que registró el código de medición instalado, no cuánta gente llegó de verdad. Un código puesto solo en la página de agradecimiento, un código que se dispara dos veces, un código en un entorno de desarrollo o un mismo código que sirve a varios sitios web, en el informe parecen visitas. Ninguno de estos casos es un fraude por definición, pero cada uno convierte la cifra en algo distinto de lo que el comprador cree.

Search Console es otro objeto y otra comprobación

Google Search Console muestra lo que Google mismo registró sobre la aparición del sitio web en los resultados de búsqueda, de modo que es en parte independiente del código de medición que instaló el vendedor, y precisamente esa independencia la hace más valiosa que la analítica, aunque las cifras allí sean menores y menos lisonjeras. Los roles allí son distintos de los de la analítica: propietario, usuario con acceso total, usuario con acceso restringido y asociado, y una propiedad tiene que tener al menos un propietario verificado; si no, nadie tiene acceso.

El usuario con acceso restringido ve el informe de rendimiento, es decir, consultas, clics, impresiones y posición media, pero no puede añadir usuarios, enviar un sitemap ni inspeccionar por completo una URL concreta, de modo que al comprador le basta para ver el tráfico de búsqueda, pero no le basta para tomar la propiedad. Es una diferencia deliberada que conviene entender antes de la conversación, porque un vendedor que ofrece solo el acceso de usuario restringido ofrece cifras, no la posibilidad de tomar el control.

Está también la pregunta de cuán antigua es la propia historia, y suele decidir más que el tamaño de las cifras, porque Google empieza a recoger datos de una propiedad en el momento en que alguien la añade, todavía antes de la verificación, de modo que una propiedad creada hace poco no puede mostrar una historia de varios años, independientemente de cuánto tiempo lleve funcionando la tienda. Pregunte cuándo se creó la propiedad y compárelo con la antigüedad que se afirma de la tienda.

Ahora, lo que esta herramienta puede mostrar mal, y no son afirmaciones sobre la deshonestidad del vendedor, sino simplemente mecánica: una propiedad puede ser de dos tipos, a saber, una propiedad de prefijo de URLs, que cubre solo una dirección con su protocolo, y una propiedad de dominio, que cubre todo el dominio con todos los subdominios. Una propiedad de dominio puede, por tanto, mezclar en una sola cifra el tráfico de la tienda y el de un blog del todo separado, y la única forma de verlo es mirar qué tipo de propiedad está abierta.

La segunda cuestión de mecánica es la verificación, y funciona así: la propiedad se verifica con una prueba en el sitio web, y uno de los métodos permitidos es precisamente el código de seguimiento de Google Analytics. Eso significa que las dos herramientas pueden haberse verificado con el mismo código, controlado por la misma persona, de modo que dos comprobaciones aparentemente independientes pueden estar hablando del mismo sitio web, quizá el equivocado. Además, los tokens de verificación no utilizados permiten a un propietario retirado con anterioridad volver a verificarse, de modo que el comprador, al convertirse en propietario, tiene que revisar qué pruebas quedan todavía en el sitio web.

Por último, conviene conocer el límite de la ventana histórica, que aquí es estricto: los datos de rendimiento se conservan dieciséis meses, de modo que de esta herramienta no se puede extraer una historia de crecimiento de tres años, y el vendedor que lo promete tiene que demostrarlo con otra cosa. Y lo último: no es correcto esperar que las cifras de la analítica y de la herramienta de búsqueda coincidan, porque miden cosas distintas, y ningún documento de Google promete una relación determinada entre ellas.

La exportación no es la tienda

El segundo gran problema está en la palabra exportación, porque el comprador la entiende como una copia de la tienda, pero en la práctica es un extracto de tablas concretas con límites concretos. WooCommerce incluye en el núcleo una herramienta de importación y exportación de productos, y de verdad funciona, pero es una herramienta de productos: no cubre en absoluto clientes ni pedidos, y para eso hace falta o un plugin de pago o acceso directo a la base de datos.

Las imágenes son un detalle aparte con consecuencias desproporcionadas, y la razón está en la mecánica de la exportación: la exportación de productos trabaja con las direcciones de las imágenes, no con los archivos mismos, de modo que las imágenes tienen que ser accesibles en el momento de la importación, y la herramienta del núcleo no transfiere los textos alternativos de las imágenes. Para una tienda con unos cuantos miles de productos eso significa que, después del traslado, parte de las imágenes puede simplemente no estar, y eso se descubre solo cuando ya es demasiado tarde para negociar el precio.

En las plataformas más cerradas los límites son más estrictos, y hay que conocerlos antes de la conversación sobre el precio, no después: los hashes de las contraseñas normalmente no se trasladan, y eso significa que todos los clientes existentes tendrán que restablecer la contraseña después del traslado, lo cual es una pérdida directa de clientes y que el vendedor mencionará pocas veces. La licencia del tema suele quedarse en la cuenta del vendedor, los plugins son suscripciones aparte con sus propias licencias, y algunas plataformas no permiten reimportar el historial de pedidos por el panel de administración en absoluto.

Al mismo grupo pertenecen tres detalles que se recuerdan pocas veces y que cada uno, por separado, cuesta dinero. Las tarjetas regalo con saldo son obligaciones frente a los clientes, y no siempre se trasladan con el resto de los datos, de modo que la pregunta de cuánto saldo sin usar hay en la tienda pertenece a la conversación del precio. Un certificado TLS no se transmite como un bien, sino que se emite de nuevo a nombre del nuevo titular, y eso es rutinario solo si el dominio ya está en sus manos, mientras que la licencia del tema suele estar atada a la cuenta del vendedor, de modo que después del traslado puede resultar que el aspecto hay que comprarlo otra vez.

De ahí se sigue un paso de comprobación que no cuesta nada y dice mucho. Pida al vendedor que genere una exportación de prueba todavía antes del contrato y ábrala usted mismo, porque allí verá de inmediato si hay clientes, si los pedidos tienen líneas de producto, si las imágenes tienen direcciones y si algo de lo que se ve en la tienda no aparece en el archivo en absoluto.

El dominio se transmite con el cambio de titular, no al cambiar los registros

La parte del dominio es aquella en la que los compradores mezclan tres operaciones del todo distintas, y esa mezcla suele terminar con el dominio quedándose a nombre del vendedor. El cambio de servidores de nombres es solo una indicación de quién sirve los registros del dominio, y con la titularidad no tiene nada que ver; el cambio de agente registrador cambia quién administra el dominio; y el cambio de titular es el que cambia a nombre de quién está registrado el dominio.

Para los dominios .es, el cambio de titular lo fija Dominios.es, y precisamente ese trámite —la transmisión de dominio— es el que protege a los titulares frente a que un extraño reescriba el dominio a su nombre. La transmisión ordinaria la puede iniciar el agente registrador que gestiona el dominio, el titular o el contacto administrativo. Si la inicia el agente registrador, el titular o el contacto administrativo confirman o rechazan el inicio por correo y luego en el panel de control de Dominios.es; si la inician el titular o el contacto administrativo, lo hacen ellos mismos en ese panel. El nuevo contacto administrativo acepta los términos en el panel. Existe además una transmisión especial para la sucesión universal inter vivos o mortis causa y la sucesión de empresas, con prueba documental y DNIe, certificado o copia del DNI. El procedimiento está en dominios.es.

Dos detalles de este trámite importan más que el resto, y el primero es que, una vez actualizados los datos del titular, el anterior titular deja de controlar el nombre, de modo que el cambio hay que hacerlo bien a la primera. El segundo es que la solicitud de una persona jurídica la hacen quienes tienen poder de representación y los datos del titular tienen que ser exactos y veraces; no basta con que la envíe un empleado cualquiera de la empresa.

Merece una atención aparte el caso de que el vendedor sea una empresa que se va a liquidar, porque precisamente aquí la compra de la tienda puede terminar con la pérdida del dominio. En Dominios.es no hay una regla según la cual el cambio de titular tenga que hacerse antes de que termine la liquidación, la actividad económica suspendida bloquee el cambio, o tras la liquidación se abra un periodo breve al cabo del cual el nombre quede libre para cualquiera. Lo que sí hay es una transmisión especial para la sucesión de empresas, con documentos; y si los datos del titular son falsos, Dominios.es puede iniciar la cancelación del dominio. Un comprador que espera a que el vendedor arregle sus asuntos puede, aun así, encontrarse con que la dirección de la tienda se ha ido a un extraño.

La cuenta de pagos no se transmite con el contrato de compraventa

La suposición de que con la tienda se transmite también la aceptación de pagos es frecuente e incorrecta, pero igual de incorrecto es decir que una cuenta de pagos no se puede trasladar en absoluto, porque la formulación correcta está en el medio: el contrato de compraventa por sí mismo no mueve la cuenta, pero el proveedor de servicios de pago tiene su propio procedimiento, y también puede negarse.

Stripe describe en su documentación exactamente este caso, y señala que el titular actual de la cuenta que quiere cederla a otro, por ejemplo al vender la empresa, tiene que ponerse primero en contacto con el servicio de asistencia para aclarar qué información hay que actualizar. Después se cambian los datos de la cuenta bancaria para los abonos, la denominación jurídica de la empresa, el número de identificación fiscal y los datos del representante, y la empresa advierte expresamente de no enviar por correo los datos del nuevo titular, mientras que el procedimiento es otro si la empresa ha pasado a estar bajo una persona jurídica de otro país.

Hay otro detalle que afecta precisamente a los datos y que los compradores conocen tarde: si el paso no consiste en tomar la misma cuenta, sino en trasladarse a una nueva, entonces entre las dos cuentas se pueden copiar clientes y métodos de pago, pero los cargos individuales, las facturas, los planes y las suscripciones, los cupones, los eventos y los registros no se copian. Para una tienda con suscripciones eso es crítico, porque interrumpir las suscripciones significa interrumpir los ingresos, y esta pregunta hay que hacerla antes del negocio, no después.

Las condiciones de los contratos de adquisición de los bancos españoles y de los intermediarios de pago locales, como Redsys, no las hemos usado aquí, porque no las leímos para esta comprobación, y es más honesto decirlo que rellenar el hueco con una conjetura, de modo que este es un hueco deliberado, no una omisión. Si la tienda acepta pagos a través de un banco o de un intermediario de pago local, la pregunta de si el contrato se puede ceder hay que hacérsela precisamente a ese proveedor, y el procedimiento de Stripe no se puede trasladar a él.

La lista de clientes es la parte jurídicamente más aguda

Aquí está el sitio en el que el comprador puede adquirir no un activo, sino una obligación, y precisamente por eso esta sección está escrita como una advertencia, no como una guía. El comienzo está en la estructura del negocio: si compra las participaciones de la empresa (un share deal), el responsable del tratamiento sigue siendo la misma persona jurídica y la base de datos no cambia de dueño; si compra la tienda como un conjunto de activos de otro sujeto (un asset deal), los datos personales llegan a un nuevo responsable del tratamiento, y ese es un caso del todo distinto.

El Reglamento general de protección de datos no promete nada sobre la compra de tiendas, y en él no hay un artículo que diga que una base de datos de clientes se transmite automáticamente. Tiene que haber una base jurídica conforme al artículo 6, y hay un deber de informar: el artículo 13 exige indicar la identidad del responsable del tratamiento en el momento en que se obtienen los datos, mientras que el artículo 14, que se aplica precisamente al caso en que los datos no se han obtenido de la propia persona, exige al nuevo responsable comunicar su identidad, los fines, la base jurídica, las categorías de datos y la fuente, y hacerlo a más tardar en el plazo de un mes o en la primera comunicación.

En España, sobre los correos de marketing se añade otra norma, y precisamente esa es el núcleo de esta sección. El artículo 21 de la Ley 34/2002, de servicios de la sociedad de la información y de comercio electrónico, prohíbe el envío de comunicaciones comerciales por correo electrónico u otro medio de comunicación electrónica equivalente que no hayan sido solicitadas o expresamente autorizadas de antemano, y la excepción exige a la vez una relación contractual previa, que el prestador hubiera obtenido de forma lícita los datos de contacto, y que los emplee para comunicaciones comerciales sobre productos o servicios de su propia empresa similares a los que fueron objeto de contratación; en la recogida y en cada mensaje tiene que haber una forma sencilla y gratuita de oponerse, y cada correo tiene que llevar una dirección válida para ejercer ese derecho. El RGPD sigue siendo de aplicación: sin base jurídica conforme al artículo 6, el tratamiento tampoco es lícito.

Y ahora lo que convierte esto en una trampa: esa excepción está escrita para el prestador que obtuvo las direcciones en sus propios tratos comerciales, es decir, el mismo que atendió a los clientes. El comprador que no ha obtenido las direcciones no es ese prestador, de modo que la excepción del anterior titular no viaja con el archivo.

Esta cuestión está resuelta de formas distintas de un país a otro, y esa discrepancia es más honesta mostrada que tapada. La conferencia de las autoridades alemanas de protección de datos (Datenschutzkonferenz) adoptó en 2024 una postura estricta, al entender que la venta de una base de datos de clientes como un activo separado suele exigir el consentimiento previo, mientras que en España el artículo 21 de la Ley Orgánica 3/2018 (LOPDGDD) presume lícitos, salvo prueba en contrario, los tratamientos —incluida la comunicación previa— que se deriven de una modificación estructural de sociedades o de la aportación o transmisión de un negocio o de una rama de actividad, siempre que sean necesarios para el buen fin de la operación y garanticen, cuando proceda, la continuidad de los servicios; si la operación no se concluye, el cesionario debe suprimir los datos de inmediato. Esa presunción no es una licencia para enviar a una lista de marketing: el artículo 21 de la LSSI-CE sigue exigiendo productos o servicios de la propia empresa del prestador. Al comprador en España le quedan el RGPD, el artículo 21 de la LOPDGDD, el artículo 21 de la LSSI-CE y una valoración jurídica del negocio concreto.

Comprobaciones que no dependen del vendedor

Todas las comprobaciones anteriores dependen de lo que el vendedor concede y de lo que muestran sus ajustes, de modo que al lado conviene poner al menos una cuya fuente sea otra, y la más sencilla de esas comprobaciones son los registros del servidor, porque anotan las peticiones con independencia de si en la página hay instalado un código de medición y de si el visitante consintió las cookies.

Esto no es un método de Google y ningún documento de Google lo recomienda, de modo que tampoco nosotros lo presentamos como una recomendación oficial, sino como una práctica en la que, al comparar el volumen de peticiones de los registros con las sesiones de analítica del mismo periodo, suele verse o una relación razonable o una diferencia sobre la que merece la pena preguntar. El acceso a los registros lo da de ordinario el panel de administración del hosting, de modo que esta comprobación exige acceso al hosting, y precisamente por eso conviene pedirlo a la vez que el resto.

La segunda fuente independiente es el extracto del proveedor de servicios de pago, y es la única de todas que muestra dinero, no visitas. Aquí importa una diferencia: un extracto que el vendedor envía como documento no es lo mismo que un extracto que usted ve en el panel del propio proveedor, porque el primero lo puede preparar cualquiera y el segundo no, de modo que pida acceso al panel o al menos una pantalla compartida con ese panel abierto.

Hay otra comprobación que cuesta cinco minutos y que casi todos se saltan: mirar cómo se ve la tienda hoy en el buscador, introduciendo su nombre y algunas frases de nombres de productos. Si la tienda afirma un tráfico de búsqueda estable, pero no aparece con su propio nombre o aparece detrás de plataformas de comercio en las que ella misma vende, entonces el tráfico viene de otra parte, y conviene aclarar de dónde, porque la publicidad de pago después del negocio puede simplemente detenerse.

La tercera es la parte contable, que no tocamos en el fondo, pero cuya existencia merece mencionarse, porque es la única que ata todo lo demás a cifras declaradas, y si la analítica, el panel de pagos y la contabilidad cuentan tres historias distintas, entonces el problema no está en la precisión de la medición, y a partir de ahí ya no es una conversación técnica.

El estado del código y de la plataforma se puede comprobar barato

La comprobación del estado técnico suena a una auditoría cara, pero la mayor parte de la respuesta se obtiene en unas horas y con datos públicos. El primer paso es determinar la versión de la plataforma y del lenguaje y compararla con el calendario de soporte publicado por el fabricante, porque después del fin del soporte las vulnerabilidades nuevas ya no se parchean, aunque la tienda siga funcionando exactamente igual que antes.

El segundo paso es la lista de plugins junto con su historial de actualizaciones, porque un plugin abandonado es a la vez un riesgo de seguridad y un coste oculto: en algún momento habrá que sustituirlo, y la sustitución en una tienda en funcionamiento suele significar reescribir también todo lo construido a su alrededor. El tercero es la pregunta de si la tienda ha sido alguna vez hackeada y qué se hizo después, y esta pregunta conviene hacerla de frente, porque una respuesta evasiva es aquí tan informativa como una afirmativa.

El cuarto paso se refiere al código, si la tienda está adaptada, y está cerca de la pregunta que hemos tratado aparte en el artículo sobre qué le pertenece cuando el sistema está listo. Aquí basta con el lado práctico: dónde está el repositorio, quién puede acceder a él y si se transmite a usted con la tienda, porque un repositorio en la cuenta personal del vendedor se queda en la cuenta personal del vendedor después del negocio, si no se mueve por separado.

Junto al repositorio están los accesos y las claves, y suelen estar dispersos por sitios que nadie ha apuntado: el panel de hosting, la cuenta del dominio, el panel de pagos, el servicio de correo, las claves de servicios externos y la analítica. Una lista de ellos conviene pedirla por escrito antes del negocio y comprobarla después, porque una clave que nadie entregó se descubre de ordinario cuando algo deja de funcionar, y para entonces el vendedor ya se ha ido.

El quinto es la lista de costes recurrentes que llegan con la tienda, y suele ser más larga de lo que el comprador espera, porque ahí entran la suscripción de la plataforma, las suscripciones aparte de los plugins, el tema, las comisiones del intermediario de pagos, el hosting, el dominio y los certificados, y cada uno tiene su propia fecha de renovación y su propio precio después del primer plazo. Esta lista conviene ponerla en una tabla antes de discutir el precio, porque precisamente ella muestra cuál es el coste mensual real de la tienda.

Qué exigir antes de comprar un ecommerce

Todo lo anterior conduce a un conjunto de exigencias que no ocupa mucho tiempo y que a un vendedor honrado no le resulta difícil cumplir: en el lado de la analítica es el acceso de Lector a la propia propiedad, no capturas de pantalla, junto con la respuesta de si está puesta la restricción «Sin acceso a métricas de ingresos», y en el lado de Search Console el acceso de usuario restringido junto con la indicación de qué tipo de propiedad está abierta.

En el lado de los datos es una exportación de prueba antes del contrato, la respuesta de si se trasladan los hashes de las contraseñas, y claridad sobre qué ocurre con el historial de pedidos. En el lado del dominio es una confirmación de a nombre de quién está registrado el dominio hoy, y el acuerdo de que el cambio de titular ocurre antes del pago o a la vez que él, no después.

En el lado de los pagos es una pregunta al proveedor de servicios de pago, no al vendedor, porque solo aquel puede decir si la cuenta se transmite y con qué condiciones, y la convicción del vendedor en esta cuestión no es una prueba. Si en la tienda hay suscripciones, entonces la misma pregunta hay que hacerla otra vez por separado precisamente sobre ellas, porque las suscripciones son la parte que en un traslado se rompe con más frecuencia. En el lado de la protección de datos es claridad sobre cómo se recogió la lista y qué se dijo entonces a los clientes, y un acuerdo escrito de que después del negocio el nuevo responsable del tratamiento cumplirá su deber de informar.

Este conjunto de exigencias parece largo, pero es más corto que una semana que pasa intentando, después del negocio, recuperar un dominio o restablecer suscripciones, y la mayor parte de ello un vendedor honrado la prepara en un par de horas. El vendedor que objeta a estas exigencias ha respondido con eso mismo a la pregunta más importante, y esa es la forma más barata posible de enterarse.

Y por último hay dos cosas que este artículo no hace a propósito, porque no son nuestro trabajo y pretender ser otra profesión sería lo peor que se podría hacer aquí. No damos una opinión sobre cuánto vale la tienda, y no sustituimos a un abogado en la cuestión del uso de una lista de clientes concreta, porque las dos son trabajo de otras personas. Si desea que comprobemos la parte técnica antes de firmar, escríbanos, y lo hacemos junto con el equipo de desarrollo de tiendas online.