Automatisert innholdsproduksjon i WordPress: arbeidsflyt og kvalitet

Automatisert innhold i WordPress betyr at strukturerte data, redaksjonelle systemer og AI-støttede utkast kobles sammen, slik at folk bruker tiden på vurderinger i stedet for på kopiering, formatering og planlegging. Prinsippet som skiller et nyttig oppsett fra en innholdsfabrikk, er kort: automatiser prosessen, ikke kvalitetsbeslutningen.

Denne guiden går gjennom hva Google faktisk sier om AI-generert og automatisert innhold, hvilke grensesnitt i WordPress som gjør publiseringsjobben (REST API, WP-CLI og AI Client, som kom med WordPress 7.0), og hvilke kontroller som holder genererte utkast utenfor indeksen til et menneske har sjekket dem.

Vil du ha den praktiske versjonen først: automatiser de repeterbare delene av arbeidsflyten (briefer, utkast, maler, berikelse, planlegging) og la den endelige publiseringsbeslutningen ligge hos en redaktør. Publisering uten redaksjonell kontroll er den delen som ikke skalerer.

Les mer om SEO og optimalisert innhold hos WPPoland.

#Hva Google sier om AI-generert innhold

Googles holdning har ligget fast siden innlegget på Search Central-bloggen 8. februar 2023. FAQ-en i det innlegget svarer direkte på det første spørsmålet:

“Riktig bruk av AI eller automatisering bryter ikke med retningslinjene våre.”

Google Search Central, Google Search’s guidance about AI-generated content (egen oversettelse)

Det samme innlegget definerer hva som gjør bruken upassende. Å bruke automatisering, også AI, til å generere innhold “med hovedformål å manipulere rangeringen i søkeresultatene er et brudd på spamreglene våre”. Innlegget svarer også på spørsmålet de fleste automatiseringsprosjekter i det stille håper skal gå den andre veien: “Bruk av AI gir ikke innhold noen særskilte fordeler. Det er bare innhold.” En generert side vurderes som enhver annen side, ut fra om den er nyttig og original og viser egenskapene Google samler under E-E-A-T.

Googles dokumentasjonsside om bruk av generativt AI-innhold, sist oppdatert 1. oktober 2026, legger til den operative delen. Generativ AI beskrives som nyttig “når man researcher et tema, og for å gi struktur til originalt innhold”. Så kommer advarselen som gjelder for enhver pipeline:

“Det er avgjørende å faktasjekke og gå gjennom alt AI-generert innhold manuelt med tanke på korrekthet og troverdighet før publisering.”

Google Search Central, Google Search’s guidance on using generative AI content on your website (egen oversettelse)

Begrunnelsen er teknisk: generative modeller henter ikke fakta, de forutsier en sannsynlig rekke av ord, så resultatet kan inneholde hallusinasjoner. Ingenting av dette garanterer at AI-innhold rangerer eller at det er trygt. Poenget er at produksjonsmetoden ikke er testen. Verdien for leseren er det.

#Hva som regnes som misbruk av innhold i stor skala

Spamregelen automatiserte WordPress-nettsteder møter, er misbruk av innhold i stor skala (scaled content abuse). Googles side om spamregler (sist oppdatert 28. august 2026) definerer det slik:

“Misbruk av innhold i stor skala er når mange sider genereres med hovedformål å manipulere søkerangeringer og ikke å hjelpe brukerne.”

Google Search Central, Spam policies for Google web search (egen oversettelse)

Regelen legger til at slikt innhold som regel er uoriginalt og gir lite eller ingen verdi for brukerne, “uansett hvordan det er laget”. Eksemplene leses som en liste over snarveier som automatiseringsverktøy gjør enkle:

• å bruke generativ AI eller lignende verktøy til å generere mange sider uten å tilføre verdi for brukerne,
• å skrape feeder, søkeresultater eller annet innhold for å generere mange sider, også gjennom automatiske transformasjoner som synonymbytte, oversettelse eller annen tilsløring,
• å sy sammen eller kombinere innhold fra ulike nettsider uten å tilføre verdi,
• å opprette flere nettsteder for å skjule at innholdet er laget i stor skala,
• å lage mange sider som gir liten eller ingen mening for en leser, men som inneholder søkeord.

