Kit Digital 2027: requisitos técnicos que pedir a una web antes de firmar

Hay presupuestos que describen con detalle cómo se verá la portada y apenas dicen cómo se mantendrá el sitio. Después de publicar llegan las preguntas difíciles: ¿por qué tarda en cargar?, ¿quién arregla el formulario?, ¿se puede exportar el contenido?, ¿qué ocurre si cambiamos de proveedor? Si una pyme espera una posible nueva convocatoria del Kit Digital en 2027 para crear su web, puede usar este tiempo para pedir respuestas técnicas comprensibles antes de firmar.

La página oficial de convocatorias de Red.es no presenta, en la consulta del 30 de septiembre de 2026, un nuevo plazo general de 2027. La Orden TDF/39/2026 cambia aspectos de las bases y contempla remanentes para determinadas solicitudes anteriores; no confirma qué soluciones podrían financiarse después. Estas preguntas sirven tanto para un presupuesto privado como para evaluar una oferta bajo condiciones futuras que aún habría que leer.

Rendimiento: pide una experiencia, no una cifra aislada

Una demo puede abrir al instante en el ordenador del estudio y tardar mucho en el teléfono de un cliente. Solicita que se prueben páginas representativas en móvil: inicio, servicio, contacto y, si existe, ficha de producto. La prueba debe hacerse con imágenes y textos reales. Una página vacía, sin vídeo ni formularios, no refleja el sitio que recibirás.

Pregunta qué decisiones evitarán peso innecesario. Fotografías adaptadas a su tamaño, vídeo con reproducción voluntaria cuando convenga y componentes que no carguen scripts sin propósito son ejemplos concretos. No pidas «puntuación perfecta» como única meta. Una cifra de laboratorio puede cambiar según condiciones; importa que las páginas principales permitan leer, navegar y actuar con fluidez. El proveedor debería explicar qué comprobó y qué cambiaría si una plantilla se vuelve pesada.

Define qué ocurrirá después de la entrega. La web puede salir rápida y degradarse cuando el equipo sube imágenes originales enormes o instala complementos sin revisar. Pide instrucciones para publicar sin perjudicar el rendimiento y un responsable de mantenimiento. La técnica tiene que sobrevivir a la vida normal del sitio, no solo a la presentación final.

Accesibilidad desde el diseño

Una web útil debe poder recorrerse con teclado, mostrar textos legibles, identificar campos de formulario y ofrecer alternativas a imágenes que contienen información. Pide probar tareas concretas: encontrar un servicio, llegar al contacto y enviar un formulario sin usar ratón. Revisa mensajes de error que expliquen qué falta. Una casilla roja sin texto puede dejar a una persona bloqueada.

La accesibilidad no se resuelve con un botón que promete cambiar toda la página de golpe. Depende de cómo se construyen componentes, textos y contenidos. Si el equipo editorial publicará artículos, necesita saber usar encabezados en orden y escribir enlaces descriptivos. Un contrato que habla de «web accesible» debería indicar criterios, revisión y correcciones incluidas. Pide que el proveedor muestre un ejemplo del proceso de comprobación.

No se trata solo de cumplir una lista. Una navegación que se entiende con teclado suele ser también más clara para quien usa el móvil o tiene prisa. Los subtítulos ayudan cuando no se puede escuchar un vídeo. El contraste permite leer en condiciones de luz difíciles. Estas decisiones amplían el uso cotidiano de la web.

Arquitectura que permita crecer sin rehacer todo

Antes de elegir tecnología, dibuja las piezas que tendrá el sitio: servicios, casos, equipo, preguntas, blog, productos o reservas. Pregunta cómo se añade una nueva pieza de cada tipo. Si cada servicio requiere copiar manualmente una página y corregir veinte detalles, el mantenimiento será propenso a errores. Un sistema de componentes puede conservar diseño y permitir diferencias de contenido reales.

Comprueba la estructura de URLs. Si se sustituye una web existente, pide inventario de páginas actuales y plan de redirecciones. Cambiar direcciones sin cuidado rompe enlaces que clientes ya guardaron y puede afectar a la visibilidad. La guía de SEO de Google ofrece un marco claro: ayudar a buscadores y personas a entender el contenido. Una arquitectura técnica limpia facilita esa tarea, pero no sustituye textos buenos.

