WordPress 7.1: directrices de IA y el nuevo tipo de contenido wp_knowledge

#Introducción

La propuesta de fusión de Greg Ziółkowski para meter un tipo de contenido wp_knowledge y directrices de IA en WordPress 7.1 generó un debate real. Las redacciones querían un lugar estándar para reglas de redactores y herramientas de IA. Los críticos, entre ellos Jon Brown de 9seeds, dijeron que debía vivir primero como plugin.

Ningún cambio aterrizó. Matt Mullenweg vetó la fusión de Guidelines en julio. El plan de ocultar el bloque Clásico del insertador se revirtió el mismo mes. WordPress 7.1 Mary Lou se publicó el 19 de agosto sin wp_knowledge, sin Guidelines y con el bloque Clásico todavía en el insertador. El resto de este artículo es la propuesta tal como estaba, más qué hacer ahora que el núcleo no la aceptó. Los fragmentos PHP y React de abajo son un bosquejo de plugin, no una API de núcleo.

#El nuevo tipo de contenido wp_knowledge y directrices de IA

El objetivo de la propuesta de Greg Ziółkowski es una sección dedicada en el núcleo para directrices del sitio, voz de marca y estructuras de contenido. Estos datos estandarizados bajo wp_knowledge están pensados para:

1. Para redactores: las directrices aparecen directamente en el editor como lista de comprobación editorial, para que los autores nuevos arranquen más rápido.
2. Para herramientas de IA: los generadores de contenido pueden obtener estas reglas vía REST-API o WP-CLI y alinear el texto generado con el estilo del sitio.

Algunos desarrolladores consideran el cambio prematuro y prefieren una prueba como feature plugin antes de cualquier fusión definitiva en el núcleo.

#Comparativa de la gestión de directrices en WordPress

Así cambia el almacenamiento de las reglas editoriales:

#Bloque Clásico: la retirada no ocurrió

Un plan para ocultar el bloque Clásico del insertador en 7.1 se revirtió. Marin Atanasov dijo que el enfoque original tenía las cosas en gran medida al revés. El bloque sigue ahí. No ejecute una conversión masiva solo porque crea que 7.1 arrancó un reloj.

Si aun así quiere convertir contenido Clásico (core/freeform) a su ritmo, aquí hay un patrón WP-CLI y un filtro de limpieza. Pruebe en una copia de la base de datos. Sustituir el delimitador freeform por un delimitador de párrafo es un instrumento tosco y destroza HTML mixto.

Ejecute el siguiente comando en el servidor:

# Find and convert classic editor block to paragraph blocks
wp db query "UPDATE wp_posts SET post_content = REPLACE(post_content, '<!-- wp:freeform -->', '<!-- wp:paragraph -->') WHERE post_content LIKE '%<!-- wp:freeform -->%'"

Además, una función auxiliar en el functions.php del tema para limpiar restos de TinyMCE:

<?php
/**
 * Fallback and clean-up utility for legacy Classic block outputs
 */
function wppoland_clean_legacy_classic_blocks($content) {
    if (has_block('core/freeform', $content)) {
        $content = str_replace('<!-- wp:freeform -->', '<!-- wp:paragraph -->', $content);
        $content = str_replace('<!-- /wp:freeform -->', '<!-- /wp:paragraph -->', $content);
    }
    return $content;
}
add_filter('the_content', 'wppoland_clean_legacy_classic_blocks', 9);

#Optimización AEO (Answer Engine Optimization) con wp_knowledge

Implementar un tipo de contenido de conocimiento por su cuenta, como plugin, sigue siendo una herramienta útil para Answer Engine Optimization. No es una función de núcleo de 7.1. En la era de Perplexity o ChatGPT Search, los sitios deben servir información con claridad. Guardar datos oficiales de la empresa en un tipo de contenido estructurado simplifica la generación de metadatos Schema.org.

Por ejemplo, un filtro que añade datos de wp_knowledge como objetos about o mentions en el JSON-LD de la página:

<?php
// Automatically append wp_knowledge metadata to JSON-LD schema
add_action('wp_head', 'wppoland_append_knowledge_schema');
function wppoland_append_knowledge_schema() {
    if (is_single()) {
        $knowledge = get_posts(['post_type' => 'wp_knowledge', 'numberposts' => 1]);
        if (!empty($knowledge)) {
            $schema = [
                "@context" => "https://schema.org",
                "@type" => "CreativeWork",
                "about" => [
                    "@type" => "Thing",
                    "name" => $knowledge[0]->post_title,
                    "description" => $knowledge[0]->post_excerpt
                ]
            ];
            echo '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_SLASHES) . '</script>';
        }
    }
}

