Det agentstyrte skiftet: hvordan KI-agenter endrer valg av plattform, design og sikkerhet i WordPress

#Hvordan KI-agenter velger CMS-plattform

Valg av plattform var tidligere en menneskelig beslutning tatt av eiere, byråer og CTO-er. Andy Peatling, som jobbet 17 år i Automattic og nå bygger Miles, en KI-designagent for WordPress, mener at denne veien er i ferd med å lukkes. I Ideas for WordPress in an agentic world (14. september 2026) skriver han at en agent velger plattform ut fra treningsdataene sine eller et nettsøk, og kan sette opp et enkelt nettsted på rundt 30 sekunder. Konklusjonen hans er rett frem: “Hvis WordPress ikke blir valgt, kommer ikke prosjektet til å vokse.” (egen oversettelse)

Han kommer med tre konkrete forslag:

• To forpliktende agentreiser. WordPress bør definere og offentlig forplikte seg til to komplette reiser en agent kan gjennomføre fra start til slutt, for eksempel et nettsted bygget helt av en kodeagent, fra opprettelse via publisering til hosting. Han nevner Abilities, MCP, Agent Skills, temametadata og utvidelsesmetadata som rørleggerarbeidet disse reisene bør koble sammen, med definerte tillatelser, godkjenninger, sjekkpunkter for tilbakerulling og revisjonsspor.
• Offentlige ytelsestester. Følg med på hvor godt agenter lykkes med disse reisene, registrer når og hvorfor agenter tar med eller utelater WordPress når de velger plattform, og mål native agent-abilities med verktøy som WP-bench.
• Én agentressurs på WordPress.org. Forklar hvor WordPress er riktig valg og hvor det ikke er det, merk aktuelle API-er tydelig og nedprioriter eldre, og strukturer dokumentasjonen slik at agenter kan lese den inn.

Det samme spørsmålet gikk igjen i en episode av WP Minute med Alex Panagis, Brian Coords, Andy Peatling og Mike McAlister, How do we get agents to use WordPress. Episodenotatene slår fast at agenter som blir bedt om å bygge et nettsted, ikke alltid anbefaler WordPress, at WordPress trenger tydeligere meninger om hvordan agenter bør bruke det, og at Abilities API kan bli grunnmuren for agentstyrt WordPress.

#Hva Elementor MCP-serveren i beta gjør i WordPress

Elementor åpnet sin MCP-beta 15. september 2026. Den eksponerer funksjoner for å bygge nettsteder gjennom WordPress-abilities, slik at en MCP-klient kan bygge og redigere sider som native Elementor-strukturer i stedet for å returnere rå HTML som noen må lime inn i en mal. Elementor nevner Claude Code, Claude Desktop, Codex og Cursor som klienter, i tillegg til alle andre verktøy som snakker MCP.

Kunngjøringen lister opp ni funksjoner:

• bygge atomiske sider og layouter i ett steg,
• redigere eller redesigne eksisterende atomiske sider og layouter,
• opprette, bruke og endre rekkefølgen på klasser og variabler, sette hover-tilstander og justere responsive bruddpunkter,
• opprette og administrere temadeler som topptekster, bunntekster, arkiver og popup-vinduer, med visningsbetingelser,
• plassere, fylle ut eller opprette komponenter,
• koble til dynamiske data som innleggsfelt, egendefinerte felt og taksonomier,
• opprette egendefinerte widgets og administrasjonsopplevelser,
• masseoppdatere innhold, feilsøke feil og tette SEO-hull,
• få tilgang til alle abilities registrert med WordPress Abilities API, også de fra utvidelser som WooCommerce, Yoast, WPForms, Jetpack og ACF.

De tre siste krever Angie, en egen Elementor-utvidelse. Betaen har faste grenser. Tilgangen er begrenset til nettstedsadministratorer, tilkoblingen gjelder per nettsted, og alt MCP genererer lagres som utkast, ikke publisert. Oppsettet krever betatesterkanalen og Atomic Editor. Elementor genererer et applikasjonspassord og legger det inn i en oppsettsprompt for KI-verktøyet, med mulighet for manuell konfigurasjon. Pro-elementer krever fortsatt en Pro-plan, og standardeditoren er uendret for alle som ikke kobler til.

