TL;DR
Vercel's 2024 analysis of 569 million GPTBot requests found AI crawlers don't execute JavaScript, rendering text embedded in PNG images effectively invisible to them. On the ChartQA benchmark, vision-language models score only 54% accuracy on chart-based questions versus 89% for humans, with performance cratering further when underlying data tables are removed. The core failure is never that the AI is dumb—it's that a specific number, spec, or claim was never written as plain text anywhere a crawler can reach it. To make images machine-readable, supply that information in alt text, captions, surrounding prose, or structured data, treating every pixel-only number as unrecoverable by default.
The verdict: if you want an AI to quote your diagram's dimensions or your chart's key stat, write that stat as text on the page—don't rely on the crawler to read it from the image.
Image SEO for AI search is the practice of exposing the information carried inside an image — a spec table, a UI screenshot, a diagram — as adjacent, crawlable text (alt attributes, captions, surrounding prose, structured data) so that systems which read text far more reliably than they read pixels can retrieve, quote, and cite it. It is not decoration. It is a translation layer between what a human sees in an image and what a language model can actually use as evidence.
That distinction matters more in 2026 than it did five years ago, because the audience for your images has split in two. One audience is a human with eyes and a browser. The other is a crawler or a retrieval pipeline feeding a language model, and that audience is, by default, mostly blind.
Why "AI reads text, not pixels" is the right starting assumption
Vercel's December 2024 analysis of AI crawler traffic, run jointly with Merj across more than 500 million GPTBot fetches, found no evidence that GPTBot, ClaudeBot, or PerplexityBot execute JavaScript — they fetch raw HTML, and even when they download script files (roughly 11.5% of the time for GPTBot, per the same analysis), they don't run them (Vercel, "The rise of the AI crawler," Dec 18, 2024). The same report notes GPTBot generated 569 million requests and Claude 370 million across Vercel's network in a single month — against Googlebot's 4.5 billion — and that all of the major AI crawlers operate from a handful of US data centers with no distributed rendering infrastructure comparable to Googlebot's headless-Chrome pipeline.
The practical upshot: if the only place a number, a spec, or a claim lives is baked into the pixels of a PNG, most AI crawlers are simply not equipped to render, decode, or reliably extract it the way a browser-based reader would. OpenAI's own documentation for its crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot) describes user-agent strings, robots.txt controls, and IP ranges in detail, but is notably silent on any guaranteed image-text extraction pipeline (OpenAI, "Overview of OpenAI Crawlers") — silence that, given how much the same documentation specifies about crawl behavior, is itself informative. Treat image-embedded text as invisible to the crawl layer by default, then earn visibility back with text.
What machine-readable actually varies by
Direct answer: Not all image content is equally hard for AI systems to recover. A comparison of common evidence types:
| Image content type | Machine-readable without help? | What you must supply in text | Consequence if you don't |
|---|---|---|---|
| Plain product photography (no embedded text) | Partially — vision models can describe objects generically | Alt text naming the product, use case, and key visual attributes | Image is indexed as "a photo," not as evidence for a specific claim |
| UI/app screenshot with dense on-screen text | Poor — small, low-contrast, or stylized text degrades OCR-style extraction | A caption or paragraph restating what the screenshot proves, not just what it shows | The exact feature/number a reader (or AI) needed is unrecoverable |
| Chart or graph with data points | Poor to moderate — models can often identify chart type but struggle with precise values | The underlying numbers as an HTML table or inline sentence, plus a descriptive caption | The one stat worth citing gets silently dropped from any AI-generated answer |
| Technical diagram/schematic | Poor — spatial relationships and labels are hard to recover reliably | Text explaining what the diagram shows and what each labeled part means | Diagram becomes decorative; the explanation it was meant to replace never gets written |
| Infographic with embedded stats | Poor — text is often stylized, layered, or rotated | Every stat also written as plain text somewhere on the page | Infographics are the single most common "evidence graveyard" on marketing pages |
| Scanned spec sheet / PDF page rendered as an image | Poor — depends entirely on external OCR the crawler may not run | A parallel HTML or plain-text version of the same spec table | Spec claims (dimensions, tolerances, certifications) become unverifiable to AI systems |
| Logo or purely decorative icon | Not applicable — nothing to extract | Empty alt attribute (alt="") so screen readers and crawlers skip it | Minor: wasted crawl attention, but low real-world cost |
The pattern across every row: the failure mode isn't "the AI is dumb," it's that the specific number or claim was never expressed as text anywhere the crawler could reach it.
What research says about the current ceiling on image understanding
This isn't guesswork — it's an active benchmarking problem in the vision-language model research community. The ChartQA benchmark, introduced by Masry et al. in 2022, was built specifically because chart-reading requires both visual parsing and numerical/logical reasoning over what's parsed; on that benchmark, strong visual-question-answering models scored around 54% accuracy versus roughly 89% for humans, with performance dropping further on charts that require multi-step arithmetic over extracted values rather than simple lookups (Masry et al., "ChartQA: A Benchmark for Question Answering about Charts with Visual and Logical Reasoning," ACL Findings 2022, arXiv:2203.10244). Follow-up benchmarks have since shown that when the underlying data table is stripped away — forcing models to read bar heights and line slopes purely from pixels, the way a human actually would — accuracy drops further, exposing what researchers call a "tabular shortcut" that earlier benchmarks inadvertently allowed models to exploit.
There's also a structural reason image-text extraction isn't equivalent to running OCR: modern multimodal models don't run a discrete OCR step and then reason over the output text. They convert image patches into embeddings the same way they convert word tokens into embeddings, and reason over both jointly — which means dense, small, rotated, or low-contrast text competes for the same limited attention budget as everything else in the image, with no guaranteed fallback to character-level extraction. That architectural difference is why performance on text-heavy images is inconsistent even across otherwise capable models, rather than a simple pass/fail on "can this model do OCR."
None of this means multimodal models are getting worse — the opposite is true, and the gap is closing. But "closing" is not "closed," and a page that depends on a model correctly reading a cluttered screenshot today is making a bet against a known, actively-researched failure mode.
The step-by-step process
- Inventory every image on a page that carries a claim, number, or spec — not just product photos, but screenshots, embedded charts, and diagrams. If removing the image would delete information (not just visual interest), it's evidentiary and needs text support.
- Classify each image using an informative / decorative / functional split before writing anything. Google's own technical writing guidance recommends describing the image's meaning in a sentence or two if it's informative, and using an empty alt attribute for images that add nothing if removed (Google, "Write helpful alt text," Technical Writing courses); the W3C's alt decision tree gives the fuller branching logic for functional images like icons that act as links or buttons (W3C WAI, "An alt Decision Tree," updated Jan 15, 2024).
- Write alt text that names the claim, not just the pixels. "Screenshot of pricing table" is weaker than "Pricing table showing three tiers: Starter at $29/month, Growth at $99/month, Enterprise custom pricing." Google explicitly warns against keyword-stuffed or vague alt text, since it degrades both accessibility and how Google's systems interpret the image's subject matter (Google Search Central, "Image SEO Best Practices").
- Pair evidentiary images with a visible caption, using the HTML
figureelement with afigcaptionchild so the caption is programmatically associated as the image's accessible name — not just visually adjacent text that a screen reader or crawler might not connect to the image (MDN, "figcaption: The Figure Caption element"). - Restate the single most important number or claim as plain text, even if it's redundant with the image. If a chart shows conversion rate rising from 2.1% to 4.8%, that sentence should also exist somewhere as a sentence, not only as a line on a graph.
- Use descriptive, hyphenated file names and place images near the text they support. Google's documentation notes it extracts image subject matter partly from surrounding page content and captions, so an image dropped far from relevant text loses that contextual signal (Google, "Image SEO Best Practices").
- Add structured data where it applies — an ImageObject reference via
primaryImageOfPage,mainEntity, or anog:imagetag for the representative image, and full markup for every page instance of an image, since Google requires per-instance metadata rather than treating a reused image as pre-documented (Google Search Central, "Image metadata in Google Images"). - Confirm the page is server-rendered or pre-rendered, not dependent on client-side JavaScript to inject the image or its surrounding text — given that major AI crawlers largely don't execute JavaScript, content that only appears after a client-side render may not exist from their point of view at all (Vercel, "The rise of the AI crawler").
- Test the page with images turned off (or read the raw HTML) and ask: does the page still make its case? If the answer is no, the text layer isn't done yet, regardless of how good the alt text is.
What this doesn't guarantee
Direct answer: Doing all of the above will not guarantee an AI system cites your page, quotes your spec, or even "sees" the image the way you intend. A few honest limits:
- It doesn't guarantee OCR-level extraction. Even with good alt text, if the image itself is the only place a number lives and a human or crawler somehow only encounters the raw image (e.g., via direct image search or a scraper that discards HTML), that number may still be lost. Text support reduces this risk; it doesn't eliminate the underlying gap in image-text extraction reliability documented by benchmarks like ChartQA.
- It doesn't fix a JavaScript-rendering problem. No amount of well-written alt text helps if the image and its caption are injected client-side and the crawler never executes the script that renders them.
- It doesn't guarantee rich results or citation. Google is explicit that structured data is not a guarantee of appearing in search features, only an eligibility signal (Google, "Image metadata in Google Images"); the same logic extends to AI answer engines, where inclusion in a generated answer depends on retrieval and ranking systems outside any individual site's control.
- It doesn't substitute for the underlying content being good. Alt text on a low-value image doesn't make the claim behind it more credible — it just makes an already-credible claim retrievable.
- It doesn't stay solved. As multimodal models improve, expectations about what "counts" as accessible will shift; a page's image-SEO work needs periodic revisiting, not a one-time pass.
Where nqzai fits
Direct answer: nqzai's site-auditing tooling treats image-carried evidence as a category worth checking on its own, not folded into a generic "missing alt text" count — it flags images that appear to carry a specific claim, spec, or number and checks whether that same information also exists as crawlable text elsewhere on the page, so evidence that would otherwise only live inside a screenshot or chart doesn't quietly disappear from what AI systems and search engines can retrieve and cite.
FAQ
Does alt text actually influence whether ChatGPT or Perplexity cite my page?
There's no published, verifiable mechanism showing alt text directly drives AI citation the way it drives traditional Google Images visibility. What's better supported is the indirect path: alt text and captions are on-page text, and on-page text is what AI crawlers reliably retrieve. Treat alt text as making your claim retrievable, not as a direct ranking lever for AI answers.
Can AI models "read" the numbers in my screenshot without any alt text?
Sometimes, especially with large, high-contrast, well-cropped text and a capable multimodal model. But benchmark research on chart and document understanding shows this is inconsistent, particularly for dense or small text, and current models don't run a guaranteed OCR fallback — they process image and text as unified embeddings, with no assurance that a cluttered spec table gets extracted correctly.
Should I use alt text, a caption, or both?
Both, for evidentiary images. Alt text is not rendered visually and serves screen readers and machine parsing; a caption (ideally in a figure/figcaption pairing) is visible to sighted readers and gives crawlers a second, differently-phrased description of the same content. Google explicitly distinguishes the two and doesn't treat captions as a substitute for alt text.
Do I need structured data on every image?
No — reserve it for images that represent the page (product images, primary diagrams) or where a specific schema type (Product, Recipe, Article) genuinely applies. Google's own guidance is to avoid generic or text-heavy images as the designated schema image and to add markup per page instance, not blanket every image on a site.
Will better OCR or multimodal models eventually make all of this unnecessary?
Some of it, over time — model capability on chart and document understanding is a live research area and is improving. But the crawler-level gap (many AI crawlers not rendering JavaScript, not guaranteeing image fetch/processing) is a separate, infrastructural problem from model capability, and improving one doesn't fix the other. Betting a spec sheet's visibility entirely on future model improvement is a bet against a moving target, not a solved problem.
What's the single highest-leverage fix if I only have time for one thing?
Restate your single most important claim, spec, or number as plain text somewhere on the page — not just inside the image. Everything else in this process (alt text, captions, structured data) improves discoverability and context, but a claim that exists in text at all is the one thing that survives every crawler, every renderer, and every model generation.