También se pueden registrar metadatos personalizados para wp_knowledge:

<?php
add_action('init', 'wppoland_register_knowledge_meta');
function wppoland_register_knowledge_meta() {
    register_post_meta('wp_knowledge', 'wikidata_qid', [
        'show_in_rest' => true,
        'single' => true,
        'type' => 'string',
        'sanitize_callback' => 'sanitize_text_field'
    ]);
}

Cuando los crawlers de IA indexan el sitio, reciben de inmediato un resumen estructurado y autoritativo de los hechos. Eso aumenta la visibilidad de la marca en las respuestas directas.

Más sobre la historia de la deprecación de bloques: el bloque Clásico (también conocido como core/freeform) fue una pieza clave en la transición de TinyMCE a Gutenberg en WordPress 5.0. Con los años, mantener TinyMCE compatible se convirtió en un freno de rendimiento. Los archivos JS del editor de bloques tenían que cargar toda la biblioteca TinyMCE (más de 1 MB) por si acaso. Ocultar el bloque Clásico habría permitido al núcleo cargar esos recursos de forma diferida. Esa ocultación no se publicó en 7.1, así que no trate una afirmación del 40% en la carga del editor como un resultado medido de 7.1.

#Análisis profundo: E-E-A-T y el papel de los datos editoriales estructurados

Integrar directrices editoriales directamente en el núcleo de WordPress mediante wp_knowledge no es casualidad. En 2026, los buscadores, sobre todo Google, dan un peso sin precedentes a los criterios E-E-A-T. La credibilidad del editor y la transparencia en la creación de contenidos son factores de posicionamiento.

Antes se actualizaban a mano las cajas de autor o las páginas «Sobre nosotros». Hoy los sistemas automatizados de Google buscan vínculos semánticos más profundos. Quieren saber si hay una política editorial y cómo se verifican los hechos.

wp_knowledge estructura esta información a nivel de sistema. Un tipo de contenido dedicado a normas éticas, equipos de expertos y metodologías de investigación pasa a formar parte del grafo de conocimiento del sitio. Los plugins de SEO pueden vincular estas reglas a los autores mediante el atributo publishingPrinciples en Schema.org. Eso señala a los buscadores que el contenido es resultado de un proceso editorial, no de una generación ciega por IA.

Los motores de respuesta también construyen relaciones directas entre entidades. Vincular autores, procesos editoriales y contenido validado mediante JSON-LD estructurado eleva el trust score de todo el sitio en los modelos de búsqueda con IA.

#Integración práctica de wp_knowledge en el flujo de publicación

Para automatizar el control de calidad en una agencia B2B, los desarrolladores pueden usar el siguiente filtro PHP para validar artículos frente a las directrices wp_knowledge antes de la publicación:

<?php
add_action('transition_post_status', 'wppoland_enforce_knowledge_rules', 10, 3);
function wppoland_enforce_knowledge_rules($new_status, $old_status, $post) {
    if ($new_status === 'publish' && $post->post_type === 'post') {
        $rules = get_posts(['post_type' => 'wp_knowledge', 's' => 'brand-voice']);
        if (!empty($rules)) {
            $excerpt = $rules[0]->post_excerpt;
            if (!empty($excerpt) && strpos($post->post_content, $excerpt) === false) {
                wp_update_post(['ID' => $post->ID, 'post_status' => 'draft']);
                wp_die('Error: The post content does not contain the mandatory brand voice excerpt.');
            }
        }
    }
}

Componente React de la barra lateral en el editor Gutenberg:

import { registerPlugin } from '@wordpress/plugins';
import { PluginSidebar } from '@wordpress/edit-post';
import { useState, useEffect } from '@wordpress/element';
import { select } from '@wordpress/data';

const BrandVoiceValidator = () => {
    const [status, setStatus] = useState('Checking...');
    useEffect(() => {
        const unsubscribe = select('core/editor').subscribe(() => {
            const content = select('core/editor').getEditedPostContent();
            if (content.includes('mejor') || content.includes('garantía')) {
                setStatus('Warning: Violates brand guidelines.');
            } else {
                setStatus('Compliant: Tone of voice matches guidelines.');
            }
        });
        return () => unsubscribe();
    }, []);
    return (
        <PluginSidebar name="brand-voice-sidebar" title="Brand Voice" icon="admin-users">
            <div style={{ padding: '16px' }}>
                <h4>Guideline Validation</h4>
                <p>{status}</p>
            </div>
        </PluginSidebar>
    );
};
registerPlugin('brand-voice-validator', { render: BrandVoiceValidator });

