Ponele que le pedís a Claude que te arme una landing en HTML, te la genera divina, la pegás en el editor de WordPress y Gutenberg te tira el cartel amarillo de «este bloque contiene contenido inesperado». Convertir HTML a bloques WordPress a mano es una de esas tareas ingratas que cualquiera que automatizó contenido conoce. Block Runner ataca justo ese dolor: es una herramienta de línea de comandos de Human Made que toma HTML generado por IA, agentes o herramientas de diseño y lo transforma en bloques nativos válidos, probados contra Gutenberg headless.
Block Runner es una CLI open source (alojada en github.com/humanmade/block-runner) que convierte HTML en bloques nativos de WordPress anidados, o valida los bloques que ya tenés. La diferencia con cualquier convertidor anterior: cada resultado se prueba contra una instancia headless de Gutenberg, sin un LLM en el medio. Si dice «editor-valid · 0 invalid blocks», es porque el propio editor lo aceptó.
En 30 segundos
- Qué es: Block Runner, una CLI de Human Made que pasa HTML a bloques WordPress válidos o valida los existentes.
- Cómo prueba la validez: contra Gutenberg headless real, no contra otra IA. Determinista y reproducible.
- Dónde corre: terminal, GitHub Actions, GitLab CI, CircleCI y pre-commit hooks.
- Qué genera: bloques nativos anidados como wp:cover > wp:columns > wp:buttons, con attachment IDs reales de las imágenes.
- Requisitos: corre por línea de comandos. Cualquier modelo, cualquier proveedor en la entrada.
Claude es un modelo de lenguaje grande desarrollado por Anthropic que genera texto, responde preguntas y asiste en tareas de programación, análisis y escritura. Lanzado en 2023, se utiliza como asistente de IA en diversas aplicaciones y plataformas.
¿Por qué validar bloques antes de publicar te ahorra el cartel amarillo?
Si alguna vez pegaste HTML ajeno en el editor de bloques, ya sabés lo que pasa. Gutenberg no guarda HTML suelto: guarda bloques con una estructura de comentarios específica (<!-- wp:cover --> y compañía) y atributos en JSON. Cuando el markup no coincide con lo que el bloque espera, el editor lo marca como inválido y te ofrece «convertir a HTML» o «recuperar». Spoiler: ninguna de las dos opciones es lo que querías.
Acá viene lo bueno: Block Runner se mete como capa de validez. Según la documentación oficial, la herramienta tiene dos usos que comparten el mismo chequeo. Generás bloques nuevos a partir de HTML, o revisás los bloques que ya escribiste. El mismo control de validez corre en los dos casos.
¿Por qué importa para quien automatiza? Porque un pipeline que escupe contenido roto en producción es peor que no tener pipeline. Vos generás cien notas con un modelo, las subís, y si una sola rompe el render no te enterás hasta que un lector (o Google) la encuentra.
¿Cómo funciona la conversión de HTML a bloques nativos?
El flujo es directo. Le pasás un archivo HTML, lo parsea, lo mapea a bloques nativos y resuelve las imágenes a IDs de adjunto reales. El ejemplo de la propia herramienta lo muestra sin vueltas. Esto se conecta con lo que analizamos en comparativa entre Claude y Gemini para desarrollo.
❯ block-runner convert hero.html
reading hero.html … 1 section, 14 nodes
resolving media … 2 images → attachment ids
<!-- wp:cover {"dimRatio":50} -->
<!-- wp:column --> … <!-- /wp:column -->
<!-- wp:buttons --> … <!-- /wp:buttons -->
✓ editor-valid · 0 invalid blocksMirá el detalle que casi nadie resuelve bien: «resolving media … 2 images → attachment ids». No te deja las imágenes como URLs colgadas. Las resuelve a IDs de la biblioteca de medios, que es como WordPress espera referenciarlas en un wp:image o un wp:cover. Eso es lo que diferencia un bloque que cualquiera puede editar después de un bloque que se rompe al primer toque.
El resultado son bloques core planos: wp:cover, wp:columns, wp:buttons, anidados como corresponde. Nada de bloques propietarios que necesiten un plugin específico instalado. Plain core blocks que abrís en cualquier WordPress, venga el HTML del modelo o de la herramienta de diseño que sea.
¿Qué diferencia hay entre generar bloques y validarlos?
Son dos momentos distintos, y conviene no mezclarlos.
- Generar: acá entra el HTML que produce Claude, un agente o una herramienta de diseño. Es la parte creativa y, por definición, impredecible. El modelo puede inventar una estructura distinta cada vez.
- Validar: acá Block Runner prueba ese resultado contra Gutenberg headless. Sin LLM en el loop. Es determinista: el mismo input da el mismo veredicto siempre.
El punto es que la validación no opina ni «mejora» tu contenido. No hay una segunda IA decidiendo si tu bloque está bueno. Hay un editor headless real diciendo «esto lo acepto» o «esto lo rechazo». Esa separación es lo que hace que puedas confiar en el resultado dentro de un pipeline automático.
¿Cómo integro Block Runner en mi flujo de CI/CD?
Funciona donde ya tenés tu automatización. Según la documentación, corre en GitHub Actions, GitLab CI, CircleCI, pre-commit y la propia CLI. Cualquier modelo, cualquier proveedor. Más contexto en temas profesionales generados con Claude.
El caso típico es un pre-commit hook. Antes de que un bloque de contenido entre al repo, Block Runner lo valida; si tira «invalid blocks», el commit no pasa y vos te enterás en tu máquina, no en producción tres días después. La misma lógica aplica en un job de CI: generás contenido en un paso, validás en el siguiente, y solo deployás lo que pasó el control.
Acordate de algo si vas a llevar esto a un sitio real: el contenido validado todavía tiene que vivir en algún lado. Si automatizás generación de notas y las subís por la REST API, asegurate de que tu hosting WordPress como el de Donweb aguante el ritmo de escritura sin tirarte timeouts. La validez del bloque es una cosa; que el origin no se caiga bajo una tanda de saves es otra.
¿Cuáles son los requisitos y cómo lo instalo?
La barrera de entrada es baja. Se usa como CLI desde la terminal. El proyecto está en GitHub bajo humanmade/block-runner y es open source, así que lo podés clonar, auditar y modificar sin pedir permiso a nadie.
Al ser una CLI distribuida vía npm, el patrón habitual es agregarla como dependencia de desarrollo de tu proyecto de contenido y llamarla desde un script. No necesitás un WordPress corriendo al lado para validar, porque el Gutenberg headless viene del lado de la herramienta. Eso es clave para CI: no tenés que levantar un sitio completo solo para chequear un bloque.
¿Qué casos de uso reales resuelve en la práctica?
Esto no es un juguete de demo. Hay flujos concretos donde cambia la vida:
- Agencias que generan con IA: producís bloques con un modelo y los validás antes de entregarle el sitio al cliente, en vez de descubrir el bloque roto en la reunión.
- Pipelines de contenido automático: un blog que publica decenas de notas por semana mete la validación entre la generación y el publish.
- Migración desde herramientas de diseño: exportás HTML de tu tool de diseño y lo convertís a bloques editables, no a un embed inerte.
- Experimentos de optimización autónoma: un agente reescribe una sección, y vos sabés que el bloque resultante sigue siendo válido sin revisarlo a mano.
El cuello de botella de estos flujos no es generar el código, es garantizar que lo generado encaje en el modelo de bloques de WordPress. Justo el hueco que Block Runner tapa. Sobre eso hablamos en estructura del núcleo de WordPress.
¿Cómo se compara con otras soluciones para convertir HTML a bloques?
No es la primera herramienta que toca este tema, pero ataca el problema desde un ángulo distinto. Las otras opciones viven adentro de WordPress; Block Runner vive en tu terminal y tu CI.
| Herramienta | Formato | Dónde corre | Validez |
|---|---|---|---|
| Block Runner | CLI | Terminal, GitHub Actions, GitLab CI, CircleCI, pre-commit | Probada contra Gutenberg headless, sin LLM |
| Convert to Blocks | Plugin WP | Dentro del admin de WordPress | Conversión en el editor |
| WP Block Converter | Programática | En el sitio WordPress | Conversión programática del lado servidor |
| Newspack Content Converter | Plugin WP | Dentro del admin | Migración masiva clásico a bloques |
La diferencia filosófica: Convert to Blocks y los plugins resuelven la conversión cuando ya estás adentro del editor, ideal para un editor humano migrando un post. WP Block Converter es otra opción para convertir del lado del servidor. Block Runner es para el otro mundo: el de la automatización, donde querés el chequeo afuera de WordPress y dentro de tu pipeline. No compiten tanto como cubren etapas distintas.
Errores comunes al automatizar bloques
- Confiar en que el HTML del modelo es válido porque «se ve bien»: que renderice en el navegador no significa que Gutenberg lo acepte. Son dos validadores distintos. Validá siempre antes de publicar.
- Dejar las imágenes como URLs externas: si no resolvés las imágenes a attachment IDs, el bloque queda frágil y la imagen no entra a la biblioteca de medios. Block Runner lo hace, pero si armás tu propio conversor, es el paso que más se olvida.
- Validar solo al final del pipeline: si chequeás recién en producción, el bloque roto ya se publicó. Movelo lo más temprano posible, idealmente a un pre-commit hook.
- Asumir que necesitás un WordPress corriendo para validar: no. El Gutenberg headless viene en la herramienta, así que tu job de CI no tiene que levantar un sitio entero.
Preguntas Frecuentes
¿Qué es Block Runner?
Block Runner es una herramienta de línea de comandos open source de Human Made que convierte HTML generado en bloques nativos de WordPress válidos, o valida bloques existentes. Cada resultado se prueba contra una instancia de Gutenberg headless, sin un modelo de lenguaje en el proceso.
¿Cómo convierto HTML generado en bloques WordPress válidos?
Con el comando block-runner convert archivo.html. La herramienta parsea el HTML, lo mapea a bloques nativos anidados (como wp:cover, wp:columns y wp:buttons), resuelve las imágenes a attachment IDs y confirma con un «editor-valid · 0 invalid blocks» si pasó el chequeo de Gutenberg.
¿Necesito instalar WordPress para usar Block Runner?
No. Es una CLI y el Gutenberg headless contra el que se valida viene del lado de la herramienta, por eso podés correrla en un job de CI sin levantar un sitio WordPress completo. En bloques de contenido dinámico en WooCommerce profundizamos sobre esto.
¿Block Runner es gratis?
Sí. Es open source y está disponible en GitHub como humanmade/block-runner. Podés clonarlo, auditarlo y adaptarlo a tu pipeline sin costo de licencia.
¿Funciona con cualquier modelo de IA?
Sí, es agnóstico al proveedor. Toma HTML venga de Claude, de un agente, de otro modelo o de una herramienta de diseño. La validación no depende de qué generó el HTML, solo de que el resultado sea aceptado por Gutenberg.
Conclusión
Durante años, automatizar contenido para WordPress chocaba siempre con la misma pared: generar HTML es fácil, pero meterlo como bloques válidos sin romper el editor era un dolor de cabeza manual. Block Runner mueve ese chequeo afuera del editor y adentro de tu terminal y tu CI, con una garantía dura: lo prueba contra el propio Gutenberg, no contra otra IA que «cree» que está bien.
Si tenés un pipeline que genera notas con IA, el próximo paso concreto es claro: cloná humanmade/block-runner, agregalo como paso de validación entre la generación y el publish, y arrancá con un pre-commit hook. El día que un modelo te escupa un bloque roto, te vas a enterar en tu máquina y no en la home del sitio.
![[PROMOTION] Wow Elements - Addons for Elementor - ilustracion](https://wordpress.donweb.com/wp-content/uploads/2026/06/wow-elements-addons-elementor-hero.jpg)
