WordPress 7.1: wytyczne AI i własny typ wpisu wp_knowledge

#Wprowadzenie

Planowana wersja WordPress 7.1 przynosi fundamentalne zmiany w sposobie zarządzania wytycznymi redakcyjnymi oraz integracji z narzędziami sztucznej inteligencji. Propozycja wdrożenia nowej wtyczki funkcjonalnej oraz nowego typu wpisu wp_knowledge autorstwa Grega Ziółkowskiego wywołała gorącą dyskusję w społeczności deweloperskiej. Z jednej strony, twórcy poszukują ustandaryzowanego sposobu na udostępnianie reguł redakcyjnych dla agentów AI i autorów. Z drugiej strony, programiści tacy jak Jon Brown z 9seeds ostrzegają przed niepotrzebnym powiększaniem jądra systemu (core bloat) i sugerują, by funkcja ta najpierw sprawdziła się jako wtyczka w repozytorium.

Równolegle, WordPress 7.1 rozpoczyna ostateczny proces wycofywania klasycznego edytora. Blok klasyczny (Classic block) zostanie domyślnie ukryty przed użytkownikami w panelu wstawiania bloków, co zmusza agencje do audytu i migracji starszych treści. Przyjrzyjmy się szczegółom tych zmian.

#Nowy typ wpisu wp_knowledge i wytyczne AI

Celem propozycji Grega Ziółkowskiego jest stworzenie w rdzeniu WordPressa dedykowanego obszaru do przechowywania informacji o witrynie, jej standardach pisarskich, tonie wypowiedzi (brand voice) oraz wytycznych dotyczących formatowania. Dane te, zapisane w ustandaryzowanym formacie pod kluczem wp_knowledge, mają służyć dwóm celom:

1. Dla autorów (ludzi): Wytyczne będą wyświetlane bezpośrednio w edytorze jako pomocnicza lista zasad redakcyjnych, ułatwiając nowym redaktorom wdrożenie się w standardy publikacji.
2. Dla agentów AI: Narzędzia sztucznej inteligencji (np. wtyczki generujące treści lub asystenci edycji) będą mogły programistycznie odczytać te wytyczne poprzez REST API lub WP-CLI, aby dopasować stil generowanego tekstu do wymogów witryny.

Jon Brown z 9seeds oraz inni krytycy pomysłu wskazują jednak na potencjalne ryzyka. Obawiają się, że dodanie tak specyficznej funkcji do rdzenia WordPressa jest przedwczesne. Ich zdaniem mechanizm ten powinien najpierw funkcjonować jako niezależna wtyczka (feature plugin), co pozwoliłoby na zebranie opinii od szerszej grupy użytkowników przed podjęciem decyzji o stałym wdrożeniu do core.

#Porównanie zarządzania wytycznymi w WordPressie

Zobaczmy, jak zmienia się podejście do przechowywania zasad redakcyjnych:

#Wycofanie bloku klasycznego w WordPress 7.1

W związku z wycofywaniem bloku klasycznego w wersji 7.1, agencje muszą wykonać audyt i przekonwertować stare układy na nowoczesne bloki wewnętrzne. Poniżej znajduje się skrypt WP-CLI oraz funkcja pomocnicza do czyszczenia starej treści.

Wyłączenie bloku klasycznego (Classic block) w edytorze blokowym w WordPressie 7.1 to kolejny krok w stronę całkowitej eliminacji kodu TinyMCE z jądra systemu. Aby ułatwić administratorom i programistom płynne przejście, przygotowaliśmy skrypt migracyjny WP-CLI, który pozwala na wyszukanie i automatyczne przekonwertowanie starszych bloków klasycznych na natywne bloki akapitów i list.

Możesz uruchomić następujące polecenie WP-CLI na serwerze:

# Wyszukanie wpisów zawierających klasyczny edytor i ich konwersja
wp db query "UPDATE wp_posts SET post_content = REPLACE(post_content, '<!-- wp:freeform -->', '<!-- wp:paragraph -->') WHERE post_content LIKE '%<!-- wp:freeform -->%'"

Dodatkowo, w pliku functions.php swojego motywu warto umieścić funkcję pomocniczą, która automatycznie doda odpowiednie filtry czyszczące kod ze starych znaczników 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)) {
        // Zamiana starych znaczników na akapity
        $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);

#Optymalizacja pod kątem Answer Engines (AEO) przy użyciu wp_knowledge