Y la estructura completa del archivo PHP del plugin para registrar el tipo de contenido:

<?php
/**
 * Plugin Name: WPPoland Custom Knowledge Base and AI Guidelines
 * Description: Registers the wp_knowledge custom post type
 * Version: 1.0.0
 */

namespace WPPoland\Knowledge;

class KnowledgeBasePlugin {
    private static $instance = null;
    public static function get_instance() { 
        if (null === self::$instance) { self::$instance = new self(); }
        return self::$instance;
    }
    private function __construct() {
        add_action('init', [$this, 'register_post_type']);
    }
    public function register_post_type() {
        register_post_type('wp_knowledge', [
            'public' => true,
            'label'  => 'Knowledge',
            'show_in_rest' => true,
            'supports' => ['title', 'editor', 'excerpt']
        ]);
    }
}
add_action('plugins_loaded', function() { KnowledgeBasePlugin::get_instance(); });

Más sobre la historia de la deprecación de bloques: el bloque Clásico (también conocido como core/freeform) fue una pieza clave en la transición de TinyMCE a Gutenberg en WordPress 5.0. Con los años, mantener TinyMCE compatible se convirtió en un freno de rendimiento. Los archivos JS del editor de bloques tenían que cargar toda la biblioteca TinyMCE (más de 1 MB) por si acaso. Ocultar el bloque Clásico habría permitido al núcleo cargar esos recursos de forma diferida. Esa ocultación no se publicó en 7.1, así que no trate una afirmación del 40% en la carga del editor como un resultado medido de 7.1.

#Guía técnica: API de validación de bloques de Gutenberg y deprecaciones en React

El bloque Clásico no se elimina en 7.2 por la fuerza de este ciclo. Los esquemas de deprecación de bloques siguen importando para sus propios bloques. Así es como Gutenberg compara el HTML guardado con una función save(), tanto si el núcleo oculta core/freeform alguna vez como si no.

#1. API de validación de bloques de Gutenberg por debajo

Cuando una entrada carga en el editor de bloques, el motor JS analiza los comentarios HTML guardados en wp_posts.post_content. Ejecuta la función save() actual del bloque y compara el resultado generado con el HTML en bruto de la base de datos.

Si la base de datos contiene:

<!-- wp:wppoland/custom-block -->
<div class="wp-block-wppoland-custom-block legacy-class">Content</div>
<!-- /wp:wppoland/custom-block -->

pero la implementación actual del bloque devuelve new-class, ocurre un error de validación. Gutenberg avisa de corrupción del bloque y ofrece botones de conversión.

#2. Volver a registrar estructuras antiguas del bloque en React (deprecations)

Para evitar errores de validación, registre versiones anteriores del bloque en el array deprecated. Gutenberg intenta coincidir con estos esquemas en orden si falla la validación principal:

import { registerBlockType } from '@wordpress/blocks';

registerBlockType( 'wppoland/custom-block', {
    title: 'Custom Block',
    attributes: {
        content: { type: 'string', source: 'html', selector: 'div' }
    },
    edit: ( { attributes } ) => <div className="new-class">{ attributes.content }</div>,
    save: ( { attributes } ) => <div className="new-class">{ attributes.content }</div>,
    deprecated: [
        {
            attributes: {
                content: { type: 'string', source: 'html', selector: 'div' }
            },
            save( { attributes } ) {
                return <div className="legacy-class">{ attributes.content }</div>;
            }
        }
    ]
} );

#3. Análisis programático de bloques en PHP (parse_blocks)

En el servidor, WordPress usa parse_blocks() para deserializar el contenido de la entrada de vuelta a un array estructurado de objetos de bloque. El analizador lee delimitadores, decodifica JSON de atributos y devuelve un árbol:

<?php
$blocks = parse_blocks( get_post( 123 )->post_content );
foreach ( $blocks as $block ) {
    if ( $block['blockName'] === 'wppoland/custom-block' ) {
        $content = $block['attrs']['content'] ?? "";
    }
}

Esta arquitectura mantiene los sitios de clientes B2B rápidos, estables y fáciles de mantener en migraciones grandes a nivel de bloques.

#Bosquejo de diseño: un almacén de conocimiento multi-redacción que usted construye

