Case Study - La diferencia entre tener web y tener criterio

El título de este documento es deliberadamente contundente. No está dirigido contra empresarios que utilizan WordPress para sus proyectos web. La mayoría de propietarios de empresas no saben ni tienen por qué saber qué tecnología hay detrás de su web. La decisión tecnológica suele delegarse, y el mercado ha normalizado WordPress como solución profesional accesible a cualquiera.

El problema no es la falta de conocimiento técnico del empresario. El problema es un ecosistema que permite tomar decisiones técnicas críticas sin criterio técnico real. WordPress no se elige porque sea la mejor solución. Se elige porque es la más accesible, la más rápida de implementar y la que menor inversión inicial aparenta. La mediocridad tecnológica suele ser inducida, no elegida conscientemente.

Este análisis no habla de modas ni de herramientas. Habla de estándares. Tener una web operativa no equivale a tener criterio sobre qué tecnología la sustenta. Y la diferencia se mide en tres dimensiones: percepción de marca, control técnico y exposición a riesgos de seguridad.

1. Marca y posicionamiento: por qué la tecnología comunica estatus

1.1 La web corporativa como señal de madurez empresarial

Cuando un proyecto adquiere dimensión real y compite en mercados donde la percepción importa, la web deja de ser un trámite administrativo. Se convierte en un indicador de madurez empresarial. La tecnología que la sustenta comunica el nivel del negocio con la misma intensidad que el diseño visual, el tono del copy o la propuesta de valor.

Las empresas que operan en segmentos competitivos entienden que cada elemento de su presencia digital contribuye al posicionamiento. Una web construida con criterio técnico transmite control, profesionalidad y capacidad de ejecución. Una web construida con la solución más accesible del mercado transmite exactamente lo contrario, aunque funcione correctamente.

La decisión técnica condiciona el posicionamiento desde el primer contacto. No se trata de funcionalidad inmediata. Se trata de coherencia estratégica. Un proyecto con ambición real no puede permitirse decisiones técnicas que lo sitúen al mismo nivel que proyectos que carecen de esa ambición. En ese sentido, la web es el primer punto de contacto con clientes potenciales cuyo ticket medio justifica una inversión técnica seria. No hay segunda oportunidad para transmitir que el proyecto está a la altura.

1.1.1 La homogeneización visual del mercado

Gran parte de las webs corporativas se parecen entre sí aunque los negocios que representan sean radicalmente distintos. La causa no es la falta de creatividad visual ni de inversión en diseño, pues hay diseñadores gráficos especializados en WordPress que hacen buenos trabajos. La causa es la homogeneización tecnológica. Cuando la mayoría de proyectos utilizan la misma plataforma, los resultados tienden a converger hacia patrones reconocibles (bloques de Elementor, plantillas de ThemeForest, UX inexistente, etc.).

WordPress, junto con su ecosistema de constructores visuales, genera una estética identificable, así que los límites técnicos de la plataforma condicionan las posibilidades de diseño. Las animaciones, los layouts predefinidos, las interacciones posibles, etc. Todo está acotado por lo que el sistema permite sin desarrollo adicional. El resultado es, en el mejor de los casos, una uniformidad que reduce drásticamente la capacidad de diferenciación. Y en el peor de los casos, un Frankenstein sin sentido que arruina la identidad corporativa.

Esta homogeneización no es accidental. Es consecuencia directa de elegir una solución que prioriza la accesibilidad sobre la capacidad de personalización técnica. Cuando cualquiera puede construir una web con las mismas herramientas, el resultado deja de diferenciar. La web se convierte en commodity.

1.2 Por qué WordPress domina el mercado corporativo

La mayoría de webs corporativas de PYMEs están basadas en WordPress por una simple razón: para hacerla no hay que ser desarrollador web. Cualquier persona puede instalar WordPress, elegir un tema, activar plugins y tener una web operativa en cuestión de horas. Esto incluye proyectos aparentemente complejos, como tiendas online con gestión de inventario (plugin WooCommerce con 2 clics), o pasarelas de pago (plugin de Stripe o Redsys con un simple copia/pega de las claves que le dé el banco).

Esta característica es simultáneamente su mayor virtud y su limitación fundamental. El mercado ha normalizado WordPress como la solución profesional estándar. Los empresarios que buscan una web corporativa encuentran WordPress en prácticamente todas las propuestas que reciben. Los proveedores lo recomiendan porque es lo que conocen, porque permite entregar resultados rápidos y porque el coste inicial aparente es bajo.

