The latest articles on DEV Community by Pablo Gonzalez (@wormuy). https://dev.to/wormuy https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4067564%2F5c8f2c79-92cb-46cd-bc8a-22c7b91fa8e8.jpg https://dev.to/wormuy en Pablo Gonzalez Fri, 07 Aug 2026 13:26:47 +0000 https://dev.to/wormuy/como-disenamos-sitios-wordpress-autogestionables-sin-sacrificar-rendimiento-ni-seo-24ma https://dev.to/wormuy/como-disenamos-sitios-wordpress-autogestionables-sin-sacrificar-rendimiento-ni-seo-24ma <p>Cuando un cliente pide una web autogestionable, la idea parece sencilla: quiere poder modificar el contenido de su sitio sin depender de un desarrollador.</p> <p>El problema aparece cuando interpretamos <em>autogestionable</em> como <em>todo tiene que ser editable</em>.</p> <p>Más opciones, más plugins, más widgets, más campos, más libertad.</p> <p>En teoría, estamos dando autonomía al cliente. En la práctica, podemos terminar entregándole un sistema más difícil de utilizar, más difícil de mantener y con muchas más posibilidades de romper la estructura, el diseño o incluso el SEO del sitio.</p> <p>Después de años desarrollando proyectos de <a href="https://www.lombrizcreativa.com/" rel="noopener noreferrer"><strong>diseño web en Uruguay</strong></a>, llegué a una conclusión bastante simple: cuanto más complejo es un sitio, más importante es simplificar la experiencia de quien va a administrarlo.</p> <h2> Autogestionable no significa que todo tenga que ser editable </h2> <p>Una de las primeras preguntas que intento resolver en un proyecto es:</p> <p><strong>¿Qué necesita modificar realmente el cliente?</strong></p> <p>No qué <em>podría</em> modificar.</p> <p>Qué necesita modificar como parte de su trabajo habitual.</p> <p>Por ejemplo, una inmobiliaria puede necesitar cargar propiedades, modificar precios, marcar inmuebles como destacados y gestionar agentes.</p> <p>Una asociación puede necesitar administrar socios, actividades, documentos o contenidos restringidos.</p> <p>Una empresa de servicios quizá solamente necesite modificar servicios, proyectos realizados, integrantes del equipo y algunas llamadas a la acción.</p> <p>Son necesidades completamente diferentes.</p> <p>Darles a todos acceso indiscriminado al constructor visual no necesariamente los hace más autónomos.</p> <p>A veces ocurre exactamente lo contrario.</p> <h2> Separar contenido, estructura y diseño </h2> <p>Una de las decisiones que más cambia la experiencia de administración en WordPress es separar estas tres cosas.</p> <p>El cliente debería poder pensar:</p> <blockquote> <p>“Voy a agregar una propiedad.”</p> </blockquote> <p>No:</p> <blockquote> <p>“Voy a duplicar esta página, cambiar estos widgets, reemplazar esta imagen, modificar este título y tratar de no romper nada.”</p> </blockquote> <p>Para eso WordPress ofrece una base excelente, que podemos complementar con custom post types, campos personalizados, taxonomías, relaciones y templates.</p> <p>El usuario carga <strong>datos</strong>.</p> <p>El sistema decide <strong>cómo mostrarlos</strong>.</p> <p>Una propiedad, un curso, un proyecto, un profesional o una actividad dejan de ser simplemente páginas y pasan a ser entidades con una estructura definida.</p> <p>Esto también permite que una misma información pueda aparecer automáticamente en diferentes lugares del sitio sin tener que cargarla varias veces.</p> <h2> Diseñar primero el sistema, después la interfaz </h2> <p>Cuando un proyecto tiene cierta complejidad, intento no empezar preguntando cómo debería verse cada página.</p> <p>Primero necesito entender:</p> <ul> <li>qué información existe;</li> <li>qué relaciones tiene;</li> <li>quién debe administrarla;</li> <li>con qué frecuencia cambia;</li> <li>dónde debe mostrarse;</li> <li>qué acciones necesita realizar el usuario.</li> </ul> <p>Recién entonces tiene sentido diseñar la interfaz.</p> <p>Este cambio de orden parece pequeño, pero evita muchos problemas posteriores.</p> <p>Porque una web puede verse muy bien y, sin embargo, tener una arquitectura interna terrible.</p> <h2> La libertad también tiene un costo </h2> <p>Los page builders modernos permiten hacer prácticamente cualquier cosa.</p> <p>Eso es fantástico para quienes desarrollamos sitios web.</p> <p>No necesariamente para quien tiene que administrar uno.</p> <p>Si cada título puede cambiar de tamaño, cada columna puede moverse, cada margen puede modificarse y cualquier bloque puede eliminarse, estamos trasladando decisiones de diseño al cliente.</p> <p>Y probablemente el cliente no quiera convertirse en diseñador web.</p> <p>Quiere cambiar un precio.</p> <p>Publicar un proyecto.</p> <p>Agregar un integrante.</p> <p>Modificar un servicio.</p> <p>Subir una propiedad.</p> <p>La interfaz debería facilitar esas tareas y proteger todo lo demás.</p> <h2> Autogestión y rendimiento no deberían ser enemigos </h2> <p>Otro problema frecuente es resolver cada necesidad instalando un nuevo plugin.</p> <p>Necesitamos una función: plugin.</p> <p>Aparece otra necesidad: otro plugin.</p> <p>Queremos solucionar algo pequeño: tercer plugin.</p> <p>Y poco a poco el sitio acumula dependencias.</p> <p>No creo que la respuesta sea simplemente “usar pocos plugins”. Hay plugins excelentes que resuelven problemas complejos muchísimo mejor de lo que tendría sentido desarrollar desde cero.</p> <p>La pregunta más útil es otra:</p> <p><strong>¿Esta herramienta aporta suficiente valor como para justificar la dependencia que estamos incorporando?</strong></p> <p>Cada componente debería tener una función clara dentro de la arquitectura.</p> <h2> La autogestión también puede afectar al SEO </h2> <p>Hay otro aspecto que a veces queda fuera de esta conversación.</p> <p>Cuando damos libertad para administrar contenidos, también estamos dando capacidad para modificar elementos que pueden afectar al posicionamiento:</p> <ul> <li>títulos;</li> <li>jerarquía de headings;</li> <li>URLs;</li> <li>imágenes;</li> <li>enlaces internos;</li> <li>categorías;</li> <li>contenido;</li> <li>metadatos.</li> </ul> <p>Por eso una buena arquitectura debería intentar que <strong>hacer lo correcto sea fácil y hacer lo incorrecto sea difícil</strong>.</p> <p>Si un tipo de contenido siempre necesita determinada estructura, podemos incorporarla al template.</p> <p>Si las imágenes necesitan determinadas proporciones, podemos orientar o limitar su carga.</p> <p>Si ciertos campos son fundamentales, podemos hacerlos explícitos en lugar de esperar que el usuario recuerde dónde colocarlos.</p> <p>La estructura protege al sitio incluso cuando quien lo administra no sabe SEO.</p> <h2> WordPress no tiene por qué parecer WordPress </h2> <p>Esta es probablemente una de las cosas que más me gustan de trabajar con WordPress.</p> <p>El panel de administración no tiene por qué conservar la lógica genérica con la que viene instalado.</p> <p>Podemos adaptar la experiencia al proyecto.</p> <p>En lugar de:</p> <p><strong>Entradas → Añadir nueva</strong></p> <p>el usuario puede encontrarse con:</p> <p><strong>Propiedades → Agregar propiedad</strong></p> <p>o:</p> <p><strong>Cursos → Crear curso</strong></p> <p>o:</p> <p><strong>Proyectos → Agregar proyecto</strong></p> <p>La diferencia técnica puede parecer pequeña.</p> <p>Para la persona que utiliza el sistema todos los días, no lo es.</p> <p>El software empieza a hablar el lenguaje de su negocio.</p> <h2> Cuanto más complejo es el sitio, más simple debería sentirse </h2> <p>Esta idea puede parecer contradictoria.</p> <p>Una web con membresías, relaciones entre contenidos, automatizaciones, permisos, ecommerce o integraciones externas puede tener una arquitectura interna considerablemente compleja.</p> <p>Pero el usuario no debería tener que experimentar esa complejidad.</p> <p>De hecho, creo que uno de los mejores indicadores de una arquitectura bien resuelta es precisamente ese:</p> <p><strong>el sistema puede ser complejo por dentro y sencillo por fuera.</strong></p> <p>No se trata de eliminar la complejidad.</p> <p>Se trata de decidir quién tiene que cargar con ella.</p> <p>Y, siempre que sea posible, debería hacerlo el sistema, no el usuario.</p> <h2> La mejor web autogestionable no es la que permite modificar todo </h2> <p>Es la que permite modificar fácilmente <strong>todo lo que necesita ser modificado</strong>.</p> <p>Esa diferencia cambia bastante la forma de diseñar un proyecto WordPress.</p> <p>En lugar de entregar simplemente páginas editables, podemos construir sistemas en los que contenido, diseño y funcionamiento tengan responsabilidades diferentes.</p> <p>El resultado suele ser una web más fácil de administrar, más difícil de romper y preparada para crecer sin convertir cada cambio futuro en un problema.</p> <p>Y quizá esa sea una definición más útil de <em>autogestionable</em>:</p> <p><strong>no darle al usuario todas las herramientas posibles, sino darle exactamente las que necesita.</strong></p> performance seo webdev wordpress