¿Cómo hacer tu web en Wordpress sin ensuciar el código ni depender de nadie?

Cómo construir sitios Wordpress rápidos, limpios y profesionales usando el editor nativo y Advanced Custom Fields (ACF), sin depender de Elementor, Divi ni ningún page builder que arruine tu código.

El Problema real con los page builders (constructores de páginas)

Imagina que contratas a un arquitecto para diseñar tu casa y en lugar de planos reales, te entrega una maqueta de plástico hecha con piezas de Lego. La maqueta tiene buen aspecto, encaja perfectamente en el presupuesto y puedes construirla sin experiencia. El problema llega cuando quieres abrir una ventana donde no hay hueco, cuando la fontanería no puede pasar por las paredes, o cuando intentas venderla y el tasador descubre que los cimientos son de espuma. Eso, exactamente, es lo que ocurre con Elementor, Divi y la mayoría de page builders en Wordpress.

No es una exageración. Millones de páginas web funcionan sobre estas herramientas y sus propietarios duermen tranquilos. Pero cuando un desarrollador abre el inspector de código, lo que ve le produce escalofríos, como docenas de div anidados sin semántica, scripts bloqueantes, CSS de cientos de kilobytes para renderizar un botón, shortcodes propietarios que encadenan el contenido al plugin para siempre y consultas a la base de datos que se multiplican como conejos.

El coste real que nadie te cuenta

Un página web creada con elementor muestra entre 4 y 8 MB de Javascript cargado en el front-end, tiempos de interactividad superiores a 6 segundos en dispositivos móviles, y puntuaciones de Core Web Vitals que Google penaliza directamente en el posicionamiento. Migrar ese sitio a otro sistema cuesta, en muchos casos, más que haberlo construido bien desde el principio.

Los tres pecados capitales de los page builders

Antes de hablar de soluciones, vale la pena entender exactamente qué hace que estos sistemas sean problemáticos a largo plazo, y son problemas estructurales.

Primer pecado es la dependencia absoluta.

Cuando construyes una página web con Divi, el contenido de cada página queda codificado en el formato propietario de Divi. Si algún día desactivas el plugin, tu sitio no muestra texto plano sino miles de shortcodes sin renderizar como [et_pb_section], [et_pb_row]. Eres prisionero del plugin te guste o no te guste. Los desarrolladores de Elegant Themes lo saben perfectamente y ahí reside parte de su modelo de negocio.

Segundo pecado es el HTML criminal.

Para generar una sección con dos columnas y un título, Elementor puede llegar a generar hasta 15 capas de div sin ningún significado semántico. Esto no es solo estético ya que los motores de búsqueda tienen cada vez más dificultades para interpretar estructuras tan ruidosas, los lectores de pantalla para accesibilidad simplemente fallan, y el mantenimiento se vuelve una pesadilla.

Tercer pecado es la ilusión del "sin código".

El marketing de estos productos promete que cualquier persona puede crear páginas web sin tocar una línea de código. Lo que no dicen es que, cuando necesitas algo que no está en su conjunto de widgets, acabas buscando un plugin de terceros que añada más capas al caos, pagando por funcionalidades que deberían ser nativas, o llamando a un desarrollador de todos modos. La promesa de "sin código" solo se cumple mientras no salgas del camino marcado.

¿Por qué existe este problema entonces?

La respuesta es histórica. Durante años, Wordpress no ofreció una interfaz de edición visual que fuera suficientemente potente para diseñadores y clientes. Cuando llegó Wordpress 4.x, la interfaz de edición de páginas era un editor de texto enriquecido sin ninguna capacidad visual. Ahí encontraron su nicho Elementor y Divi, llenar un vacío real con una solución rápida pero costosa a largo plazo.

Ese vacío ya no existe. Desde Wordpress 5.0, el editor nativo Gutenberg ha evolucionado hasta convertirse en una herramienta de diseño visual completamente capaz. Combinado con Advanced Custom Fields (ACF), lo que se puede construir con código limpio, estándar y portable supera con creces lo que cualquier page builder puede ofrecer.

Qué es Gutenberg realmente (y por qué lo subestimas y no lo usas en tus proyectos)

Gutenberg es el nombre oficial del editor de bloques de Wordpress, introducido en la versión 5.0 en diciembre de 2018. Pero llamarlo simplemente "el editor" es quedarse muy corto. Gutenberg es, en realidad, una apuesta arquitectónica completa de Automattic y la comunidad Wordpress para modernizar la plataforma desde sus cimientos.