To konsekvenser betyr noe for WordPress-prosjekter. Maskinoversettelse som bare brukes til å mangedoble antall sider, er nevnt eksplisitt, så en flerspråklig pipeline trenger samme gjennomgang som en enspråklig. Og regelen avsluttes med en instruks: hvis du har slikt innhold på nettstedet ditt, skal du holde det utenfor søk. I praksis betyr det noindex på genererte sider som ikke har bestått gjennomgang, ikke et håp om at ingen legger merke til dem.

Googles side om å lage nyttig, pålitelig innhold med mennesker i fokus lister opp tilsvarende varselsignaler, blant annet “omfattende automatisering for å produsere innhold om mange temaer” og å lage store mengder innhold om mange ulike temaer i håp om at noe av det rangerer.

#Nivåer av innholdsautomatisering i WordPress

All innholdsautomatisering er ikke lik. Den spenner fra minimal hjelp til helautomatisk publisering, og hvert trinn har et annet risikonivå.

#Nivå 1: AI-assistanse (lav risiko)

AI hjelper med bestemte deler av en arbeidsflyt som mennesker styrer:

• Temaresearch: AI grupperer søk, finner hull sammenlignet med eksisterende artikler og foreslår vinklinger.
• Briefer: AI gjør SEO-data og redaksjonelle notater om til en strukturert brief.
• Kontroll etter skriving: AI foreslår forbedringer av lesbarhet, struktur og tematisk dekning i et utkast skrevet av et menneske.

Skribenten forblir forfatteren. Dette er bruken Google beskriver som å researche et tema og gi struktur.

#Nivå 2: AI-støttede utkast (middels risiko)

AI lager utkast som mennesker går gjennom og beriker:

• Fullt første utkast: AI skriver et utkast ut fra en detaljert brief.
• Redaksjonell gjennomgang: en redaktør kontrollerer korrektheten, legger til egen erfaring og justerer merkevarens stemme.
• Berikelse: teamet legger til egne data, skjermbilder og ekte eksempler som modellen ikke kan levere.

Hvor mye tid dette sparer, avhenger av hvor grundig gjennomgangen er. Et utkast der hver påstand må sjekkes på nytt, sparer mindre enn det ser ut til.

#Nivå 3: programmatisk innhold (høy risiko)

Sider generert i stor skala fra data og maler:

• Lokasjonssider: “[Tjeneste] i [By]” for mange byer.
• Sammenligningssider: “[Produkt A] vs. [Produkt B]” bygget fra en produktdatabase.
• FAQ-sider: bygget fra supportsaker og søkedata.

Det er på dette nivået regelen om misbruk av innhold i stor skala treffer mest direkte. Det fungerer bare når hver side har data leseren ikke kan få fra malen alene.

#Nivå 4: helautomatisk publisering (svært høy risiko)

AI genererer, kontrollerer og publiserer uten et menneske i løkken. Risikoene er konkrete:

• faktisk feil informasjon publisert uten kontroll,
• generisk tekst som ikke tilfører noe nytt,
• tynne eller nesten like sider som faller inn under spamregelen,
• skade på merkevaren når en feil påstand går ut i dens navn.

Vi fraråder dette i nesten alle tilfeller. Det er bare forsvarlig for dataoppdateringer med svært lav risiko, for eksempel lagerbeholdning eller åpningstid hentet fra et kildesystem.

#Hvordan AI-arbeidsflyter med flere agenter deler opp arbeidet

Noen team sender ikke lenger én prompt til én modell. De deler arbeidet opp i roller, hver med sin egen prompt eller agent og egne instruksjoner:

• Researcher: samler kilder til briefen, for eksempel dokumentasjon, versjonsnotater og teamets egne data.
• Strukturerer: lager en disposisjon ut fra briefen, søkeintensjonen og retningslinjene for merkevarens stemme.
• Skribent: skriver utkastet og tar med de konkrete tekniske datapunktene fra briefen.
• Redaktør: kontrollerer tonen, flagger hver påstand uten kilde og sammenligner utkastet med veiledningen om E-E-A-T.

