Umbraco AI Content Generation: Text, Images and Translation Editors Actually Use

Umbraco AI content generation works when AI sits inside the editor’s existing workflow: a generate button next to a text or media property, page drafts built from an existing Block Grid layout, and translation that writes into the right language variant without touching block structure. Prompts should know which field they fill and its limits, every result should pass a human review before publish, API keys should stay on the server, and costs should be capped per field, per page and per job.

This guide covers where to put AI in the Umbraco back office, how to design prompts around property types and blocks, how to translate Block Grid and Block List content safely, and how to handle moderation, data and cost. The examples come from OSKI’s client work and from the four Umbraco AI packages we maintain.

What editors actually use

The rule of thumb is simple: editors keep using AI that saves them a switch of context and drop AI that adds one.

Features that get used:

• Field-level text generation: meta descriptions, summaries, product or course descriptions, first drafts of rich text.
• Image generation or search inside a media property, so the image lands in the Media library without a download and upload.
• Page drafts from a known layout, when a site has many similar pages.
• Translation of whole pages or branches into an existing language variant, with a clear status of what is done and what is out of date.

Features that tend to be ignored: a separate “AI section” that requires copying text back into fields, chat windows that do not know which page is open, and generators that produce one long blob of text the editor has to split into blocks by hand.

Worked example: EducatedOn

EducatedOn manages courses, tests and learning materials in Umbraco on Umbraco Cloud. OSKI added OpenAI text generation to text string, textarea and Rich Text Editor fields, and image generation through the Stability API, with generated images uploaded to Umbraco and placed into the content automatically. The work started by refactoring an existing Umbraco package, which gave the AI features a stable base. The EducatedOn case study reports that editors now generate text directly inside Umbraco, images land in content without manual uploading, and content creation became significantly faster.

Where to put AI in the Umbraco back office

There are three placements, and most sites need more than one.

Field-level: the button next to the property

This is where editors spend their time, so it is where AI pays off first. umContentCreator, our free MIT-licensed package, gives text box, text area and rich text properties a generate button. Editors set a maximum word count and a model behavior slider, write a prompt, then append the result to existing content, replace it or regenerate. Media properties can create an image from a phrase with the Stability AI API or find one through Google Custom Search with region and usage rights settings. Setup is a data type swap on the document types, so templates and content structure stay the same. Release lines exist for Umbraco 10, 15 and 17.

Page-level and batch: a section with history

Long-running work does not belong in a modal. umContentGenerator, also free and MIT licensed, runs in its own Content Generator section on Umbraco 17.3 to 18.x. You pick an existing page as a template; it copies the Block Grid or Block List structure, including nested blocks, into a new page of the same document type and fills each text block and image slot with new content based on a title and context notes. Generation runs as a background job, so long pages do not hit proxy timeouts, and a history table shows status, text and image counts and run time. The new page can be saved as a draft or saved and published.

umBlogGenerator applies the same idea to SEO comparison posts. It is free to use but not open source, and it maps its output into your blog document type’s Block Grid property and element types.

Umbraco’s own AI foundation

Umbraco HQ now offers Umbraco.AI, a foundation for AI in the back office, along with Umbraco.AI.Prompt for property prompts, both on the Umbraco Marketplace. The docs describe a chain from provider to connection (credentials) to profile (model, temperature, max tokens and a system prompt template) to each AI request, with middleware and guardrails, built on Microsoft.Extensions.AI. Umbraco lists providers including Anthropic, OpenAI, Google, Amazon Bedrock and Microsoft Foundry, and states that “AI never publishes content on its own.” Copilot and further agent capabilities are described as rolling out. If you are starting a new integration on Umbraco 17 or later, check whether it should sit on this foundation rather than calling a provider directly.

On versions: Umbraco 17 is the current long-term support release, supported until November 27, 2028, and Umbraco 18, published in June 2026, is a standard-term release. Most new AI packages, ours included, target Umbraco 17 and .NET 10.

Prompts tied to property types and Block Grid structure

A generic “write content about X” prompt produces generic content. The fix is to build each prompt from what Umbraco already knows about the field.

Inputs worth passing to the model for every generation:

• Property purpose: the property name, alias and description from the document type. A well-written property description (“One sentence, shown on listing cards”) is already a prompt.
• Format and limits: plain text versus rich text, maximum length, whether headings or links are allowed. Enforce limits in code too; models miss character counts.
• Page context: the page title, document type and neighboring field values. Umbraco’s own property prompts read surrounding content for this reason.
• Block context: for a block inside a Block Grid or Block List, the element type, its position and what the blocks before and after contain.
• Site rules: tone of voice, banned claims, terminology. Put these in one shared instruction (a profile or settings screen), not in every prompt.

How Block Grid data shapes generation

A Block Grid value is JSON with a layout section and separate contentData and settingsData entries for each block, each linked to an element type by key. That structure is useful: you can generate content per element type with a prompt specific to that block (“hero heading, max 8 words”, “FAQ answer, 2 to 3 sentences”) and leave settings such as column spans, colors and visibility untouched.

