Automate Blog Featured Images: Everything That Happens After the Model Returns a Picture

Every post on this blog opens with an image nobody drew. It is generated, compressed, uploaded and captioned by the same routine that writes the post, and the whole thing runs before I read a word of it.

The generating takes about twenty seconds. That part is genuinely solved, and it is also the only part anyone writes about. Every guide I have read on this ends the moment a file exists on disk, as though the picture appearing were the finish line rather than the start of the work.

It is not. The four things that actually decide whether a generated hero helps or hurts happen after the model returns: what you asked for, how many bytes you ship, what you write in the alt field, and whether the file survives the trip into your CMS. I have shipped one of these every weekday for a while now, and every one of those four has broken on me at least once.

Here is the whole pipeline, including the parts that broke.

Why AI blog images look like stock photos

The failure mode is not the model. It is the brief.

Most prompts describe the article's subject. You are writing about marketing automation, so you type "an illustration for a blog post about marketing automation," and you get a person at a desk with a laptop and some floating gears. It is technically an image about marketing automation. It is also indistinguishable from the twelve thousand other images about marketing automation, which means it tells a reader nothing and gives them no reason to believe the page underneath it is any different.

A hero should encode the article's argument, not its topic. If the piece argues that the hard part of a publishing system is the state file rather than the writing, the illustration should show someone reading a file, not someone typing. That single shift does more for image quality than any model upgrade.

Four things ride in every prompt I send, in this order:

A fixed style clause, reused verbatim. Mine names a flat-vector editorial illustration, a dark tech aesthetic, a specific two-colour gradient accent, a soft glow and a wide composition. It never changes. Consistency across a blog is a decision you make once, not a judgement you re-make every Tuesday, and it is the difference between a blog that looks designed and one that looks like it was assembled from four different image tools.

A person doing the specific thing. Not a generic figure at a workstation. A builder orchestrating agents, or shipping an app, or reading a log. Naming the action is what stops the model from reaching for its default office scene.

Concrete objects from the article. Terminal windows, agent nodes, app cards, dashboards, whatever the piece is actually about. Abstractions produce abstractions.

An explicit ban on text. This is the one people leave out and then wonder why every third image has garbled pseudo-words in it. Image models are enthusiastic about labels and bad at spelling. I end every prompt with an instruction that only the short labels I named are visible, and that there is no other readable body text and no paragraphs. It does not work every time. It works most of the time, and the failures are obvious in a one-second glance.

Honest number: roughly one in five heroes gets re-run. Almost always because the model invented text somewhere, occasionally because it produced something handsome that says nothing about the article. Neither is a disaster, because a re-run costs twenty seconds. But anyone telling you this is fully hands-off is describing a version of the workflow they have not run for six months.

What size should a blog featured image be?

The question people ask is about dimensions. The constraint that actually matters is bytes.

A hero image sitting at the top of an article is a strong candidate to be the largest element the browser paints, which makes it the thing your Largest Contentful Paint score is measuring. Google's own Largest Contentful Paint documentation puts a good score at 2.5 seconds or less and a poor one above 4.0 seconds, measured at the 75th percentile of page loads across mobile and desktop. That percentile is the part worth sitting with: you are not being graded on your own fast laptop on office wifi. You are being graded on the slowest quarter of real visits.

A raw file straight out of an image model is frequently over a megabyte. Putting that at the top of an article, unconverted, is the single easiest way to fail that threshold on a phone, and it is exactly what happens when a workflow generates a file and uploads it without a step in between.

So invert the usual order. Instead of picking dimensions and accepting whatever byte count falls out, pick a byte ceiling first and let the encoder find the largest image that fits under it. In practice that means converting to WebP and searching a short ladder of width and quality pairs until one lands under budget.

The measured numbers from my own ladder, which I tuned by looking at real published posts rather than by theory:

• Around 800 pixels wide at low quality reads visibly soft on a good screen. Fine in a thumbnail, not fine as a hero.

• Around 1024 pixels at a middling quality setting is clean. This is the sweet spot.

• Around 1100 pixels at high quality is indistinguishable from the 1024 version to my eye, while costing meaningfully more bytes.

So the ladder tops out just above 1024 and never chases pixels nobody can see. That is the entire tuning insight, and it took me maybe an hour of comparing files side by side to arrive at.

My own ceiling is about 17 KB, which is aggressive to the point of being unusual, and I should say why rather than let anyone copy it blindly. My blog runs on a hosted platform with no publishing API, so the image reaches the CMS as text inside a browser automation step, and text is expensive in a way that bytes on disk are not. That is a constraint of my plumbing, not a law of the web. If you are uploading over a normal API, a ceiling somewhere in the 100 to 150 KB range gives you a visibly better image and still keeps you well clear of trouble.