#Hvordan Block Runner fra Human Made validerer Gutenberg-blokker

Block Runner er et CLI-verktøy og JavaScript-bibliotek med åpen kildekode fra Human Made, lisensiert under GPL-2.0-or-later. README-filen beskriver det som et verktøy som “konverterer støttet HTML til native Gutenberg-blokker og sjekker den genererte markupen med Gutenberg-pakkene som WordPress-editoren bruker” (egen oversettelse). Pakken ble første gang publisert på npm 24. juni 2026; versjon 0.9.10 kom 4. oktober 2026.

Problemet den løser, kjenner alle som har limt generert markup inn i editoren: markup editoren ikke gjenkjenner, ender som en Egendefinert HTML-blokk eller en blokk som ber om gjenoppretting. Block Runner tilbyr fire ruter, dokumentert i README-filen:

• convert gjør HTML om til blokkmarkup med innebygde regler,
• assemble bygger sideinnhold fra et blokktre som en agent har planlagt,
• author genererer kildekoden til en gjenbrukbar registrert blokk, for eksempel en merknadsblokk, for en utvidelse,
• validate og fix sjekker eller kanoniserer eksisterende blokkmarkup.

Pakken kaller ingen KI-modell. En ekstern agent kan tolke et design og gi Block Runner en strukturert plan, og deterministisk kode setter deretter sammen og validerer resultatet. En medfølgende skill for kodeagenter installeres med npx --no-install block-runner skill --install, som skriver den til .agents/skills/block-runner og .claude/skills/block-runner. Grunnleggende konvertering krever Node.js (20.19+, 22.13+ eller 24+) og ingen WordPress-installasjon, Docker eller agent.

README-filen er tydelig på begrensningene. Strukturer som ikke støttes, kan bli liggende som Egendefinert HTML med advarsler, og --strict får kjøringen til å feile ved reserveblokker og uløste mediefiler. Med dens egne ord: “Gyldig markup beviser ikke visuell troskap eller kompatibilitet med alle nettsteder.” (egen oversettelse) Resultatet må fortsatt sjekkes i WordPress-installasjonen det skal brukes i. For bakgrunn om hvordan blokker, mønstre og maler henger sammen, se vår guide til Gutenberg-blokker og full site editing.

#Hvilke sårbarheter WordPress 7.1.1 rettet og hvem som meldte dem

WordPress 7.1.1 ble lansert 17. september 2026 som en vedlikeholds- og sikkerhetsutgivelse: 17 feilrettinger i kjernen, 19 feilrettinger i blokkeditoren og 11 sikkerhetsrettelser. Kunngjøringen ber om oppdatering umiddelbart og sier at sikkerhetsrettelsene ved behov tilbakeføres til alle grener som fortsatt får sikkerhetsrettelser. Hele listen med kreditter, slik den ble publisert:

Anthropic er kreditert for to av de elleve problemene, og pwn.ai deler én kreditt med Paulos Yibelo. Begge Anthropic-problemene krever en autentisert konto, det ene bare på Contributor-nivå. Det betyr noe for agentoppsett: en agent som er koblet til et nettsted, opptrer som en WordPress-bruker, så rollen du gir den, avgjør hvilke av disse feilklassene den kan nå på en installasjon som ikke er oppdatert. Vår guide til sikkerhetsherding av WordPress dekker roller, oppdateringer og overvåking.

#WordPress-arrangement om KI i Faro i oktober 2026

Det portugisiske WordPress-miljøet (Comunidade Portuguesa de WordPress) arrangerer WordPress Day for AI Faro 2026 24. oktober 2026 på hotellet AP Eva Senses i Faro. Ifølge arrangementets nettside varer det fra 09:00 til 18:00 med 100 plasser, og foredragene holdes på portugisisk og engelsk.