La normalización genera un círculo vicioso. Cuanto más se utiliza WordPress, más se normaliza su uso. Cuanto más se normaliza, más difícil resulta justificar una alternativa ante un cliente que no tiene criterio técnico (ni tiene por qué tenerlo) para evaluar opciones. El resultado es un mercado donde la solución estándar no es la mejor, sino la más accesible.

1.2.1 Barrera de entrada casi inexistente

WordPress elimina prácticamente cualquier barrera de entrada para construir una web. Temas predefinidos, constructores visuales de tipo drag-and-drop, plugins que añaden funcionalidad sin escribir código. Cualquier persona con conocimientos básicos de informática puede gestionar una web WordPress sin intervención técnica.

Pero esta accesibilidad tiene un coste que no aparece en el presupuesto inicial. Cuando no se requiere conocimiento técnico para construir o gestionar una web, el resultado tiende a ser genérico. Los temas limitan las posibilidades de personalización real y armonía estética. Los constructores visuales generan código innecesariamente complejo, repetitivo y difícil de mantener. Así que la facilidad de uso, se paga con la pérdida del control técnico y estético sobre el proyecto global.

El problema no es que WordPress sea accesible. El problema es que esta accesibilidad se ha convertido en el estándar para proyectos que requieren algo más. Cuando un proyecto corporativo con tickets medios de cuatro y cinco cifras utiliza la misma herramienta que un blog personal, algo falla en el proceso de decisión técnica.

1.2.2 El problema no es WordPress, es lo que su web transmite

WordPress no es una herramienta inherentemente deficiente, del mismo modo que tampoco lo son un martillo o un sacacorchos del chino. Cumplen su función para determinados casos de uso. El problema es lo que representa en el contexto del mercado actual: la normalización de soluciones genéricas como estándar profesional.

Cuando cualquiera puede construir una web con una herramienta básica, el resultado deja de diferenciar. Una web WordPress ejecutada con profesionalidad sigue siendo una web WordPress. Transmite que se eligió la solución más accesible del mercado, no la más adecuada para el proyecto específico. Y en mercados competitivos donde la percepción condiciona la conversión, esta señal tiene consecuencias medibles.

En segundo lugar, la tecnología comunica estatus. Una arquitectura técnica sólida transmite que el proyecto tiene criterio, recursos y ambición proporcional a su posicionamiento. Una arquitectura genérica o mal diseñada transmite lo contrario.

1.3 El coste invisible de elegir la solución fácil

Al igual que el motivo de elegir WordPress suele ser el económico, el coste será de percepción de su marca, que llevado a una segunda derivada, tratándose de una web corporativa, al final desembocará en el económico. Porque una web WordPress funciona de forma aceptable en términos operativos: muestra contenido, captura leads, procesa formularios, etc. Pero comunica 1) que es una más y 2) que se eligió la solución fácil. En mercados competitivos donde el posicionamiento requiere diferenciación, esta señal tiene consecuencias reales sobre la tasa de conversión.

El coste invisible se materializa en oportunidades que no llegan a concretarse. Clientes potenciales que perciben el proyecto como menos profesional de lo que es. Socios que dudan del nivel técnico de la operación. Estos efectos no aparecen como línea de gasto en ningún presupuesto, pero condicionan el crecimiento del negocio de formas difíciles de cuantificar.

1.3.1 Ser percibido como uno más

Una decisión técnica condiciona el posicionamiento de marca. Cuando un proyecto utiliza la misma tecnología que la mayoría del mercado, se percibe como uno más. La diferenciación se vuelve más difícil porque la base técnica no aporta ningún elemento distintivo. Todo el peso de la diferenciación recae sobre elementos más superficiales: diseño, copy, oferta.

En mercados competitivos donde la diferenciación es condición necesaria para justificar precios premium, la tecnología no puede ser neutral. Tiene que sumar. Una arquitectura técnica sólida es una señal de calidad que los competidores no pueden replicar instalando un plugin. Es un diferenciador estructural.

El coste de ser percibido como uno más no se mide en euros de forma directa. Se mide en ROAS deteriorado, en tasas de conversión inferiores a las que el proyecto podría alcanzar, en CPAs que podrían ser menores si la percepción de marca fuera coherente con el posicionamiento pretendido.

