AI system for generating alt texts for images: automation and SEO

AI alt text generation: where indexing breaks

An image in a catalog is an independent entry point from image search, and it gets lost quietly.

An empty alt attribute, the same description across a thousand items, or a caption assembled by substituting the section name — and the image drops out of search results, even though the page is formally indexed.

The reason is almost always organizational: descriptions are assembled once and manually. While the catalog is small, the team can go through the albums in full, but at thousands of items the markup diverges from the product range.

Some product cards are left with an empty alt, others with a placeholder like "product photo," and the search engine does not distinguish them.

Template image descriptions break differently.

A substitution like "{category} buy" formally fills the attribute, but it does not describe the content and repeats across hundreds of pages: search does not understand what is in the image, and the entire section looks low-content. Categories where angle, configuration, or color differ suffer most.

Automatic image description removes dependence on manual passes. The system looks at the image itself and builds a caption from the content — what the item is and how it is shown — rather than from the section name.

Uniqueness and correspondence to content are checked before writing to the markup, so duplicates and empty values do not accumulate between exports.

Below we look at how AI alt text generation closes these gaps and what is needed for image indexing in the catalog to hold up without manual support.

Measurable effect: indexing coverage, speed, eliminated failures

The effect of alt text generation is measured not by the number of described images, but by what changed in the index and in the pace of the content team's work.

Before implementation, we record a baseline: the share of catalog pages in the index, image coverage in search, the number of markup errors, and the time to publish one item.

We repeat the same measurements on the same sample after launch — otherwise "it got better" remains an opinion.

What we check after implementation:

• Share of indexed pages with images — grows due to product cards that previously dropped out of search results because of an empty or template alt.
• Image coverage in search — images are found by semantic queries, not only by file name.
• Speed of catalog filling — publishing an item does not wait for a manual description: captions arrive together with the upload.
• Class of markup errors — alt duplicates, captions like "image_01," and empty values go away; only isolated corrections remain.
• Description automation — the share of human edits falls to spot-checking rather than full rewriting.

We take the quality benchmark from Google Search Central recommendations: alt describes the content and function of the image in the page's language.

We selectively check some generations manually and calculate the share of edits — it shows whether the system maintains the bar without constant editor involvement.

Batch, streaming, and manual image description modes

The three modes are not competing systems, but entry points into one set of description rules. The only difference is how an image enters processing and who confirms the result: a batch pass over the entire catalog, item-by-item description at upload time, or human proofreading.

The choice of mode is determined by the publication flow and how critical accuracy is for a specific catalog section.

Switching between modes does not require migration: descriptions are tied to the image identifier in shared storage.

Therefore, the catalog can be run once as a batch, then new items added in a stream, and disputed wording on important pages resolved manually — without reprocessing what is already done.

In practice, the working option is mixed: batch covers the already accumulated catalog, streaming picks up new items, and manual review remains a filter for pages that bring traffic.

Describe your publication flow and archive volume — we will return with an estimate and a mode scheme for it.

Implementation stages: from markup audit to handover of guidelines

Implementation proceeds from facts, not from the model: first we measure what is already marked up, and only then configure the system.

In a catalog with thousands of items, 30-40% of images usually come with an empty attribute or a service file name — and until this is measured, AI alt text generation works on noise.

1. Markup audit. We export images together with their environment — title, category, adjacent text — and sort them into groups: empty attribute, service name, duplicate, meaningful description.

   The output is a table of shares and a list of pages where markup hinders both indexing and accessibility.

2. Description schema design. We define sources of facts for each group of pages: product card properties, category, block content. We fix the description structure — what comes first, what is mandatory, what varies — so that neighboring cards do not receive identical texts.

3. Description language setup. We set length, grammatical cases, stop words, and rules for images without useful context. For decorative elements, we separately specify an empty attribute — otherwise garbage goes into the markup.

4. Description quality check. We run a control sample and look at the share that passed the rules, the share that are unique, and the number of filter triggers. We review discrepancies manually and return them to the settings until the result stabilizes.

5. Trial launch on a limited group of pages. We capture metrics: share of images with descriptions, correctness of insertion into markup, and processing time for the export. We expand coverage only after a stable result.

6. Handover of guidelines. We provide the client's team with instructions: how to add new rules, what to do with new page types, how to check the export, and where to look in case of discrepancy. After that, the system is maintained internally, without external support at every step.

Documentation, markup schemas, and handover guidelines

After launch, the client retains not only a working service and access credentials, but also a set of documentation by which the system can be developed without us.

We record not "how to press a button," but how the decisions are structured: why the description is formed in this particular way and where the boundaries of automation lie.

• System documentation. The image path from upload to description writing, component composition, failure points, and behavior when external services are unavailable.
• Image markup schema. Types of pages and entities, links between an image and a product or material, required fields, and conflict signs.
• Description formation rules. Length, structure, tone, handling of trademarks, duplicates, and repeated images.
• Editor instructions. How to process the review queue, where to override generated text, how to mark an error — with examples of correct and incorrect descriptions.
• Description update guideline. Regeneration triggers: product range change, new page template, mass image replacement.
• Configurations and dictionaries. Stop lists, thematic dictionaries, confidence thresholds, and exception rules by catalog section.
• Responsibility map. Who approves rule changes, who accepts new page types, and how knowledge is transferred to a new employee.