Det er to spor. Utviklingssporet dekker KI-assistert utvikling, programmeringsverktøy, API-er, automatisering, LLM-integrasjoner, MCP og arbeidsflyter for WordPress-utvikling. Forretningssporet er for eiere, byråer og fagfolk og dekker produktivitet, automatisering av arbeidsflyter og kundeopplevelse.

#Hva WordPress Abilities API er og hvordan en ability registreres

Abilities API er laget Elementor bygger på. Serverdelen kom med WordPress 6.9. En ability er en navngitt funksjonsenhet på formen namespace/ability-name, registrert med wp_register_ability() i en callback på kroken wp_abilities_api_init. Hver ability tilhører nøyaktig én kategori, registrert med wp_register_ability_category() på wp_abilities_api_categories_init.

De obligatoriske argumentene er label, description, category, output_schema, execute_callback og permission_callback. input_schema er valgfritt og trengs bare når ability-en tar imot inndata. Begge skjemaene er JSON Schema, og inndata som ikke består valideringen, når aldri tillatelses-callbacken. meta-arrayet bærer atferdshint i annotations: readonly, destructive og idempotent.

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/get-site-title', array(
		'label'               => __( 'Get site title', 'my-plugin' ),
		'description'         => __( 'Returns the title of this site.', 'my-plugin' ),
		'category'            => 'site',
		'output_schema'       => array( 'type' => 'string' ),
		'execute_callback'    => fn() => get_bloginfo( 'name' ),
		'permission_callback' => fn() => current_user_can( 'read' ),
		'meta'                => array(
			'annotations'  => array( 'readonly' => true ),
			'show_in_rest' => true,
		),
	) );
} );

To standardinnstillinger er verdt å kjenne til. Abilities eksponeres ikke over REST med mindre show_in_rest er satt til true, og REST-endepunktene under /wp-json/wp-abilities/v1 krever en autentisert bruker og respekterer tillatelses-callbacken til hver ability. Kjernen registrerer selv tre abilities i 6.9: core/get-site-info, core/get-user-info og core/get-environment-info. Det frittstående GitHub-repositoriet ble arkivert etter sammenslåingen med kjernen. For praktiske eksempler på abilities i redaksjonelle arbeidsflyter, se KI-arbeidsflyter i WordPress med Abilities API.

#Hvordan WordPress MCP Adapter eksponerer abilities for MCP-klienter

MCP Adapter er den offisielle WordPress-pakken som gjør abilities om til MCP-verktøy, ressurser og prompter. Versjon 0.7.0, lansert 2. oktober 2026, gjør den til en kanonisk utvidelse. Utvidelser bør deklarere Requires Plugins: mcp-adapter i headeren sin i stedet for å pakke med en kopi; medfølgende kopier fungerer fortsatt, men logger et varsel om avvikling.

Oppdatering, 28. oktober 2026. Gjeldende versjon er 0.7.1, lansert 16. oktober 2026. Den har en trinnvis oppsettsveiledning for nettstedseiere: koble til en AI-klient, opprette et applikasjonspassord, teste tilkoblingen og løse vanlige problemer. Når en klient ber om en ability som ikke finnes, foreslår adapteren tilgjengelige abilities som passer, eller viser klienten til discovery.

Abilities er private som standard. En ability når MCP bare når meta.public (eller meta.mcp.public) er true. Standardserveren, på /wp-json/mcp/mcp-adapter-default-server, eksponerer tre metaverktøy i stedet for ett verktøy per ability: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info og mcp-adapter-execute-ability. Agenten lister opp hva som er tilgjengelig, henter skjemaet den trenger, og kjører deretter. Slik holder tools/list-svaret seg på tre skjemaer uansett hvor mange utvidelser som registrerer abilities. En egendefinert server opprettet på kroken mcp_adapter_init gjør det motsatte og lister hver valgte ability som et eget verktøy.

Det finnes to måter å koble til en klient på:

• STDIO gjennom WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin. Flagget --user avgjør hvilken WordPress-bruker tillatelsessjekkene kjøres som; uten det er økten uautentisert.
• HTTP gjennom proxyen @automattic/mcp-wordpress-remote, som autentiserer med et applikasjonspassord.