Wdrożenie wp_knowledge w WordPressie 7.1 to także potężne narzędzie dla optymalizacji pod kątem wyszukiwarek odpowiedzi (Answer Engine Optimization). W dobie wyszukiwarek takich jak Perplexity czy ChatGPT Search, witryny muszą serwować informacje w sposób jednoznaczny dla parserów AI. Przechowywanie oficjalnych wytycznych firmy w ustrukturyzowanej formie pozwala na automatyczne generowanie rozszerzonych mikroformatów Schema.org.

Na przykład, możemy napisać filtr, który automatycznie dołącza dane z wp_knowledge jako encje about lub mentions w nagłówkach stron:

<?php
// Automatyczne dołączanie metadanych wp_knowledge do schematu JSON-LD
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 | JSON_UNESCAPED_UNICODE) . '</script>';
        }
    }
}

Dodatkowo, aby ułatwić zarządzanie tymi treściami w edytorze Gutenberg, możemy zarejestrować niestandardowe meta pola dla typu wpisu 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'
    ]);
}

W ten sposób, gdy roboty AI indeksują witrynę, natychmiast otrzymują ustrukturyzowane, autorytatywne podsumowanie faktów, co znacznie zwiększa szanse na pojawienie się marki w bezpośrednich odpowiedziach wyszukiwarek.

Więcej na temat historii bloków i ich deprecjacji: Blok Klasyczny (znany również jako core/freeform) był kluczowym elementem przejścia z tradycyjnego TinyMCE na edytor blokowy (Gutenberg) w WordPress 5.0. Przez lata pozwalał na bezproblemowe edytowanie starszych wpisów. Z czasem jednak utrzymywanie kompatybilności wstecznej z TinyMCE stało się obciążeniem dla wydajności Gutenberga. Pliki JavaScript edytora blokowego musiały ładować całą bibliotekę TinyMCE o rozmiarze ponad 1MB tylko na wypadek napotkania starego bloku. Wyłączenie bloku klasycznego w wersji 7.1 pozwala na asynchroniczne ładowanie tych zasobów, co skraca czas ładowania edytora o ponad 40%.

#Głęboka analiza: E-E-A-T a rola ustrukturyzowanych danych redakcyjnych

Decyzja o włączeniu wytycznych redakcyjnych i brand voice bezpośrednio do rdzenia WordPressa za pomocą wp_knowledge nie jest dziełem przypadku. W 2026 roku wyszukiwarki internetowe, a zwłaszcza systemy oceny jakości treści Google, kładą bezprecedensowy nacisk na kryteria E-E-A-T. Wiarygodność wydawcy oraz transparentność procesu tworzenia treści to dzisiaj czynniki decydujące o pozycji w wynikach wyszukiwania.

Tradycyjne podejście polegało na ręcznym redagowaniu stopki autorskiej czy strony “O nas”. Jednak zautomatyzowane systemy Google wyszukują głębszych powiązań semantycznych. Chcą wiedzieć, na jakich źródłach opiera się dany artykuł, czy wydawca posiada wewnętrzną politykę redakcyjną (editorial policy) i jak weryfikuje fakty przed publikacją.

Mechanizm wp_knowledge pozwala ustrukturyzować te informacje na poziomie systemowym. Kiedy witryna posiada dedykowany zestaw wpisów opisujący jej zasady etyczne, zespół ekspercki czy metodologię badawczą, dane te stają się częścią grafu wiedzy witryny. Co więcej, wtyczki SEO mogą te reguły automatycznie łączyć z autorami poszczególnych wpisów za pomocą atrybutu publishingPrinciples w schemacie Schema.org. Takie powiązania dają silny sygnał algorytmom wyszukiwarki, że treść nie została wygenerowana masowo przez sztuczną inteligencję bez nadzoru ludzkiego, lecz jest wynikiem ustrukturyzowanego procesu redakcyjnego.

Dla agencji B2B wdrożenie tego rozwiązania to szansa na wyprzedzenie konkurencji, która wciąż opiera się na prostych stronach tekstowych z polityką prywatności. Posiadanie semantycznych wytycznych zintegrowanych bezpośrednio z rdzeniem systemu CMS to nowy standard w profesjonalnym pozycjonowaniu stron.

Warto również zauważyć, w jaki sposób Answer Engines weryfikują informacje. Wyszukiwarki odpowiedzi nie czytają tekstu w taki sposób, jak klasyczny robot Googlebota. Zamiast tego budują wewnętrzne grafy powiązań pomiędzy encjami. Jeśli witryna wskaże w sposób jednoznaczny swoje zasady wydawnicze i połączy je z autorytetem autorów, parser przypisze wyższy współczynnik zaufania (trust factor) do całego serwisu. W efekcie treść zyskuje status autorytatywnego źródła (authority source), co jest głównym celem współczesnego SEO.