The rule we follow: AI writes values into content properties; code owns structure, keys and settings. A generator that asks a model to return a full Block Grid JSON document will eventually return invalid keys or a broken layout.

Translation that keeps Block Grid and Block List structure

Translation is the AI feature with the clearest return on multilingual Umbraco sites, and also the easiest to get wrong. The common failure is sending a whole property value, JSON and all, to the model and writing back whatever comes out.

A safe approach:

1. Walk the structure. Recurse through Block Grid, Block List and nested blocks, property by property.
2. Use editor-aware handlers. Rich text needs markup and links preserved, a multi-URL picker needs only its link titles translated, multiple textstrings need each item translated separately, plain strings are simple.
3. Translate values only. Send text to the model; keep keys, element type references, layout and settings in code.
4. Exclude what must not change. Product codes, brand names and fields such as URLs or IDs should be marked to keep unchanged.
5. Write to the target culture and record what was translated, from which source version.
6. Track state. Flag pages that need translation, need an editor check or are out of date because the source changed.

This is how umContentTranslator works. It translates content trees and dictionary items with Claude or OpenAI on Umbraco 17 and 18, walks nested Block List, Block Grid and single-block editors field by field, has separate handlers for rich text, Markdown, multiple textstrings, multi-URL pickers and plain strings, supports exclusions and custom translation instructions for tone or terms, and translates meta titles and descriptions when SeoToolkit MetaFields is installed. A Translation Logs view shows jobs, warnings and errors per node. Unlike our other packages, umContentTranslator is commercial: it ships under an OSKI EULA with a built-in free trial, and a perpetual license covers one domain including its development, staging and test instances.

On the Nordic language learning platform we built a translation-aware editor as one of three custom back-office tools, which is another reminder that translation is a workflow problem as much as a model problem.

Moderation and review before publish

AI output should be treated as a draft until a person has approved it. The question is how to make that review part of the workflow instead of a hope.

Worked example: teacher-approved hints at TutorPro

TutorPro is not an Umbraco site, but its moderation pattern transfers directly. Azure OpenAI writes exercise hints from the exercise type, the task and the correct answers, and the prompt keeps the answer out of the hint. Teachers can edit, regenerate, delete or approve each hint before any student sees it. The TutorPro case study describes the result: AI hints reach students only after a teacher approves them.

In Umbraco terms, the same pattern looks like this:

• Default to draft. Generators save, they do not publish, unless an administrator explicitly allows otherwise for a specific job.
• Mark AI content. Keep a log of which nodes and properties were generated or translated, by which model, and when.
• Use states. “Needs editor check” is a real status, visible in a dashboard, not a mental note.
• Restrict access. Grant AI sections and settings to specific user groups. Umbraco hides new sections until they are allowed for a group, which is a useful default.
• Check claims and facts. Product specs, prices, legal text and medical or financial statements need a subject-matter review, whatever the model.
• Check images. Generated images need the same rights and accessibility review as stock images, including alt text written for the page.

API keys and data handling

AI features in a CMS send your content to a third party. Plan for that on day one.

Keys

• Keep keys on the server. The browser should call your back-office API, never the AI provider directly.
• Load keys from configuration or environment variables in production, or from a settings screen that stores them securely. umBlogGenerator, for example, accepts keys from its settings screen, appsettings.json or environment variables, and stored keys are never returned by its settings API.
• Use separate keys per environment and per site so you can rotate and attribute spend.

Data

• OpenAI states that data sent to its API is not used for training unless you opt in, and is retained for abuse monitoring for up to 30 days by default. Anthropic states that inputs and outputs from its commercial products, including the API, are not used for training by default.
• With Azure OpenAI, Microsoft states that prompts and completions are not available to OpenAI and are not used to improve the models, which some organizations prefer for data residency and contracts.
• Only send the fields being generated or translated. Do not include member data, form submissions or unpublished personal content in prompts.
• Licensed packages may also call a licensing service. umContentTranslator sends the license key, domain and instance ID to the OSKI licensing service, separate from the content that goes to your AI provider.
• Update your privacy documentation and processor list to name the AI provider.

Cost control

AI packages for Umbraco usually run on your own API key, so you pay the provider directly. Spend scales with output length, number of fields and how often jobs rerun.

Implementation checklist

• Decide placements: field buttons, page actions, batch sections.
• Write property descriptions that double as generation instructions.
• Define site-wide tone and terminology rules once.
• Generate per block and per property; let code own Block Grid structure.
• Translate values only, with editor-aware handlers and exclusions.
• Default to draft; add “needs editor check” states and an audit log.
• Keep keys server-side; restrict sections to the right user groups.
• Name the AI provider in privacy documentation.
• Set caps, per-job model choice and monitoring before rollout.

If you want to add AI generation or translation to an existing Umbraco site, start with one field type and one translation flow, measure how editors use them for a few weeks, then expand. Our Umbraco development team builds these features as custom back-office extensions or on top of our packages, depending on how much of your workflow is standard.