Subcontratar desarrollo WordPress en una agencia SEO: cómo hacerlo con una iguala mensual

Una agencia SEO vende auditorías, estrategia de contenidos y link building. Después de la auditoría queda una lista de tareas, y una parte de ellas exige tocar el código del tema, los plugins o la configuración del servidor. Sin un desarrollador WordPress en el equipo, esa lista se queda en el cajón y el cliente pregunta por qué el informe de marzo sigue sin efecto en julio. Esta guía explica cómo externalizar ese trabajo con una iguala mensual: qué pasarle al desarrollador, cómo darle acceso sin ceder cuentas, qué poner en el contrato y cómo comprobar que el trabajo da resultado.

Los apartados sobre propiedad intelectual y protección de datos resumen la Ley de Propiedad Intelectual española y el RGPD tal como estaban el 24 de octubre de 2026. No son asesoramiento jurídico individual para tu agencia.

#En resumen

• La agencia se queda con el diagnóstico, las prioridades y la relación con el cliente. El desarrollador responde de la implantación y de que el cambio no rompa producción.
• El acceso se da a una persona, no a una empresa: un usuario propio en Search Console, una cuenta propia en WordPress, una clave SSH propia. Cada uno se retira con un solo gesto.
• En el contrato fija el límite mensual de horas, el tiempo de primera respuesta (separado del tiempo de solución), cómo se presupuestan los trabajos grandes, la marca blanca y la confidencialidad.
• El código que escribe un desarrollador externo es suyo mientras no ceda los derechos por escrito, y la cesión vale solo para lo que el contrato enumera.
• Un desarrollador con acceso a webs con datos personales es un encargado del tratamiento de segundo nivel, así que necesitas la autorización del cliente y un contrato de encargo.
• El resultado se mide por tarea: estado antes, fecha de implantación, estado tras 28 días de datos de CrUX o de Search Console.

#Glosario para quien dirige la agencia

#Qué tareas de una auditoría SEO necesitan un desarrollador WordPress

Una auditoría técnica suele terminar con una lista de hallazgos, no con una lista de personas. El primer paso es repartir quién hace qué. El reparto de abajo sale de dónde está el cambio: en el contenido y los ajustes del panel, o en el código y el servidor.

Cuando envías una incidencia al desarrollador, la columna “agencia” indica lo que él espera de ti: la lista de URL, los datos de Search Console, el mapa de redirecciones. Una incidencia sin esos datos empieza con preguntas, y las preguntas se comen horas del paquete. De dónde salen las semanas de espera para cambios sencillos lo explicamos en el artículo por qué los cambios en una web WordPress tardan semanas.

#Cómo dar acceso a Search Console a un desarrollador sin ceder la cuenta

Search Console tiene cinco niveles de acceso. Su descripción procede de la documentación de Google sobre usuarios y permisos (support.google.com).

El desarrollador casi nunca necesita ser propietario. Le basta con acceso total: ve todos los datos, y añadir usuarios y cambiar ajustes sigue siendo cosa de los propietarios.

Al terminar la colaboración es fácil olvidar los tokens. Según la misma página de Google, el propietario eliminado pierde el acceso, pero sus tokens de verificación no se borran ni se invalidan. Si el token (archivo HTML, metaetiqueta, registro DNS) sigue en la web o en el dominio, esa persona puede volver a verificar la propiedad. Por eso un desarrollador externo no debería verificar la propiedad con su propia cuenta. Y si alguna vez lo hizo, al despedirte de él eliminas tanto el usuario como su token. Google lo advierte en el panel: si al eliminar a alguien aparece un aviso de que puede recuperar el acceso, sus tokens siguen en su sitio.

Si se eliminan todos los propietarios verificados, el resto de usuarios y los propietarios delegados pierden el acceso tras un periodo de transición. El propietario verificado debe ser, por tanto, el cliente, y la agencia y el desarrollador trabajan con accesos que el cliente puede controlar.

#Qué rol de WordPress dar a un desarrollador externo

WordPress tiene seis roles por defecto. La documentación de wordpress.org los describe así: el Superadministrador gestiona una red multisitio, el Administrador tiene acceso a todas las funciones de administración de un sitio individual, el Editor publica y gestiona entradas, también las de otros, el Autor publica sus propias entradas, el Colaborador escribe pero no publica, y el Suscriptor solo gestiona su perfil.

