Preguntas frecuentes de Web

De 8 a 14 semanas para un proyecto completo, con entregas quincenales desde la tercera. Los efectos en negocio se miden tras el lanzamiento.

Arquitectura y decisiones documentadas, iteraciones cortas con entregas funcionando, integraciones, tests automatizados, despliegue con CI/CD y documentación completa.

Acceso a los sistemas que se integran, a las cuentas de los entornos y a un interlocutor con capacidad de decisión.

Con cobertura de tests, frecuencia de despliegue, tiempo de recuperación de incidencias y coste de cada nueva funcionalidad.

Por sprint, con una revisión de arquitectura al cierre de cada fase.

Cuando la lógica es propia, la lógica crece y el volumen de contenido es alto, WordPress se convierte en un freno. Si la web es un catálogo con cinco páginas, un constructor es más barato y más rápido. La decisión se toma con el criterio de quién va a mantenerlo en los próximos tres años.

De 12 a 16 semanas para un proyecto completo, con arquitectura validada en las dos primeras. Los efectos en rendimiento se ven en el primer despliegue.

Arquitectura con contratos de API, API de contenido versionada, estrategia de renderizado por página, seguridad de la capa de datos, despliegue con caché y reutilización en otros canales.

Acceso al CMS actual, a las APIs internas y a un equipo técnico del cliente para el traspaso.

Con LCP e INP en producción, tiempo de publicación, reutilización del contenido y coste de despliegue.

Trimestral, con revisión de la API y de sus contratos.

No. Es mejor cuando el contenido va a varios sitios, cuando la web es una aplicación o cuando el equipo técnico necesita esa separación. Para una web de contenido con un solo canal, headless multiplica el coste de mantenimiento sin retorno. La primera pregunta siempre es qué problema concreto resuelve.

De 3 a 4 semanas por ciclo de mejora. La primera lectura de conversión llega entre 2 y 4 semanas tras publicar.

Mapa del flujo con puntos de fuga, reducción de pasos y campos, configuración de pagos y medios de envío, visibilidad de costes, control de errores y plan de tests.

Acceso al panel de la tienda, a las métricas de pago y a los tickets de soporte del equipo comercial.

Con conversión por paso, abandono por campo, tasa de error de pago y valor medio del carrito recuperado.

Mensual, con un ciclo de test por trimestre.

No siempre. Acortar sin entender por qué se cae la gente suele empeorar la conversión es se eliminan datos que el cliente necesitaba para decidir. Primero el mapa, luego el recorte. Y hay fugas que no están en el checkout: la confianza en la web, las condiciones de envío o la formación del coste.

De 3 a 5 semanas según el tamaño del catálogo. La mejora en la búsqueda se mide entre 4 y 8 semanas.

Estructura de catálogo, modelo de atributos y facetas, filtros por nivel, buscador con sinónimos y tolerancia a errores, indexación de fichas y medición de búsqueda.

Acceso al panel de la tienda, al registro de búsquedas y a los datos de catálogo del ERP.

Con búsquedas sin resultado, clics por resultado, conversión de las páginas de categoría y uso de filtros.

Trimestral, con el mapa de búsquedas actualizadas y las facetas ajustadas.

No. El motor de búsqueda es la parte fácil. Lo difícil es que el catálogo tenga la forma que el cliente busca. Si las categorías no reflejan el lenguaje de la gente, ningún buscador devuelve lo que se espera. Primero el modelo de catálogo, después el motor.

De 3 a 4 semanas para la auditoría y el informe. Las correcciones dependen del volumen es entre 4 y 12 semanas para el cierre de las incidencias críticas.

Auditoría automática y manual, informe de incidencias con criterio WCAG, corrección de código, pruebas reales con tecnologías de asistencia, declaración de accesibilidad y plan de mantenimiento.

Acceso al código, al editor y a los entornos de prueba, y una persona del cliente para las decisiones de contenido.

Con número de incidencias por nivel, cobertura de las pruebas manuales y conversión por tipo de dispositivo.

Trimestral, con control automático en cada entrega nueva.

No. Los plugins comprueban una parte y no modifican el código. No cambian un campo sin etiqueta ni un foco invisible. Además, añaden peso y a veces introducen problemas nuevos. La accesibilidad se resuelve en el HTML y en el CSS, y luego se verifica con herramientas automáticas y con personas.

De 1 a 2 semanas de implementación, más la revisión de las etiquetas de las herramientas de medición.

Categorías de consentimiento, bloqueo real de cookies no esenciales, registro auditable de decisiones, tests de aceptación y rechazo, Consent Mode y medición del efecto en conversión.

Acceso al gestor de etiquetas, a la web y al listado de herramientas de analítica y publicidad.

Con tasa de aceptación real, cookies bloqueadas antes del consentimiento y efecto en la conversión.

Trimestral, con revisión cada vez que se añade una herramienta nueva.

No es obligatorio, pero es la única forma de medir el contenido publicitario sin perder el consentimiento. En la práctica, casi todas las webs con publicidad lo necesitan para no quedarse a ciegas con el rendimiento de sus campañas. La decisión final depende de la lectura legal de tu sector y de la AEPD de referencia.

De 1 a 2 semanas para configurar la política, las copias y la primera restauración de prueba. Después, una prueba trimestral automática.

Política de copias con su retención, copias automáticas de ficheros y base de datos, copia externa cifrada, verificación de integridad, prueba de restauración cronometrada y plan de continuidad.

Acceso al servidor, a la base de datos, al almacenamiento externo y a un coste mensual de infraestructura acordado.

Con tiempo real de restauración, integridad verificada, cobertura de datos y cumplimiento de la retención.

Trimestral, con prueba de restauración y revisión del coste de almacenamiento.

Depende de cuánto se puede perder. Con cambios diarios, una copia diaria con retención de un mes; con contenido que cambia cada hora, cada hora. Lo importante es que la retención cubra el peor escenario realista y que exista una copia fuera del servidor, porque el fallo más común no es la corrupción: es la pérdida del servidor entero.