AI Generated Images for WordPress Posts and Pages

The post is finished. It needs a header image. Twenty minutes later you are comparing three near-identical photographs of a woman pointing at a whiteboard, the good one costs 14 dollars, the free one carries a watermark, and the publishing slot has not moved. So you take something off a search results page, drop it into the editor, and quietly inherit whoever’s copyright that was.

AI generated images for WordPress exist to break that loop. Most write-ups describe a workflow that does not survive a real publishing schedule though: a prompt box, a spinner, a credit balance, and four re-rolls before anything is usable. There is a second model that fits editorial work better, and it answers the licensing question that actually keeps agencies awake.

We build and sell both WordPress plugins named below, so weigh what follows accordingly. The workflow arguments apply whatever tooling you use.

AI generated images for WordPress: generate-and-wait versus search-and-pick

The generate-and-wait model is the familiar one. You write a prompt, a GPU renders it, you wait, you judge, you adjust, you wait again. It buys specificity: if you need a red bicycle on a wet street at dusk, you can iterate until you have exactly that. It costs latency and, usually, money per image.

The search-and-pick model inverts the trade. Instead of commissioning a render you query a corpus of images already rendered. Our own plugin, AI Images for WordPress, taps the Lexica.art API together with Stable Diffusion, a latent text-to-image diffusion model, and puts a searchable database of 9 million prompts behind a block in the editor. You type what you have in mind, browse the results, and pick.

Be clear-eyed about what you give up: no specific composition on demand, no product of your own in the frame, no fourth variation of a result you nearly liked. You take what exists.

For most editorial work that is the right trade. A 1,600-word article does not need commissioned art, it needs a slot filled with something relevant that does not misrepresent the content, and judging twenty candidates on screen beats describing one in words and hoping.

Rule of thumb: if the image is decoration with a topical hint, search and pick. If the image is the point of the page - a diagram, a screenshot, a specific product - neither model helps and you should be making it yourself.

Are AI generated images copyright free?

This decides whether any of it is usable on client work, and a vague answer is worse than none.

The plugin’s position is concrete: every image in the searchable database is public domain, usable by anyone for any purpose, not subject to copyright, publishable without licensing or attribution. That is why the search model matters commercially - the rights question is settled before you insert the image, not after somebody’s reverse-image-search bot finds it.

Some wider context, none of it legal advice:

• Copyright offices in several jurisdictions, including the US, hold that a work produced without human authorship is not registrable. That is why machine-rendered output tends to land in the public domain, not a reason to relax about every image you find online.
• Public domain answers copyright. It does not answer trademark or personality rights. A generated image containing what looks like a real logo, or a face resembling a real person, is still a problem on an advertisement even if nobody owns the pixels.
• Keep a provenance note on client projects. A line in the handover doc saying which images came from where costs nothing now and settles arguments later.

The real difference from stock photography is not price. It is that you stop maintaining a licence ledger, and stop wondering what breaks when the subscription lapses.

What the plugin needs before it works at all

Three requirements decide this before you evaluate a single image.

• The Gutenberg editor. The importer is a block. If the Classic Editor is your default you can still switch to Gutenberg on an individual post to bring the image in, then carry on however you like.
• WordPress core above 5.0. Anything still receiving security updates clears this easily.
• Rate limiting. Image search is subject to API call limits set by Lexica.art. That rarely bites on a one-image-per-post rhythm. It bites when you backfill headers across forty archive posts in one evening, so batch that work - ten posts a week is a workflow, forty in a sitting is a rate-limit ticket you file against yourself.

Inline in the body, or set as the featured image

The plugin can place a chosen image directly into the body of a post or page, or set it as the featured image. These look like the same action in the editor and behave completely differently everywhere else.

The featured image travels. It is what your archive grid renders, what most themes push into the Open Graph tag that Slack and LinkedIn unfurl, and what an RSS feed or a newsletter built from it picks up - four or five appearances, at crops you did not choose. Body images do not travel: they break up long text and are read in context.