En una instalación individual solo el Administrador tiene, entre otras, estas capacidades: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users y unfiltered_html. En un multisitio solo las tiene el Superadministrador. Esto significa que un desarrollador que tiene que actualizar plugins o instalar otros nuevos necesita el rol de Administrador en staging y, por lo general, también en producción. El rol de Editor no basta para el trabajo técnico.

Como la cuenta del desarrollador es una cuenta de administrador, importa la higiene a su alrededor:

• Una cuenta para cada persona. Una cuenta compartida “agencia-dev” significa que no sabes quién cambió qué, y que no puedes retirar el acceso a una persona sin cambiar la contraseña a todas.
• Edición de archivos desactivada en el panel. La documentación de seguridad de WordPress (developer.wordpress.org) indica que define( 'DISALLOW_FILE_EDIT', true ); en wp-config.php equivale a quitar a todos los usuarios edit_themes, edit_plugins y edit_files. De todos modos, el desarrollador debería desplegar el código desde un repositorio y no desde el editor del panel.
• Staging con el entorno marcado. La función wp_get_environment_type() devuelve local, development, staging o production, y si no se ha definido nada asume production (developer.wordpress.org). Marcar la copia como staging permite que el código y los plugins se comporten de otra forma, por ejemplo que no envíen correos a los clientes de la tienda.
• SFTP o SSH en lugar de FTP. La misma documentación de seguridad recomienda SFTP, porque la contraseña y los datos viajan cifrados. En la práctica funciona mejor una clave SSH por persona: retirar el acceso consiste en borrar una línea de authorized_keys, sin cambiar la contraseña de nadie más. Sobre el despliegue con SSH y Git escribimos en despliegue moderno de WordPress con SSH y Git.

Las cuentas del alojamiento, del registrador del dominio, de la CDN y las licencias de plugins premium deberían pertenecer al cliente o a la agencia. El desarrollador recibe acceso a ellas como usuario, no como titular.

#Cómo retirar los accesos al terminar la colaboración

Lista para el día en que termina el contrato, mejor si figura en el propio contrato como obligación de ambas partes:

1. Search Console: elimina al usuario y todos sus tokens de verificación (archivo, metaetiqueta, registro DNS).
2. WordPress: elimina las cuentas del desarrollador en producción y en staging, y atribuye sus entradas a otro usuario.
3. Servidor: borra sus claves SSH de authorized_keys, las cuentas SFTP y, si las hay, las cuentas de base de datos.
4. Repositorio: retira el acceso a la organización, a las claves de despliegue y a los secretos de CI.
5. Alojamiento, CDN, gestor de DNS, pasarela de pago: elimina al usuario y, donde la cuenta era compartida, cambia la contraseña y las claves API.
6. Herramientas externas: Google Analytics, Tag Manager, monitorización, gestor de contraseñas.
7. Datos: confirmación por escrito de que el desarrollador ha suprimido o devuelto las copias de bases de datos y archivos con datos personales (lo exige la letra g del art. 28.3 del RGPD, que se explica más abajo).

Si esta lista no se puede completar en una hora, los accesos se concedieron con demasiada amplitud o sobre cuentas compartidas.

#Core Web Vitals: qué arregla el desarrollador y qué el alojamiento

Los umbrales los publica web.dev (vitals). Se miden en el percentil 75 de las visitas, por separado para móvil y para ordenador.

INP pasó a ser una métrica estable de Core Web Vitals en 2024 y sustituyó a FID. Los informes de clientes anteriores a ese cambio que hablan de FID describen una métrica que Google ya no usa en este conjunto.

El reparto de responsabilidades sale de cómo se compone cada métrica. El LCP incluye el tiempo de conexión, de redirecciones y de respuesta del servidor, y solo después la carga y el renderizado del elemento. Parte de ese tiempo corresponde al alojamiento y parte al tema.

Un desarrollador que ante cada mal resultado contesta “es culpa del alojamiento” no está enseñando ninguna medición. Un buen socio, ante un TTFB alto, separa el tiempo de PHP, de la base de datos y de la red, y solo entonces señala al responsable. Si el cliente necesita un diagnóstico aparte antes de decidir los cambios, para eso está la auditoría de Core Web Vitals, y las correcciones en sí las describe la página de optimización de velocidad de WordPress. Una revisión técnica de las métricas la tienes en la guía rendimiento de WordPress: Core Web Vitals, caché e imágenes.

#Qué poner en el contrato de iguala con un desarrollador WordPress

