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.

#Qué es el tipo de contenido wp_knowledge en WordPress

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: el propietario del sitio escribe las normas una vez, en la página Directrices dentro de Ajustes, y los redactores nuevos las leen en un solo lugar en vez de en un PDF.
2. Para herramientas de IA: cualquier herramienta con los permisos adecuados puede leer estos registros a través de la REST API y alinear el texto generado con el estilo del sitio. La propuesta no trae proveedor de IA, modelo ni algoritmo de recuperación propios.

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

#En qué se diferencia wp_knowledge de las directrices tradicionales

Así cambia el almacenamiento de las reglas editoriales:

#Qué definía la propuesta de fusión para wp_knowledge

La propuesta de fusión describe Knowledge como «una primitiva general para guardar conocimiento del sitio, orientado a autores y a agentes, como contenido estándar de WordPress» (Greg Ziółkowski, traducción propia). Usa piezas que WordPress ya tiene: un tipo de contenido personalizado, una taxonomía, roles y capacidades, revisiones y REST. El código experimental en Gutenberg coincide con la propuesta:

• El tipo de contenido wp_knowledge se registra con public en false y sin pantallas propias en el escritorio. Los registros nunca aparecen en consultas del front-end.
• La taxonomía wp_knowledge_type indica qué es un registro. El núcleo define tres tipos: guideline (una norma que es la fuente de verdad), memory (contexto duradero que un usuario guardó o aprobó) y note (texto de trabajo privado). Un registro guardado sin tipo pasa a note. Los plugins añaden tipos con el filtro wp_knowledge_types.
• La pantalla Directrices se construye a partir de ámbitos: Site, Copy, Images y Blocks. Cada ámbito es un registro guideline con un slug reservado, por ejemplo guideline-copy, y los plugins pueden registrar más.
• La REST vive en /wp/v2/knowledge, con un registro de solo lectura en /wp/v2/knowledge/guideline-scopes. Leer colecciones exige autenticación.
• Los registros nuevos son privados (private) por defecto. Las revisiones se conservan y el autoguardado está desactivado, porque los registros no tienen sesión de editor.

Las capacidades siguen el espacio de nombres *_knowledge_items. La política de acceso del PR 78296 de Gutenberg, tal como la recoge la propuesta:

La propia pantalla Directrices sigue exigiendo manage_options. Como nada en wp_knowledge es público, un crawler nunca lo ve. Un enlace publishingPrinciples en tu schema tiene que apuntar a una página pública.

#Cómo pasaron las Directrices de Gutenberg 22.7 a una fusión vetada

El nombre y el almacenamiento cambiaron dos veces antes del veto. Las Directrices llegaron como experimento en Gutenberg 22.7, descritas el 23 de marzo de 2026 por Aagam Shah. Se activaban en Gutenberg, Experimentos, y en Ajustes aparecía una página Directrices con secciones Site, Copy, Images, Blocks y Additional, más exportación a guidelines.json, importación e historial de revisiones. El almacenamiento era un tipo de contenido llamado wp_content_guideline, con cada categoría en metadatos de la entrada y REST en /wp/v2/content-guidelines. La publicación dice que Directrices «se centra a propósito en la captura y la consulta» (Aagam Shah, traducción propia) y no aplica reglas ni genera contenido.

El 22 de junio, Greg Ziółkowski publicó la propuesta de fusión para 7.1, con el parche del núcleo en el PR 12201 de wordpress-develop (ticket de Trac 65476). El PR 79149 de Gutenberg, fusionado el 29 de junio, renombró el almacenamiento a wp_knowledge. El 10 de julio, Anne McCarthy publicó la decisión en los comentarios tras una revisión con Matt Mullenweg: el trabajo no seguiría adelante en 7.1, y el núcleo no debe incorporar cosas «que no estén ya impulsadas por una adopción real con un crecimiento impresionante de semana a semana (piense en dos dígitos)» (Anne McCarthy, traducción propia). La Beta 1 salió el 15 de julio.

Lo que vino después está en GitHub. Ziółkowski abrió el PR 949 de WordPress/ai el 18 de agosto para llevar el experimento al plugin de IA. Lo cerró sin fusionar el 1 de octubre, después de que los mantenedores dijeran que los experimentos del plugin de IA deben apoyarse en los experimentos de Gutenberg en lugar de duplicarlos. A 14 de octubre de 2026, el PR 12201 sigue abierto y el wp-includes/post.php de la rama 7.1 no contiene wp_knowledge. La función solo existe detrás de la opción de experimento de Gutenberg.

#WordPress 7.1 elimina el bloque Clásico

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 ejecutes una conversión masiva solo porque creas que 7.1 arrancó un reloj. Fuente: publicación de Marin Atanasov del 7 de julio.

Si aun así quieres convertir contenido Clásico (core/freeform) a tu ritmo, aquí hay un patrón WP-CLI y un filtro de limpieza. Prueba 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.

Ejecuta 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);

#Qué sustituye a la ocultación del bloque Clásico en el núcleo de WordPress

