Edición completa del sitio WordPress: guía práctica
Resumen
La edicion completa del sitio WordPress en 2026 es una realidad madura: el 68% de las nuevas instalaciones usan bloques. Este folio cubre la anatomía mínima de un tema de bloques, el Editor del Sitio en WP 6.9, theme.json v3, el bloque Query Loop y las Anulaciones de patrón. También detalla los tres puntos de fricción reales en producción y las herramientas que importan.
La edicion completa del sitio WordPress alcanzó un punto de inflexión en 2026. En WordPress 6.9, el 68% de las nuevas instalaciones utilizan por defecto la arquitectura basada en bloques. Para freelances y agencias que aún entregan temas PHP clásicos a sus clientes, la pregunta ya no es si adoptar el FSE, sino cómo hacerlo sin romper los flujos de trabajo en producción.
Este folio cubre la mecánica, no el marketing. Probado en sitios reales de clientes con WordPress 6.8 y 6.9.
Lo que el FSE reemplaza, y lo que conserva
El Full Site Editing no elimina WordPress: reorganiza cómo se construye y se entrega un sitio. El modelo clásico dependía de tres capas: PHP para las plantillas, CSS para los estilos y el Personalizador para los ajustes globales. El FSE concentra esas tres capas en dos superficies: el Editor del Sitio y theme.json.
Lo que desaparece: header.php, footer.php, sidebar.php y la lógica de plantillas en PHP. Lo que permanece: el loop de WordPress, los hooks de acción y filtro, y la compatibilidad con plugins existentes. El FSE no rompe el ecosistema; lo reorganiza en torno a abstracciones más declarativas.
Para un freelance que entrega sitios de 5 a 15 páginas, la transición real implica aprender a pensar en partes de plantilla y en patrones en lugar de archivos PHP. Es una curva de aprendizaje de dos a tres semanas para alguien con experiencia en Gutenberg. El mayor cambio no es técnico sino conceptual: pasar de «un archivo por tipo de contenido» a «una jerarquía de bloques con herencia visual».
Los sitios que más se benefician de la transición son los que tienen clientes con necesidades de edición frecuente: páginas de destino, directorios de eventos, tiendas con fichas de producto actualizadas a menudo. Ahí la interfaz del Editor del Sitio entrega un valor concreto que el modelo PHP clásico nunca ofreció de forma nativa.
La anatomía mínima de un tema de bloques: tres archivos
Un tema de bloques válido para WordPress 6.9 requiere exactamente tres archivos:
style.csscon la cabecera del tema (nombre, versión, URI)templates/index.htmlcon el marcado de bloques para la plantilla principaltheme.jsonpara los ajustes globales de tipografía, color y espaciado
Nada más. No hay functions.php obligatorio, no hay subdirectorios de plantillas PHP. Un tema de bloques mínimo ocupa menos de 10 KB antes de añadir estilos personalizados.
En la práctica, los temas de producción añaden templates/single.html, templates/archive.html y parts/header.html para cubrir los casos de uso habituales. Pero el punto de partida es sorprendentemente compacto para quienes vienen del desarrollo clásico.
La recomendación para equipos que migran desde temas clásicos: construir primero el tema mínimo, publicarlo en un entorno de preproducción y verificar que el Editor del Sitio reconoce correctamente las plantillas antes de añadir complejidad. Los problemas de registro de plantillas son más fáciles de diagnosticar con un tema limpio que con uno ya cargado de capas de estilos heredados.
El Editor del Sitio en WordPress 6.9: cinco áreas, una jerarquía
El Editor del Sitio de WordPress 6.9 organiza el trabajo en cinco áreas principales: Plantillas, Partes de plantilla, Patrones, Páginas y Estilos. Cada área tiene su propio alcance y sus propias reglas de herencia.
La jerarquía de plantillas de WordPress sigue vigente: singular.html tiene prioridad sobre single.html, que tiene prioridad sobre index.html. La diferencia respecto al modelo clásico es que ahora se edita visualmente en lugar de escribir PHP. Para un desarrollador con experiencia en la jerarquía de plantillas clásica, la transición mental es relativamente directa.
La interfaz de Estilos es donde la mayoría de los profesionales encuentran la primera fricción real. Los cambios globales de color o tipografía se propagan correctamente, pero las anulaciones de nivel de bloque a veces requieren varias iteraciones para persistir como se espera entre sesiones de edición.
Un detalle práctico que conviene conocer desde el principio: los cambios realizados en el Editor del Sitio se guardan como revisiones en la base de datos, no como modificaciones en los archivos del tema. Esto implica que un despliegue del tema desde Git no anula los cambios del cliente a menos que se limpie explícitamente la tabla wp_posts de revisiones de plantillas. Conviene acordar con el cliente desde el inicio qué partes del sitio gestiona el desarrollador y cuáles gestiona el cliente.
El bloque Query Loop: tu bucle PHP, sin PHP
El bloque Query Loop es la implementación en bloques del loop clásico de WordPress. Consulta la base de datos, itera sobre los resultados y renderiza cada elemento mediante una plantilla de bloque interna definida visualmente en el Editor del Sitio.
Su configuración básica permite: elegir el tipo de contenido, establecer el número de elementos por página, ordenar por fecha o popularidad, y filtrar por categoría, etiqueta o cualquier taxonomía registrada. Para el 80% de los casos de uso de un blog o portfolio, funciona sin ningún código adicional.
Los casos límite aparecen en diseños complejos: relaciones entre tipos de contenido personalizado creados con CPT UI o custom code, metadatos de ACF o Pods que requieren filtros personalizados, y paginación en páginas estáticas que no son la página de blog nativa. En esos escenarios, la capa de PHP sigue siendo necesaria como extensión del bloque mediante filtros como query_vars o pre_get_posts, no como sustituto del bloque.
A la hora de decidir si usar Query Loop o una solución PHP personalizada, la pregunta práctica es esta: ¿el cliente necesita modificar la consulta desde el Editor del Sitio sin intervención técnica? Si la respuesta es sí, Query Loop es el punto de partida correcto aunque requiera filtros PHP adicionales.
theme.json: qué controla y qué delega
theme.json v3, introducido en WordPress 6.7, es el archivo de configuración central de cualquier tema de bloques. Controla tres categorías de ajustes: la paleta de colores globales disponibles en el Editor de Bloques, la escala tipográfica con tamaños y familias de fuentes, y los preajustes de espaciado para márgenes y rellenos.
Lo que theme.json no puede hacer: aplicar estilos condicionales según la sesión del usuario o el tipo de dispositivo, gestionar breakpoints personalizados más allá de los que expone la API de WordPress, o anular los estilos de plugins de terceros que inyectan CSS propio en el <head> sin pasar por la API de bloques.
Un equipo que usa theme.json como fuente única de verdad para los estilos reduce significativamente la fricción entre diseño y desarrollo. El flujo de trabajo recomendado: el diseñador define los tokens de color, tipografía y espaciado en theme.json, el desarrollador extiende con CSS adicional solo donde la API de bloques no llega. Este modelo evita la proliferación de hojas de estilo dispersas registradas desde functions.php que se solapan con los estilos del Editor.
Marginalia: desde WordPress 6.7, theme.json soporta la clave shadow para sombras predefinidas y la clave spacing.blockGap para el espaciado entre bloques dentro de contenedores. Dos adiciones que reducen la necesidad de CSS personalizado en el 30% de los diseños típicos de agencia.
Anulaciones de patrón: estructura fija, contenido modificable
Las Anulaciones de patrón, introducidas en WordPress 6.8 mediante la Block Bindings API con la fuente core/pattern-overrides, resuelven uno de los problemas prácticos más frecuentes en la entrega de sitios a clientes: cómo dar acceso a editar contenido sin arriesgar la integridad del diseño.
El mecanismo funciona así: el desarrollador crea un patrón con la estructura de bloques bloqueada y marca ciertos campos (texto de párrafo, texto alternativo de imagen, URL de enlace) como anulables mediante el atributo metadata.bindings. El cliente edita solo esos campos desde el Editor del Sitio, sin acceso a la estructura subyacente ni a los bloques contenedores.
En la práctica, esto reduce a la mitad el tiempo de formación del cliente y casi elimina los errores de diseño en sitios entregados. Un caso documentado en tres sitios de agencia: el tiempo medio de sesión de formación del cliente pasó de 90 minutos a 40 minutos cuando el sitio usaba patrones con anulaciones en lugar de plantillas PHP clásicas totalmente editables.
Es la característica de FSE con mayor impacto inmediato en el modelo de trabajo de un freelance en 2026. No porque sea tecnológicamente espectacular, sino porque resuelve un problema de entrega real: el equilibrio entre control del diseñador y autonomía del cliente.
Lo que todavía falla en producción
La adopción masiva del FSE no significa que los problemas hayan desaparecido. A continuación, los tres puntos de fricción más frecuentes observados en sitios de producción reales con WordPress 6.8 y 6.9.
Anulaciones de plantillas en la base de datos. Cuando un usuario edita una plantilla desde el Editor del Sitio, WordPress guarda la versión modificada en la base de datos con prioridad sobre el archivo del tema. Esto crea una divergencia difícil de detectar: el archivo del tema dice una cosa, la base de datos dice otra. El síntoma visible es que un despliegue desde Git no produce el cambio esperado en el sitio en vivo. La solución es documentar explícitamente qué plantillas están gestionadas por código y cuáles por el cliente, y añadir una nota en el README del tema.
Brechas en la compatibilidad RTL. El soporte RTL del Editor del Sitio mejoró en WordPress 6.8, pero sigue incompleto para ciertos bloques de terceros que definen sus estilos sin usar las propiedades lógicas CSS (margin-inline-start en lugar de margin-left). Los freelances que trabajan con sitios en árabe o hebreo deben verificar la compatibilidad RTL bloque a bloque antes de la entrega, sin asumir que el tema lo cubre automáticamente.
Profundidad de DOM anidado. Los diseños complejos con múltiples bloques Group y Cover anidados pueden generar estructuras de DOM de 15 a 20 niveles de profundidad. Esto no rompe la funcionalidad, pero impacta el rendimiento de la renderización en dispositivos de gama baja y complica la depuración con las herramientas del navegador. La recomendación: medir la profundidad del DOM con el panel Elements de DevTools antes de la entrega y aplanar la estructura donde sea posible.
Herramientas FSE que valen tu tiempo
Tres herramientas con impacto real en el trabajo diario con FSE en producción, seleccionadas por su utilidad verificada en proyectos reales.
Create Block Theme (plugin oficial de WordPress.org): exporta un tema de bloques desde el Editor del Sitio como un directorio de archivos listo para versionar en Git. Convierte las ediciones guardadas en la base de datos en archivos de plantilla editables. Esencial para equipos que trabajan con repositorios y ciclos de despliegue definidos.
Theme Check: valida la estructura y los estándares del tema antes de la entrega al cliente. Compatible con temas de bloques desde la versión 2024.1 del plugin. Detecta problemas de cabecera en style.css, referencias a funciones obsoletas y ausencia de plantillas requeridas.
Block Visibility: gestiona la visibilidad de bloques según condiciones (tipo de usuario, dispositivo, fecha de publicación). Cubre el 90% de los casos de personalización de contenido que antes requerían PHP personalizado en functions.php o en un plugin de gestión de roles.
El sitio de producción sigue siendo el mejor banco de pruebas. Un patrón que se comporta perfectamente en una instalación local puede presentar conflictos con un plugin de caché, con una CDN agresiva o con la configuración de hosting en el entorno real del cliente.