Una iguala con un desarrollador vende dos cosas: tiempo reservado y una respuesta previsible. El contrato debe describir ambas de forma que, a los tres meses, nadie tenga que adivinar qué se acordó.

#Alcance y horas

Límite mensual de horas, cómo se computan (por ejemplo, en fracciones de 15 minutos), qué entra en el paquete y qué no. Redacción de ejemplo:

El Prestador reserva para el Cliente 24 horas de trabajo en cada mes natural. Las horas no utilizadas en un mes no se trasladan a los meses siguientes.

Que las horas no se acumulen parece una ventaja solo para el desarrollador, pero tiene sentido para las dos partes. El desarrollador rechaza a otros clientes para guardar ese tiempo para la agencia. Si las horas se acumularan sin límite, al cabo de medio año la agencia podría exigir varias decenas de horas en una sola semana, algo que nadie puede atender. Si sobran horas todos los meses, el paquete es demasiado grande.

#Tiempo de respuesta y tiempo de solución

Son dos compromisos distintos. El tiempo de respuesta es la confirmación, el diagnóstico inicial y el plan. El tiempo de solución depende de la causa, y la causa nadie la conoce antes del diagnóstico. Redacción de ejemplo:

Se entiende por tiempo de respuesta la confirmación de la recepción de la incidencia junto con un diagnóstico inicial y un plan de actuación. El tiempo de respuesta se computa en días laborables, de lunes a viernes, en horario laboral según la hora central europea (CET). El tiempo de respuesta no constituye un plazo de resolución de la incidencia.

Para una agencia en la España peninsular, CET es su propia hora, así que el reloj del SLA coincide con su jornada. Si atiendes a clientes de Canarias, que van una hora por detrás, conviene dejar escrito que manda la hora CET y no la del cliente.

Añade también qué significa cada prioridad (por ejemplo, P1: producción o pedidos caídos; P2: despliegue bloqueado; P3: desarrollo y optimización) y quién la asigna. Sin definición, cada incidencia del cliente se convierte en P1.

#Trabajo fuera de horario

Si el SLA funciona en días laborables, escribe claramente que las noches, los fines de semana y las urgencias fuera de ese horario requieren un acuerdo aparte y por escrito. Una agencia que promete al cliente guardia 24 horas y tiene un desarrollador en horario de oficina está vendiendo algo que no tiene.

#Trabajos grandes fuera del paquete

Una migración, un nuevo tipo de contenido o la reconstrucción de plantillas rara vez caben en el límite mensual. El contrato debe decir que una tarea por encima de cierto número de horas recibe un alcance escrito propio, una estimación y una aprobación antes de empezar.

#Periodo inicial y preaviso

Al principio de la colaboración parte del tiempo se va en conocer las webs de los clientes, los accesos y el proceso de la agencia. Por eso tiene sentido un primer periodo más largo y, después, un contrato mensual con un preaviso fijado.

#Marca blanca, confidencialidad y no captación del cliente

Acuerdo de confidencialidad firmado antes de pasar nombres de clientes y accesos. La regla de que el desarrollador solo habla con el cliente final cuando la agencia lo quiere. La prohibición de presentar una oferta propia al cliente final durante la colaboración y durante un plazo determinado después.

#Definición de incidencia lista

La incidencia incluye el resultado esperado, las URL, el entorno, los datos para reproducir el problema y el criterio de aceptación. Una incidencia sin eso vuelve a la agencia con preguntas, y el tiempo dedicado a ellas cuenta o no cuenta contra el paquete. También eso hay que dejarlo escrito.

Si buscas un socio para la web completa y no una iguala por horas, te servirá nuestro artículo sobre cómo elegir una agencia WordPress. El mantenimiento continuo de una sola web sin desarrollo lo describe el servicio de mantenimiento WordPress.

#De quién es el código escrito para un cliente de la agencia

La Ley de Propiedad Intelectual española (Real Decreto Legislativo 1/1996, texto consolidado en el BOE, última actualización publicada el 30/03/2022) incluye los programas de ordenador entre las obras protegidas (art. 10.1, letra i). La excepción a favor de quien contrata es estrecha. El art. 97.4 dice que, cuando un trabajador asalariado crea un programa en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su empresario, los derechos de explotación, tanto del programa fuente como del programa objeto, corresponden exclusivamente al empresario, salvo pacto en contrario. Un desarrollador autónomo, o una empresa que factura a la agencia, no es un trabajador asalariado, así que ese artículo no le alcanza.