Når arbeidet deles opp, blir hvert steg lettere å teste, men faktaene blir ikke mer pålitelige. En “redaktør”-agent er fortsatt en språkmodell. Faktasjekken Google kaller avgjørende, må gjøres av et menneske mot kilden, og pipelinen bør gi den personen en liste over påstander og kilder i stedet for en ferdig artikkel.

#Hvordan lage WordPress-utkast via REST API

WordPress REST API er det vanlige inngangspunktet for en ekstern pipeline. Et nytt innlegg opprettes med POST /wp/v2/posts. Ifølge referansen for Posts godtar argumentet status verdiene publish, future, draft, pending og private, og date er publiseringsdatoen i nettstedets tidssone (med date_gmt som GMT-variant). Det samme endepunktet tar imot title, content, excerpt, categories, tags, author og meta.

For automatisert innhold er statusen kontrollpunktet. En pipeline som skriver pending, legger hvert utkast i køen for innlegg som venter på gjennomgang (Pending review i det engelske grensesnittet), som redaktørene allerede kjenner, og en pipeline som aldri skriver publish, kan ikke publisere ved en feil.

Autentisering for skript går som regel via applikasjonspassord (Application Passwords), som kom inn i kjernen i WordPress 5.6. Integrasjonsguiden på make.wordpress.org forklarer at legitimasjonen sendes med HTTP Basic-autentisering over HTTPS, at funksjonen som standard bare er tilgjengelig på nettsteder som serveres over HTTPS, og at brukerne lager og tilbakekaller disse passordene på skjermen for redigering av bruker. Opprett en egen bruker med rollen Bidragsyter (Contributor) for pipelinen, slik at kontoen ikke kan publisere selv om skriptet ber om det.

curl -X POST https://example.com/wp-json/wp/v2/posts \
  -u "content-pipeline:$APPLICATION_PASSWORD" \
  -H "Content-Type: application/json" \
  -d '{"title":"Utkast fra pipelinen","content":"<p>Body</p>","status":"pending"}'

En konto med rollen Bidragsyter kan sende inn til gjennomgang, men ikke publisere, noe som passer arbeidsflyten over. Tilbakekall applikasjonspassordet når pipelinen legges ned.

#Hvordan lage WordPress-innlegg med WP-CLI

Når pipelinen kjører på selve serveren, er WP-CLI enklere enn HTTP. Referansen for wp post create lister opp valgene som betyr noe for automatisering:

• --post_status har draft som standard, så et glemt flagg feiler trygt.
• En filsti som første argument leser innholdet fra den filen, og - leser fra standard input, noe som passer en generator som skriver til stdout.
• --meta_input tar imot et JSON-objekt med metanøkler og verdier, nyttig for å registrere hvordan utkastet ble laget.
• --porcelain skriver bare ut ID-en til det nye innlegget, slik at neste steg i skriptet kan bruke den.
• --post_status=future sammen med --post_date planlegger et innlegg.

POST_ID=$(wp post create ./draft.html \
  --post_title='Utkast fra pipelinen' \
  --post_status=pending \
  --meta_input='{"_generated_by":"pipeline","_review_status":"pending"}' \
  --porcelain)
echo "Opprettet utkast $POST_ID"

Referansen nevner også at --tax_input hopper over kontrollen av brukerrettigheter som kjernen vanligvis gjør. Et WP-CLI-skript kjører med mer makt enn en REST-klient, så hold det unna alt som tar imot input utenfra.

#Hvordan AI Client i WordPress 7.0 genererer tekst

WordPress 7.0 “Armstrong”, lansert 20. mai 2026, la til en AI Client i kjernen. Utviklernotatet Introducing the AI Client in WordPress 7.0 beskriver hvordan den fungerer:

