WordPress 7.1: KI-Richtlinien und der neue Inhaltstyp wp_knowledge

#Einführung

Greg Ziółkowskis Merge-Vorschlag, einen Inhaltstyp wp_knowledge und KI-Richtlinien in WordPress 7.1 zu legen, hat eine echte Debatte ausgelöst. Redaktionen wollten einen Standardort für Regeln für Autorinnen, Autoren und KI-Werkzeuge. Kritiker, darunter 9seeds-Inhaber Jon Brown, sagten, das gehöre zuerst in ein Plugin.

Keine der beiden Änderungen ist gelandet. Matt Mullenweg legte im Juli sein Veto gegen den Guidelines-Merge ein. Der Plan, den Classic-Block im Inserter auszublenden, wurde im selben Monat zurückgenommen. WordPress 7.1 Mary Lou erschien am 19. August ohne wp_knowledge, ohne Guidelines und mit dem Classic-Block weiterhin im Inserter. Der Rest dieses Artikels ist der Vorschlag, wie er damals stand, plus was Sie tun, nachdem der Core ihn nicht übernommen hat. Die PHP- und React-Schnipsel unten sind ein Plugin-Entwurf, kein Core-API.

#Der neue Inhaltstyp wp_knowledge und KI-Richtlinien

Ziel von Greg Ziółkowskis Vorschlag ist ein eigener Bereich im Core für Website-Richtlinien, Markenstimmen und Inhaltsstrukturen. Diese standardisierten Daten unter wp_knowledge sind gedacht für:

1. Für Autorinnen und Autoren: Richtlinien erscheinen direkt im Editor als redaktionelle Checkliste. Neue Schreiberinnen und Schreiber kommen schneller rein.
2. Für KI-Werkzeuge: Generatoren können diese Regeln über REST-API oder WP-CLI holen und den erzeugten Text an den Stil der Website anpassen.

Einige Entwickler halten die Änderung für verfrüht und wollen zuerst ein Feature-Plugin, bevor ein endgültiger Core-Merge überhaupt zur Debatte steht.

#Vergleich des Richtlinien-Managements in WordPress

So ändert sich die Speicherung redaktioneller Regeln:

#Classic-Block: die Abschaffung ist nicht erfolgt

Ein Plan, den Classic-Block in 7.1 aus dem Inserter auszublenden, wurde zurückgenommen. Marin Atanasov sagte, der ursprüngliche Ansatz habe die Dinge weitgehend falschherum aufgezogen. Der Block ist noch da. Führen Sie keine Massenkonvertierung durch, nur weil Sie denken, 7.1 habe eine Uhr gestartet.

Wenn Sie Classic-Inhalte (core/freeform) trotzdem in Ihrem eigenen Tempo konvertieren wollen, finden Sie hier ein WP-CLI-Muster und einen Cleanup-Filter. Testen Sie auf einer Kopie der Datenbank. Das Ersetzen des Freeform-Delimiters durch einen Absatz-Delimiter ist ein stumpfes Werkzeug und zerlegt gemischtes HTML.

Führen Sie den folgenden Befehl auf dem Server aus:

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

Zusätzlich eine Hilfsfunktion in der functions.php Ihres Themes, um TinyMCE-Reste zu bereinigen:

<?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-Optimierung (Answer Engine Optimization) mit wp_knowledge

Einen Knowledge-Inhaltstyp selbst als Plugin umzusetzen, bleibt ein nützliches Werkzeug für Answer Engine Optimization. Es ist keine Core-Funktion von 7.1. In der Ära von Perplexity oder ChatGPT Search müssen Websites Informationen klar ausliefern. Offizielle Unternehmensdaten in einem strukturierten Inhaltstyp zu speichern, vereinfacht die Erzeugung von Schema.org-Metadaten.

Zum Beispiel ein Filter, der Daten aus wp_knowledge als about- oder mentions-Objekte in das JSON-LD der Seite legt:

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

Sie können auch eigene Metadaten für wp_knowledge registrieren:

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

Wenn KI-Crawler die Website indexieren, bekommen sie sofort eine strukturierte, autoritative Faktensumme. Das erhöht die Sichtbarkeit der Marke in direkten Suchantworten.

Mehr zur Block-Deprecation: Der Classic-Block (auch core/freeform) war ein Schlüsselstück beim Übergang von TinyMCE zu Gutenberg in WordPress 5.0. Über die Jahre wurde die Abwärtskompatibilität mit TinyMCE zu einem Leistungsproblem. Die JS-Dateien des Block-Editors mussten die gesamte TinyMCE-Bibliothek (über 1 MB) vorsorglich laden. Das Ausblenden des Classic-Blocks hätte dem Core erlaubt, diese Assets lazy zu laden. Dieses Ausblenden ist in 7.1 nicht ausgeliefert worden. Behandeln Sie eine Behauptung von 40 Prozent Editor-Ladezeit nicht als gemessenes 7.1-Ergebnis.

#Vertiefung: E-E-A-T und die Rolle strukturierter Redaktionsdaten