2. Decisión técnica: cuando la arquitectura deja de ser un detalle

2.1 La realidad funcional de la web corporativa media

La mayoría de webs corporativas requieren unas funciones muy simples: home y contacto, páginas informativas que describen servicios, una sección de casos de estudio o portfolio, contenido institucional sobre el equipo y la empresa y un blog con actualizaciones periódicas. Y a lo sumo, algún formulario de contacto o de captación de leads a través de newsletter. No hay más porque no se necesita más, y en ese punto no presentan ningún problema.

Sin embargo esta simplicidad funcional, contrasta con la complejidad técnica que WordPress introduce por defecto. Una web corporativa típica no necesita backend activo procesando peticiones PHP en tiempo real. Tampoco necesita una base de datos consultándose con cada visita, ni un sistema de gestión de usuarios con permisos diferenciados. Porque la mayoría del contenido es estático, los cambios son esporádicos y la funcionalidad dinámica real se limita a formularios que pueden gestionarse con servicios externos. Pues bien: una instalación WordPress, tiene todo eso. Y lejos de sumar, lo que hace es aportar complejidad artificiosa (mayor tiempo de carga y mantenimiento) y ampliar la superficie de ataque para ser hackeado, de lo cual hablaremos en el apartado 3.

La desconexión entre necesidad funcional y complejidad técnica es el problema central que se plantea en este segundo apartado, ya que WordPress fue diseñado como un CMS para blogs, no para páginas web, y por tanto su arquitectura está optimizada para gestionar contenido dinámico que cambia frecuentemente (agregar, eliminar o editar posts, por varios usuarios y con diferenciación de permisos por roles). La mayoría de webs corporativas evidentemente no encajan en ese modelo, y el resultado es una solución sobredimensionada para un problema simple.

Las webs corporativas son, en su inmensa mayoría, esencialmente estáticas. Entiéndase por estático que el contenido a mostrar es siempre el mismo, y no que carezca de animaciones o transiciones. Las páginas que presenta son informativas, y la funcionalidad se limita a mostrar información estructurada y capturar leads a través de formularios. Por lo tanto esta realidad no requiere backend activo: no requiere base de datos en producción, no requiere procesamiento del lado del servidor en cada petición. Así que una web estática puede (debe) construirse, desplegarse y mantenerse sin servidor tradicional de PHP, porque el contenido que se muestre debe estar ya escrito, y no generarse cada vez que alguien la visita haciendo una petición a la base de datos MySQL e imprimiéndola por PHP. El resultado de hacerlo sencillo (estático) es inherentemente más rápido, más seguro y más simple de mantener. Sin embargo, WordPress introduce toda la complejidad de un CMS dinámico, que una web corporativa para su caso no necesita.

Esta sobredimensión tiene costes reales. Cada petición requiere procesamiento en el servidor, ya que cada página se genera dinámicamente aunque el contenido no haya cambiado desde hace meses. Por otro lado, los temas y plugins añades capas adicionales de procesamiento. El resultado es una web más lenta y más compleja de lo estrictamente necesario para cumplir su función.

Además, un backend activo requiere mantenimiento continuo: actualizaciones de seguridad del core de WordPress, de cada plugin instalado y del tema. Monitoreo de rendimiento, gestión de copias de seguridad de la base de datos, migraciones a la última versión de PHP, etc. Cada actualización puede introducir incompatibilidades o vulnerabilidades; todo ello para webs que no tienen una estructura que lo necesite.

2.2 Plugins como sustituto de arquitectura

WordPress depende estructuralmente de plugins para añadir cualquier funcionalidad que no venga incluida en el core. Cada plugin es un parche acumulativo, desarrollado por terceros (todos distintos) sobre una base que no fue diseñada específicamente para esa funcionalidad. El resultado es una arquitectura fragmentada donde la funcionalidad se añade mediante acumulación, no mediante el diseño coherente. Y eso de por sí, es una chapuza, pues los plugins introducen dependencias no controladas, conflictos entre versiones, aumento de tiempos de carga y vulnerabilidades de seguridad (ya no solo cuando los desarrolladores dejan de mantener el código, sino también las zero-day). Cada actualización puede romper la funcionalidad existente, porque el que diseña el plugin no lo hace pensando en que encaje con los otros ~60.000 plugins que tiene el repositorio de WordPress, y en consecuencia, cada plugin añadido aumenta la superficie de ataque y la complejidad del sistema. A medida que se añaden plugins, la arquitectura se vuelve progresivamente más pesada, inestable y vulnerable.