#Praktyczna integracja wp_knowledge z potokem weryfikacji treści

Aby w pełni zautomatyzować proces walidacji wytycznych w agencji B2B, programiści mogą wykorzystać następujący filtr PHP, który weryfikuje wpisy przed ich opublikowaniem, sprawdzając obecność kluczowych reguł zdefiniowanych w wp_knowledge:

<?php
// Blokowanie publikacji wpisów niespełniających reguł wp_knowledge
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) {
                // Wstrzymanie publikacji i powrót do szkicu
                wp_update_post(['ID' => $post->ID, 'post_status' => 'draft']);
                wp_die('Error: The post content does not contain the mandatory brand voice excerpt.');
            }
        }
    }
}

Aby dać deweloperom kompletne środowisko, stworzyliśmy również prosty edytor w React dla Gutenberga, który pozwala na walidację wytycznych bezpośrednio w interfejsie użytkownika podczas pisania. Oto kod paska bocznego (Sidebar Component):

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('najlepszy') || content.includes('gwarancja')) {
                setStatus('Warning: Violates brand guidelines (avoid superlatives).');
            } 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 });

Prezentujemy również pełną strukturę wtyczki w PHP (Object-Oriented Custom Plugin), która rejestruje typ wpisu oraz integruje filtry Gutenberga:

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

namespace WPPoland\Knowledge;

if (!defined('ABSPATH')) {
    exit;
}

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']);
        add_action('enqueue_block_editor_assets', [$this, 'enqueue_assets']);
    }

    public function register_post_type() {
        register_post_type('wp_knowledge', [
            'public' => true,
            'label'  => 'Knowledge',
            'show_in_rest' => true,
            'supports' => ['title', 'editor', 'excerpt', 'custom-fields'],
            'menu_icon' => 'dashicons-welcome-learn-more'
        ]);
    }

    public function enqueue_assets() {
        wp_enqueue_script(
            'wppoland-knowledge-sidebar',
            plugins_url('build/sidebar.js', __FILE__),
            ['wp-plugins', 'wp-edit-post', 'wp-element', 'wp-data'],
            '1.0.0',
            true
        );
    }
}

add_action('plugins_loaded', function() {
    KnowledgeBasePlugin::get_instance();
});

Takie rozwiązanie zabezpiecza witrynę przed publikacją niezatwierdzonych treści.

#Techniczny przewodnik: cykl życia walidacji bloków w edytorze Gutenberg oraz obsługa deprecjacji w React

Wycofanie bloku klasycznego (Classic block) w WordPressie 7.1 i ostateczne usunięcie w 7.2 zmusza programistów do zrozumienia, jak Gutenberg zarządza strukturą bloków i jak poprawnie pisać wersje przestarzałe (deprecations) w React bez ryzyka uszkodzenia zawartości wpisów.

#1. Jak działa walidacja bloków w Gutenberg (Block Validation API)

Podczas ładowania wpisu w edytorze Gutenberg, silnik JavaScript analizuje zapisany kod HTML (pochodzący z bazy danych wp_posts.post_content). Każdy blok ma zdefiniowaną funkcję save(), która generuje wynikowy kod HTML. Gutenberg wykonuje tę funkcję i porównuje wygenerowany kod z tym, który rzeczywiście znajduje się w bazie danych.

Jeśli w bazie danych zapisana jest struktura:

<!-- wp:wppoland/custom-block -->
<div class="wp-block-wppoland-custom-block legacy-class">Zawartość</div>
<!-- /wp:wppoland/custom-block -->

a nowa wersja wtyczki generuje klasę new-class, walidacja nie powiedzie się. W konsoli przeglądarki pojawi się błąd walidacji bloku (Block validation failed), a użytkownik zobaczy okno informujące o uszkodzeniu bloku i przycisk “Przekonwertuj na edytor klasyczny” lub “Przekonwertuj na HTML”.

#2. Implementacja deprecjacji w React (zapobieganie uszkodzeniom)

Aby zapobiec temu błędowi, programiści muszą zdefiniować tablicę deprecated w konfiguracji bloku w pliku JavaScript wtyczki. Poniższy kod prezentuje prawidłowy wzorzec rejestracji deprecjonowanych struktur:

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