• Inngangspunktet er wp_ai_client_prompt(), som returnerer en WP_AI_Client_Prompt_Builder.
• Konfigurasjonsmetodene omfatter using_system_instruction(), using_temperature(), using_max_tokens() og using_model_preference(). En modellpreferanse er en prioritert liste, ikke et krav: den første tilgjengelige modellen brukes.
• as_json_response( $schema ) ber om strukturert JSON, som passer bedre for briefer og metadata enn fritekst.
• generate_text() og de andre generate_*()-metodene returnerer en WP_Error ved feil, så den vanlige is_wp_error()-kontrollen gjelder.
• Kjernen leveres uten leverandør. Administratorer kobler til en på innstillingsskjermen Connectors, med leverandørutvidelser som de offisielle for Anthropic, Google og OpenAI. Utvidelseskode håndterer aldri API-nøkler.
• is_supported_for_text_generation() og søsknene sjekker tilgjengelighet uten å gjøre et API-kall.

$builder = wp_ai_client_prompt( $brief )
    ->using_system_instruction( 'Skriv et første utkast. Merk hver påstand som trenger en kilde, med [SOURCE].' )
    ->using_temperature( 0.4 );

if ( ! $builder->is_supported_for_text_generation() ) {
    return;
}

$text = $builder->generate_text();
if ( is_wp_error( $text ) ) {
    return $text;
}

wp_insert_post( [
    'post_title'   => $title,
    'post_content' => wp_kses_post( $text ),
    'post_status'  => 'pending',
], true );

Notatet dokumenterer også filteret wp_ai_client_prevent_prompt. Når det returnerer true, gjøres ingen kall, is_supported_*()-kontrollene returnerer false og generate_*() returnerer en WP_Error. Det gir eieren av nettstedet én bryter for å stoppe generering, for eksempel utenfor en godkjent rolle eller under en revisjon. For funksjoner som vises i administrasjonspanelet, anbefaler notatet et eget REST-endepunkt på serversiden per funksjon, med egne tilgangskontroller.

AI Client gjør det enklere å generere tekst inne i WordPress. Den endrer ikke noe av Googles veiledning over: det den produserer, må fortsatt gjennomgås før det går live.

#Automatiske kvalitetskontroller for AI-utkast

Før en redaktør åpner et utkast, kan billige automatiske kontroller fange de åpenbare feilene. Dette eksemplet lagrer resultatene i innleggets metadata, slik at redaktøren ser dem i listen over innlegg som venter på gjennomgang:

// Automatiske kvalitetskontroller for genererte utkast
function automated_quality_checks( $post_id ) {
    if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
        return;
    }
    if ( ! get_post_meta( $post_id, '_generated_by', true ) ) {
        return;
    }

    $content = get_post_field( 'post_content', $post_id );
    $issues  = [];

    // Minimumslengde
    $word_count = str_word_count( wp_strip_all_tags( $content ) );
    if ( $word_count < 800 ) {
        $issues[] = "For kort: {$word_count} ord (minimum 800)";
    }

    // Interne lenker
    $internal_links = preg_match_all( '/href=["\']\/nb\//', $content );
    if ( $internal_links < 2 ) {
        $issues[] = "For få interne lenker: {$internal_links} (minimum 2)";
    }

    // Mellomtitler
    $headings = preg_match_all( '/<h[2-3]/', $content );
    if ( $headings < 3 ) {
        $issues[] = "For få mellomtitler: {$headings} (minimum 3)";
    }

    // Kildemarkører modellen har latt stå igjen
    if ( false !== strpos( $content, '[SOURCE]' ) ) {
        $issues[] = 'Påstander er fortsatt merket [SOURCE] uten kildehenvisning';
    }

    // Enkel duplikatsjekk
    $first_paragraph = wp_strip_all_tags( substr( $content, 0, 500 ) );
    $similar_posts   = new WP_Query( [
        's'              => $first_paragraph,
        'posts_per_page' => 1,
        'post__not_in'   => [ $post_id ],
    ] );
    if ( $similar_posts->have_posts() ) {
        $issues[] = 'Mulig duplisert innhold';
    }

    update_post_meta( $post_id, '_quality_issues', $issues );
    update_post_meta( $post_id, '_quality_score', empty( $issues ) ? 'pass' : 'needs_review' );
}
add_action( 'save_post', 'automated_quality_checks' );