Su nombre no es accidental ya que Johannes Gutenberg fue el inventor de la imprenta de tipos móviles. La analogía es precisa, así como la imprenta separó el contenido del proceso de composición y lo hizo recombinable, el editor Gutenberg separa el contenido estructurado (bloques) del presentación final (templates y estilos), haciendo que el primero sea reutilizable, portable y semánticamente correcto.

La arquitectura técnica que lo hace diferente

Gutenberg está construido sobre React, la librería de Facebook para interfaces de usuario. Esto no es un detalle menor, significa que cada bloque es un componente JavaScript con su propio estado, propiedades y lógica de renderizado. A diferencia de los shortcodes o los meta boxes clásicos, los bloques tienen una representación visual directa en el editor que corresponde fielmente a lo que se verá en el front-end.

El formato de almacenamiento de los bloques es HTML con comentarios especiales. Cuando guardas una página en Gutenberg, el contenido se almacena así en la base de datos.

<h2 class="wp-block-heading">Mi título</h2>



<p>El contenido del párrafo.</p>

¿Ves lo que ocurre aquí? Incluso si desactivas Gutenberg y usas el editor clásico, o cualquier otro sistema, el contenido sigue siendo HTML completamente válido y legible. No hay shortcodes propietarios. No hay dependencia. El HTML está ahí, semánticamente correcto, esperando ser usado por cualquier sistema que venga después.

A diferencia de Elementor o Divi, el contenido guardado con Gutenberg es HTML estándar. Puedes exportar, migrar, cambiar de tema o de plataforma sin perder ni una coma de tu contenido. Tu página web te pertenece completamente.

La evolución de Gutenberg ya no es lo que era

Uno de los argumentos más frecuentes contra Gutenberg es que "en sus primeras versiones era muy limitado". La versión inicial de 2018 tenía una selección básica de bloques, la experiencia de usuario era torpe y la curva de aprendizaje era pronunciada. Los detractores tomaron nota y muchos no han vuelto a mirar desde entonces.

Lo que esas personas no saben es que Gutenberg ha tenido más de cincuenta versiones mayores desde su lanzamiento. En 2024 y 2025, el editor incluye características que hace seis años parecían imposibles sin un page builder como los estilos globales configurables desde el editor, patrones de bloques (colecciones de bloques reutilizables), variaciones de estilo con un clic, diseño en cuadrícula con alineaciones complejas, Full Site Editing para editar plantillas completas, y una API de desarrollo de bloques que permite crear piezas de diseño completamente personalizadas con cualquier nivel de complejidad.

Bloques nativos

Más de 90 bloques incluidos de serie como párrafos, encabezados, imágenes, galerías, columnas, botones, formularios, tablas, código, vídeo, y muchos más.

Estilos globales

Define tipografía, colores, espaciados y variantes de estilo una sola vez y aplícalos globalmente. El diseño de sistemas era solo para grandes equipos, ahora no.

Patrones de bloques

Colecciones de bloques prediseñadas y reutilizables. Crea una vez, inserta en cualquier página, actualiza desde un lugar central.

Full site editing

Edita cabecera, pie, plantillas de página, plantillas de archivo, plantilla del blog, todo desde el mismo editor visual.

HTML semántico limpio

La salida es HTML5 correcto, sin capas de divs innecesarios. Excelente para SEO, accesibilidad y mantenibilidad del código.

API extensible

Crea tus propios bloques con JavaScript y PHP. La API de bloques de Wordpress es estándar web, documentada y sin sorpresas.

La filosofía de bloques es como pensar en componentes

Para sacar el máximo partido a Gutenberg, es necesario hacer un cambio de mentalidad. La forma de pensar en páginas web cuando usas un page builder es, añado una sección, dentro pongo columnas, dentro de las columnas pongo widgets etc etc, ves exactamente como construyes el diseño y eso está genial, pero no te das cuenta de las consecuencias que tiene en tu página web para mal.

Con Gutenberg, la forma correcta de pensar es "qué tipo de contenido estructurado necesito y como lo quiero mostrar pero a nivel semantico". Primero empiezas por lo que significa el contenido. Un título es un encabezado, no un "widget de texto grande". Un conjunto de testimonios es una lista de citas, no "tres columnas con iconos y texto". Esta distinción puede parecer filosófica, pero tiene consecuencias prácticas enormes.