Sikkerheten fungerer i to lag. En tillatelses-callback for transporten beskytter hele serveren og er som standard is_user_logged_in(), og hver ability kjører fortsatt sin egen permission_callback. Adapteren støtter MCP-protokollrevisjonene 2025-11-25 og 2026-07-28; eldre klienter betjenes gjennom skjemaet for 2025-11-25.

#Hva MCP-spesifikasjonen krever av verktøy og verter

Spesifikasjonen for Model Context Protocol definerer JSON-RPC 2.0-meldinger mellom verter (LLM-applikasjonene), klienter (koblinger inne i verten) og servere (tjenester som leverer kontekst og funksjoner). Servere kan tilby ressurser, prompter og verktøy. Den gjeldende revisjonen, 2026-07-28, definerer to standardtransporter: stdio for en underprosess startet av klienten, og Streamable HTTP, der hver melding er en POST til ett enkelt endepunkt.

Kapittelet om verktøy setter reglene som betyr noe når en agent skriver til WordPress. Det bør alltid være et menneske i loopen som kan avvise verktøykall. Servere må validere alle verktøyinndata, implementere tilgangskontroll, begrense antall kall og rense utdata. Klienter bør be om bekreftelse ved sensitive operasjoner, vise verktøyinndata før kallet, sette tidsavbrudd og logge verktøybruk. Verktøyannotasjoner må behandles som upålitelige med mindre de kommer fra en pålitelig server.

WordPress-delene passer inn i disse reglene. Validering med JSON Schema i Abilities API dekker inndatakontroll, permission_callback dekker tilgangskontroll, annotasjonene readonly og destructive forteller klienten hvilke kall som trenger bekreftelse, og at Elementor bare lagrer utkast, holder et menneske mellom agenten og den publiserte siden. Adapteren har ingen innebygd hastighetsbegrensning (observabilitetsguiden lister bare en feilkode, ability_rate_limit, som en ability kan returnere), så hastighetsbegrensning blir liggende hos hostinglaget eller i selve ability-en.

#Hvordan MCP-serverkort fungerer for oppdagelse

Agenter må også finne en server før de kan koble til. SEP-2127, som har nådd status Final som utvidelse, definerer MCP Server Cards: statiske metadatadokumenter som beskriver en ekstern servers identitet, transportendepunkter og støttede protokollversjoner. Et kort kan ligge på en hvilken som helst ikke-reservert URI, med streamable-http-url/server-card reservert som anbefalt plassering. For oppdagelse på domenenivå kan en AI Catalog publisert på /.well-known/ai-catalog.json lenke til eller bygge inn kortene.

Kortene utelater bevisst verktøy, ressurser og prompter. SEP-en forklarer at det en server eksponerer, kan variere etter bruker, økt og konfigurasjon, så klienter må bruke det direkte kallet tools/list. Kort må ikke inneholde påloggingsdata eller brukerspesifikke data, og de er valgfrie: servere uten kort fungerer fortsatt. På WordPress er adapterens endepunkt-URL det naturlige utgangspunktet for et kort. Vår guide til WPPolands MCP-server i drift viser en offentlig, skrivebeskyttet server i praksis.

#Hvordan bygge WordPress-nettsteder for KI-agenter og GEO

wppoland.com kjører på Astro 7 på Cloudflare Pages, med Schema.org-data generert fra frontmatter på hver side. Arbeidsregelen vår er at en side skal være like lett for en maskin å lese som for et menneske. For WordPress-nettsteder er den dokumenterte veien kort: registrer abilities med ærlige skjemaer og annotasjoner, publiser bare de du vil ha offentlige gjennom MCP Adapter, gi agenten en WordPress-bruker med den snevreste rollen som gjør jobben, og hold innholdsendringer som utkast til et menneske godkjenner dem. De samme strukturerte dataene tjener også Generative Engine Optimization (GEO). Når den hostede WordPress.com-Agenten og MCP write er nok versus en self-hosted adapter, se WordPress.com Agent og MCP write.

Hvis du vil ha hjelp med dette, se vår tjeneste for utvikling av MCP-servere eller be om en gjennomgang.