Two smaller decisions worth copying. Generate at 16:9, because the same file becomes your social preview and you would rather not crop it twice. And name the file after the post slug, which costs nothing and satisfies Google's image guidance on descriptive filenames at the same time.

If you want to see what this looks like as a whole publishing system rather than one step of it, I wrote up the routine that surrounds this in how I publish a ranking post every weekday.

How to write alt text for an AI-generated image

Here is the mistake I made repeatedly, and had to be corrected on more than once: pasting the generation prompt into the alt text field.

It feels reasonable. You have a perfectly good description of the image sitting right there, so you paste it. Now a person using a screen reader is being read sixty words of art direction about electric-blue gradient accents, soft glow and wide compositions, none of which tells them anything about the page they are on. It is the worst of both worlds, useless to a human and stuffed with words that have nothing to do with the article.

Google's image documentation is direct about what the field is for. It calls alt text the most important attribute for providing metadata about an image, asks for "useful, information-rich content that uses keywords appropriately and is in context of the content of the page," and explicitly warns that filling the attribute with keywords "results in a negative user experience and may cause your site to be seen as spam."

My rule now is short and boring: the alt text says what the image is about in the language of the page. For this post, that is a four-word phrase naming the thing the post is about. Not a description of the illustration's composition, not the style clause, not a sentence.

There is a real tension here that I would rather name than paper over. On this blog the alt field doubles as an on-page signal, so it carries the target phrase. That is defensible only because the image genuinely is about that thing. The moment you find yourself writing alt text for a phrase the image does not depict, you have crossed from description into stuffing, and the guidance above is about exactly that line. The honest test is whether a person who cannot see the image would be helped by what you wrote. If the answer is no, it does not matter that it reads well to a crawler.

One more thing the guides skip: alt text and the image itself are separate quality problems. A perfect caption on a generic image is still a generic image.

The upload step, and what to do when your CMS has no API

Every workflow template I looked at assumes the same thing: your CMS has a REST endpoint, you post the file to a media library, you get an ID back, you attach it to the post. If that describes your setup, this section is easy and you can skim it.

Mine does not. This blog runs on a hosted platform whose publishing surface is a browser, so the file has to arrive the way a file arrives when a human picks it: as a real file object handed to a hidden file input, which the platform then uploads to its own storage and hands back a reference token.

I am not going to reproduce that as code, because the specific incantation only matters if you are on the same platform. The three lessons generalise, and they are the ones that cost me time.

The upload is not finished when the request returns. It is finished when the record holds a reference to the stored object. Those are different moments, often separated by ten seconds or more while the file makes its way to object storage. If you save immediately after firing the upload, you will save a record with an empty image field and no error anywhere.

Fill the record before you upload, and save once. This is the failure that confused me longest. The platform validates the whole record on save. Save a post whose title field is still empty and the entire thing is discarded, including the image you just successfully uploaded. The storage object genuinely exists. The upload genuinely worked. The image is still gone on reload, and nothing tells you why. Title, body and settings go in first, the image goes in last, and one submit persists everything together.

Verify somewhere other than where you uploaded. On my platform the hero does not render on the post's own page at all, only on the index. And the index lazy-loads it, so a perfectly good image reports a natural width of zero until you scroll it into view or force it to load eagerly. I have twice concluded an upload had failed when the only thing that had failed was my check.

The general principle underneath all three: when a step crosses a system boundary, verify the far side. Not the return value of the call you made, the state of the thing you were trying to change.

This is the same discipline that makes the rest of my publishing hold together, and it is why I keep the image step inside the same routine that writes the post rather than bolting it on afterwards. If you are building the surrounding machinery, the repurposing workflow I actually run covers how one trigger fans out into an article, social posts and the images for both.

Every image you generate is already watermarked

This is the fact that appears in none of the write-ups on this subject, and it changes how you should think about what generated art is for.

Google's image generation documentation states it plainly: all generated images include a SynthID watermark. Not an optional flag, not a setting. Every image, invisibly, by default. The same page documents the aspect ratios available, including the 16:9 you want for a hero, and the resolution tiers, where the cheapest model is limited to 1K and the larger ones go to 2K and 4K.

Two consequences follow, and only one of them is about compliance.

The first is that you cannot quietly pass a generated image off as a photograph, and you should not want to. That is not a restriction, it is a clarification of the job. A hero image is decoration and orientation. It tells a reader what kind of piece they have landed on and gives their eye somewhere to rest. It is not evidence.