Pregunta qué partes del sitio se podrán editar sin tocar código. El negocio debería poder actualizar horarios, preguntas o descripciones habituales según el alcance contratado. Al mismo tiempo, no todas las opciones necesitan quedar abiertas: si cualquiera puede alterar la plantilla principal, será fácil romper consistencia. Pide roles adecuados para quienes editan y un camino claro para cambios mayores.

Datos, seguridad y copias

Si la web recoge contactos, reservas o ventas, pregunta dónde llegan los datos, quién accede y durante cuánto tiempo se conservan conforme al funcionamiento y obligaciones aplicables. No aceptes un formulario cuyo destino nadie conoce. Prueba el envío en distintos dispositivos, comprueba la recepción y acuerda qué hará el equipo si deja de funcionar. La seguridad comienza por saber qué datos manejas.

Pide una estrategia de copias que se pueda restaurar. ¿Qué incluye: archivos, base de datos, configuración? ¿Con qué frecuencia se crea? ¿Quién la custodia y quién ha probado recuperarla? Una captura de pantalla de la carpeta de backups no demuestra que el sitio pueda volver a funcionar. Para una tienda o un sistema de reservas, define además cómo se tratarían pedidos generados entre la copia y la incidencia.

Las actualizaciones también requieren responsable. Un gestor de contenidos y sus componentes pueden necesitar mantenimiento. Pregunta qué revisiones entran en el precio inicial, qué se contrata aparte y cómo se comunica una incidencia. «Soporte incluido» puede significar desde respuesta a dudas por correo hasta corrección de fallos; concreta horario, canal y alcance.

Dominio, código y salida del proveedor

La empresa debería saber bajo qué cuenta está registrado su dominio y tener acceso a los servicios críticos. Si el proveedor administra alojamiento, pide condiciones de renovación y recuperación. Pregunta por el código o la posibilidad de exportar el sitio según la tecnología elegida, por licencias y por componentes que dejarían de funcionar al terminar una suscripción. El objetivo es conocer las dependencias antes de que se conviertan en un problema.

No todas las plataformas permiten el mismo tipo de traslado. Una solución cerrada puede ser adecuada si el coste y la salida están claros; una arquitectura más flexible puede exigir más mantenimiento. Compara alternativas según tu capacidad y necesidad, no por una etiqueta. Pide una explicación en lenguaje común: qué se puede llevar la empresa, cuánto costaría y cuánto tiempo requeriría cambiar de equipo.

Incluye una sesión de entrega con el personal que actualizará el sitio. Deberían salir pudiendo realizar tres tareas frecuentes y sabiendo a quién llamar para el resto. Una carpeta llena de credenciales sin instrucciones no equivale a un traspaso. Tampoco conviene que las contraseñas circulen por mensajes informales. Acuerda un método de acceso y recuperación adecuado.

Una aceptación que evita discusiones

Antes de publicar, escribe una lista de comprobaciones: páginas previstas, enlaces, formularios, versión móvil, accesibilidad básica, redirecciones, copias, accesos y formación. Hazla parte de la propuesta. Así la conversación final no se reduce a si «se ve bien». Si algo falla, quedará claro si era un requisito acordado y quién lo corrige.

Reserva un periodo para detectar incidencias con tráfico real. Un formulario puede funcionar en pruebas y fallar para determinados mensajes; una ficha puede romperse con un título largo. Pide plazo y canal para reportarlo. Tras esa etapa, anota qué entra en mantenimiento. Una web tiene un lanzamiento, pero también una operación diaria que necesita dueño.

La ayuda futura se comprobará después

La adenda de gestión de Red.es y Cámara de España prevé actividad en 2027 y 2028, incluidos expedientes anteriores; no abre una nueva convocatoria. Puedes seguir el posible nuevo Kit Digital y comprobar en Red.es y el BOE cualquier anuncio antes de tomar una decisión de financiación.

Si llegan bases nuevas, coteja sus entregables exigidos con tu lista técnica. Señala qué está incluido, qué precisa presupuesto propio y cómo se verificará. Si no llegan, la lista mantiene su utilidad: convierte una promesa de «web profesional» en una compra que puedes entender, probar y sostener. La calidad técnica empieza en preguntas que el proveedor sea capaz de contestar sin esconderse detrás de términos incomprensibles.