# Image SEO and Alt Text in the Age of AI

**Author:** John Morabito (Founder, /winston)
**Published:** September 19, 2026
**Reading time:** 10 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/image-seo-and-alt-text-for-ai/

Images are the part of a page that does the most work on a person and the least on a machine. Someone looks at a photo of a finished kitchen and reads the style, the budget bracket, and whether they want it, in about a second. A crawler looks at the same file and gets a URL, a few kilobytes, and whatever you chose to say about it. Everything in image SEO lives in that gap.

The gap narrowed recently and people have over-read what that means. You can hand a photo to ChatGPT or Gemini and get a decent description back, so it is tempting to assume the systems building AI answers are looking at your pictures the same way. Retrieval does not work like that. The pipeline that decides which pages get pulled into an answer runs mostly on text, and even where a model can genuinely see an image, it leans on the words around it to decide what the image is of and whether the page is worth trusting. The practical rule has not changed: a picture can support a claim, but the text has to make it.

## What an engine actually receives about an image

Strip a page down to what a crawler gets about any single image and the inventory is short. The file name and the path it sits at. The alt attribute. The caption, if there is one, and the text immediately around it. The page it appears on and what that page is about. Any structured data that references the file. The dimensions, the format, and the file size. And, underneath all of it, whether the crawler can fetch the file at all.

That is the complete list, which is why image SEO stays tractable while other parts of the discipline get murkier. Every technique below is a way of putting real information into one of those slots. Either you filled a slot or you left it empty.

## File names, which are free and usually wasted

Most sites ship whatever the camera or the design tool produced. A folder of files called IMG_4821.jpg and Screenshot 2026-03-14 at 11.02.08.png tells an engine nothing, and it tells the person who has to maintain the site even less. A file called park-slope-brownstone-kitchen-remodel.jpg says something before anything else on the page has loaded.

Do not oversell this. A file name is a small signal and it will not carry a page on its own. It is worth doing because it costs nothing at upload time and because it compounds: descriptive names make your own media library usable, which makes every later decision about images faster. Rename before you publish, though. Renaming an image after the fact changes a URL that may already be indexed, linked, or cached, and that is a migration, not a cleanup.

## Alt text, written for the person it is for

Alt text has two jobs and they point in the same direction. It is the text alternative a screen reader announces to someone who cannot see the image, which is an accessibility requirement with real standards and, in many contexts, real legal weight behind it. It is also the most direct statement you make to an engine about what the image contains. The useful thing is that writing it properly for the first purpose is what makes it good for the second, so you never have to choose.

The test I use: if you read the alt text aloud to someone on the phone who is looking at the same page with the images switched off, would they understand what they are missing? That one question settles most of the edge cases.

- Describe what the image actually shows, in the context of this page. The same photograph of a storefront might be "the shop front on Fifth Avenue with the awning down" on an about page and "the accessible ramp at the side entrance" on a directions page. Context decides what matters.
- Skip "image of" and "photo of". A screen reader already announces that it is an image, so the prefix is noise repeated on every file.
- A sentence is usually right. Long enough to carry the information, short enough that nobody has to sit through it.
- Decorative images get an empty alt attribute, written as alt="", not a missing one. Empty tells the screen reader to skip it. Missing tells it to guess, and it will often read the file name out loud.
- If the image is a link or a button, describe where it goes or what it does, not what it looks like. The alt text on a linked logo should say where the link leads.
- If there is text inside the image, put that text in the alt attribute. Words baked into a graphic are invisible to everything that is not looking at the pixels.

The failure mode is ancient and still everywhere: alt text as a keyword slot. Strings like "kitchen remodel brooklyn kitchen renovation brooklyn contractor" are useless to a screen reader user, obvious to an engine, and they signal that the rest of the page was probably built the same way. The keyword belongs in the alt text only when the keyword is a true description of the picture, which, for a genuinely relevant image, it often is anyway.

> A rule worth adopting outright: if an image is worth putting on the page, it is worth describing, and if it is not worth describing, ask why it is on the page. Most sites carry a layer of stock imagery that fails both halves of that question.

## Captions and the paragraph around the picture

Alt text is an attribute. A caption is ordinary visible text sitting in the reading path directly under the thing it describes, and the difference does more work than people expect. People who can see the image perfectly well still read the caption. And because a caption is plain page copy, it is available to be the sentence an engine lifts when it summarizes what you showed.