Redaktionelle Richtlinien direkt im WordPress-Core über wp_knowledge waren kein Zufall. 2026 legen Suchmaschinen, vor allem Google, beispiellosen Wert auf E-E-A-T. Vertrauenswürdigkeit des Herausgebers und Transparenz der Inhaltserstellung sind Rankingfaktoren.

Früher wurden Autorenboxen oder Über-uns-Seiten manuell gepflegt. Heute suchen Googles automatisierte Systeme nach tieferen semantischen Verknüpfungen. Sie wollen wissen, ob eine redaktionelle Richtlinie vorliegt und wie Fakten geprüft werden.

wp_knowledge strukturiert diese Informationen auf Systemebene. Ein eigener Inhaltstyp für ethische Standards, Expertenteams und Forschungsmethoden wird Teil des Wissensgraphen der Website. SEO-Plugins können diese Regeln über das Attribut publishingPrinciples in Schema.org mit Autorinnen und Autoren verknüpfen. Das signalisiert Suchmaschinen, dass der Inhalt aus einem redaktionellen Prozess stammt und nicht unkontrolliert von einer KI erzeugt wurde.

Answer Engines bauen außerdem direkte Beziehungen zwischen Entitäten. Autoren, Redaktionsprozesse und validierte Inhalte über strukturiertes JSON-LD zu verknüpfen, hebt den Trust-Score der gesamten Site in KI-Suchmodellen.

#Praktische Integration von wp_knowledge in den Veröffentlichungsfluss

Um die Qualitätskontrolle in einer B2B-Agentur zu automatisieren, können Entwickler den folgenden PHP-Filter nutzen, der Beiträge vor der Veröffentlichung gegen wp_knowledge-Richtlinien prüft:

<?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-Komponente für den 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('beste') || content.includes('garantie')) {
                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 });

Und die vollständige PHP-Plugin-Dateistruktur zur Registrierung des Inhaltstyps:

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

Mehr zur Block-Deprecation: Der Classic-Block (auch core/freeform) war ein Schlüsselstück beim Übergang von TinyMCE zu Gutenberg in WordPress 5.0. Über die Jahre wurde die Abwärtskompatibilität mit TinyMCE zu einem Leistungsproblem. Die JS-Dateien des Block-Editors mussten die gesamte TinyMCE-Bibliothek (über 1 MB) vorsorglich laden. Das Ausblenden des Classic-Blocks hätte dem Core erlaubt, diese Assets lazy zu laden. Dieses Ausblenden ist in 7.1 nicht ausgeliefert worden. Behandeln Sie eine Behauptung von 40 Prozent Editor-Ladezeit nicht als gemessenes 7.1-Ergebnis.

#Technischer Leitfaden: Gutenberg-Blockvalidierungs-API und Deprecations in React

Der Classic-Block wird in 7.2 nicht auf der Grundlage dieses Zyklus entfernt. Block-Deprecation-Schemas bleiben für Ihre eigenen Blöcke relevant. So gleicht Gutenberg gespeichertes HTML mit einer save()-Funktion ab, unabhängig davon, ob der Core core/freeform jemals ausblendet.

#1. Gutenberg-Blockvalidierungs-API unter der Haube

Wenn ein Beitrag im Block-Editor lädt, parst die JS-Engine die gespeicherten HTML-Kommentare in wp_posts.post_content. Sie führt die aktuelle save()-Funktion des Blocks aus und vergleicht die Ausgabe mit dem Roh-HTML in der Datenbank.

Wenn die Datenbank enthält:

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

die aktuelle Implementierung aber new-class ausgibt, entsteht ein Validierungsfehler. Gutenberg warnt vor Blockkorruption und bietet Konvertierungsschaltflächen.

#2. Alte Blockstrukturen in React neu registrieren (Deprecations)

Um Validierungsfehler zu verhindern, registrieren Sie frühere Blockversionen im Array deprecated. Gutenberg versucht diese Schemas der Reihe nach, wenn die primäre Validierung scheitert:

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

Auf dem Server deserialisiert WordPress den Beitragsinhalt mit parse_blocks() in ein strukturiertes Array von Blockobjekten. Der Parser liest Delimiter, dekodiert Attribut-JSON und gibt einen Baum zurück:

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

Diese Architektur hält B2B-Kundenseiten performant, stabil und wartbar, wenn Sie große Migrationen auf Blockebene fahren.

#Entwurfsskizze: ein Redaktions-Wissensspeicher, den Sie selbst bauen

wp_knowledge ist nicht in 7.1. Wenn Sie strukturierte Redaktionsregeln für Menschen und Agenten brauchen, registrieren Sie Ihren eigenen Inhaltstyp in einem Plugin. Die Skizze unten ist genau diese Plugin-Form. Das ist keine Kunden-Fallstudie und kein Core-API.

Redaktionen, die Stilregeln schon in PDFs halten, haben dasselbe Problem wie vor 7.1: Redakteurinnen und Redakteure prüfen Entwürfe von Hand, und externe Generatoren haben keinen offiziellen Ort, an dem sie die Regeln lesen.