La publicación del 7 de julio dice que la ocultación no acercó el proyecto a dejar de cargar TinyMCE y fija el principio de que «el bloque Clásico debe quedar obsoleto por elección, no por la fuerza» (Marin Atanasov, traducción propia). También retiró el aviso de deprecación a nivel de bloque, devolvió la acción «Convertir en bloques» a la barra de herramientas y eliminó el filtro wp_classic_block_supports_inserter, que nunca salió en una versión estable. El plugin Enable Classic Block se va a cerrar, así que puedes desactivarlo.

La publicación enumera el trabajo que sustituye a la ocultación:

• entender por qué la gente sigue dependiendo del Clásico y cerrar esas carencias,
• hacer fiable «Convertir en bloques», que todavía tiene fallos e incoherencias,
• crear mejores herramientas de conversión y migración, incluida la migración masiva,
• mejorar el registro de los recursos de TinyMCE y permitir desactivarlos,
• dar a los plugins una forma de declarar una dependencia explícita de TinyMCE,
• explorar la carga de TinyMCE bajo demanda o de forma asíncrona,
• dejar de cargar TinyMCE en el editor de bloques cuando el bloque Clásico está desactivado en el gestor de bloques.

Puedes comprobar el estado de 7.1 en el código: el block.json de core/freeform en la rama 7.1 no tiene la opción inserter: false. El último punto de la lista es trabajo futuro, así que no cuentes con que desactivar el bloque Clásico en el gestor de bloques quite TinyMCE del editor de 7.1.

#Cómo añadir datos de wp_knowledge al schema JSON-LD

Implementar un tipo de contenido de conocimiento por tu 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 wppoland_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' => 'wppoland_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('wppoland_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.

#Cómo la política editorial en Schema.org refuerza el E-E-A-T

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. Como los registros propuestos son privados, ese enlace tiene que apuntar a una página pública que publique la misma política. 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.

#Cómo validar entradas con las reglas de wp_knowledge antes de publicar

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' => 'wppoland_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 wppoland_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('wppoland_knowledge', [
            'public' => true,
            'label'  => 'Knowledge',
            'show_in_rest' => true,
            'supports' => ['title', 'editor', 'excerpt']
        ]);
    }
}
add_action('plugins_loaded', function() { KnowledgeBasePlugin::get_instance(); });

#Cómo funcionan la validación de bloques y las deprecaciones en Gutenberg

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 tus 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, registra 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.

#Cómo construir un plugin wp_knowledge para varias redacciones

wp_knowledge no está en 7.1. Si necesitas reglas editoriales estructuradas para humanos y agentes, registra tu 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.

El prefijo importa. El manual de plugins sobre tipos de contenido personalizados dice: «Para garantizar la compatibilidad futura, no use wp_ como identificador» (WordPress Plugin Handbook, traducción propia). El experimento de Gutenberg solo registra wp_knowledge si ese tipo de contenido aún no existe. Un plugin que ocupe el nombre antes sustituye un almacén privado por los ajustes que haya elegido, incluido public en true. Por eso el bosquejo de abajo usa wppoland_knowledge.

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 wppoland_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/wppoland_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 tuyo, con permisos y una superficie REST que puedas versionar. Ese fue el resultado al que apuntó el veto: prueba adopción fuera del núcleo primero.

#Ayuda wp_knowledge al AEO de sitios B2B

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 como experimento en Gutenberg. 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é las directrices estructuradas cuentan para la visibilidad B2B

1. Verificación E-E-A-T (señales de confianza): los motores de respuesta favorecen fuentes transparentes y autoritativas. Las políticas editoriales, las biografías de expertos y los flujos de verificación solo ayudan cuando están en páginas públicas que los bots de IA pueden vincular con autores activos. Los registros del almacén wp_knowledge propuesto son privados, así que alimentarían tus propias herramientas, no a los crawlers.
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 (la propiedad publishingPrinciples). Eso señala un pipeline editorial controlado a los crawlers de IA.
3. No cuentes con una ganancia de Core Web Vitals por la deprecación del bloque Clásico. Esa ocultación no se publicó. Si quieres TinyMCE fuera de la ruta del editor, eso sigue siendo trabajo tuyo en el plugin y el tema, no un almuerzo gratis de 7.1.

Si necesitas directrices estructuradas en un sitio de cliente, registra tu propio tipo de contenido. No esperes a que el núcleo revierta el veto.

#Qué hacer después de actualizar a WordPress 7.1

1. No conviertas en masa bloques Clásicos por esta versión. El insertador sigue ofreciéndolos.
2. Audita el uso de Clásico solo cuando vuelvas a tocar ese contenido, para conocer la deuda.
3. No busques wp_knowledge en un sitio 7.1. No está ahí. Si necesitas el almacenamiento, publica un plugin.
4. Prueba el editor de entradas en iframe, que sí se publicó. Los bloques propios que asumen un document global se romperán. Lee la nota sobre el editor en iframe.
5. Mantén Guidelines en Gutenberg si ya usas el experimento. No prometas 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 quieres reglas editoriales estructuradas para agentes, construye el plugin. No lo escribas en un plan de actualización 7.1 como si el núcleo lo hubiera aceptado.