1. Featured images are chosen for the grid, not for the post. Open your blog index and look at eight together: if three are the same purple-gradient abstraction, the grid is telling readers the posts are interchangeable. Check the crop your theme uses too - a 1:1 picture in a 16:9 card loses its top and bottom.
2. Body images earn their place or come out. An image that illustrates nothing in the paragraph beside it is weight the reader pays for and gets nothing back from.

Hosting the file yourself is not a detail

Every image you select is downloaded into your own WordPress media library, served from your domain rather than fetched from an external service at page load. That reads like a footnote. It is the whole point.

Hot-linking from a third party means:

• Their rate limits, uptime and pricing decisions become yours, mid-campaign, without warning.
• You cannot set cache headers, so the asset never benefits from your CDN or your cache policy.
• Your readers’ browsers request a host you do not control, a privacy disclosure you now have to describe.
• WordPress cannot generate its sized variants, so no srcset is emitted and mobile visitors download the desktop file.

That last one matters most. A real attachment gets thumbnail, medium, medium_large and large versions plus a srcset, so a phone pulls a 768px file instead of a 1,600px one. A remote <img> with a bare src gets none of it, and on a hero image that is often the difference between passing and failing Largest Contentful Paint.

The same argument covers the other automated route into the library. Our WordPress Image Scraper pulls every image from a given URL and stores each file locally as a normal media library upload rather than hot-linking it, over http or https, handling .jpg and .png. It needs the php-curl extension and a trailing slash on the URLs you feed it. It is a migration and own-asset tool: pointing it at a competitor’s gallery puts their photographs on your server, which is exactly as bad an idea as it sounds.

The housekeeping every automated import creates

Any tool that deposits files into the media library without a human at the keyboard creates the same three-part debt, and that is where most image SEO problems genuinely start.

Filenames. An imported file arrives named by a machine. Renaming later means every reference to the old URL has to move with it, so the cheap moment to fix a filename is immediately after import, while the image is used in exactly one place.

Alt text. No importer can write this, because alt text describes what the image contributes to this page. Accessibility requirement first, ranking signal a distant second. Decorative images should carry an empty alt="" rather than a keyword-stuffed sentence a screen reader has to read aloud.

Byte weight. The hero is usually the LCP element, and LCP is the Core Web Vitals metric most likely to fail. Convert to WebP, which typically saves 25 to 35 percent over JPEG at equivalent quality, and keep the hero under roughly 200 KB. Lazy-load everything except that first image - modern WordPress tries to skip lazy loading on the first content image and add fetchpriority="high", but verify it in DevTools rather than trusting it.

Where an AI hero helps, and where it costs you

It helps on conceptual blog posts, category headers, newsletter banners, 404 pages and social cards - anywhere the image sets a mood and no reader believes it documents anything.

It costs you on case studies, team and about pages, testimonials, pricing pages and any B2B page where the buyer is deciding whether you are real. A generated image there reads as a shortcut, and a buyer who spots one starts looking for others. The tell is rarely six fingers any more - it is the plastic sheen and the lighting with no source.

The test: could a reasonable reader think this image documents something real - a place, a person, a product, an event? If yes, do not generate it. Photograph it, screenshot it, or leave the space empty.

The pre-publish routine

Six steps, in this order, every time an image arrives through an automated route:

1. Search the concept, not the literal subject. “Isolation” returns better editorial imagery than “man alone at desk”.
2. Judge the candidate at the size it will be seen, including the archive grid crop.
3. Import it, so the file lands in your media library, not a remote URL.
4. Fix the filename immediately, while the image is referenced in one place.
5. Write the alt text yourself, or set it empty if the image is decorative.
6. Convert to WebP, confirm the hero is under about 200 KB, then apply the documents-something-real test once more. If it fails, ship without an image - a clean page beats a page that looks staged.

Backfilling an archive? Do not start at the oldest post. Sort by traffic, take the ten highest-traffic pages with no featured image, and stop there for the week.