Everything is stored in a repository alongside the code and versioned: rule changes go through approval, and the edit history is preserved. A new team gets up to speed from documents, not from chat correspondence.

Case study: e-commerce catalog — indexing coverage tripled

What it was like before implementation

We analyze a case of description automation in an e-commerce catalog: about 6,200 items, and in 4,800 product cards the alt attribute was empty or contained a file name like IMG_0421 — for search, such images did not exist.

The content manager filled everything manually: 3-4 minutes per card, 40-60 items per week, meaning the catalog would not be completed even in a year.

What was changed

The task was split into three layers. Recognition determines what is in the image: product category, color, material, angle. Description assembly uses templates with substitution of card attributes, so alt matches the page content instead of turning into a set of keywords.

A task queue fills in new items during catalog export, and we take measurements from Google Search Console reports — it shows which pages actually got into the index.

Metrics before and after

What limitations emerged

The implementation experience also revealed the limits of applicability. Infographics with embedded text — size grids, composition, delivery terms — remained for manual review: the model sees the image, but not the meaning of the table inside it.

Group shots with several products are described by the foreground; templates were additionally adjusted for them separately.

And most importantly: alt by itself does not replace work on texts — the growth in indexing coverage came from the combination of "description + attributes + internal linking."

How AI description differs from template substitution of names

Template substitution assembles a string from catalog fields: name, category, brand, sometimes color. Engineering-wise, it is an operation on text — the same input gives the same output, with full predictability.

While the catalog has uniform images with descriptive names, this is enough: the description is formally filled and does not get in the way.

It all breaks on a gallery of 8–12 shots of one product. The template outputs the same string for all of them, and the page gets a dozen duplicates differing by suffix.

Search engines see the repetitions and get no signal about what is in a specific shot: overall view, packaging, kit, component part.

The second class of errors is irrelevance. Substitution does not know what is in the photo: if the name says "office chair" but the shot shows a rocking mechanism, the alt text describes something other than what is visible. This hurts both search and people who use a screen reader.

AI image description proceeds from the shot: the model compares what it sees with the context of the page and category and formulates a string for the specific image.

The share of unique descriptions across the gallery grows from a few to almost full coverage, and matches remain where the shots are truly identical.

Comparison of the approaches comes down to two measurements: the share of unique descriptions after normalization and the share of strings matching the content of the shot during spot-checking. The first is calculated by a script, the second by manual labeling of the sample. On uniform catalogs the gap is minimal; on complex ones it is multiple times larger.

Technical concerns: quality, duplicates, behavior during failures

Description accuracy is checked not on a dozen examples, but on a sample: the text is compared with the content of the shot and the purpose of the page, and discrepancies are recorded as a markup defect.

For each class of images, a closed set is defined of what must go into the description — object, action, context — and what is prohibited: guesses about people, brands, or numbers. Anything outside these bounds goes to manual review, not into the markup.

Repeating descriptions are suppressed before writing: the wording is normalized and compared with those already issued within the section, and if the match is high, it is reassembled.

If uniqueness is not achieved within the allotted attempts, the image goes to an operator for review — the catalog is not filled with uniform strings.

What happens if the image source or the page is unavailable?

The task remains in the queue and is retried with an increasing delay; writing is not performed until both the image and the page context are obtained.

The current description in the markup is not overwritten: until a new one is generated and checked, the previous text remains on the site. A failure of one stream does not block the others — the queue is processed in parts.

Which images does the system not process?

Decorative elements, backgrounds, separators — by the rules they are supposed to have an empty description. Diagrams, dense collages, and screenshots with small text are recognized unreliably, so they go to manual labeling.

Such limitations are discussed in advance — you understand what share of the catalog is processed automatically and what requires an operator.

Let's discuss the task: what to prepare for the conversation

To keep the task discussion to one conversation rather than three, it is useful to gather the inputs in advance.

They determine the architecture of alt text generation: where the system gets images from, which fields it uses to build the description, and how the result gets into the catalog markup. Below is a list that removes most questions at the start.

• Catalog data sources: product export in a file, access to the product card interface, or a database query. It is important which fields are available — name, category, attributes, manufacturer.
• Image storage: where the files are stored, how permanent URLs are formed, and whether images are accessible without authorization.
• Current markup: how the image description attribute is filled now, whether there is a template, and whose area it is in — the site theme, the product card component, or the content management system.
• Image types: main product photo, gallery, infographics, promo banners. Each needs its own description format.
• Volumes and frequency: how many items are in the catalog now and how quickly new ones appear.
• Languages and style requirements: one language or several, length restrictions, whether category mentions are needed.
• Operating mode: one-time processing of the entire catalog, generation at product upload, or both scenarios together.
• Acceptance criteria: who checks quality and by which metric — the share of descriptions accepted without edits and catalog coverage.

After the discussion, we will return with an estimate and work plan: the generation scheme, the order of outputting descriptions into markup, the composition of stages, and timelines.

If some inputs are unavailable, that is not critical — we will gather them ourselves during the analysis stage. The next step is a short call on the listed points and a written plan with an estimate.