WordPress 7.1 AI guidelines and the wp_knowledge custom post type

#Introduction

Greg Ziółkowski’s merge proposal to put a wp_knowledge custom post type and AI Guidelines into WordPress 7.1 sparked a real debate. Creators wanted a standard place to store rules for human writers and AI tools. Critics, including 9seeds owner Jon Brown, said it should live as a plugin first.

Neither change landed. Matt Mullenweg vetoed the Guidelines merge in July. The Classic block hide-from-inserter plan was reversed the same month. WordPress 7.1 Mary Lou shipped on 19 August without wp_knowledge, without Guidelines, and with the Classic block still in the inserter. The rest of this article is the proposal as it stood, plus what to do now that core did not take it. The PHP and React snippets below are a plugin-shaped sketch, not a core API.

#The new wp_knowledge post type and AI Guidelines

The goal of Greg Ziółkowski’s proposal is to define a dedicated section in the core to store website guidelines, brand voices, and content structures. This standardized data under wp_knowledge is intended for:

1. For Writers: Guidelines appear directly in the editor as an editorial checklist, making it easier for new writers to get started.
2. For AI Tools: Artificial intelligence tools (such as content generators) can fetch these rules via REST-API or WP-CLI to align the generated text with the website’s style.

However, some developers argue that the change is premature and prefer a trial run as an independent feature plugin before a final core merge.

#Comparing Guideline Management in WordPress

Here is how storing editorial rules changes:

#Classic block: the phase-out did not happen

A plan to hide the Classic block from the inserter in 7.1 was reversed. Marin Atanasov said the original approach had things largely backward. The block is still there. Do not run a mass conversion because you think 7.1 started a clock.

If you still want to convert Classic (core/freeform) content on your own schedule, here is a WP-CLI pattern and a cleanup filter. Test on a copy of the database first. Replacing the freeform delimiter with a paragraph delimiter is a blunt instrument and will mangle mixed HTML.

Run the following command on the server:

# 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 -->%'"

Additionally, add a utility function in your theme’s functions.php to clean up legacy TinyMCE leftovers:

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

#AEO optimization (Answer Engine Optimization) using wp_knowledge

Implementing a knowledge post type yourself, as a plugin, is still a useful tool for Answer Engine Optimization. It is not a 7.1 core feature. In the era of Perplexity or ChatGPT Search, websites must serve information clearly. Storing official corporate details in a structured post type simplifies generating rich Schema.org metadata.

For example, we can write a filter to include data from wp_knowledge as about or mentions objects in the page’s JSON-LD schema:

<?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>';
        }
    }
}

We can also register custom metadata for 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'
    ]);
}

When AI crawlers index the website, they immediately get a structured, authoritative summary of facts, which increases the brand’s visibility in direct search answers.

More on block deprecation history: The Classic block (also known as core/freeform) was a key component during the transition from legacy TinyMCE to Gutenberg in WordPress 5.0. Over the years, keeping TinyMCE backwards compatible became a major performance drag. Block editor JS files had to load the entire 1MB+ TinyMCE library just in case. Hiding the Classic block would have let core lazy-load those assets. That hide did not ship in 7.1, so do not treat a 40% editor-load claim as a measured 7.1 result.

#Deep dive: E-E-A-T and the role of structured editorial data

The integration of editorial guidelines directly in the WordPress core via wp_knowledge is no coincidence. In 2026, search engines, and especially Google, place unprecedented emphasis on E-E-A-T criteria. Publisher trustworthiness and transparency in content creation are now key ranking factors.

Previously, author boxes or about pages were manually updated. Today, Google’s automated systems search for deeper semantic links. They want to know if there is an editorial policy (editorial policy) and how facts are verified.

wp_knowledge structures this information at the system level. A dedicated post type for ethical standards, expert teams, and research methodologies becomes part of the site’s knowledge graph. SEO plugins can link these rules to authors via the publishingPrinciples attribute in Schema.org. This signals to search engines that the content is the result of a careful editorial process and not blindly generated by an AI.

Additionally, Answer Engines construct direct relationships between distinct entities. Linking authors, editorial processes, and validated content via structured JSON-LD dramatically boosts the trust score of the entire site in AI search models.

#Practical integration of wp_knowledge into publication workflows

To automate quality control in a B2B agency, developers can use the following PHP filter to validate posts against the wp_knowledge guidelines before publication:

<?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.');
            }
        }
    }
}

React Sidebar Component for Gutenberg editor:

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('best') || content.includes('guarantee')) {
                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 });

And the complete PHP plugin file structure for registering the post type:

<?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(); });

More on block deprecation history: The Classic block (also known as core/freeform) was a key component during the transition from legacy TinyMCE to Gutenberg in WordPress 5.0. Over the years, keeping TinyMCE backwards compatible became a major performance drag. Block editor JS files had to load the entire 1MB+ TinyMCE library just in case. Hiding the Classic block would have let core lazy-load those assets. That hide did not ship in 7.1, so do not treat a 40% editor-load claim as a measured 7.1 result.