Frente a eso, están las webs secillas en Node.js, donde la arquitectura es correcta desde la base porque se diseña para las necesidades específicas del proyecto. No se construye mediante acumulación de plugins, sino con código personalizado a través de un desarrollador, partiendo de decisiones técnicas conscientes que consideran el caso de uso real, no un caso de uso genérico que le sirva a 50 millones de webs.

2.3 Por qué optimizar WordPress no soluciona el problema

Optimizar WordPress mejora métricas puntuales de rendimiento (Google PageSpeed Insights por ejemplo), pero no soluciona el problema estructural. Por que las optimizaciones de WordPress son, por lo que hemos visto antes, reactivas. Sistemas de caché (LiteSpeed, WP Rocket o W3 Total Cache) para reducir consultas a la base de datos que no deberían existir en una web estática, minificación CSS para reducir el tamaño de archivos generados de forma catastrófica, minificación de JS porque cada plugin se quiere ejecutar el primero de la lista, etc. Todo ello, en el mejor de los casos, con un CDN auxiliar (y pagado) para servir contenido estático desde ubicaciones cercanas al usuario.

Todas estas optimizaciones vienen por intentan compensar una arquitectura que no es la correcta para el caso de uso. Funcionan, sí. Y mejoran los tiempos de carga. Pero no eliminan la complejidad subyacente: el backend sigue activo, la base de datos sigue siendo necesaria y los plugins siguen ejecutándose.

En contraposición, una web estática con la tecnología adecuada será siempre mucho más rápida, porque no requiere procesamiento en el servidor con cada petición. No hay consultas a base de datos, ni ejecución de PHP que consuma CPU y RAM (de un unos hostings que además en la mayoría de casos dejan mucho que desear, aunque eso es harina de otro costal). En otras palabras: como no hay generación dinámica de contenido que ya existe, el resultado es rendimiento estructural que no necesita optimizaciones reactivas, porque sencillamente, no hay ineficiencias que compensar.

2.4 Node.js como herramienta de construcción de páginas corporativas

En este paradigma, Node.js se emplea como entorno de desarrollo y construcción para generar sitios web estáticos, en lugar de utilizar un CMS dinámico como WordPress. El frontend se desarrolla habitualmente mediante frameworks y generadores basados en Node.js, como Next.js o Astro, que permiten definir la interfaz mediante componentes (normalmente con React) y renderizar las páginas en tiempo de build. Durante este proceso, Node.js ejecuta el JavaScript necesario para generar los archivos estáticos finales. Posteriormente, dichos archivos se despliegan en una plataforma de hosting (como Vercel) y en el caso de un sitio puramente estático, como puede ser una web corporativa, en producción no se ejecuta Node.js, sino que el contenido se sirve directamente desde un CDN global.

En ese sentido, la inmutabilidad elimina los problemas de gestión en producción, bases de datos, etc. Porque no hay código ejecutándose que pueda fallar de formas impredecibles: el artefacto es exactamente lo que se construyó y probó antes del despliegue.

2.5 Aplicación práctica: reconstrucción de la web de Foix

La reconstrucción de la web de Foix en 2025 responde a una decisión estratégica tomada tras validar el modelo de negocio. Durante la fase de validación, WordPress cumplió su función: permitió lanzar rápidamente, iterar sobre el mensaje y confirmar que existía demanda real para los servicios de la agencia. Esa fase ya terminó.

Una vez confirmado que el modelo de negocio funciona, la web deja de ser un soporte temporal y se convierte en un activo estratégico permanente. La percepción de marca condiciona directamente la tasa de conversión de los leads que llegan a través de campañas de paid media. Esa tasa de conversión afecta al ROAS de las campañas. El ROAS afecta al CPA efectivo. La cadena causal es directa: marca → conversión → ROAS → CPA.

Una agencia que gestiona presupuestos publicitarios significativos para sus clientes no puede permitirse una web que comunique mediocridad tecnológica. La coherencia entre el posicionamiento de alta gama y la ejecución técnica de la propia web no es opcional. Es condición necesaria para que el posicionamiento sea creíble.

