Why alt text for images breaks on a product stream
A catalog with several thousand items almost always hits the same wall: alt text for images is filled in formally. At the start, a content manager writes descriptions manually and maintains quality, but when adding hundreds of products a week, the manual pass stops scaling.
Empty alt values appear on some cards, duplicate alts appear in whole groups, and descriptions like "photo 1" that carry no meaning for either search or a person.
Then the accumulation effect kicks in. Mass catalog markup is done using a "category + SKU" template, and a month later half the cards differ only by the digit at the end.
Search engines see uniform text and stop considering it relevant, while products with unique characteristics — color, material, purpose — lose visibility in image search results.
A user with a screen reader hears "product image" instead of a description and doesn't understand what's in front of them.
The cost of the mistake isn't only in rankings. When alt text for images diverges from the actual content — mixed-up models, outdated photos after an assortment change — this is a direct path to returns and complaints: the buyer relied on a description they never saw.
Manual proofreading doesn't catch such a discrepancy on a stream, and the template only replicates it.
The problem isn't that the team isn't trying, but that manual and template approaches can't handle the volume. There needs to be a way to generate meaningful descriptions for each image and check them for duplicates and empty values automatically. Let's break down how this is solved.
How alt-text generation for images closes these gaps
What changes in catalog metrics
Automatic markup closes the main measurable gap: the share of images with filled-in alt text grows from 20–30% (the usual state of a catalog where editors get to the cards last) to 95%+ across the entire array.
At the same time, an entire class of errors disappears — empty alt="" on meaningful images, duplicates of the same text on dozens of products, descriptions like "IMG_2841.jpg". Search engines and screen readers get a meaningful description instead of a placeholder.
Generation modes and when to use each
Alt-text generation is not reduced to a single model run across the entire catalog. In practice, a choice is made between several modes, and the quality of alt directly depends on how well the mode matches the type of content.
| Option | When it fits | Limitations |
|---|---|---|
| Fully automatic run | Mass identical cards, thousands of SKUs | Requires post-filtering by stop words and length |
| Generation + manual proofreading | Products with legally significant descriptions | Consumes editor time for review |
| Hybrid: template + model | Categories with a stable structure ("color + material + type") | The template must be maintained when the assortment changes |
| Fully manual markup | One-off image pages | Does not scale, quality drops with volume |
Why this works sustainably
The key effect is not a one-time upload of texts, but a pipeline: new products get alt text at the moment of publication, not when someone gets around to them. That is precisely why the share of filled-in descriptions stays at a high level rather than sliding back a month later.
We build such pipelines in conjunction with the product catalog and media storage — AltText.ai and similar services handle generation, but alt quality is determined by post-processing and validation rules, not by the model itself.
What we check at the output
Automatic markup without quality control produces garbage: overly long descriptions, repetitions, irrelevant keywords. That is why the pipeline has built-in checks — length within readability limits, absence of duplicates, presence of meaningful product attributes. This is what distinguishes a working flow from "ran the model and forgot about it".
How we implement alt-text generation in a catalog
Implementation starts not with the generator, but with an audit of the current markup: we export all catalog images, look at what share has alt filled in, where it is duplicated, where it contains a file name like IMG_2043.jpg, and where it is missing entirely.
At this same stage we record the product categories and the rules by which the text should differ — otherwise the generator will produce identical wording for a thousand items and the search engine will treat them as junk.
After that, the work proceeds in stages:
- Markup audit and image inventory: we count the volume, the share of empty and template
altvalues, and identify product groups. - Setting up generation rules for each category: what goes into the text — name, type, key attribute, color or material, if they are visible in the photo.
- Connecting generation to the export: texts are created in batches when a product is uploaded and stored in a separate field, without overwriting existing correct values.
- Quality check on a sample: we manually review several hundred items, filtering out repetitions, nonsense, and overly long strings.
- Length limiting and cleanup: we bring texts to a reasonable length, remove service characters and unnecessary repetitions of the name.
- Running across the entire catalog and selective monitoring after publication: we verify that the markup is served to search engines and does not break the layout of the product cards.
- Handover of the configured system: the rules, export scripts, and instructions for adding new categories remain with your team.
The key point is that the rules live separately from the page code. When you add a new category or change the product card template, it is enough to describe the attributes for generation rather than rewrite the markup manually. Describe your task — we will get back to you with an estimate and a stage-by-stage plan.
How does template alt text differ from content-generated alt text?
Template alt text is built from predefined fields: category name, brand, SKU, sometimes color or size. This approach produces a predictable string, but it describes the product in catalog terms rather than in terms of what is actually visible in the image.
As a result, dozens of product cards end up with nearly identical captions that carry no new information either for search engines or for a blind user reading the page through a screen reader.
Content-generated alt text works differently: the model analyzes the image itself — the angle, composition, background, secondary objects, details of cut or texture — and formulates a description tied to that specific shot.
The difference between the approaches shows up in the precision of the description: a template answers the question "what product is this," while content-generated alt text answers the question "what exactly is shown in this image." For a gallery where the same product is shot from five angles, this is fundamental: each image gets its own caption instead of five copies of a single string.
In practice, a template hits its ceiling as soon as the catalog goes beyond uniform items.
As soon as sets, products with accessories in frame, infographics with text, or lifestyle photography appear, field-based substitution starts producing descriptions that don't match the image.
Content-generated alt text handles such cases because it relies on visual features rather than on the structure of the product card.
There is a flip side: content-generated alt text requires verification for factual errors — the model may misidentify the material or the purpose of an item.
That is why in the workflow the description goes through validation against the product reference guide and length rules, and questionable cases are sent for manual review.
A template doesn't require such verification, but it also doesn't deliver an increase in description precision where it's needed most.
The bottom line: a template satisfies the formal requirement for an alt attribute, while content-generated alt text satisfies the task of description.
The choice between them is determined not by ease of implementation, but by how uniform the catalog is and how important it is for each image to be described individually.
Case study: how a catalog of 40,000 products got rid of empty alt
A catalog of 40,000 items lived with an empty alt on 92% of images: content managers physically could not keep up with tagging new arrivals, and some cards inherited a file name like IMG_2043.jpg.
Search engines did not index such images, and screen readers announced them as "image" — the page lost both traffic and accessibility.
We built a mass-processing pipeline: an image goes through a recognition model that determines the product category, its attributes, and the shooting scene, after which alt text for images is generated from a template with the recognized features substituted in.
The finished descriptions go into a review queue — an editor confirms or edits the wording, and only after that does the value go into the database.
What changed in the metrics
- The share of filled-in alt grew from 8% to 97% across the entire catalog.
- Processing 40,000 images took less than a work week instead of months of manual tagging.
- Manual edits dropped to 11% of cards — the model described the rest correctly on the first pass.
- Duplicates and junk descriptions like "product, photo, picture" were cleaned out completely.
We addressed the quality issue separately: each category got its own set of required features, so alt for footwear and for household appliances are built by different rules and do not turn into a uniform stream.
The model runs on our infrastructure — OpenAI Vision paired with our own post-processing layer that filters out hallucinations and checks the string length.
What if the model makes a mistake on a rare category? Such items are flagged with low confidence and go into the editor's priority queue — they do not enter the database until confirmed.
How does this relate to the SEO effect? A filled-in alt is one of the signals of image relevance; after tagging, the share of card impressions in image search grew, and the behavioral metrics of catalog pages improved.
The pipeline is re-run for each new batch of products, so the catalog no longer accumulates untagged images.
What to do if the catalog is already manually or partially marked up?
Most often, the catalog is already partially marked up: for top products, the alt text for images is written manually and works, while for the long tail it is empty or contains a file name like IMG_0421.jpg.
Rewriting everything indiscriminately is unnecessary and harmful: we leave manual texts that bring traffic as they are, and enable generation only for positions without a description or with obvious junk.
Before launch, we take a snapshot of the current markup — an export of all values into a table with product identifiers, so that at any moment there is something to compare the result against.
What if generation ruins already marked-up product cards? The rule is simple: the script writes only to empty fields and to those marked as drafts, and does not touch manually filled ones without separate confirmation.
Every change is logged — you can see what it was, what it became, and when. Rollback is done from the taken snapshot: we restore the previous values by the list of identifiers, without manually going through the product cards.
What about access to the catalog? We work through a separate user with permissions only to read and write the media library — without access to orders, payments, and customer data.
If the catalog is closed, we prepare the markup on an export and hand over a ready file for import by your team.
What if the catalog structure is non-standard? First, we analyze the storage schema: where the images are stored, how they are linked to products, and whether there are multiple language versions.
This determines how to distribute the texts across fields and avoid duplicating them between variants.
Can generation be launched not on the entire catalog at once?
Yes, and that is a reasonable start. We take one category or a few hundred positions, review the result visually and by metrics, and only then expand to the entire catalog. Such a phased launch reduces risk and provides a clear rollback point at every step.
What you receive:
- an export of the source markup with a snapshot of all values before changes;
- the rules by which generation bypasses manually filled fields;
- a change log tied to product identifiers;
- rollback instructions — which data to restore and in what order;
- a description of the catalog schema and how texts are distributed across fields;
- a separate user with limited permissions and a list of granted accesses;
- a report on the pilot category: the share of filled positions and what remains for manual review.
Describe how your catalog is structured and what is already marked up — we will get back to you with an estimate and a phased launch plan.
Timeline for implementing alt-text generation by stages
Implementing alt-text generation is not "turn on the model and forget about it." Most of the time goes into auditing the current markup, assembling an attribute dictionary, and setting up quality checks: the generation itself takes hours, while data preparation and control take weeks.
Below are approximate stages of work without tying them to specific dates; the order of stages is fixed, and the duration depends on the size of the catalog and the number of language versions.
| Stage | What happens | Approximate timeline |
|---|---|---|
| Catalog and markup audit | Inventorying images, exporting current alt-texts, finding empty and duplicate values, assessing the share of products without descriptions | 3-5 business days |
| Dictionary and rules assembly | Agreeing on templates by category, stop words, length limits, requirements for mentioning the brand and model | 1 week |
| Generation setup | Connecting the model to the catalog, configuring the processing queue, caching results, handling errors and retries | 1-2 weeks |
| Pilot on a sample | Running on 5-10% of the catalog, manual accuracy review, measuring the share of edits, adjusting templates | 1 week |
| Full run | Processing the entire catalog in batches, writing to the database, logging changes for rollback | 1-3 weeks |
| Quality control | Automated checks for duplicates, length, prohibited wording; selective manual acceptance | 1 week |
| System handover | Documentation, regulations for adding new products, training the client's team, transferring access | 3-5 business days |
Timelines shrink if the catalog is already marked up and ready product descriptions exist — then the audit and dictionary assembly stages run in parallel. They stretch if images are stored in different systems or some products are described only by SKUs.
Schema.org sets requirements for the alt attribute in product markup, and we verify generation results against these rules at the quality control stage — this reduces the risk of manual edits after delivery.