Bloques simples, bloques complejos y bloques de contenedor

El ecosistema de bloques tiene una jerarquía natural que vale la pena entender.

Los bloques simples son unidades de contenido sin hijos, un párrafo, una imagen, un vídeo, un botón. Son los átomos de la pantalla. Tienen pocas opciones de configuración, son rápidos y predecibles.

Los bloques complejos tienen lógica interna más sofisticada, una galería con lightbox, un reproductor de audio, un mapa interactivo. Son piezas que encapsulan funcionalidad específica.

Los bloques de contenedor pueden anidar otros bloques, columnas, grupos, cover. Son los organizadores del layout. Aquí es donde ocurre la magia del diseño visual en Gutenberg.

El bloque Grupo es el nuevo div semántico

El bloque Grupo merece mención especial porque es el que más confusión genera entre quienes vienen de page builders. En Elementor, una "sección" es un contenedor genérico. En Gutenberg, el bloque Grupo es un contenedor configurable que puede ser un div, un section, un aside, un header, un footer o un figure, dependiendo de lo que semanticamente represente.

Esta elección de etiqueta HTML tiene importancia real ya que los motores de búsqueda entienden que el contenido dentro de un section es una sección temática coherente. Un lector de pantalla sabe que un aside es contenido complementario. Esto es accesibilidad y SEO integrados desde el nivel del bloque, no como una capa de parches encima.

<section class="wp-block-group hero-section">

  
  <h1 class="wp-block-heading">Título de la sección</h1>
  

  
  <p>Descripción semánticamente correcta.</p>
  

</section>

Compara esto con el output de Elementor para la misma estructura, fácilmente doce o más niveles de div con clases propietarias, atributos data- sin uso funcional, y CSS inline inyectado directamente en el HTML.

Patrones de bloques es el verdadero sistema de componentes

Los patrones de bloques son, probablemente, la característica de Gutenberg más infrautilizada y más potente para trabajo profesional. Un patrón es una colección predefinida de bloques que se puede insertar en cualquier lugar con un solo clic.

¿Qué diferencia un patrón de una plantilla de Elementor? La diferencia es fundamental, cuando insertas un patrón en Gutenberg, el contenido se convierte en bloques normales dentro de tu página. No hay conexión con el patrón original. Puedes modificarlo libremente. Si alguien elimina el plugin que registró el patrón, tu contenido ya insertado sigue intacto porque es HTML estándar.

Los patrones se registran con PHP nativo y no requieren ningún plugin adicional

register_block_pattern(
  'mi-tema/hero-con-cta',
  [
    'title'       => 'Hero con llamada a la acción',
    'description' => 'Sección hero con título, subtítulo y botón',
    'categories'  => [ 'featured' ],
    'content'     => get_template_part_content( 'patterns/hero-cta' ),
  ]
);

Organiza tus patrones en categorías propias: 'heroes', 'ctas', 'testimonials', 'pricing'. Registra las categorías con register_block_pattern_category(). Cuando abres el insertor de bloques, encontrarás tus patrones exactamente donde los necesitas, sin buscar entre los nativos.

Full Site Editing es Wordpress moderno de pies a cabeza

ACF es el plugin con el SUPERPODER que le Faltaba a Gutenberg

Advanced Custom Fields, conocido como ACF, es el plugin de WordPress más descargado de todos los tiempos en su categoría, con más de dos millones de instalaciones activas. Su premisa siempre ha sido siemple, añadir campos personalizados a cualquier tipo de contenido de WordPress de una forma estructurada, visual y usable tanto para desarrolladores como para clientes.

Pero los "campos personalizados" no capturan la verdadera dimensión de lo que ACF permite. ACF es, en esencia, un sistema de modelado de datos para Wordpress. Te permite definir exactamente qué información puede tener cada tipo de contenido y presentar esa información al editor de una forma clara y estructurada.

¿Por qué realmente necesitamos ACF junto a Gutenberg?

Gutenberg es excelente para contenido editorial como texto, imágenes, vídeos, citas. Es lo que usarías para escribir una entrada de blog, crear una página de servicios o redactar una landing page. Pero hay tipos de contenido que no encajan bien en el modelo editorial como...

