Modelo editorial claro
Se crean bloques y campos para las tareas reales del equipo; no un editor que obliga a improvisar cada página.
——
Arquitectura, diseño y desarrollo propio alineados con la marca, el negocio y la forma de trabajar.
WordPress es útil cuando se diseña como un sistema editorial, no como una suma de plugins.
Un WordPress a medida permite que el equipo publique y mantenga contenido sin renunciar a una interfaz propia, velocidad o control técnico. La clave está en definir qué se edita, qué se protege y qué procesos deben ser sencillos para quien trabajará con la web cada semana.
El alcance se define a partir de la decisión que debe facilitar la web, los datos que la sostienen y la operativa que el equipo quiere impulsar.
Se crean bloques y campos para las tareas reales del equipo; no un editor que obliga a improvisar cada página.
Plantillas, imágenes, caché y dependencias se deciden antes de que la web tenga que correr una carrera de optimización.
Se minimizan capas y plugins para que actualizar, asegurar y evolucionar la instalación sea previsible.
La solución se ajusta a la situación de partida. Estas son las capas que se revisan para aportar valor al encargo.
Si la marca, el catálogo o la forma de vender no caben bien en un tema comprado, el problema no se arregla acumulando excepciones. Se diseña un sistema de contenidos y componentes que parte de la necesidad real.
La diferencia entre una web que el equipo mantiene y una que se congela está en si existe un modelo de contenido. Cuando cada página se monta a mano con un maquetador, publicar la número cuarenta cuesta lo mismo que la primera y el resultado es cada vez más irregular. Cuando hay bloques definidos, publicar es rellenar campos y el diseño se sostiene solo. Definir ese modelo es la parte menos vistosa del proyecto y la que decide si dentro de dos años la web sigue teniendo sentido.
Cada plugin es código de un tercero con su propio calendario de actualizaciones, sus dependencias y su riesgo. Treinta plugins son treinta motivos por los que la web puede romperse un martes sin que nadie haya tocado nada. El criterio es sencillo: si algo se usa de verdad y está bien mantenido, se instala; si resuelve un problema de dos líneas, se escriben esas dos líneas. Una instalación con ocho plugins se actualiza sin miedo, y eso vale más que cualquier función de más.
El proyecto termina con el código en un repositorio a vuestro nombre, un entorno que se puede levantar en otra máquina, y documentación de qué se edita dónde. Suena obvio y no lo es: buena parte de las webs que llegan a rehacerse no se pueden mover porque nadie sabe cómo estaban montadas. Poder cambiar de proveedor sin rehacer nada es una característica del producto, no un gesto de buena voluntad.
Sí. La edición se limita a campos y componentes preparados para cada necesidad. Esto protege el diseño y hace más difícil romper una página por accidente.
Puede servir para validar algo pequeño. Cuando la propuesta, el catálogo, los mercados o la operativa son específicos, la plantilla acaba imponiendo decisiones que deberían pertenecer al negocio.
No hace falta tenerlo resuelto: hace falta tenerlo reunido. La web actual, a quién os dirigís, qué ofrecéis, qué materiales existen y quién decide. En la primera fase se separa lo que bloquea de lo que puede resolverse mientras se construye.
Por recorridos y decisiones, no por número de pantallas. Se concreta qué tiene que poder hacer una persona, qué contenido lo sostiene y qué queda fuera de esta fase, y eso es lo que se presupuesta.
Menos de lo que se teme, pero en momentos concretos. Hacen falta dos o tres sesiones de decisión y acceso a quien conoce el negocio. El resto avanza sin reuniones de seguimiento que no deciden nada.
Se revisan los recorridos que importan en móvil y escritorio, los formularios, la velocidad real, la accesibilidad y lo que cambia de sitio respecto a la web anterior. La revisión sale del alcance, no de una lista genérica.
Por la calidad de las consultas que llegan y por lo que el equipo consigue hacer solo. Una subida de visitas sin mejores conversaciones no es una mejora, y conviene decirlo antes de empezar.
Queda documentado cómo se edita cada cosa y una lista priorizada de lo que se dejó para más adelante. A partir de ahí, o lo lleva el equipo o se acuerda un seguimiento por fases.
Los casos muestran cómo se traduce el trabajo en una situación real.
Una conversación breve permite concretar el encaje, las decisiones necesarias y el siguiente paso.