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, design tokens en un solo archivo y alineación con la dirección del desarrollo del core de WordPress. 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.

#Qué archivos necesita realmente un tema de WordPress

Un tema clásico necesita exactamente dos archivos para que WordPress lo liste y permita activarlo: style.css, cuyo comentario de cabecera lleva el nombre del tema y el resto de metadatos, e index.php como plantilla de último recurso. Todo lo demás que se suele ver, header.php, footer.php, functions.php, single.php, page.php, es opcional en sentido estricto y solo hace falta cuando quieres que la jerarquía de plantillas se ramifique. Un tema de bloques cambia el segundo archivo: style.css sigue llevando el comentario de cabecera, pero la plantilla de reserva es templates/index.html en lugar de index.php. theme.json tampoco es obligatorio formalmente, aunque un tema de bloques sin él hereda los valores por defecto del core para colores, espaciado y tipografía, que casi nunca es lo que quieres. Un tema hijo añade una regla más: la línea Template: de la cabecera de su style.css tiene que nombrar la carpeta del tema padre.

#1. Archivos de un tema clásico y un tema de bloques

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. Qué sustituye theme.json en functions.php

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. Cómo organizar esos tokens como un sistema de diseño compartido entre proyectos se explica en la guía de sistemas de diseño escalables con Gutenberg. 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. Cómo funcionan los estilos globales en WordPress

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. Diferencias entre tema de bloques y tema clásico

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. Son más rápidos los temas de bloques

Durante años la respuesta fue un sí claro, y desde WordPress 6.9 la diferencia es mucho menor.

1. Estilos de los bloques del core: los temas de bloques cargan el CSS de los bloques del core por separado y solo para los bloques que se renderizan, porque _add_default_theme_supports() activa should_load_separate_core_block_assets y should_load_block_assets_on_demand. Los temas clásicos recibían antes la hoja agrupada wp-block-library en cada página. Desde la 6.9, wp_load_classic_theme_block_styles_on_demand() activa esos mismos dos filtros para los temas clásicos y añade un búfer de salida que sube al head los estilos tardíos. El búfer tiene un coste: impide el streaming de la respuesta, así que el tiempo hasta el primer byte puede subir ligeramente. Un tema que necesite streaming puede desactivarlo con el filtro wp_should_output_buffer_template_for_enhancement.
2. Tokens de diseño en lugar de hojas de estilos: theme.json emite variables CSS en vez de una cascada pesada. Un tema clásico obtiene los mismos tokens en cuanto incluye un archivo theme.json.
3. La hoja de estilos propia del tema: aquí sigue habiendo una diferencia real. Un tema clásico suele llevar un style.css grande con todos los componentes, mientras que un tema de bloques mantiene la mayor parte del estilo en theme.json y en estilos por bloque.
4. 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.

Un tema no tiene puntuación de Lighthouse; una página sí. En un sitio real el resultado depende mucho más del banner de consentimiento, los mapas y formularios incrustados, los archivos de fuentes y el tamaño de las imágenes que del tipo de tema. Mide tus propias páginas; la guía de Core Web Vitals explica cómo.

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 usar un tema 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.
• Quieres design tokens y estilos por bloque por defecto en lugar de una hoja de estilos grande del tema.
• 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. Qué tema elegir para WooCommerce, blog o LMS

• 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.

#Qué es un tema 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.

#Qué funciones del Editor del sitio funcionan con temas clásicos según la versión de WordPress

La frontera entre los dos tipos de tema se ha movido en casi cada versión. El Theme Handbook define los temas híbridos como “temas clásicos que han adoptado algunas funciones modernas relacionadas con los bloques” y aclara que híbrido no es un tipo de tema oficial (What is a theme, traducción propia). La tabla recoge qué llegó a los temas clásicos y cuándo, con fechas del archivo de versiones de WordPress.

En el core actual, wp-admin/menu.php da a un tema clásico la entrada completa Diseño del Editor del sitio cuando incluye theme.json o declara soporte de editor-styles, y solo la entrada Patrones en caso contrario. Un tema de bloques recibe la entrada Editor. Por eso en 2026 la pregunta práctica rara vez es “clásico o de bloques” en abstracto. Es qué funciones adopta un proyecto, en qué orden, y si merece la pena dar el último paso, añadir templates/index.html.

#Tema de bloques vs tema clásico de WordPress: cuál 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
• Los editores deben cambiar plantillas y estilos globales sin un despliegue
• Quieres usar theme.json para design tokens (colores, tipografía, espaciado) en lugar de CSS disperso
• El proyecto es una construcción nueva sin código legacy que mantener

Elige un tema clásico cuando:

• Necesitas lógica PHP compleja en plantillas (loops personalizados, layouts condicionales, overrides de WooCommerce)
• El proyecto depende de widgets, menus clásicos 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 migración supera el beneficio

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

WordPress 7.0 se publicó el 20 de mayo de 2026 y la 7.1 el 19 de agosto de 2026; la versión actual es la 7.1.3, del 6 de octubre de 2026. La Abilities API llegó antes, en la 6.9, y funciona igual con ambos tipos de tema, así que no es un argumento a favor de ninguna de las dos arquitecturas.

#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.