• Un directorio de profesionales con nombre, foto, especialidad, localización y horarios.
• Un catálogo de productos con características técnicas, variantes y precios.
• Una página de equipo donde cada miembro tiene biografía, redes sociales y área de expertise.
• Una galería de proyectos con cliente, año, categoría, tecnologías usadas y enlace al resultado.
• Un FAQ donde cada pregunta-respuesta es un par de datos relacionados.
• Un menú de restaurante con secciones, platos, ingredientes, alérgenos y precios.

Para todos estos casos, intentar usar solo bloques de Gutenberg resulta torpe, el editor puede modificar accidentalmente la estructura, la presentación está mezclada con los datos, y no hay validación de que se hayan rellenado todos los campos obligatorios. ACF resuelve esto de manera elegante y profesional.

El sistema de tipos de campo de ACF

ACF ofrece más de treinta tipos de campo diferentes, cada uno con su propia interfaz de edición y su propio tipo de dato almacenado. Aquí mostramos los más relevantes.

Custom Post Types + ACF el dúo dinámico que también debes aprender si quieres hacer bien tus páginas web

Los Custom Post Types son tipos de contenido personalizados de Wordpress. Por defecto, Wordpress tiene Posts (noticias, blog) y Pages (páginas estáticas). Los CPTs te permiten crear Proyectos, Servicios, Miembros del equipo, Testimonios, Eventos, o cualquier entidad que tu sitio necesite.

La combinación CPT + ACF es la base de casi cualquier sitio Wordpress avanzado. Defines el CPT para tener un tipo de contenido estructurado, y usas ACF para definir exactamente qué campos tiene cada elemento de ese tipo. El resultado es una experiencia de edición a medida, limpia y a prueba de errores.

// functions.php — Registrar CPT "Proyectos"
register_post_type( 'proyecto', [
  'labels'        => [ 'name' => 'Proyectos', 'singular_name' => 'Proyecto' ],
  'public'        => true,
  'has_archive'   => true,
  'show_in_rest'  => true, // Necesario para Gutenberg
  'supports'      => [ 'title', 'thumbnail', 'editor' ],
  'menu_icon'     => 'dashicons-portfolio',
] );

// Campos ACF asociados al CPT "proyecto"
// (definidos en la interfaz visual de ACF o por código)
// - cliente (Text)
// - año_proyecto (Date Picker)
// - enlace_live (URL)
// - tecnologias (Checkbox)
// - galeria_proyecto (Gallery)
// - destacado (True/False)

El resultado en el back-end es una pantalla de edición limpia, con exactamente los campos que el editor necesita, sin campos irrelevantes ni opciones que puedan romper el diseño. Es experiencia de usuario para el cliente, no solo para el visitante del sitio.

ACF Blocks el diseño sin código basura

Aquí llegamos al punto donde Gutenberg y ACF se unen para crear algo verdaderamente potente que son los ACF Blocks. Esta característica, disponible desde ACF Pro 5.8, permite registrar bloques de Gutenberg personalizados usando solo PHP y HTML/CSS, sin necesidad de escribir JavaScript ni JSX.

La propuesta de valor es muy notable ya que cualquier desarrollador PHP con conocimientos de Wordpress puede crear bloques de Gutenberg completamente a medida, con campos de contenido editables visualmente en el editor, renderizado y HTML limpio en el front-end.

Cómo funciona un ACF Block

Un ACF Block tiene tres componentes, el registro (PHP), los campos asociados (ACF) y la plantilla de renderizado (PHP/HTML). Aquí un ejemplo completo de un bloque de tarjeta de testimonio.

1. Registro del bloque, functions.php

add_action( 'acf/init', function() {
  acf_register_block_type([
    'name'              => 'testimonio',
    'title'             => 'Testimonio',
    'description'       => 'Cita de un cliente con foto y nombre',
    'render_template'   => 'blocks/testimonio.php',
    'category'          => 'mi-empresa',
    'icon'              => 'format-quote',
    'keywords'          => [ 'testimonio', 'reseña', 'cliente' ],
    'supports'          => [ 'align' => true, 'jsx' => true ],
    'example'           => [
      'attributes' => [ 'mode' => 'preview', 'data' => [
        'texto'   => 'Increíble servicio, superó todas las expectativas.',
        'nombre'  => 'María García',
        'empresa' => 'Acme Corp',
      ]]
    ],
  ]);
    });