La arquitectura elegida elimina WordPress y toda su complejidad asociada. El contenido se genera en tiempo de construcción. El despliegue es un artefacto estático servido desde edge locations globales. No hay backend en producción. No hay base de datos. No hay plugins que mantener. No hay superficie de ataque que defender. El resultado es una web técnicamente coherente con el nivel del servicio que la agencia ofrece a sus clientes.

3. Ciberseguridad: cuando menos superficie de ataque es más seguridad

3.1 La mayoría de ataques existen porque hay algo que atacar

La mayoría de ataques a webs corporativas existen porque hay infraestructura atacable. Backends activos procesando peticiones. Bases de datos almacenando información. Paneles de administración accesibles desde internet. Lógica ejecutándose en producción que puede contener vulnerabilidades. Cada uno de estos componentes es un vector de ataque potencial.

Un backend activo procesa peticiones, ejecuta código y accede a bases de datos. Cada una de estas operaciones puede ser explotada si existe una vulnerabilidad. Inyecciones SQL. Ejecución de código remoto. Escalada de privilegios. Cross-site scripting. Todas estas categorías de ataque requieren un backend activo para existir. Sin backend, no hay vector de ataque.

Una base de datos en producción contiene información que tiene valor para atacantes. Credenciales de usuarios. Datos de configuración. Contenido que puede modificarse maliciosamente. Cualquier vulnerabilidad que permita acceso a la base de datos compromete toda esa información. En una arquitectura estática, no hay base de datos que atacar.

3.1.1 WordPress como objetivo habitual

WordPress es objetivo habitual de ataques automatizados porque es ubicuo y tiene una superficie de ataque estructuralmente grande. Plugins desactualizados con vulnerabilidades conocidas. Versiones de PHP con fallos de seguridad. Temas con código inseguro. Configuraciones por defecto que exponen información sensible. Paneles de administración accesibles públicamente.

Los bots automatizados, incluyendo sistemas cada vez más sofisticados basados en IA, escanean webs WordPress de forma continua. Buscan versiones desactualizadas de plugins conocidos por tener vulnerabilidades. Prueban credenciales por defecto. Explotan configuraciones inseguras. Cuando encuentran una vulnerabilidad, la explotan automáticamente sin intervención humana.

La superficie de ataque de WordPress es grande por diseño, no por implementación deficiente. Backend activo con PHP. Base de datos MySQL. Sistema de usuarios con autenticación. Plugins de terceros con calidad variable. Cada componente añade vectores de ataque potenciales que deben defenderse activamente.

3.2 Seguridad por eliminación, no por acumulación

La aproximación correcta a la seguridad web consiste en eliminar vectores de ataque, no en acumular capas defensivas sobre una superficie de ataque grande. Una arquitectura estática elimina vectores completos de forma estructural. No hay backend que atacar porque no existe backend en producción. No hay base de datos que comprometer porque no hay base de datos. No hay código ejecutándose que pueda contener vulnerabilidades explotables.

Las capas defensivas tradicionales son necesariamente reactivas. Firewalls de aplicación que intentan detectar patrones de ataque. Sistemas de detección de intrusiones que monitorizan comportamiento anómalo. Actualizaciones de seguridad que parchean vulnerabilidades después de ser descubiertas. Todas estas medidas intentan defender una superficie de ataque que existe. Eliminar la superficie de ataque es estructuralmente más efectivo.

3.2.1 Qué desaparece en una arquitectura estática

En una arquitectura estática desaparecen categorías completas de vulnerabilidades. No hay base de datos, por lo tanto no hay inyecciones SQL posibles. No hay panel de administración en producción, por lo tanto no hay credenciales que robar ni sesiones que secuestrar. No hay endpoints dinámicos, por lo tanto no hay lógica de negocio que explotar. No hay código ejecutándose en el servidor, por lo tanto no hay ejecución remota de código posible.

Un atacante no puede inyectar SQL porque no hay consultas SQL. No puede ejecutar código remoto porque no hay intérprete ejecutando código en el servidor. No puede escalar privilegios porque no hay sistema de usuarios. No puede modificar contenido porque no hay base de datos donde el contenido resida. La superficie de ataque se reduce a servir archivos estáticos desde un CDN, una operación con vectores de ataque mínimos y bien comprendidos.

