Temas de bloques vs temas clásicos de WordPress en 2026

Durante más de una década (2010 a 2020), el desarrollo de temas WordPress se veía igual: creabas header.php, footer.php, un loop en index.php y estilos en style.css. La lógica vivía en PHP, la apariencia en CSS, y ambos mundos rara vez se cruzaban.

Con WordPress 5.9 llegó el enfoque Full Site Editing (FSE), hoy simplemente llamado Editor del sitio, y en 2026 la pregunta es más aguda que nunca: ¿deberías seguir escribiendo temas en PHP o pasar por completo a bloques, plantillas HTML y theme.json?

Esta guía desglosa qué son realmente los temas de bloques, en qué se diferencian de los temas clásicos a nivel de código, cuándo gana cada uno y cómo planificar una migración entre ellos. Cubre los modelos clásico, de bloques e híbrido.

Respuesta corta: elige un tema de bloques cuando quieras gestión del sitio desde el editor, mejores Core Web Vitals y una hoja de ruta WordPress más limpia a largo plazo. Mantén un tema clásico cuando el proyecto todavía depende de plantillas PHP personalizadas, control estricto del layout o un flujo de trabajo pesado con page builders. El modelo híbrido se sitúa entre ambos y es donde aterriza buena parte de los proyectos profesionales.

#Qué es un tema de bloques en WordPress

Un tema de bloques es un tema de WordPress construido íntegramente con bloques: sus plantillas son archivos HTML con marcado de bloques en lugar de archivos PHP, sus tokens de diseño viven en un único theme.json, y cada parte del sitio (header, footer, archivos, 404) se edita visualmente en el Editor del sitio. Full Site Editing (FSE) es el término paraguas para este sistema, y antes de comparar conviene definir sus piezas, porque se introdujeron juntos varios subsistemas distintos.

El Editor del sitio (Apariencia -> Editor) es una interfaz visual para editar cada parte de un sitio: plantillas, partes de plantilla, estilos, patrones y navegación. En un tema clásico solo editabas el contenido de entradas y páginas en el editor de bloques. En un tema de bloques, ese mismo lienzo de bloques ahora edita el header, el footer, la plantilla de entrada individual, el archivo, el 404 y los resultados de búsqueda.

theme.json es un único archivo de configuración en la raíz del tema que declara los design tokens y los ajustes del editor. Define la paleta de colores, la escala tipográfica, la escala de espaciado, los anchos de layout y qué controles aparecen en el editor. WordPress lo lee y genera variables CSS tanto para el front end como para el editor, de modo que la vista de edición coincide con la página publicada.

Plantillas de bloques y partes de plantilla son archivos HTML dentro de templates/ y parts/. En lugar de single.php entregas templates/single.html, y en lugar de un footer fijo en footer.php entregas parts/footer.html. Estos archivos contienen marcado de bloques (comentarios HTML como <!-- wp:post-title /-->), no PHP.

Estilos globales es la capa de cara al usuario sobre theme.json. Los propietarios del sitio pueden ajustar colores, fuentes y espaciado desde el panel de Estilos sin tocar código, y los temas pueden ofrecer variaciones de estilo como archivos JSON adicionales en una carpeta styles/.

Patrones de bloques son composiciones de bloques reutilizables y ya diseñadas. Reemplazaron buena parte de lo que ofrecían los page builders: un hero, una sección de precios, una llamada a la acción, todo editable como bloques nativos y registrado desde un directorio patterns/.

Entender estas cinco piezas es casi toda la batalla. Un tema de bloques es, en esencia, theme.json más plantillas HTML más patrones, editado a través del Editor del sitio.

#1. Anatomía: PHP vs HTML

Esta es la diferencia más fundamental, y la que inquieta a muchos desarrolladores veteranos.

#Tema clásico

Basado en archivos PHP. Cuando WordPress carga una página, recorre la jerarquía de plantillas (por ejemplo single-product.php, luego single.php, luego index.php) y el motor PHP ensambla el header, el loop y el footer en tiempo de petición.

• Estructura: header.php, page.php, single.php, archive.php, sidebar.php, functions.php.
• Lógica: puedes mezclar libremente PHP con HTML, por ejemplo if ( is_user_logged_in() ) o un WP_Query totalmente personalizado.
• Fortaleza: control total sobre el marcado y facilidad para inyectar lógica de negocio, llamadas a APIs externas o vistas condicionales.
• Debilidad: el propietario del sitio no puede tocar el header, el footer ni el layout sin editar código o pedirlo a un desarrollador.