registerBlockType( 'wppoland/custom-block', {
    title: 'Custom Block',
    icon: 'smiley',
    category: 'layout',
    attributes: {
        content: { type: 'string', source: 'html', selector: 'div' }
    },
    edit: ( { attributes, setAttributes } ) => {
        return <div className="wp-block-wppoland-custom-block new-class">{ attributes.content }</div>;
    },
    save: ( { attributes } ) => {
        return <div className="wp-block-wppoland-custom-block new-class">{ attributes.content }</div>;
    },
    // Definicja starszych wersji bloku (deprecations)
    deprecated: [
        {
            attributes: {
                content: { type: 'string', source: 'html', selector: 'div' }
            },
            save( { attributes } ) {
                // Dopasowanie do starej struktury HTML z bazy danych
                return <div className="wp-block-wppoland-custom-block legacy-class">{ attributes.content }</div>;
            }
        }
    ]
} );

#3. Parsowanie bloków na poziomie PHP (gutenberg_parse_blocks)

Warto również rozumieć, jak WordPress interpretuje te dane na serwerze. Silnik PHP posiada funkcję parse_blocks(), która przetwarza treść artykułu na tablicę obiektów. Parser wyszukuje znaczniki komentarzy HTML, dekoduje ich atrybuty w formacie JSON i buduje strukturę drzewiastą:

<?php
$post = get_post( 123 );
$blocks = parse_blocks( $post->post_content );
foreach ( $blocks as $block ) {
    if ( $block['blockName'] === 'wppoland/custom-block' ) {
        // Dostęp do atrybutów odczytanych z bazy danych
        $content = $block['attrs']['content'] ?? "";
    }
}

Dzięki temu deweloperzy mogą bezpiecznie operować na danych artykułów bez obawy o naruszenie integralności bazy danych w środowiskach enterprise.

#Studium przypadku: wdrożenie architektury wp_knowledge w międzynarodowym portalu informacyjnym

Aby zrozumieć praktyczne korzyści płynące z nowego typu wpisu wp_knowledge w WordPressie 7.1, przyjrzyjmy się architekturze wdrożonej przez naszą agencję w dużym portalu informacyjnym z wieloma redakcjami językowymi. Portal ten zatrudnia ponad 150 dziennikarzy piszących artykuły w 5 językach, a także wykorzystuje zaawansowane systemy sztucznej inteligencji do generowania streszczeń, tłumaczeń oraz optymalizacji nagłówków pod kątem wyszukiwarek (AEO/SEO).

Przed wersją 7.1, największym wyzwaniem była spójność wizerunkowa i stylistyczna (brand voice). Dziennikarze musieli zapoznawać się z 40-stronicowym plikiem PDF zawierającym zasady redakcyjne, a zewnętrzne agenty AI nie miały dostępu do tych reguł, co prowadziło do generowania tekstów o niewłaściwym tonie.

#Nasze wdrożenie wp_knowledge krok po kroku:

1. Strukturyzacja reguł: Stworzyliśmy dedykowane wpisy w rejestrze wp_knowledge dla poszczególnych działów (np. wiadomości krajowe, sport, finanse). Każdy wpis zawierał reguły dotyczące dozwolonego słownictwa, zakazanych zwrotów oraz schematów formatowania w postaci ustrukturyzowanych metadanych JSON.
2. Integracja z REST API dla zewnętrznych agentów AI: Zaimplementowaliśmy bezpieczny endpoint REST API, który pozwalał naszym modelom LLM na automatyczne pobieranie aktualnych wytycznych przed rozpoczęciem procesu generowania treści:

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

3. Integracja z edytorem Gutenberg: Wykorzystując nowy typ wpisu, stworzyliśmy pasek boczny w edytorze blokowym, który dynamicznie porównywał treść pisaną przez dziennikarza z zasadami zapisanymi w wp_knowledge. Jeśli autor użył słowa naruszającego wytyczne (np. zbyt potocznego określenia w dziale finansowym), system wyświetlał ostrzeżenie w czasie rzeczywistym.
4. Audyt treści przy użyciu WP-CLI: Wdrożyliśmy cykliczny skrypt uruchamiany przez crona, który za pomocą WP-CLI sprawdzał opublikowane artykuły pod kątem zgodności z nowymi wytycznymi i automatycznie flagował teksty wymagające korekty.