Los derechos pasan entonces solo por contrato, y su alcance lo deciden estos artículos:

Para los programas de ordenador, el contenido de los derechos de explotación lo fija el art. 99: la reproducción total o parcial, permanente o transitoria; la traducción, adaptación, arreglo o cualquier otra transformación; y cualquier forma de distribución pública. En el contrato con el desarrollador conviene enumerarlos uno a uno, junto con el derecho a que otras personas sigan modificando el código y el consentimiento expreso para transmitir los derechos al cliente final. Sin esto último, la agencia puede tener los derechos y no poder entregarlos.

Redacción de ejemplo, que debe revisar el abogado de la agencia:

Con la firma del acta de entrega de cada mes, el Prestador cede al Cliente, en exclusiva, para todo el mundo y por todo el plazo de protección legal, los derechos de explotación sobre el código desarrollado en ese mes, en las modalidades de reproducción total o parcial, permanente o transitoria, traducción, adaptación, arreglo y cualquier otra transformación, y distribución pública, incluida la puesta a disposición en internet. El Prestador consiente expresamente que el Cliente transmita estos derechos a sus propios clientes.

El contrato no abarca WordPress en sí. WordPress se publica bajo la licencia GPLv2 o posterior, y WordPress.org considera que los plugins y temas son obras derivadas que heredan la GPL (wordpress.org). La cesión afecta al código que el desarrollador ha escrito para la agencia. Ese código debería ir desde el primer día al repositorio de la agencia o del cliente. Los derechos sobre el papel sirven de poco si el código solo está en el portátil del desarrollador.

#¿Es el desarrollador externo un encargado del tratamiento según el RGPD?

Casi siempre, si tiene acceso a bases de datos con datos personales: pedidos de WooCommerce, formularios de contacto, cuentas de usuario, listas de newsletter. El esquema suele ser este: el cliente de la agencia es el responsable del tratamiento, la agencia es la encargada, y el desarrollador al que la agencia encomienda trabajo sobre esos datos es otro encargado, un subencargado.

El art. 28.2 del RGPD (EUR-Lex) dice: “El encargado del tratamiento no recurrirá a otro encargado sin la autorización previa por escrito, específica o general, del responsable.” Con una autorización general, la agencia informa al cliente de cualquier incorporación o sustitución prevista de otros encargados, y el cliente puede oponerse. El art. 28.4 exige que al subencargado se le impongan, mediante contrato, las mismas obligaciones de protección de datos que tiene la agencia frente al cliente. Si el desarrollador no las cumple, la agencia sigue siendo plenamente responsable ante el cliente.

En la práctica, eso significa tres documentos:

1. En el contrato de la agencia con el cliente: la autorización (específica o general) para recurrir a subencargados, con el nombre del desarrollador o con un mecanismo de aviso.
2. Un contrato de encargo del tratamiento entre la agencia y el desarrollador que repita las obligaciones del art. 28.3: tratar los datos solo siguiendo instrucciones documentadas, confidencialidad de las personas con acceso, medidas de seguridad del art. 32, ayuda con las solicitudes de los interesados, supresión o devolución de los datos al terminar el servicio, y puesta a disposición de la información necesaria para auditorías.
3. Una regla de trabajo con los datos: staging con datos anonimizados o reducidos, copia de la base de producción solo cuando la tarea lo exige, y borrado de esa copia al cerrar la incidencia.

Redacción de ejemplo para la cláusula sobre datos en staging:

El Prestador no trasladará copias de la base de datos de producción fuera de la infraestructura indicada por el Cliente. Si una tarea exige trabajar con una copia de los datos, el Prestador la suprimirá en un plazo de 7 días desde el cierre de la incidencia y lo confirmará en la propia incidencia.

#Cómo medir el trabajo del desarrollador en una iguala

El informe de horas dice cuánto tiempo se ha consumido. No dice si la web del cliente funciona mejor. La medición hay que planificarla en cada tarea, antes de que el desarrollador empiece.

Para las tareas de rendimiento, la fuente son los datos de campo. La API de CrUX ofrece una media móvil de 28 días de métricas agregadas y se actualiza a diario hacia las 04:00 UTC (developer.chrome.com). Solo entran páginas públicamente detectables y con suficientes visitas, así que una subpágina pequeña puede no tener datos a nivel de URL, solo a nivel de todo el dominio. El informe de Core Web Vitals de Search Console usa esos mismos datos de CrUX, agrupa URL parecidas y asigna al grupo el estado de su peor métrica. Tras implantar una corrección, el botón para iniciar la validación abre una ventana de 28 días: si el problema no aparece en ninguna URL durante ese tiempo, Google lo da por resuelto (support.google.com).