The surrounding paragraph does even more. When a model or a crawler is working out what an image means, the nearest text is the strongest available context, and it is the part you were going to write anyway. So write it deliberately. If you publish a chart, state the finding in the sentence above it. If you publish a before and after, say what changed in words. If you publish a diagram of a process, list the steps.

This is the same discipline that makes an FAQ answer quotable rather than decorative, which I went through in [FAQ pages that win AI answers](https://www.winstondigitalmarketing.com/playbooks/faq-pages-that-win-ai-answers/). Self-contained text wins because a retrieval system can take one passage away from the page and it still stands up. A caption that reads "Figure 3" does not survive that trip. A caption that says what Figure 3 shows does.

## Image structured data, kept honest

Structured data will not make a weak image rank, but it removes ambiguity about which file belongs to which thing, and ambiguity is what makes engines cautious. The useful pieces are modest.

- Reference your primary image from the page's main schema type. An Article, Product, Recipe, or Event block that names its image ties the file to the entity the page is about rather than leaving it as one of many files that happen to be present.
- Use an ImageObject when you need to say more than a URL: a caption, the content URL, the creator, the dimensions. It is also where licensing information lives if you want your images eligible for the licensable treatment in image results.
- Keep product and recipe imagery attached to the product and recipe blocks specifically, since those are the places image presence is expected and a missing image is treated as an incomplete record.

The rule that matters more than any property is parity. Do not declare an image in structured data that the page does not actually show, do not caption it in schema differently from how you caption it on the page, and do not point at a file that returns anything other than the image. Schema that disagrees with the page is worse than no schema, because it converts a neutral gap into evidence that your markup cannot be trusted.

## An image a crawler cannot fetch is not an image

Before any of the labeling work pays off, the file has to be reachable. This is the part that silently breaks, because nothing about the page looks wrong to a human. The usual causes are worth checking in order:

- Lazy loading that only fires on a real scroll event, with no server-rendered source for the crawler to find.
- Images set as CSS background properties. A background image can be the right choice visually, but it is not an image as far as image search is concerned, and it carries no alt text.
- Images injected entirely by client-side JavaScript after load, which makes them dependent on rendering that may not happen.
- Hotlink protection, a firewall rule, or a CDN configuration that serves bot user agents an error or a placeholder.
- A robots.txt rule disallowing the media directory, usually added years ago for a reason nobody remembers.

Check by fetching an image URL directly the way a bot would, not by looking at the page in your browser. Your browser runs JavaScript, carries your cookies, and is not being filtered by whatever rule is blocking the crawler. The same reachability logic governs whether AI crawlers can get around your site at all, which I covered in [internal linking for AI crawlers](https://www.winstondigitalmarketing.com/playbooks/internal-linking-for-ai-crawlers/).

Then there is weight. Images are the largest thing on most pages, so they are where page speed is usually won or lost: serve a modern format, size the file to the largest dimension it will actually be displayed at instead of shipping a 4000 pixel original into a 600 pixel slot, set explicit width and height so the layout does not jump while it loads, and lazy-load what sits below the fold while eagerly loading the one image at the top. On an image-heavy site, an image sitemap is worth adding so the files are declared rather than only discovered.

## The rule: never let an image carry meaning an engine needs

Any fact a search engine or an AI answer might need has to exist as text on the page. The image can show it, reinforce it, and make it persuasive. It cannot be the only place the fact lives.

The violations are predictable once you start looking for them. Pricing laid out in a designed graphic. A comparison table exported as a PNG. Opening hours and an address baked into a hero image. Product specifications printed on a lifestyle shot. A process explained entirely by a flow diagram. Every one of those is a page that answers a question perfectly for a human and not at all for the systems deciding who gets cited. Every one of them is also unreadable to a screen reader, which is how you know the accessibility problem and the visibility problem were always one problem.

The fix is never to delete the graphic. Keep it, and write the same information underneath it in text. You lose nothing and the page starts being able to answer for itself.

## What the work actually buys

Three payoffs, worth separating because each one persuades a different person in the room.

- Image search and visual results. Still a meaningful traffic source in categories where people search by look, which is most of design, retail, food, travel, and every trade with a visible result. Labeled images are the entry ticket.
- AI answers. Labeled, captioned, described imagery gives an engine concrete evidence that you have actually done the thing you claim to do. It is a large part of why visual businesses with unreadable portfolios go missing from answers where they clearly belong, which I worked through for one of them in [SEO for interior designers](https://www.winstondigitalmarketing.com/playbooks/seo-for-interior-designers/).
- Accessibility, which carries an obligation the other two do not. It also produces the best alt text, because writing for a person who cannot see the image is what keeps the description honest.

## Where to start

An image audit gets unmanageable fast on a large site, so bound it. Work in this order and stop when you run out of appetite:

1. Find the pages that matter commercially and check whether any of them carry information only in a graphic. Fix those first, because that is the one failure that costs you answers outright.
2. Check that your images are fetchable by a bot. One blocked directory can be worth more than every alt attribute you are about to write.
3. Fix the alt text on the templates rather than the pages. Product images, author photos, logos, and card thumbnails are usually generated, so one template change corrects thousands of files.
4. Write real captions on the images that are doing argumentative work: charts, before and afters, process diagrams, case study photos.
5. Adopt a file naming convention for everything new. Do not rename the archive unless you have a reason worth the redirects.

None of this is exotic and none of it needs a tool you do not already have. The blocker at most companies is that nobody has decided the pictures count as content, so they stay decoration and nobody owns them.

Making a site legible to AI engines is the core of our [GEO service](https://www.winstondigitalmarketing.com/services/generative-engine-optimization/), and images are one of the places we most often find a business has been invisible for years for a reason nobody had looked at.

## Frequently asked questions

### Does alt text still matter for SEO now that AI models can see images?

Yes, and for a reason that gets missed. The fact that a model can describe an image you hand it directly does not mean the retrieval pipeline that assembles an AI answer is looking at your pictures. That pipeline runs largely on text, and even where a system can process the image, the words around it are what establish what the image is of and whether the page is credible. Alt text remains the most direct statement you make about an image's content, it is what image search reads, and it is a genuine accessibility requirement independent of any search benefit. Nothing about multimodal models makes an unlabeled image easier to use.

### What makes alt text good?

It describes what the image actually shows, in the context of the page it sits on, in about a sentence. Skip openers like "image of" or "photo of", because a screen reader already announces that it is an image. Let the page decide what matters: the same storefront photo should be described differently on an about page than on a directions page. If the image is a link or a button, describe where it leads or what it does rather than what it looks like. If there is text inside the graphic, put that text in the alt attribute, because words baked into pixels are invisible otherwise. The reliable test is whether someone who cannot see the image would understand what they are missing from your description alone.

### Should every image have alt text?

Every image needs an alt attribute, but not every image needs a description. Images that carry meaning get a real description. Purely decorative images, such as a background texture or a divider flourish, get an empty attribute written as alt="". The empty attribute is doing real work: it tells a screen reader to skip the image, whereas leaving the attribute off entirely leaves the software to guess, which often means reading the file name aloud. So the choice is between describing the image and explicitly marking it as decorative. Leaving it out is not one of the options. It is also worth asking why an image that has nothing to describe is on the page at all.

### What image structured data should I use?

Reference your primary image from whatever schema type the page already declares, so an Article, Product, Recipe, or Event block names its image and ties the file to the thing the page is about. Use an ImageObject when you need to express more than a URL, such as a caption, the creator, the dimensions, or licensing information if you want the images eligible for the licensable treatment in image results. Product and recipe imagery in particular belongs attached to those blocks, since a missing image reads as an incomplete record. The rule that matters more than any individual property is parity: do not declare an image the page does not show, do not caption it differently in schema than on the page, and do not point at a URL that fails to return the image.

### Why would my images not be showing up in search at all?

Usually because a crawler cannot get to the file, and the page looks perfectly normal to you while that is true. The common causes are lazy loading that only fires on a real scroll with no server-rendered source, images applied as CSS background properties, which are not images as far as image search is concerned and cannot carry alt text, images injected entirely by client-side JavaScript after load, hotlink protection or a CDN rule that serves bot user agents an error, and a robots.txt line disallowing the media directory that somebody added years ago. Test by requesting an image URL directly the way a bot would rather than by viewing the page in your browser, because your browser runs JavaScript, carries your cookies, and is not subject to whatever rule is doing the blocking.