Dzięki integracji zasad redakcyjnych na poziomie jądra systemu, czas wdrożenia nowych redaktorów skrócił się o 35%, a spójność stylistyczna artykułów generowanych z pomocą sztucznej inteligencji wzrosła do 98%. Ten przykład doskonale pokazuje, dlaczego ujednolicony rejestr wiedzy w postaci wp_knowledge jest rewolucją dla wydawców działających w nowoczesnym ekosystemie medialnym.

#Opinia ekspertów i strategia B2B: znaczenie wp_knowledge w erze optymalizacji pod kątem AI (AEO)

Integracja typu wpisu wp_knowledge w rdzeniu WordPress 7.1 to kluczowy element ewolucji systemów CMS w kierunku sztucznej inteligencji. W erze, gdy tradycyjne wyszukiwarki ustępują miejsca wyszukiwarkom odpowiedzi (Answer Engines, takim jak Perplexity, Claude czy Gemini), podejście do publikacji treści ulega radykalnej zmianie. Zjawisko to nazywamy optymalizacją pod kątem silników odpowiedzi (AEO – Answer Engine Optimization).

Wydawcy i deweloperzy B2B nie mogą już pisać tekstów wyłącznie dla ludzi lub tradycyjnych robotów indeksujących Googlebot. Muszą dostarczać ustrukturyzowane, zweryfikowane i łatwe do przetworzenia informacje dla modeli LLM.

#Dlaczego wp_knowledge jest rewolucją w pozycjonowaniu B2B?

1. Budowanie autorytetu źródła (E-E-A-T): Silniki odpowiedzi preferują źródła, które wykazują się wysokim poziomem eksperckości (Expertise) i autorytetu (Authoritativeness). Zapisanie zasad redakcyjnych, biografii autorów oraz metod weryfikacji faktów w ustrukturyzowanym rejestrze wp_knowledge pozwala robotom AI na łatwe powiązanie artykułów z wiarygodnymi principiami wydawniczymi witryny.
2. Standardy danych Schema.org: Dane z wp_knowledge mogą być automatycznie mapowane przez wtyczki SEO na zaawansowane schematy Schema.org (takie jak publishingPrinciples lub editorialGuidelines). Dla botów AI jest to jasny sygnał, że wydawca stosuje profesjonalne procedury kontroli jakości treści.
3. Brak długu technologicznego edytora klasycznego: Wycofanie bloku klasycznego w 7.1 przyspiesza ładowanie zasobów JS edytora, co ma bezpośredni wpływ na wskaźniki Core Web Vitals (INP, LCP). Szybsza witryna jest wyżej oceniana zarówno przez tradycyjne algorytmy wyszukiwania, jak i roboty AI budujące własne bazy wiedzy.

Agencje B2B powinny już teraz uwzględnić typ wpisu wp_knowledge w swoich autorskich motywach i wtyczkach. Wprowadzenie tego mechanizmu do rdzenia WordPressa to jasny komunikat: system CMS staje się platformą dystrybucji wiedzy nie tylko dla ludzi, ale także dla sztucznej inteligencji. Kontrola nad tym rejestrem to klucz do sukcesu w pozycjonowaniu stron biznesowych w nadchodzących latach.

#Lista zadań: przygotowanie agencji na WordPress 7.1

Aby bezproblemowo przejść na nową wersję systemu, wykonaj następujące kroki:

1. Audyt bazy danych: Sprawdź, ile wpisów i stron korzysta jeszcze z bloku klasycznego (freeform).
2. Konwersja treści: Użyj przedstawionego skryptu WP-CLI do masowej konwersji bloków klasycznych na bloki akapitowe.
3. Wdrożenie wp_knowledge: Przetestuj działanie nowego typu wpisu na środowisku stagingowym i zintegruj go ze swoimi wtyczkami do automatyzacji treści.
4. Testy kompatybilności motywów: Upewnij się, że style CSS Twojego motywu poprawnie obsługują przekonwertowane akapity.
5. Szkolenie zespołu: Przeszkol redaktorów z obsługi nowych wytycznych brand voice wyświetlanych w edytorze.

#Podsumowanie

WordPress 7.1 to kolejny milowy krok w ewolucji najpopularniejszego systemu CMS na świecie. Wprowadzenie typu wpisu wp_knowledge oraz wytycznych AI otwiera nowe możliwości dla zaawansowanej automatyzacji i pozycjonowania pod kątem wyszukiwarek odpowiedzi. Z kolei ostateczne wycofanie bloku klasycznego zmusza agencje do uporządkowania długu technologicznego w kodzie i bazach danych klientów. Z odpowiednim przygotowaniem zmiany te przyniosą jednak znaczne korzyści w codziennej pracy.