Encargar una web o una tienda WordPress no es comprar un producto en la estantería, sino entrar en una relación de la que es difícil salir a mitad de camino. La decisión más importante no tiene que ver con el precio ni con el portafolio de quien parece más bonito, sino con lo que queda en tus manos cuando el proyecto termina: el acceso, el código y los derechos. Esta guía reúne las preguntas que realmente separan a un buen proveedor de los problemas, y un área en la que casi nadie piensa hasta que es demasiado tarde: el derecho.
Agencia, freelance o equipo interno
Es una elección de continuidad, no de calidad. Un freelance aislado puede ser la mejor opción técnica y el más rápido al decidir, pero también es un único punto de fallo. Hemos visto una tienda detenerse durante una semana porque la única persona que conocía su código se había ido a la montaña sin cobertura, y el conocimiento sobre el proyecto no estaba registrado en ningún sitio. Un equipo interno resuelve el problema de la continuidad, pero solo compensa con una carga de trabajo constante y elevada; con tareas irregulares, un puesto fijo está parado y cuesta igual.
Una agencia es el término medio: pagas un sobreprecio por el equipo y el proceso y, a cambio, obtienes personas sustituibles y documentación, de modo que el proyecto no se detiene cuando una persona se va. El modelo intermedio razonable para la mayoría de las empresas B2B y las tiendas es un ingeniero fijo y nombrado por parte del proveedor, pero con un equipo y conocimiento registrado detrás. La pregunta de control es sencilla: qué pasa con mi proyecto cuando esa persona concreta enferma o se va.
En qué fijarte en lugar de en un portafolio bonito
Un portafolio muestra cómo se ve algo en una captura de pantalla, no cómo funciona bajo carga. Tres cosas dicen más que una galería de trabajos anteriores.
La primera es el rendimiento medido, no declarado. Pide un resultado de Core Web Vitals a partir de datos de campo, o de una prueba en un móvil medio con una conexión más lenta, no en un portátil con fibra. La metodología y los umbrales los describe el equipo de Google en la documentación de Web Vitals. Un buen proveedor muestra cifras antes y después, explica cómo maneja los page builders pesados y cuántas consultas a la base de datos genera una página de producto.
La segunda es la forma de trabajar con el código. Pregunta directamente si el código está versionado en un repositorio o se sube por FTP directamente al servidor. El versionado no es un capricho: es la posibilidad de revertir un error, auditar cambios y permitir que cualquier otra persona retome el proyecto. La falta de repositorio significa que quedas atado a un único proveedor, porque nadie más entra en ese código sin arqueología.
La tercera es la seguridad tras el lanzamiento. Una web no es un cuadro que se cuelga y se olvida; los plugins hay que actualizarlos, y la cadena de suministro de los plugins puede ser un vector de ataque. Pregunta quién responde por las actualizaciones tras el arranque y cómo es la respuesta ante un incidente. La falta de respuesta significa que respondes tú, solo que aún no lo sabes.
Cinco preguntas antes de firmar
Estas cinco preguntas cuestan un minuto y ahorran meses.
- ¿De quién serán los derechos patrimoniales de autor sobre el código y el diseño cuando termine el proyecto, y en qué modalidades de explotación?
- ¿Obtendré acceso administrativo completo al alojamiento, al dominio, al repositorio y a las cuentas externas, o trabajamos en vuestra cuenta cerrada?
- ¿El código está versionado y los despliegues son reproducibles, o los cambios llegan al servidor a mano?
- ¿Quién responde por las actualizaciones, las copias de seguridad y la seguridad tras el lanzamiento, y qué abarca el mantenimiento?
- ¿Veré un resultado real de rendimiento en el móvil, o solo capturas del portafolio?
Si cualquiera de estas preguntas recibe una respuesta evasiva, no es una cuestión de conocimiento, sino de un modelo de negocio que ata al cliente al proveedor por la fuerza y no por la calidad.
Derecho y propiedad: el área en la que nadie piensa lo bastante pronto
Aquí empieza la parte más fácil de pasar por alto y más difícil de corregir después. Según la ley polaca, el mero pago de un proyecto no transfiere automáticamente los derechos patrimoniales de autor sobre el código, las imágenes o los textos; se necesita una cláusula expresa en el contrato que indique las modalidades de explotación. Sin ella, los derechos se quedan con el proveedor y tú solo tienes una licencia para usar aquello por lo que pagaste. El abogado polaco Tomasz Palak lo resume sin rodeos: como escribe en su guía sobre derechos de autor para creadores, “al publicar no se pierden los derechos”, lo que funciona en ambos sentidos, también por parte del proveedor, mientras este no ceda los derechos de forma consciente.
La misma cautela se aplica a los materiales que se suben a la web. Que una foto esté disponible en internet, o que la haya generado un modelo de IA, no significa que puedas usarla comercialmente; hay que comprobar la licencia, porque, como recuerda Palak, no toda “imagen gratuita” es realmente gratuita, y una licencia CC BY no es lo mismo que CC0. Por tu parte, conviene asegurar tres cosas en el contrato:
- La cesión de los derechos patrimoniales de autor sobre el código, el diseño y los contenidos, y no solo una licencia.
- Una declaración del proveedor de que posee los derechos sobre todos los materiales usados, fotos, tipografías y plugins premium, así como sus licencias.
- El cumplimiento del RGPD si la web recoge datos, es decir, quién es el responsable del tratamiento y quién el encargado, y qué pasa con los datos cuando termina la colaboración.
Si usas herramientas de IA para contenidos o imágenes, recuerda una regla que Palak repite: la herramienta no te quita la responsabilidad por lo que publicas. Comprueba los términos de la herramienta y no introduzcas datos que no puedes divulgar. Lo mismo vale para la agencia que contratas: conviene preguntar si usa IA y cómo, y quién responde por los derechos sobre los resultados.
Banderas rojas
Algunas señales ante las que es mejor dar las gracias antes de firmar. Un proveedor que no quiere entregar el acceso al alojamiento, al dominio y al código. La ausencia de repositorio y despliegues exclusivamente manuales. Un precio indicado al margen del alcance, sin análisis de los requisitos reales. Promesas de posiciones en Google o de “visibilidad en la IA” dadas de palabra, sin explicar en qué deben consistir. Por último, el silencio sobre los derechos de autor, porque eso suele significar que los derechos se quedan con el proveedor y solo te enterarás cuando intentes cambiar de proveedor.
Qué sigue
Elegir bien a un proveedor WordPress se reduce a un principio: asegura lo que quedará en tus manos cuando el proyecto termine, antes de que empiece. El acceso, el código versionado y los derechos cedidos por escrito importan más que la diapositiva más bonita de la propuesta. Si estás planeando una web o una tienda y quieres repasar esta lista en un caso concreto, describe lo que el proyecto debe lograr y revisamos juntos a qué prestar atención en tu situación.
Los aspectos jurídicos de este texto tienen carácter general y no constituyen asesoramiento jurídico; ante un contrato concreto, conviene consultar a un abogado especializado en derechos de autor y nuevas tecnologías.
Última actualización: 11 de junio de 2026.
