La entrega de una web debe permitir a tu empresa acceder a las cuentas necesarias, localizar los archivos acordados, entender cómo se publican los cambios y saber quién se ocupa de los problemas. Pide un inventario por escrito, compruébalo con tus propios accesos autorizados y registra lo que siga pendiente antes de cerrar el proyecto.
Esta lista de comprobación está pensada para empresas que reciben una web nueva o cambian de equipo de mantenimiento. Se centra en el control práctico y la continuidad. Los recursos, permisos y servicios que te corresponda recibir dependen de lo pactado; una invitación a una cuenta o una carpeta de archivos no resuelve por sí sola los derechos de propiedad intelectual.
1. Acuerda qué incluye la entrega
Empieza por la propuesta y el alcance final acordado. Enumera las páginas, los idiomas, las integraciones y los materiales editables que se entregan. Distingue la web publicada de sus archivos fuente, archivos de diseño, exportaciones de contenido y servicios de terceros. Una web creada en un editor alojado puede tener un proceso de exportación distinto al de un desarrollo a medida, así que pregunta qué necesitaría otro proveedor autorizado para mantener esta web en concreto.
Anota la fecha de entrega, la versión exacta que se acepta y la persona responsable de cada elemento. Si el trabajo continúa después del lanzamiento, indica a qué versión corresponde la documentación. Una grabación de un editor antiguo o un archivo generado antes de la última corrección pueden resultar engañosos aunque existan todas las carpetas previstas.
Usa tres estados sencillos: recibido y comprobado, recibido sin comprobar y pendiente. «Enviado por correo» no significa «utilizable por el equipo receptor». Añade una nota de aceptación que explique la comprobación realizada, como abrir el archivo de diseño en la aplicación acordada o acceder a la cuenta de alojamiento con el rol previsto.
Elige pronto el formato de entrega
Mantén un inventario breve en una ubicación compartida que la empresa pueda conservar. Guarda los archivos de apoyo en carpetas con nombres claros y añade la versión o la fecha cuando sea relevante. No conviertas ese inventario en un documento de contraseñas. Registra dónde se gestionan las credenciales y quién puede conceder acceso, y guarda los datos secretos en un sistema seguro adecuado.
2. Comprueba cuentas, dominio y responsabilidades de facturación
Identifica el registrador del dominio, el proveedor de DNS, el servicio de alojamiento, el editor web o repositorio de código y cualquier servicio de formularios, reservas o correo del que dependa la web. Pueden ser cuentas distintas. Poder editar una página no implica necesariamente poder renovar el dominio, cambiar el contacto de facturación o restaurar la web.
Para cada cuenta, registra la organización responsable, el usuario invitado, el nivel de permisos, quién gestiona la renovación o suscripción y el contacto de recuperación. Usa invitaciones individuales cuando la plataforma lo permita. Comprueba que las personas adecuadas pueden entrar con sus propias cuentas y realizar las tareas que exige su rol. Sigue el proceso del proveedor para la autenticación multifactor y la recuperación; evita compartir una única contraseña de administrador.
Pide al equipo actual que explique qué registros DNS corresponden a la web y cuáles al correo u otros servicios. Conserva un registro fechado de la configuración antes de cualquier cambio acordado. Cloudflare documenta la importación y exportación de registros DNS; otros proveedores tienen sus propios controles. Una lista de registros exportada sirve como referencia, pero no es una copia de seguridad completa de todos los servicios vinculados al dominio.
La entrega no requiere necesariamente cambiar todos los proveedores. Si hace falta un traslado, acuerda primero la cuenta de destino, las dependencias, los plazos y las comprobaciones. No canceles el servicio existente solo porque haya llegado una invitación nueva. Confirma quién pagará la próxima renovación y adónde llegarán los avisos importantes, sobre todo si el contacto original deja el proyecto.
3. Prepara un inventario que puedas comprobar
La siguiente tabla es un punto de partida. Sustituye los ejemplos por tus sistemas reales y los entregables acordados. Asigna una persona responsable y un estado a cada fila. Si un elemento queda fuera del alcance del proyecto, indícalo expresamente junto con la siguiente acción, en lugar de darlo por entregado sin aclararlo.
| Elemento que registrar | Documentación que pedir | Comprobación del equipo receptor |
|---|---|---|
| Dominio, DNS y alojamiento | Ubicación de las cuentas, roles, contacto para la renovación y registro de la configuración | Las personas autorizadas pueden localizar los servicios y consultar los ajustes necesarios |
| Código fuente o editor de la web | Repositorio o espacio de trabajo, versión aceptada e instrucciones de publicación | El equipo receptor puede abrir el proyecto e identificar la versión publicada |
| Materiales de contenido y diseño | Archivos editables acordados, exportaciones, lista de recursos y referencias de licencias | Los archivos se abren correctamente y se documentan los límites de uso o edición |
| Formularios e integraciones | Destinos, cuentas responsables, dependencias y procedimiento de prueba seguro | Una prueba acordada demuestra el recorrido previsto sin contactar con clientes reales |
| Copias de seguridad y recuperación | Ubicación, contenido y fecha de las copias, e instrucciones de restauración | Una demostración segura de recuperación cubre las partes pertinentes de la web |
| Soporte y trabajo pendiente | Canal de contacto, alcance, periodo de cobertura y lista de incidencias | Cada asunto pendiente tiene una siguiente acción acordada y una persona responsable |
Pide documentación que puedas volver a consultar después de la llamada. Una grabación breve puede explicar un cambio habitual de contenido; un comando por escrito o una secuencia de publicación puede ayudar al responsable técnico del mantenimiento. Ninguno debe revelar claves secretas. El inventario debe indicar dónde están esos materiales y quién los actualiza cuando cambia la web.
Comprueba por separado el acceso al código y a la publicación
Un repositorio de código y una cuenta de alojamiento cumplen funciones distintas. Si se acuerda transferir un repositorio, revisa después sus integraciones y permisos. GitHub señala que los webhooks, los secretos y las claves de despliegue siguen asociados a un repositorio transferido. Por tanto, la transferencia no sustituye la revisión de quién y qué puede seguir actuando sobre el proyecto.
4. Haz que los archivos y las instrucciones de recuperación sean utilizables
Pide los materiales incluidos en el acuerdo en un formato que el equipo receptor pueda utilizar. Pueden incluir contenido editable de las páginas, imágenes originales, archivos de logotipo aprobados, documentos de diseño y código fuente. Enumera las tipografías externas, imágenes de banco, plugins y otras dependencias, junto con los datos de cuenta o licencia necesarios para aclarar su uso futuro. No des por hecho que todos los recursos de terceros se pueden transferir o reutilizar sin restricciones.
Para un desarrollo a medida, pide el entorno de ejecución compatible, las instrucciones para instalar dependencias, el comando de compilación, los nombres de las variables de configuración y el proceso para previsualizar y publicar un cambio. Mantén los valores secretos fuera de la documentación general. Una persona capacitada para mantener la web debería poder distinguir qué ajustes corresponden a un entorno de pruebas y cuáles conectan con servicios en producción.
Define qué incluye una copia de seguridad. La documentación de WordPress explica que una restauración habitual de WordPress necesita tanto la base de datos como los archivos. Para otra plataforma, pide al proveedor que describa sus dependencias equivalentes. Una captura de pantalla, un archivo con el código fuente o una exportación del texto de las páginas pueden resultar útiles, pero ninguno debería presentarse como un plan completo de recuperación sin explicar sus límites.
Acuerda quién hace las copias de seguridad, dónde se guardan, durante cuánto tiempo se conservan y cómo se comprueba la restauración. Pide una demostración en un entorno seguro, con un tratamiento adecuado de los datos de clientes. Registra qué se restauró y qué quedó fuera del ejercicio. No uses la web publicada como prueba improvisada de recuperación ni supongas que una copia sin comprobar resolverá cualquier caída.
5. Realiza una breve revisión de aceptación
Usa las cuentas autorizadas del propio equipo receptor durante la revisión. Localiza la versión aceptada de la web, abre el editor o el proyecto, busca las instrucciones de soporte y demuestra un cambio habitual en un entorno de previsualización o pruebas. El objetivo es comprobar si la siguiente persona puede gestionar la web con los materiales entregados, sin depender de explicaciones que solo existen en la memoria del proveedor.
Revisa algunos recorridos reales de clientes: leer la información de un servicio, navegar desde un teléfono, llegar al canal de consultas e inspeccionar los estados de confirmación y error acordados. Prepara pruebas seguras para formularios, reservas y pagos. Acuerda de antemano las direcciones y los destinos de prueba para que la revisión de entrega no envíe mensajes a clientes reales ni cree pedidos involuntarios.
Comprueba también que las cuentas de búsqueda y medición, cuando estén incluidas, dispongan de los accesos adecuados. Google Search Console distingue entre propietarios, usuarios con acceso completo y usuarios con acceso restringido, y explica cómo afectan los tokens de verificación a la propiedad verificada. La revisión de permisos de Search Console es independiente del acceso a la propia web. Registra la propiedad y el rol correspondientes, sin considerar el acceso una prueba de que Google ha indexado todas las páginas.
Una entrega hipotética para una consultoría
Imagina una consultoría que recibe una web de cinco páginas. Su responsable puede editar textos, pero los avisos de renovación siguen llegando a un proveedor anterior y el destino del formulario no está documentado. El equipo registra ambas carencias, confirma el contacto de facturación siguiendo el proceso del proveedor y documenta el recorrido del formulario mediante una prueba acordada. Después, el responsable repite una edición en previsualización siguiendo las instrucciones entregadas. Es un ejemplo del método, no un resultado real de un cliente.
6. Define el soporte y revisa los accesos restantes
Deja por escrito qué ocurre después de la aceptación. ¿Quién se ocupa de una caída, un fallo del formulario, un cambio de contenido o la renovación de una suscripción? Separa la corrección de los defectos de entrega acordados de las nuevas funciones y el mantenimiento continuo. Indica el canal de contacto acordado, el periodo de cobertura, los costes cuando proceda y cualquier compromiso de respuesta. La existencia de un correo de soporte no implica una supervisión las 24 horas.
Mantén una lista breve de trabajo pendiente con el problema, su impacto, la siguiente acción, la persona responsable y la fecha de revisión. Decide qué incidencias impiden la aceptación y cuáles pueden resolverse después mediante un acuerdo explícito. Si una integración de reservas sigue sin estar disponible, por ejemplo, registra la vía alternativa para los clientes y quién decide cuándo está lista la integración definitiva.
Revisa los colaboradores que dejan el proyecto, las invitaciones, los tokens de integración y los contactos de recuperación una vez que el equipo receptor haya comprobado la continuidad. Conserva solo los accesos necesarios para el trabajo continuado acordado. Coordina las revocaciones o renovaciones de credenciales con la persona responsable técnica para que la limpieza no interrumpa inesperadamente la publicación, los formularios u otro servicio dependiente. Conserva un registro de las decisiones sin guardar en él valores secretos.
7. Incluye los requisitos de entrega en el briefing de la web
El mejor momento para acordar una entrega útil es antes de empezar el trabajo. Añade quiénes editarán la web, la capacidad técnica interna, los archivos necesarios, la organización de las cuentas y las necesidades de soporte al briefing del proyecto web. Si una web existente cambia de proveedor, combina este inventario con una revisión para el rediseño para mantener claras las responsabilidades sobre los servicios existentes.
Antes de cerrar el proyecto, confirma que el inventario coincide con el acuerdo, los accesos necesarios funcionan, los archivos entregados se abren, la revisión segura queda documentada y el trabajo pendiente tiene una persona responsable. Guarda juntas la versión aceptada y las notas de entrega. Así, quien se ocupe después del mantenimiento tendrá un punto de partida práctico cuando surja un cambio o un problema.
El servicio web de Digital Studio parte de 2.190 EUR para un desarrollo único de hasta cinco páginas con contenido aportado, diseño adaptable, bases de SEO, un formulario de captación de contactos y lanzamiento en tu dominio. Los materiales concretos de entrega, los traslados, la formación y el soporte continuo deben acordarse por escrito para tu proyecto; esta lista de comprobación no los añade al paquete publicado. Describe tu web y tus necesidades de entrega para poder hablar del alcance antes de empezar el trabajo.