Tersklene er eksempler for dine egne redaksjonelle regler, ikke tall fra Google. At et utkast består kontrollen, betyr bare at det er verdt et menneskes tid. Det sier ingenting om hvorvidt faktaene stemmer.

#Programmatisk SEO i WordPress i stor skala

Programmatisk SEO er den mest ambisiøse formen for automatisering: hundrevis eller tusenvis av sider bygget fra strukturerte data og maler. WordPress håndterer lagringen godt. Egendefinerte innleggstyper og egendefinerte felt (for eksempel med ACF) holder datamodellen, og REST API eller WP-CLI importerer oppføringer fra en ekstern database.

Spørsmålet er ikke om WordPress kan lagre sidene, men om hver side fortjener å finnes. Eksemplene på misbruk av innhold i stor skala beskriver nøyaktig hva som går galt: en mal der bare bynavnet endres, gir ingen verdi for leseren.

Typiske eksempler som kan fungere:

• Tjenestesider per sted: for et firma som tilbyr vedlikehold av WordPress i flere byer, trenger hver side data som stemmer for akkurat den byen: ekte prosjekter, ekte kundeuttalelser, den lokale kontaktpersonen og lokale forhold som endrer tjenesten.
• Integrasjonssider: for et SaaS-produkt trenger sider av typen “WordPress + [Verktøy]” de faktiske konfigurasjonsstegene, begrensningene i den integrasjonen og supportspørsmål som kom fra brukere av det verktøyet.

Regler vi bruker før vi genererer et slikt sett:

1. Hver side trenger unike data. Kan du ikke si hva som er annerledes på side 214 sammenlignet med side 213, skal du ikke publisere side 214.
2. Sjekk søkeintensjonen for hver variant. Bekreft at folk søker etter varianten før du bygger den.
3. Hold sider som ikke er gjennomgått, utenfor indeksen. Bruk noindex til siden har bestått gjennomgangen, noe spamregelen også ber om.
4. Følg med på indekseringen. Search Console viser hvilke genererte sider Google indekserer og hvilke den ignorerer.
5. Slå sammen tynne sider. En side uten trafikk og uten unike data slås sammen med en sterkere side eller fjernes.

#Hvordan oppdatere WordPress-innlegg med live API-data

Noe innhold er bare riktig når det følger et kildesystem. Her hjelper automatisering mest, fordi jobben er synkronisering og ikke skriving:

• Priser og tilgjengelighet: en produkt- eller abonnementsside leser pris og lagerstatus fra nettbutikken eller faktureringssystemet i stedet for en kopi i innleggsteksten.
• Referansedata som endres: en sikkerhetsartikkel kan vise listen over nylige sikkerhetsvarsler fra en feed som en planlagt jobb oppdaterer.
• Webhooks: en ekstern hendelse (en produktoppdatering, en ny versjon) utløser en oppdatering av de berørte innleggene via REST API.
• Headless WordPress: WordPress leverer innholdet via API-et sitt til flere frontender, så én oppdatering når alle kanaler.

Hold de genererte delene i blokker eller felt som malen viser, ikke i den redaksjonelle teksten. Da viser en feed som feiler en gammel verdi på ett sted, i stedet for å ødelegge artikkelen.

#Hvordan opplyse om AI-bruk og kontrollere metadata

Googles veiledning nevner to oppgaver som pipelines ofte hopper over.

Den første er metadata. Kravet om faktasjekk “gjelder også metadata som <title>-elementer, metabeskrivelser, strukturerte data og alternativ tekst for bilder”, fordi disse vises direkte i søkeresultatene. En generert metabeskrivelse med en feil påstand er like synlig som en feil setning i brødteksten. For strukturerte data ber Google deg også følge de generelle retningslinjene og reglene for hver enkelt funksjon, og validere markeringen.

Den andre er kontekst. Google foreslår at utgivere som genererer innhold automatisk, vurderer å “legge til informasjon om hvordan innholdet ble laget”, for eksempel bakgrunn om hvordan automatisering ble brukt og bildemetadata. Siden om nyttig innhold rammer dette inn som “Hvordan”-spørsmålet: om bruken av automatisering er selvsagt for besøkende gjennom opplysninger eller på andre måter. FAQ-en fra 2023 legger til at slike opplysninger er nyttige der noen kan spørre “Hvordan ble dette laget?”, og at det å oppgi AI som forfatter neppe er den beste måten å gjøre det på.