#Tema de bloques

Basado en archivos de plantilla HTML con marcado de bloques. No hay PHP en los propios archivos de plantilla.

• Estructura: templates/index.html, templates/single.html, parts/header.html, parts/footer.html, theme.json.
• Lógica: ninguna en el archivo de plantilla. Las plantillas son marcado de bloques estático, y toda la salida dinámica proviene de bloques como <!-- wp:post-title /-->, el bloque Query Loop o el bloque de Contenido de la entrada.
• Fortaleza: el propietario del sitio puede editar todo el sitio, incluidos header y footer, en un único lienzo visual.
• Debilidad: la lógica del lado del servidor debe trasladarse a un bloque personalizado, una variación de bloque, la API Block Bindings o un shortcode, en lugar de vivir en línea dentro de una plantilla.

El cambio mental es que la lógica de presentación abandona el archivo de plantilla. Donde un tema clásico pone una condición directamente en single.php, un tema de bloques expresa la misma intención mediante contexto de bloque, block bindings o un bloque específico registrado en un plugin o en el functions.php del tema.

#2. El corazón del tema: functions.php vs theme.json

En la era clásica, functions.php era el cajón de sastre: registrar menús, sidebars, tamaños de imagen, encolar hojas de estilos y scripts, y definir banderas de add_theme_support(). Las decisiones de diseño quedaban dispersas entre PHP y uno o más archivos CSS.

En la era de bloques, theme.json centraliza la configuración. Controla:

1. Paleta de colores: los colores con nombre que se ofrecen a los editores, emitidos como variables CSS.
2. Tipografía: tamaños de fuente, familias tipográficas, altura de línea y tipografía fluida.
3. Espaciado: una escala de espaciado y el hueco entre bloques usados de forma consistente.
4. Layout: ancho de contenido y ancho amplio (contentSize, wideSize) que gobiernan la alineación.
5. Controles y disponibilidad: appearanceTools, ajustes por bloque y la capacidad de desactivar controles que no quieres que los editores toquen.

Ejemplo de theme.json en 2026:

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "720px", "wideSize": "1200px" },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0055FF", "name": "Azul marca" }
      ]
    },
    "typography": {
      "fluid": true,
      "fontSizes": [
        { "slug": "small", "size": "14px", "name": "Pequeño" }
      ]
    }
  }
}

En lugar de mantener cientos de líneas de CSS más registro en PHP, declaras los tokens una sola vez en JSON. WordPress genera CSS optimizado y variables CSS para el front end y el editor, y por eso la vista previa del editor por fin coincide con el resultado publicado. functions.php sigue existiendo en un tema de bloques, pero se vuelve pequeño: encolar una fuente, registrar una categoría de patrones, añadir banderas de soporte del editor y poco más.

#3. Estilos globales y el Editor del sitio

theme.json fija los valores por defecto; Estilos globales permite al propietario del sitio sobrescribirlos sin código. Desde el panel de Estilos, un editor puede cambiar la fuente del cuerpo, ajustar la paleta o modificar el espaciado, y esas elecciones se guardan por sitio.

Los temas también pueden ofrecer variaciones de estilo: archivos JSON adicionales en una carpeta styles/ que presentan todo el sitio con un aspecto distinto, por ejemplo una variación oscura o una de alto contraste, seleccionables con un clic. Es una capacidad que los temas clásicos nunca tuvieron de forma nativa, y es uno de los argumentos más fuertes a favor de los temas de bloques en proyectos con marca flexible.

El contrapunto es la gobernanza. Dar acceso completo a Estilos globales a un editor sin formación puede producir tipografía inconsistente o contraste roto. Los temas de bloques responden con bloqueo de bloques y desactivando controles concretos en theme.json, pero el desarrollador tiene que establecer esas barreras de forma deliberada.

#4. Qué pasa con los widgets y los menús

En los temas de bloques, no hay pantalla de Widgets ni el editor de Menús clásico bajo Apariencia.

• En lugar de widgets, tienes partes de plantilla. El footer es una parte de plantilla HTML que editas en el mismo lienzo de bloques que cualquier entrada.
• En lugar del editor de menús clásico, tienes el bloque de navegación, editado directamente en el header, con su menú almacenado como una entidad reutilizable wp_navigation.