#Ein Workflow in Plugin-Form:

1. Strukturierte Wissensknoten: Wir definierten konkrete wp_knowledge-Beiträge mit redaktionellen Richtlinien für verschiedene Ressorts (Nachrichten, Finanzen, Sport). Die Regeln lagen als strukturierte JSON-Schema-Payloads.
2. REST-API-Verteilung für KI-Werkzeuge: Wir stellten einen abgesicherten REST-Endpunkt bereit, damit externe Content-Pipelines lokalisierte Formatvorgaben dynamisch holen können:

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

3. Echtzeit-Auditor in der Gutenberg-Sidebar: Eine React-Komponente in der Editor-Sidebar abonnierte Dokumentänderungen und markierte Vokabular oder Formulierungen, die gegen die aktiven Ressortregeln verstießen.
4. Programmatische WP-CLI-Qualitätsprüfungen: Ein Cron-Skript per WP-CLI prüfte veröffentlichte Beiträge gegen die Richtlinien und flaggte Ausnahmen für die Chefredaktion.

Nichts davon braucht einen Core-Inhaltstyp. Es braucht ein Plugin, das Ihnen gehört, mit Rechten und einer REST-Oberfläche, die Sie versionieren können. Darauf zielte das Veto: Adoption zuerst außerhalb des Cores beweisen.

#Expertenmeinung und B2B-Strategie: die Rolle von wp_knowledge in der AEO-Ära

Ein nativer Inhaltstyp wp_knowledge im Core wäre ein nützlicher Schritt für die KI-Ära gewesen. In 7.1 ist er nicht. Das Veto hat die Arbeit in Gutenberg und bei Automattic gelassen. Wenn Suchverhalten von klassischen Trefferlisten zu Answer Engines (Perplexity, Claude, Gemini) wandert, wird aus SEO Answer Engine Optimisation (AEO).

Enterprise-B2B-Entwickler und Verlage können nicht mehr nur für menschliche Lesbarkeit oder einfache Keyword-Indexer schreiben. Sie müssen strukturierte, prüfbare, maschinenlesbare Payloads liefern, aus denen KI-Modelle genaue Antworten bauen.

#Warum wp_knowledge für B2B-Sichtbarkeit zählt:

1. E-E-A-T-Verifikation (Vertrauenssignale): Answer Engines bevorzugen transparente, autoritative Quellen. Redaktionsrichtlinien, Expertenbios und Prüfworkflows in wp_knowledge zu speichern, erlaubt KI-Bots, diese Dateien mit aktiven Autorinnen und Autoren zu verknüpfen.
2. Schema.org-Prinzipien: Datenpunkte aus wp_knowledge können SEO-Tools automatisch auf Schema.org-Felder mappen (etwa publishingPrinciples oder editorialGuidelines). Das signalisiert KI-Crawlern eine kontrollierte Redaktionspipeline.
3. Bauen Sie keinen Core-Web-Vitals-Gewinn auf Classic-Block-Deprecation. Das Ausblenden ist nicht ausgeliefert. Wenn Sie TinyMCE vom Editor-Pfad haben wollen, bleibt das Ihre Plugin- und Theme-Arbeit, kein Gratisgeschenk von 7.1.

Wenn Sie auf einer Kundenseite strukturierte Richtlinien brauchen, registrieren Sie Ihren eigenen Inhaltstyp. Warten Sie nicht darauf, dass der Core das Veto zurücknimmt.

#Checkliste nach WordPress 7.1

1. Konvertieren Sie Classic-Blöcke nicht massenhaft wegen dieses Releases. Der Inserter bietet sie weiterhin an.
2. Prüfen Sie Classic-Nutzung erst, wenn Sie diese Inhalte ohnehin anfassen, damit Sie die Schulden kennen.
3. Suchen Sie nicht nach wp_knowledge auf einer 7.1-Site. Es ist nicht da. Wenn Sie den Speicher brauchen, liefern Sie ein Plugin.
4. Testen Sie den iframed Beitragseditor, der tatsächlich ausgeliefert wurde. Eigene Blöcke, die ein globales document annehmen, brechen. Siehe den Hinweis zum iframed Editor.
5. Lassen Sie Guidelines in Gutenberg, wenn Sie das Experiment schon nutzen. Versprechen Sie Kunden keinen Core-Einstellungsbildschirm.

#Zusammenfassung

WordPress 7.1 Mary Lou erschien ohne wp_knowledge und ohne Guidelines. Der Merge wurde per Veto gestoppt. Der Classic-Block steht weiterhin im Inserter. Die nützliche 7.1-Arbeit für Agenturen liegt woanders: responsives Styling, clientseitige Medien und der dauerhaft iframed Editor. Wenn Sie weiterhin strukturierte Redaktionsregeln für Agenten wollen, bauen Sie das Plugin. Schreiben Sie es nicht in einen 7.1-Upgrade-Plan, als hätte der Core es übernommen.