The second is the line I hold as a result: the moment an image would carry a factual claim, it stops being a generated illustration and becomes a real screenshot or a real chart. No generated dashboards with numbers on them. No generated photographs of real people or real places. No generated anything that a reader could reasonably mistake for a record of something that happened. If a post makes a claim about what a tool did, the picture of that is a screenshot, taken by me, of the tool doing it.

I will not overstate the watermark either. It is designed to survive ordinary modification, and I have not tested how it fares through the aggressive re-encoding my byte budget puts every file through. Which is the point: a watermark is a provenance signal maintained by someone else, not a disclosure policy you get to outsource. Decide what you tell readers on your own terms.

Where a human still belongs

Ten seconds, once, before publish. I look for four things:

Invented text anywhere in the frame. Anatomy that went wrong, which is usually hands. Whether the image says anything at all about the article, or whether it is a handsome picture of nothing. And whether it looks like the last four heroes, because a style clause that is working produces a family resemblance, while a style clause that is working too hard produces four copies of the same image.

That is the whole review. It catches the one-in-five, and it is not worth automating away, because the thing I am checking is exactly the thing a model is worst at judging about its own output.

If you want the version of this that goes further than heroes for your own blog, the session I built the image side of my stack from is Own a Production-Ready AI Image SaaS, which walks through image generation as an actual product rather than an internal tool: credits, the storage layer, the billing plumbing, the parts that are boring and load-bearing. The full replay of that session is available instantly, and it ships the app itself. I pulled the compression and storage habits in this post more or less straight out of it. I also wrote up what building that taught me in the weekend playbook for an AI image SaaS.

Build it this weekend: five steps

1. Write the style clause once. One sentence naming the medium, the palette, the mood and the composition. Save it in a file next to your publishing instructions. Never edit it casually.

2. Write a prompt template that takes the argument, not the title. The input to your template should be one sentence describing what the article claims, plus the concrete objects that appear in it. Append the style clause and the no-text instruction at the end.

3. Set a byte ceiling before you write the converter. Then write a short loop that walks a ladder of width and quality pairs and stops at the first one under budget. Log the numbers it chose so you can tune the ladder later instead of guessing.

4. Wire the upload, then wire the verification separately. Fill every required field first, upload last, save once, and confirm the saved record holds an image reference rather than confirming the upload call succeeded.

5. Add the ten-second look, and log the filename beside the post slug. The log is what lets you go back six weeks later and see which prompts produced images you still like.

That is a weekend at the outside, and most of it is step three.

Get the sessions and the apps

I teach this kind of thing live every couple of weeks, and members of the Reinventing AI Accelerator get the live sessions plus the vault of apps, tools and agents that come out of them, including the image stack this post describes. If you are building your own publishing system and would rather see one running than read about one, that is the place to look. One small ask: come with a project you are actually stuck on, because the sessions are considerably more useful when someone brings a real problem.

Frequently asked questions

What size should a blog featured image be?

Set a byte ceiling, not a pixel target. Around 1024 pixels wide in WebP at a middling quality setting is clean as a hero and lands in a comfortable size range for most sites; below roughly 800 pixels it starts reading soft. Generate at 16:9 so the same file works as your social preview. The number that matters is how many bytes reach a phone on a bad connection, because the hero is usually what your Largest Contentful Paint is measuring, and a good score there is 2.5 seconds or less at the 75th percentile.

Do AI-generated images hurt SEO?

Nothing in Google's published image guidance asks where an image came from. What it asks is whether the image is useful, whether it is described accurately in the alt attribute, whether the filename is descriptive and whether the page loads quickly. A generated image that is relevant, well captioned and small does all four. An unconverted one-megabyte file with the generation prompt pasted into the alt attribute fails three of them, and that is what actually hurts you.

Should I disclose that a blog image is AI-generated?

Decide it as a policy and apply it consistently rather than case by case. Note that generated images already carry an invisible provenance watermark by default, so the question is not whether the information exists, only whether you surface it. My own line is simpler than a disclosure rule: illustrations can be generated, anything that carries a factual claim cannot. A screenshot has to be a real screenshot.

What should alt text say for an AI-generated image?

What the image is about, in the language of the page, in a few words. Not the generation prompt. Not a description of the art style. Google calls alt text the most important metadata attribute for an image and warns specifically against filling it with keywords, so the test is whether a person who cannot see the image would be helped by what you wrote.

Why do all my AI blog images look the same?

Two different problems wearing the same costume. If they look the same as each other, that is your style clause working and it is usually what you want, as long as the subject inside the frame changes. If they look the same as everyone else's, your prompt is describing the topic rather than the argument, and the model is falling back to the most average illustration of that topic it knows. Change what the person in the frame is doing and the objects around them, and leave the style alone.