2. Plantilla de renderizado, blocks/testimonio.php

<?php
    $texto   = get_field( 'texto' );
    $nombre  = get_field( 'nombre' );
    $empresa = get_field( 'empresa' );
    $foto    = get_field( 'foto' );
    $classes = get_block_wrapper_attributes([ 'class' => 'bloque-testimonio' ]);
    ?>
    <figure <?php echo $classes; ?>>
      <blockquote>
        <p><?php echo esc_html( $texto ); ?></p>
      </blockquote>
      <figcaption>
        <?php if ( $foto ) : ?>
          <img src="<?php echo esc_url( $foto['url'] ); ?>"
               alt="<?php echo esc_attr( $nombre ); ?>"
               class="testimonio__avatar">
        <?php endif; ?>
        <strong><?php echo esc_html( $nombre ); ?></strong>
        <span><?php echo esc_html( $empresa ); ?></span>
      </figcaption>
</figure>

El HTML que sale al front-end es exactamente el que has escrito, una figure con un blockquote y un figcaption. Salida de HTML5 semánticamente correcto sin divs envueltos, sin clases propietarias, sin Javascript en el cliente. Solo el marcado que necesitas, nada más.

El modo preview es lo que el cliente ve al insertar el bloque

Una de las grandes ventajas de los ACF Blocks es el atributo example en el registro. Cuando defines datos de ejemplo, el editor de bloques muestra una previsualización visual del bloque en el panel de inserción, antes de que el usuario lo coloque en la página. El cliente sabe exactamente qué está insertando, igual que en cualquier page builder, pero con código limpio en el resultado final.

Flexible Content es el constructor de páginas que tú controlas

Si los campos de ACF son potentes, el campo Flexible Content es directamente transformador. Permite definir múltiples "layouts" (secciones de página), cada uno con sus propios subcampos, y permite al editor reordenarlos, añadirlos o eliminarlos libremente. Es, efectivamente, un page builder personalizado, pero donde tú defines exactamente qué secciones existen y cómo se renderizan.

// Template de página con Flexible Content
<?php
if ( have_rows( 'secciones_pagina' ) ) :
  while ( have_rows( 'secciones_pagina' ) ) : the_row();

    if ( get_row_layout() === 'hero' ) :
      get_template_part( 'template-parts/secciones/hero' );

    elseif ( get_row_layout() === 'servicios_grid' ) :
      get_template_part( 'template-parts/secciones/servicios-grid' );

    elseif ( get_row_layout() === 'cta_centrado' ) :
      get_template_part( 'template-parts/secciones/cta' );

    endif;
  endwhile;
endif;
?>

El resultado es que el cliente tiene un editor visual donde puede construir su página añadiendo secciones prediseñadas, en el orden que quiera, con su propio contenido. El desarrollador mantiene control total sobre el HTML, el CSS y el comportamiento de cada sección. Y el front-end genera código limpio porque el código de cada sección lo has escrito tú.

La combinación ganadora

Gutenberg para contenido editorial (texto, imágenes, estructura libre) + ACF Fields para datos estructurados en CPTs + ACF Blocks para componentes de diseño complejos + ACF Flexible Content para constructores de página controlados. Cada herramienta en su lugar, sin pisarse, sin código redundante.

El resultado es una página web donde el cliente tiene una experiencia de edición comparable a cualquier page builder premium, pero el código es limpio, portable, semántico y rápido y todo eso se traduce en que tendrás una página web profesional, rápida y correctamente fabricada para posicionar en Google sin penalizaciones.

El flujo de trabajo profesional completo

Llegamos al rendimiento de tu página web que es algo realmente super importante

El rendimiento web en la actualidad no es un lujo ni una optimización opcional. Es un factor de posicionamiento directo en Google (Core Web Vitals), un determinante de la tasa de conversión (cada segundo de carga adicional reduce las conversiones entre un 4% y un 7% según datos de Google), y una expectativa básica del usuario moderno que accede mayoritariamente desde dispositivos móviles con conexiones variables.

El peso de los page builders

Los datos son consistentes en múltiples estudios de la comunidad Wordpress. Una página web creada con Elementor carga entre 3 y 6 MB de recursos en el front-end, incluyendo el Javascript del editor cargado innecesariamente en la vista pública, hojas de estilo para todos los widgets aunque no se usen en esa página, y librerías JavaScript de terceros integradas sin optimización.