For nettbutikker har Google Merchant Center egne regler: AI-genererte bilder må ha IPTC-verdien DigitalSourceType satt til TrainedAlgorithmicMedia, og AI-genererte produkttitler og produktbeskrivelser må oppgis separat og merkes som AI-generert.

Oversatt til WordPress: lagre detaljene om genereringen i innleggets metadata (feltene --meta_input og meta over), vis en kort merknad om hvordan artikkelen ble laget der leserne forventer en, og la bylinen tilhøre personen som har gått gjennom teksten og står for den.

#Verktøy for å automatisere WordPress-innhold

#AI-verktøy for utkast

• AI Client i WordPress 7.0: generering inne i WordPress gjennom en tilkoblet leverandør.
• Leverandørenes API-er (Anthropic, OpenAI, Google): utkast i stor skala fra en ekstern pipeline.
• DeepL API: automatisk oversettelse, som fortsatt må gjennomgås fordi spamregelen nevner oversettelse brukt til å mangedoble sider.

#Verktøy for publisering

• WP-CLI: lager innlegg fra kommandolinjen eller fra en cron-jobb på serveren.
• WordPress REST API: kobler til eksterne pipelines via applikasjonspassord.
• n8n, Make, Zapier: orkestrerer arbeidsflyter uten egen kode.

#Verktøy for overvåking

• Google Search Console: indeksering og ytelse for genererte sider.
• Query Monitor: problemer med database og ytelse når antallet innlegg vokser.
• Egne rapporter: kvalitetsflagg fra innleggets metadata, tid brukt på gjennomgang og grunner til avvisning.

#Risikoer ved AI-generert innhold og hvordan du reduserer dem

Tynt innhold. Sett redaksjonelle minstekrav (unike data, kilder, interne lenker), hold sider som ikke er gjennomgått på noindex og revider genererte sett jevnlig.

Feilinformasjon. Gjør menneskelig faktasjekk obligatorisk for faktainnhold, og la modellen merke påstander som trenger en kilde, slik at redaktøren sjekker en liste i stedet for å lese alt på nytt.

Spamtiltak i søk. Følg regelen om misbruk av innhold i stor skala og veiledningen om nyttig innhold. Volum er ikke et mål.

Ujevn merkevare. Skriv en stilguide som systeminstruksjonen kan sitere, og sjekk terminologien automatisk.

Avhengighet av én leverandør. Modellpreferansene i AI Client og skjermen Connectors gjør det lettere å bytte leverandør. Hold promptene og kontrollene i din egen kode, så følger de med deg.

Tap av redaksjonell kompetanse. Behold folk som kan skrive og redigere. AI mangedobler det et team får gjort, men erstatter ikke vurderingen Google ber om.

#Hva du bør måle i automatisert innhold

Tabellen viser hva vi følger med på og hvor du leser det av. Målene hører til hvert prosjekt og bygger på prosjektets eget utgangspunkt, så ingen mål er oppgitt her.

#Hvor du starter med automatisering av WordPress-innhold

Innholdsautomatisering i WordPress fungerer når den drives med disiplin. Automatiser research, utkast, maler, berikelse og planlegging. La fakta, publiseringsbeslutningen og ansvaret for siden ligge hos mennesker. Googles veiledning trekker grensen tydelig: automatisering er tillatt, massesider uten verdi faller inn under regelen om misbruk av innhold i stor skala, og AI-innhold får ingen særbehandling, verken positiv eller negativ.

Et praktisk første steg er å liste opp sidetypene dine, datakildene bak hver av dem og reglene for menneskelig godkjenning, og deretter koble til bare én avgrenset arbeidsflyt, for eksempel briefer eller metabeskrivelser, med pending som eneste status pipelinen kan skrive.

Trenger du hjelp med automatiserte innholdsflyter i WordPress, kan du kontakte WPPoland. Vi jobber også med WordPress-utvikling og programmatisk SEO.