De ahí sale el ritmo: medición antes, fecha de implantación, medición al cabo de al menos 28 días. Un informe a la semana muestra una mezcla de visitas antiguas y nuevas.

Para las tareas SEO (redirecciones, indexación, datos estructurados), la medición son los informes de Search Console: el estado de indexación de las URL señaladas, el informe de mejoras del tipo de datos estructurado correspondiente y el rendimiento en búsqueda del grupo de páginas antes y después del cambio.

Un formato sencillo de informe mensual que la agencia puede entregar al cliente con su propia marca:

Las casillas numéricas se rellenan con datos de las herramientas, no con estimaciones. La columna “estado de la medición” evita anunciar un éxito que todavía no se ve.

#Cómo reconocer a un mal socio de marca blanca

Señales de alarma al elegir a un desarrollador o a una empresa que va a trabajar bajo tu marca:

• Incidencias ilimitadas por una cuota fija. Alguien acaba pagando la falta de límite: normalmente una cola en la que tu incidencia espera sin fecha.
• Ningún tiempo de respuesta por escrito. “Respondemos rápido” no es un compromiso. Pregunta por el tiempo de respuesta para la prioridad crítica y por el horario en que se aplica.
• Promesa de tiempo de solución para cualquier avería. Nadie conoce la causa antes del diagnóstico. Una garantía de solución en 2 horas sin matices indica que el contrato no se ha pensado.
• Horas que se acumulan sin límite. Suena bien, pero crea una deuda de tiempo que el socio no podrá saldar de golpe.
• Sin staging. Un desarrollador que despliega los cambios directamente en la producción del cliente traslada el riesgo a tu agencia.
• Cuentas compartidas y una contraseña para todo el equipo. No se puede saber quién cambió qué, ni retirar el acceso a una sola persona.
• Verificación de Search Console con la cuenta del propio desarrollador. Al despedirse quedan los tokens, y con ellos la posibilidad de volver.
• Código solo en el servidor, sin repositorio de la agencia o del cliente. Los derechos de propiedad intelectual sobre el papel no ayudan si no tienes el código.
• Sin contrato de encargo del tratamiento. Si el socio no pregunta por los datos personales, no está pensando en la responsabilidad que la agencia asume por él ante el cliente.
• Un socio que quiere hablar con el cliente final desde el primer día. Marca blanca significa que la agencia decide cuándo ocurre eso, y si ocurre.

#Cómo funciona Agency Development Desk

Agency Development Desk es nuestro servicio estable para agencias SEO, de branding y de diseño que no tienen desarrollador WordPress y WooCommerce propio. Sigue las mismas reglas que esta guía presenta como seguras:

• tres paquetes con un límite mensual de horas: Desk Flex (10 h), Desk Core (24 h) y Desk Embedded (48 h), cada uno con un tiempo de primera respuesta por escrito que depende de la prioridad;
• el SLA funciona en días laborables CET, y el trabajo de noche, en fin de semana y de urgencia requiere un acuerdo aparte por escrito;
• respuesta significa confirmación, diagnóstico inicial y plan, no una solución garantizada en ese mismo plazo;
• las horas no utilizadas no pasan al mes siguiente, porque esa capacidad estaba reservada para la agencia;
• el primer periodo dura dos meses, y después el paquete es mensual con un mes de preaviso;
• los sprints grandes reciben un alcance escrito propio, una estimación y una aprobación;
• acuerdo de confidencialidad antes de pasar los accesos, trabajo en marca blanca dentro del proceso de la agencia y compromiso de no captación del cliente escrito en el contrato;
• el código va a un repositorio que controla la agencia o el cliente, y las cuentas y licencias no dependen de nosotros.

Las tareas se reciben mediante incidencia escrita con el resultado esperado, los enlaces, el entorno y el criterio de aceptación, sin reuniones obligatorias. Los precios de los paquetes están en la página del servicio. Para valorar si encajamos basta un correo con el tipo de clientes que atiende tu agencia, el stack, un backlog de ejemplo de la última auditoría y el número de horas mensuales que esperas.