Una página web equivalente construido con Gutenberg y un tema ligero carga entre 200 y 600 KB. La diferencia no es marginal, sino enorme. En un dispositivo móvil con conexión 3G, la diferencia entre 4 MB y 400 KB es la diferencia entre una página que carga en 12 segundos y una que carga en 1.5 segundos.

Y está el Core Web Vitals

Los Core Web Vitals de Google son tres métricas que miden la experiencia de usuario real, LCP (Largest Contentful Paint, velocidad percibida de carga), INP (Interaction to Next Paint, responsividad) y CLS (Cumulative Layout Shift, estabilidad visual).

LCP, Gutenberg gana por defecto porque genera HTML más ligero y que el navegador puede procesar más rápido. Sin Javascript de Elementor bloqueando el renderizado, el elemento más grande (normalmente una imagen o el título principal) aparece antes.

INP, Aquí la diferencia es dramática. Elementor carga entre 15 y 25 scripts Javascript en el front-end. Cada script tiene que ser parseado y ejecutado por el motor JS del navegador, ocupando el hilo principal. Con Gutenberg nativo, la carga de Javascript en el front-end es mínima o nula si el tema no lo requiere.

CLS, El Cumulative Layout Shift mide cuánto se mueve el contenido visualmente durante la carga. Los page builders, con su CSS cargado de forma asíncrona y sus fuentes web múltiples, son propensos a CLS elevado. Un tema bien construido con Gutenberg puede alcanzar CLS de 0.

Sitios migrados de Elementor a Gutenberg con tema ligero muestran consistentemente mejoras de 40-60 puntos en PageSpeed Insights, reducción del tiempo de bloqueo total de 2.3 segundos a bajo 0.1 segundos, y LCP pasando de 4.5 segundos a menos de 1.5 segundos. Estos no son casos aislados; son los resultados esperables con una implementación correcta.

El problema específico del CSS de Elementor

Elementor genera CSS de forma dinámica, almacenado en la base de datos y servido como archivo. Cada vez que editas el diseño de una sección, Elementor regenera este CSS. El problema es que el CSS se genera para todos los breakpoints de todos los widgets usados en el sitio, aunque la página actual solo use tres widgets. El resultado es CSS de cientos de kilobytes que el navegador tiene que descargar y parsear para mostrar una página.

Con Gutenberg y un tema bien estructurado, el CSS de la página es solo el CSS real necesario para renderizar esa página. Nada más.

La comparativa entre Gutenberg y Page Builders

Es el momento de confrontar directamente los argumentos más comunes que se esgrimen a favor de los page builders, y responderlos con datos y perspectiva técnica.

Y ahora salen los que dicen, "pero es más rápido construir con Elementor"

Es el argumento más honesto que existe a favor de los page builders, y merece una respuesta igualmente honesta, "para el primer proyecto, sí, puede ser más rápido". Para el segundo, "la diferencia es mínima". A partir del tercero, el flujo de trabajo con Gutenberg y ACF es igual de rápido o más, porque trabajas con tus propios bloques, tus propios patrones, tu propio sistema de diseño que se reutiliza entre proyectos.

La velocidad de Elementor es la velocidad del arranque. La velocidad de Gutenberg es la velocidad de crucero. Si construyes una página web al año, quizás Elementor tiene sentido. Si construyes muchás páginas web, la inversión en un sistema propio basado en Gutenberg y ACF se amortiza con creces.

Casos de uso y ejemplos prácticos

La teoría es importante, pero la práctica es donde se demuestra el valor real. Aquí algunos escenarios concretos con la implementación recomendada usando Gutenberg y ACF.

Crear una landing page de alto rendimiento

Una landing page para captar leads necesita velocidad máxima, diseño impecable y cero distracciones. Con Gutenberg crear una página estática con el template blank-canvas que elimina cabecera y pie, construir con bloques nativos (Cover para el hero, Columns para beneficios, Buttons para CTAs, y un Formulario de contacto nativo de Wordpress o un plugin ligero).

Resultado: página con PageSpeed >95 móvil, LCP <1.2s, sin JavaScript de terceros.

Crear portafolio de proyectos para agencia

Una agencia necesita mostrar sus proyectos con imagen, cliente, categoría y descripción, permite filtrar por tipo de proyecto; muestra proyectos relacionados en cada página individual. 