wp_knowledge no está en 7.1. Si necesita reglas editoriales estructuradas para humanos y agentes, registra su propio tipo de contenido en un plugin. El bosquejo de abajo es esa forma de plugin. No es un caso de cliente y no es una API de núcleo.

Las redacciones que ya guardan reglas de estilo en PDF siguen con el mismo problema de antes de 7.1: los editores revisan borradores a mano, y los generadores externos no tienen un lugar oficial del que leer las reglas.

#Un flujo con forma de plugin:

1. Nodos de conocimiento estructurados: definimos entradas wp_knowledge concretas con directrices editoriales para distintas mesas (noticias, finanzas, deportes). Las reglas estaban como payloads de JSON schema.
2. Distribución REST API para herramientas de IA: expusimos un endpoint REST seguro, para que pipelines externos de generación de contenido obtengan restricciones de formato localizadas de forma dinámica:

   curl -H "Authorization: Bearer [TOKEN]" https://portal.wppoland.dev/wp-json/wp/v2/wp_knowledge?category=brand-voice

3. Auditor en tiempo real en la barra lateral de Gutenberg: un componente React en la barra lateral del editor se suscribía a los cambios del documento y resaltaba vocabulario o frases que violaban las directrices activas de la mesa.
4. Controles de calidad programáticos con WP-CLI: un script cron con WP-CLI auditaba entradas publicadas frente a las directrices y marcaba excepciones para revisión de editores sénior.

Nada de eso exige un tipo de contenido en el núcleo. Exige un plugin suyo, con permisos y una superficie REST que pueda versionar. Ese fue el resultado al que apuntó el veto: pruebe adopción fuera del núcleo primero.

#Opinión experta y estrategia B2B: el papel de wp_knowledge en la era AEO

Un tipo de contenido nativo wp_knowledge en el núcleo habría sido un paso útil para la era de la IA. No está en 7.1. El veto dejó el trabajo en Gutenberg y en Automattic. A medida que el comportamiento de búsqueda pasa de enlaces clásicos a motores de respuesta (Perplexity, Claude, Gemini), la disciplina de SEO evoluciona hacia Answer Engine Optimisation (AEO).

Los desarrolladores y editores B2B ya no pueden escribir solo para legibilidad humana o indexadores básicos de palabras clave. Deben entregar payloads estructurados, verificables y legibles por máquina, para que los modelos de IA construyan respuestas precisas.

#Por qué wp_knowledge cuenta para la visibilidad B2B:

1. Verificación E-E-A-T (señales de confianza): los motores de respuesta favorecen fuentes transparentes y autoritativas. Guardar políticas editoriales, biografías de expertos y flujos de verificación en wp_knowledge permite a los bots de IA vincular esos archivos con autores activos.
2. Integración de principios Schema.org: los puntos de datos de wp_knowledge pueden mapearse automáticamente por herramientas de SEO a campos Schema.org (como publishingPrinciples o editorialGuidelines). Eso señala un pipeline editorial controlado a los crawlers de IA.
3. No cuente con una ganancia de Core Web Vitals por la deprecación del bloque Clásico. Esa ocultación no se publicó. Si quiere TinyMCE fuera de la ruta del editor, eso sigue siendo trabajo suyo en el plugin y el tema, no un almuerzo gratis de 7.1.

Si necesita directrices estructuradas en un sitio de cliente, registre su propio tipo de contenido. No espere a que el núcleo revierta el veto.

#Lista de comprobación después de WordPress 7.1

1. No convierta en masa bloques Clásicos por esta versión. El insertador sigue ofreciéndolos.
2. Audite el uso de Clásico solo cuando vuelva a tocar ese contenido, para conocer la deuda.
3. No busque wp_knowledge en un sitio 7.1. No está ahí. Si necesita el almacenamiento, publique un plugin.
4. Pruebe el editor de entradas en iframe, que sí se publicó. Los bloques propios que asumen un document global se romperán. Vea la nota sobre el editor en iframe.
5. Mantenga Guidelines en Gutenberg si ya usa el experimento. No prometa a los clientes una pantalla de ajustes en el núcleo.

#Resumen

WordPress 7.1 Mary Lou se publicó sin wp_knowledge y sin Guidelines. La fusión se vetó. El bloque Clásico sigue en el insertador. El trabajo útil de 7.1 para agencias está en otro sitio: estilos responsivos, media en el cliente y el editor siempre en iframe. Si aún quiere reglas editoriales estructuradas para agentes, construya el plugin. No lo escriba en un plan de actualización 7.1 como si el núcleo lo hubiera aceptado.