La seguridad por eliminación es estructuralmente más robusta que la seguridad por acumulación. En lugar de intentar defender una superficie de ataque grande con múltiples capas, se elimina la superficie de ataque. El resultado es una web más segura por diseño, no por configuración correcta de medidas defensivas.

3.3 Infraestructura moderna como consecuencia natural

La arquitectura estática conduce naturalmente a infraestructura moderna de despliegue. Deploy gestionado con integración continua. Aislamiento por diseño entre despliegues. Rollbacks triviales a versiones anteriores. Replicación automática del contenido en edge locations globales.

Plataformas como Vercel gestionan el despliegue automáticamente cuando se actualiza el repositorio de código. Cada commit puede generar un nuevo despliegue. Cada despliegue es un artefacto inmutable que puede servirse indefinidamente o revertirse instantáneamente. No hay procesos manuales de actualización. No hay ventanas de mantenimiento. No hay riesgo de dejar el sitio en estado inconsistente durante una actualización.

El aislamiento por diseño significa que cada despliegue es completamente independiente. No hay estado compartido entre versiones. No hay base de datos que migrar. No hay configuración que sincronizar. Cada entorno es idéntico porque el artefacto desplegado es idéntico.

3.4 Cuándo tiene sentido este enfoque

Este enfoque tiene sentido cuando el proyecto es serio, cuando tiene ambición real de crecimiento, y cuando el posicionamiento de marca importa. No se trata de adoptar tecnología moderna por ser moderna. Se trata de elegir la arquitectura correcta para el caso de uso real.

3.4.1 Por qué en un proyecto serio siempre tiene sentido

En un proyecto con ambición real, la arquitectura técnica correcta no es opcional. La tecnología comunica el nivel del negocio. Una web técnicamente sólida es una señal de calidad que los competidores no pueden replicar instalando plugins. Es un diferenciador estructural que refuerza el posicionamiento en lugar de contradecirlo.

No todos los proyectos están preparados para este enfoque. Requiere criterio técnico para tomar la decisión. Requiere recursos para ejecutarla. Requiere comprensión de que la tecnología no es un detalle operativo, sino una decisión estratégica con impacto en la percepción de marca. Cuando el proyecto es serio y el posicionamiento justifica tickets altos, no hay alternativa técnicamente coherente.

La tecnología como reflejo del nivel del negocio significa que las decisiones técnicas condicionan cómo el mercado percibe el proyecto. Un negocio que pretende posicionarse en el segmento alto no puede permitirse decisiones técnicas que lo sitúen al mismo nivel que proyectos sin esa ambición. La arquitectura correcta no es una opción entre varias equivalentes. Es una consecuencia natural del nivel de ambición del proyecto.

Validación técnica

Las métricas de Lighthouse para esta web confirman lo que la arquitectura garantiza por diseño. Rendimiento, accesibilidad, mejores prácticas y SEO en rangos máximos. Estos resultados no son consecuencia de optimizaciones aplicadas sobre una base ineficiente. Son consecuencia directa de una arquitectura que no introduce ineficiencias que luego haya que compensar.

Lighthouse es una herramienta de auditoría de laboratorio. Valida aspectos técnicos medibles: tiempos de carga, cumplimiento de estándares de accesibilidad, implementación de mejores prácticas técnicas, factores de SEO on-page. No valida criterio estratégico. No valida coherencia entre posicionamiento y ejecución. No valida decisiones de arquitectura. Es una métrica útil pero insuficiente para evaluar la calidad técnica completa de un proyecto.

Los resultados de Lighthouse son consecuencia, no objetivo. Una web estática alcanza métricas máximas porque no requiere procesamiento en el servidor. Porque el HTML es semántico desde el inicio. Porque no hay complejidad innecesaria que introduzca problemas de rendimiento o accesibilidad. WordPress puede alcanzar métricas similares con suficientes plugins de optimización y configuración cuidadosa. La diferencia es que una aproximación es estructural y la otra es reactiva.

La diferencia entre una web optimizada y una web bien diseñada no es visible en Lighthouse. Lighthouse mide el resultado, no el proceso. Una web estática alcanza estas métricas por diseño. Una web WordPress optimizada las alcanza añadiendo capas de compensación sobre una base que no fue diseñada para el caso de uso. Ambas pueden producir el mismo número. Solo una de ellas es técnicamente coherente.