WordPress przez lata był platformą dla ludzi. Człowiek pisał treść, człowiek konfigurował pluginy, człowiek czytał wyniki.
WordPress 7.0 zmienia to założenie. Nie przez wielkie ogłoszenie. Przez infrastrukturę.
WP AI Client, Abilities API, Playground MCP Server — każda z tych funkcji jest technicznie skromna. Razem: WordPress staje się platformą którą agenci AI rozumieją nativnie, bez specjalnych obejść.
Trzy warstwy agent-readiness w WordPress 7.0
Warstwa 1: AI jako usługa systemowa
Przed WordPress 7.0 każdy plugin który chciał korzystać z AI musiał samodzielnie zarządzać kluczami API, autentykacją i komunikacją z modelem. Yoast miał swoją integrację. WooCommerce swoją. Elementor swoją. Każdy plugin był silosem.
WP AI Client (Settings → Connectors) to infrastrukturalna odpowiedź: administrator konfiguruje provider raz — OpenAI, Anthropic, Gemini — i każdy plugin który obsługuje nowe API korzysta z tej konfiguracji. WordPress traktuje AI jak traktuje e-mail czy media upload: jako usługę systemową, nie domenę każdego pluginu z osobna.
Dla właściciela strony: w praktyce to znaczy że pluginy które obsługują WP AI Client będą działać „od razu” z modelem który już skonfigurowałeś — bez odwiedzania ustawień każdego pluginu osobno.
Warstwa 2: Strona mówi agentowi co potrafi
Agenty AI które odwiedzają strony mają problem: nie wiedzą co mogą na tej stronie zrobić. Kupić? Zarezerwować? Wyszukać? Muszą odgadywać przez parsowanie HTML i analizę formularzy. To jest niedeterministyczne i zawodne.
Abilities API rozwiązuje to przez standardowe ogłoszenie możliwości. Plugin który chce udostępnić akcję agentowi rejestruje ją z input/output schema: „Potrafię add_to_cart. Oczekuję: {product_id: integer, quantity: integer}. Zwracam: {cart_id, total}.”
Agent zakupowy który „widzi” tę abilities nie musi zgadywać. Ma precyzyjną mapę.
To jest jeden z powodów dla których Google w projekcie WebMCP powołuje się explicite na WordPress Abilities API — to jest fundament pod integrację przeglądarek z agentami.
Warstwa 3: HTML który agent zawsze widzi tak samo
PHP-only blocks — nowe w WordPress 7.0 — to możliwość rejestrowania bloków wyłącznie w PHP, bez React i JavaScript. Efekt: blok jest renderowany po stronie serwera, zawsze w ten sam sposób, bez JavaScript hydration.
Dla agentów to ma znaczenie: blok który wymaga JavaScript może być niewidoczny dla agenta który nie wykonuje JS (co dotyczy wielu AI crawlerów). PHP-only block jest zawsze widoczny, zawsze taki sam.
To nie jest duża zmiana. Ale w połączeniu z Full Site Editing i Block Themes — WordPress 7.0 dąży do strony gdzie struktura HTML jest przewidywalna i agent-readable przez samą architekturę.
Co to konkretnie zmienia — zależnie od tego co robisz ze stroną
Masz sklep WooCommerce
WooCommerce już teraz ma REST API przez które agent może sprawdzić produkt, cenę i dostępność bez parsowania HTML. WordPress 7.0 dodaje Abilities API — pluginy WooCommerce będą mogły deklarować akcje (add_to_cart, checkout) w standardowy sposób.
Praktyczny krok: upewnij się że masz Product schema na stronach produktów (Yoast WooCommerce SEO robi to automatycznie). To jest pierwsza rzecz którą agenty zakupowe sprawdzają.
Piszesz treści i zależy Ci na GEO
Yoast SEO integruje się z NLWeb — standard Microsoftu który daje stronie endpoint /ask do odpowiadania na pytania agentów. Update Yoast = automatyczna agent-queryability bez dodatkowej konfiguracji.
Praktyczny krok: zaktualizuj Yoast po premierze WP 7.0, sprawdź czy /ask endpoint działa (po prostu wejdź na /ask?q=twoje-pytanie). Jeśli działa — Twoja strona odpowiada agentom w naturalnym języku.
Budujesz strony dla klientów
WordPress 7.0 wprowadza różnicę między stronami zbudowanymi na Block Themes (FSE) a stronami na klasycznych motywach z page builderami.
Block Theme + FSE = przewidywalny, semantyczny HTML. Nawigacja zawsze w <nav>, treść zawsze w <main>. Agent który crawluje taką stronę ma strukturę którą może przewidzieć.
Klasyczny motyw + Divi/Elementor = zagnieżdżone <div> bez semantycznej struktury. Agent musi zgadywać.
To nie znaczy że musisz dziś przebudowywać strony klientów. Znaczy że przy nowych projektach Block Theme jest inwestycją w agent-readiness której klasyczny page builder nie daje.
Co z Divi?
Divi 5 (Elegant Themes) jest osobną historią — page builder który sam w sobie buduje na własnej architekturze blokowej, niezależnej od Gutenberg. Divi 5.3 (kwiecień 2026) wprowadził AI Agenta z human-in-the-loop.
Divi i WordPress 7.0 koegzystują — możesz mieć WP AI Client skonfigurowany i Divi na froncie. Abilities API jednak jest najlepiej obsługiwane przez pluginy które współpracują z Gutenberg. Jeśli budujesz nową stronę z priorytetem agent-readiness — to jest argument za Full Site Editing zamiast page buildera.
Roadmap: co jeszcze będzie w 2026
WordPress 7.1 (sierpień 2026): real-time collaboration — edycja przez wiele osób jednocześnie. Architektonicznie poprawiona wersja funkcji która nie zdążyła do 7.0.
WordPress 7.2 (grudzień 2026): rozszerzenie collaboration features, pierwsze kroki w kierunku natywnej wielojęzyczności w core.
Jedno zdanie podsumowania
WordPress 7.0 nie jest rewolucją dla użytkowników końcowych — ale jest infrastrukturalnym skokiem który za 12-18 miesięcy sprawi że strony WordPress będą miały natywną agent-readiness której dziś trzeba pilnować ręcznie.
Słownik pojęć: WordPress 7.0 · WP AI Client · Abilities API · Gutenberg · Full Site Editing · WooCommerce agent-ready· Yoast SEO w erze AI · WordPress REST API