Implementación: CPT proyecto con ACF fields (imagen_principal, cliente, categoría, descripción_corta, galería, tecnologías). Template single-proyecto.html con bloques nativos para el layout. Archivo de proyectos con filtrado JavaScript ligero. Sin page builder, sin plugins de constructores de portafolio.

Crear una web corporativa con multiples secciones

Una empresa necesita páginas complejas con hero, servicios en grid, estadísticas, testimonios, clientes y CTA final. Todo ello editable por el cliente sin tocar código. 

Implementación: Flexible Content de ACF con layouts prediseñados (hero, servicios-grid, estadísticas, testimonios, logos-clientes, cta). 

Cada layout es un template PHP con HTML limpio. El cliente construye sus páginas añadiendo y reordenando secciones desde la interfaz de ACF, que es mucho más clara que el panel lateral de Elementor.

Crear un directorio de profesionales

Un directorio con cientos de perfiles, cada uno con foto, especialidad, localización, horarios y botón de contacto. Búsqueda y filtrado por especialidad. 

Implementación, CPT profesional con ACF fields completos. Taxonomy especialidad para filtrado.

Template de archivo con WP_Query y AJAX para filtrado sin recarga. Template individual para el perfil completo. Todo con HTML semántico, velocidad máxima y datos estructurados JSON-LD para SEO de los perfiles.

Crear un blog editorial de alto tráfico

Un medio de comunicación con múltiples autores, categorías, artículos con rich content (infografías, galerías, vídeos embebidos, citas destacadas, boxes informativos). Gutenberg es, literalmente, el escenario para el que fue diseñado. Los bloques nativos cubren todos los formatos editoriales habituales. Los patrones de bloque permiten a los redactores insertar formatos complejos (un box de "Lo más importante" o un "Ficha técnica") con un solo clic y sin romper el diseño.

Lo que yo haría

La web ha madurado muchísimo en los últimos años. Los visitantes tienen expectativas de velocidad y experiencia que las páginas web construidas con page builders tienen crecientes dificultades para satisfacer. 

• Recueda que los los motores de búsqueda penalizan explícitamente las páginas web lentas y con HTML mal estructurado. 
• Los clientes empiezan a preguntar por los Core Web Vitals. 
• Y las herramientas nativas de Wordpress han alcanzado un nivel de madurez que hace los page builders innecesarios para proyectos profesionales.

Gutenberg y ACF no son la solución 100% perfecta para todos los casos. Si necesitas hacer el diseño y crear una página web en 2 telediarios, un page builder puede ser una opción. Si necesitas que una persona sin conocimientos técnicos construya páginas completamente a su gusto sin ninguna restricción, el page builder es la mejor opción.

Pero para proyectos donde importan la velocidad, el SEO, la mantenibilidad a largo plazo, la calidad del código, la portabilidad del contenido y la experiencia de edición estructurada para el cliente, Gutenberg con ACF es la respuesta correcta. No porque sea más moderna o más trendy, sino porque genera mejores resultados medibles en todas las métricas que realmente importan.

"La mejor herramienta no es la que genera el resultado más rápido hoy, sino la que no te crea problemas dentro de tres años."

Por dónde empezar

1. Instala WordPress localmente e instala ACF Pro con licencia de desarrollador.
2. Estudia la documentación oficial de Gutenberg.
3. Lee la documentación de ACF sobre Blocks.
4. Estudia un tema de referencia basado en bloques como el que trae Wordpress por defecto como Twenty Twenty-Four es el mejor ejemplo oficial de la comunidad.
5. Construye un proyecto pequeño completo con estas indicaciones antes de comprometerte con un proyecto de tu cliente.
6. Crea tu primera biblioteca de patrones de bloque y bloques ACF reutilizables entre proyectos.

El camino no es instantáneo y que requiere aprendizaje y práctica. Pero los desarrolladores que han hecho esta transición coinciden en que, una vez superada la curva de aprendizaje, no vuelven a los page builders. No porque sea más sencillo, sino porque los resultados son muchísimos mejores.

Wordpress lleva más de veinte años siendo la plataforma dominante de la web. Gutenberg es su apuesta de futuro y está aquí para quedarse. Aprender a dominarlo no es una opción avanzada para especialistas, es la habilidad fundamental del desarrollador Wordpress moderno.