#Technical guide: Gutenberg block validation API and handling deprecations in React

The Classic block is not being removed in 7.2 on the strength of this cycle. Block deprecation schemas still matter for your own blocks. Here is how Gutenberg matches saved HTML to a save() function, which is useful whether or not core ever hides core/freeform.

#1. Gutenberg Block Validation API under the Hood

When a post loads in the Gutenberg block editor, the JS engine parses the saved HTML comments in wp_posts.post_content. It executes the block’s current save() function and compares the generated output against the raw HTML string stored in the database.

If the database contains:

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

But the block’s current implementation outputs new-class, a validation error occurs. Gutenberg prompts the user with a warning about block corruption and provides conversion buttons.

#2. Re-registering Legacy Block Structures in React (Deprecations)

To prevent block validation errors, register previous versions of the block in the deprecated configuration array. Gutenberg will attempt to match these schemas in order if the primary validation fails:

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. Programmatic Block Parsing in PHP (parse_blocks)

At the server level, WordPress uses parse_blocks() to deserialize the post content back into a structured array of block objects. The parser reads block delimiters, decodes attribute JSON payloads, and returns a hierarchical tree:

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

This architecture keeps B2B client sites highly performant, stable, and easily maintainable when performing massive block-level migrations.

#Design sketch: a multi-desk knowledge store you would build yourself

wp_knowledge is not in 7.1. If you need structured editorial rules for humans and agents, you register your own post type in a plugin. The sketch below is that plugin shape. It is not a client case study and it is not a core API.

Newsrooms that already keep style rules in PDFs still have the same problem they had before 7.1: editors check drafts by hand, and external generators have no official place to read the rules.

#A plugin-shaped workflow:

1. Structured Knowledge Nodes: We defined specific wp_knowledge custom posts containing editorial guidelines for different desks (news, finance, sports). These rules were stored as structured JSON schema payloads.
2. REST API Distribution for AI Tools: We exposed a secure REST API endpoint, allowing external content generation pipelines to fetch localized formatting constraints dynamically:

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

3. Real-Time Gutenberg Sidebar Auditor: We developed a React component in the block editor sidebar. It subscribed to document changes and automatically highlighted any vocabulary or phrasing that violated the active desk guidelines.
4. Programmatic WP-CLI Quality Checks: We deployed a cron script using WP-CLI to audit published posts against guidelines and flag exceptions for senior editor review.

None of that requires a core post type. It requires a plugin you own, with permissions and a REST surface you can version. That is the outcome the veto pointed at: prove adoption outside core first.

#Expert Opinion & B2B Strategy: The Role of wp_knowledge in the AI-Optimisation (AEO) Era

A native wp_knowledge post type in core would have been a useful step for the AI era. It is not in 7.1. The veto left the work in Gutenberg and at Automattic. As search behavior shifts from traditional query links to Answer Engines (such as Perplexity, Claude, and Gemini), the discipline of SEO is evolving into Answer Engine Optimisation (AEO).

Enterprise B2B developers and publishers can no longer write copy solely for human readability or basic keyword indexers. They must deliver structured, verifiable, and machine-readable data payloads that AI models can consume to construct accurate answers.

#Why wp_knowledge is a crucial for B2B site visibility:

1. EEAT Verification (Trust Signals): Answer engines favor highly transparent and authoritative sources. Storing editorial policies, expert bios, and verification workflows in wp_knowledge allows AI bots to parse and tie these files to active authors.
2. Schema.org Principles Integration: Data points from wp_knowledge can be automatically mapped by SEO tools to advanced Schema.org fields (such as publishingPrinciples or editorialGuidelines). This signals a high-quality editorial pipeline to AI crawlers.
3. Do not bank a Core Web Vitals win on Classic block deprecation. That hide did not ship. If you want TinyMCE off the editor path, that is still your plugin and theme work, not a 7.1 free lunch.

If you need structured guidelines on a client site, register your own post type. Do not wait for core to reverse the veto.

#Checklist after WordPress 7.1

1. Do not mass-convert Classic blocks because of this release. The inserter still offers them.
2. Audit Classic usage only when you next touch that content, so you know the debt.
3. Do not look for wp_knowledge on a 7.1 site. It is not there. If you need the storage, ship a plugin.
4. Test the iframed post editor, which did ship. Custom blocks that assume a global document will break. See the iframed editor note.
5. Keep Guidelines in Gutenberg if you already use the experiment. Do not promise clients a core settings screen.

#Summary

WordPress 7.1 Mary Lou shipped without wp_knowledge and without Guidelines. The merge was vetoed. The Classic block is still in the inserter. The useful 7.1 work for agencies is elsewhere: responsive styling, client-side media, and the always-iframed editor. If you still want structured editorial rules for agents, build the plugin. Do not write it into a 7.1 upgrade plan as if core took it.