Para los clientes acostumbrados al WordPress antiguo, esto es un choque cultural real. Los familiares apartados de “widgets” y “menús” desaparecen, reemplazados por bloques. Algunos plugins que dependían de registrar widgets ahora entregan bloques en su lugar, y unos pocos más antiguos exponen su widget solo a través del bloque Widget heredado como puente de compatibilidad. Auditar la compatibilidad de plugins es, por tanto, un paso real antes de comprometer a un cliente con un tema de bloques.

#5. Comparativa de funciones y capacidades

La tabla siguiente resume dónde divergen ambos modelos en el trabajo diario.

Lee la tabla como una ayuda a la decisión, no como un marcador. Ninguna columna es universalmente mejor; la elección correcta depende de quién edita el sitio y de cuánta lógica de servidor personalizada arrastran las plantillas.

#6. Rendimiento y experiencia de desarrollo

En rendimiento puro de front end, los temas de bloques suelen llevar ventaja.

1. Carga de estilos: WordPress encola CSS solo para los bloques que se renderizan en una página dada, mientras que un tema clásico normalmente carga un style.css grande en cada petición.
2. Tokens de diseño en lugar de hojas de estilos: theme.json emite variables CSS en vez de una cascada pesada, lo que mantiene el CSS crítico más pequeño.
3. Marcado más limpio, con matiz: la salida de FSE suele ser ordenada, pero los bloques de layout anidados pueden producir div envolventes de más (“div-itis”) si los patrones se construyen sin cuidado.
4. Core Web Vitals: temas de bloques por defecto como Twenty Twenty-Six puntúan muy bien en Lighthouse casi de fábrica, porque cargan CSS mínimo y sin dependencia de jQuery.

La experiencia de desarrollo es más matizada y depende del equipo. El desarrollo de temas de bloques se apoya en configuración JSON, marcado de bloques y JavaScript para bloques personalizados (block.json, register_block_type, la cadena de herramientas @wordpress/scripts). Los equipos con raíces profundas en PHP pero poca experiencia con React o herramientas de bloques afrontan una curva de aprendizaje real. El desarrollo clásico, en cambio, resulta inmediatamente familiar para cualquier desarrollador PHP, pero no ofrece edición visual al cliente ni un sistema de design tokens sin trabajo adicional. En la práctica, la vía más rápida para un equipo con mucho PHP es el tema híbrido, que les permite adoptar theme.json y patrones primero y añadir bloques personalizados de forma gradual.

#7. Migrar de un tema clásico a un tema de bloques

La migración rara vez es un solo interruptor. El contenido de tu base de datos (entradas, páginas, medios) no se ve afectado, pero la capa de presentación debe reconstruirse.

Consideraciones prácticas:

• Plantillas: cada plantilla PHP necesita una plantilla de bloques equivalente. Las plantillas condicionales complejas pueden necesitar dividirse en patrones más block bindings.
• Menús: los menús existentes no se convierten automáticamente; los reconstruyes como bloques de navegación, aunque los elementos del menú suelen recrearse rápido.
• Widgets: las áreas de widgets no existen en un tema de bloques, así que los widgets de sidebar y footer pasan a ser partes de plantilla o bloques.
• Ajustes del Personalizador: las opciones fijadas en el Personalizador (logo, colores, CSS personalizado) se trasladan a theme.json y Estilos globales. El CSS personalizado puede conservarse en el campo de CSS adicional de Estilos globales durante la transición.
• Salida de plugins: verifica que cada plugin activo entrega bloques o shortcodes en lugar de depender de widgets o hooks de plantilla que un tema de bloques ya no dispara igual.

Una ruta segura es incremental: primero convierte el tema clásico en híbrido añadiendo theme.json y soporte de patrones de bloques, verifica los design tokens y la experiencia de edición, y después reemplaza las plantillas PHP por plantillas de bloques una a una. Así evitas una reescritura arriesgada de golpe y puedes probar cada plantilla contra contenido real y Core Web Vitals antes de continuar.

#8. Cuándo mantener un tema clásico

Un tema clásico sigue siendo la opción correcta cuando:

• El proyecto arrastra mucha lógica PHP de vista, como condiciones de visualización avanzadas, loops personalizados o sobrescrituras profundas de plantillas de WooCommerce.
• El cliente no se siente cómodo con la edición completa y necesitas evitar cambios accidentales de layout en el header o el footer.
• La construcción depende de un page builder como Elementor o Divi, que todavía asumen una estructura clásica y en gran parte se saltan FSE.
• Mantienes un sitio maduro donde el coste de migración supera claramente el beneficio.
• La experiencia del equipo es primero PHP, con poca capacidad para invertir ahora en herramientas de bloques.

#9. Cuándo ganan los temas de bloques

Un tema de bloques es la opción más fuerte cuando:

• El sitio está guiado por contenido: un sitio corporativo, un blog, una publicación o un portfolio.
• El propietario quiere editar headers, footers y plantillas sin un desarrollador en cada cambio.
• El rendimiento y los Core Web Vitals son prioridad y quieres CSS por bloque y design tokens por defecto.
• La flexibilidad de marca importa y las variaciones de estilo aportan valor real.
• Quieres alinearte con la dirección del core de WordPress, que ahora concentra su desarrollo en la experiencia de bloques y FSE.

#10. Recomendación por tipo de sitio

• Sitio corporativo o de pequeña empresa: tema de bloques. Los editores obtienen control seguro sobre todo el layout y el rendimiento es fuerte por defecto.
• Blog o publicación: tema de bloques. El bloque Query Loop, los patrones y el marcado limpio encajan bien con flujos editoriales.
• Portfolio o sitio de presentación: tema de bloques, a menudo con un par de variaciones de estilo para looks estacionales.
• Tienda WooCommerce: depende. El carrito y el checkout basados en bloques encajan con un tema de bloques, pero las tiendas con plantillas de producto en PHP muy personalizadas pueden quedarse en clásico o híbrido.
• Membresía, LMS o aplicación compleja: clásico o híbrido. La lógica de vista pesada y las integraciones externas son más fáciles de controlar en plantillas PHP.
• Sitio guiado por page builder: clásico. El builder ya gobierna el layout, así que FSE aporta poco.

#El enfoque híbrido

El modelo híbrido es el término medio pragmático. Es un tema PHP clásico que añade theme.json (para la paleta de colores, la tipografía y los tokens de espaciado en el editor) y soporte de patrones de bloques, manteniendo plantillas PHP concretas como header.php o single.php para el control estructural. Muchos proyectos profesionales en 2026 se entregan exactamente así, adoptando la edición de bloques donde ayuda y conservando PHP donde importa.

#Tema de bloques vs tema clasico de WordPress: cual elegir en 2026

La decisión depende de tres factores: complejidad del proyecto, habilidades técnicas del cliente y requisitos de mantenimiento a largo plazo.

Elige un tema de bloques cuando:

• El cliente necesita editar headers, footers y plantillas sin ayuda del desarrollador
• El rendimiento es prioridad (los temas de bloques cargan solo el CSS de los bloques realmente usados)
• Quieres usar theme.json para design tokens (colores, tipografia, espaciado) en lugar de CSS disperso
• El proyecto es una construcción nueva sin código legacy que mantener

Elige un tema clasico cuando:

• Necesitas lógica PHP compleja en plantillas (loops personalizados, layouts condicionales, overrides de WooCommerce)
• El proyecto depende de widgets, menus clasicos o el Customizer
• Tu equipo tiene profunda experiencia en PHP pero limitada experiencia en desarrollo de bloques Gutenberg
• Estas manteniendo un sitio existente y el coste de migracion supera el beneficio

El enfoque híbrido: Muchos proyectos WordPress profesionales en 2026 usan un tema clasico con soporte selectivo de bloques. Registra patrones de bloques y plantillas donde anadan valor, mantiene plantillas PHP donde ofrezcan más control. WordPress no obliga a una elección de todo o nada.

Para WordPress 7.0, los temas de bloques ganaran funciones adicionales impulsadas por IA a traves de la Abilities API, haciendo que la ruta FSE sea cada vez más atractiva para nuevos proyectos.

#Resumen

Descubre más sobre servicios de desarrollo WordPress en WPPoland. El mundo WordPress se ha dividido en dos campos. No luches contra ello. Aprende la sintaxis de theme.json - es una habilidad tan importante en 2026 como conocer CSS lo era en 2015.