Screenshots and Diagrams: The Images Nobody Optimises
Image SEO advice assumes photographs, but the images that carry the most information on a technical site are screenshots, charts and diagrams. They need different formats, different alt text and a different quality setting, and almost nobody gives them any.
Search for advice on image SEO and you will get advice about photographs. Descriptive filenames, compression, responsive sizes, alt text describing the scene. All correct, all written with a photograph in mind.
Meanwhile the images doing the most work on documentation, software, finance and B2B sites are screenshots, charts and diagrams — and every piece of standard advice is either wrong or insufficient for them. They are compressed with a photographic setting that destroys their text. They get alt text describing their appearance rather than their meaning. They are exported as raster when they started as vector. And they quietly go stale in a way photographs never do.
Why they behave differently
Three properties separate informational images from photographic ones, and each has consequences.
They are mostly hard edges and flat colour. Lossy compression is tuned for continuous tone and natural noise. Give it a screenshot and it produces ringing around letterforms and halos at boundaries. The degradation appears at quality settings where a photograph still looks perfect, so a single global setting means either wasting bytes on photographs or wrecking screenshots.
Their content is the point. A photograph of a workshop conveys atmosphere; if a reader misses a detail, little is lost. A screenshot exists because of one specific thing in it. If the reader cannot identify that thing, the image has failed entirely.
They expire. Interfaces get redesigned, charts describe periods that end, diagrams describe architectures that change. A photograph of a hand tool is good for a decade. A screenshot of a settings panel may be wrong next quarter.
Format and quality
The rule is simple: never route informational images through your photographic pipeline.
| Image type | Format | Quality | Why |
|---|---|---|---|
| Interface screenshot | WebP lossless, PNG fallback | Lossless | Text smears under lossy compression |
| Screenshot with photographic content | WebP or AVIF | 85–90 | Mixed content, favour the photographic half |
| Chart or graph exported from a tool | SVG if available, else PNG | Lossless | Thin lines and small labels ring badly |
| Hand-built diagram | SVG | Vector | Scales cleanly, usually far smaller |
| Code sample as an image | Do not | — | Use a real code block instead |
That last row is worth stating plainly. A screenshot of code is unreadable to a screen reader, uncopyable, unsearchable, and invisible to anything parsing the page. It exists because it was quicker to paste. Use a formatted code block.
On sizing, remember that a screenshot taken on a high-density display is typically twice the pixel dimensions it will render at. That is fine and often desirable for crispness, but it should be delivered through the same responsive srcset and sizes machinery as any other image, not shipped at full size to every device.
The interaction between format and compression is where most of the damage happens, and choosing quality settings per content type rather than globally is the single change that fixes the majority of it.
Alt text that carries the meaning
This is where informational images are most often failed, and the failure is subtle because the alt text is usually present. It is just describing the wrong layer.
Consider a screenshot showing where a metadata toggle lives in a settings panel.
Describing appearance: "Screenshot of the settings page." Accurate, useless. The reader learns a screenshot exists.
Describing contents: "Settings page showing General, Media, Permalinks and Privacy sections, with a sidebar menu and a Save button." Thorough, still useless, and now tedious. None of that is why the image is there.
Describing meaning: "The Media settings panel, with the Preserve image metadata checkbox highlighted under the Uploads heading." That is what a sighted reader takes from the image in half a second.
The test is to ask what the reader is supposed to do or understand after seeing it, then write that. The same principle applies to charts: state the finding, not the chart furniture. "Conversions rising steadily from 2 to 5 percent between January and June" beats any description of axes and legends.
Where precise values matter, they belong in a table or in the prose, not in alt text. Alt text is a sentence, not a data container, and a reader navigating by screen reader cannot skim a long one. This is a specific case of a broader point covered in what accessible images require beyond the alt attribute, and it is where automated approaches struggle most — tools that generate alt text describe what is visible rather than why it was included, which is adequate for a photograph and insufficient for a diagram.
Annotation deserves a note too. If you have added an arrow pointing at the relevant control, that arrow is information a non-sighted reader cannot access. The alt text has to say what the arrow says.
Keeping them from going stale
The maintenance problem is real and is almost never anybody's job.
What makes it tractable is knowing where things are. A naming scheme that encodes the product area and the interface version turns "find every screenshot of the billing page" from an afternoon into a search. Something like settings-media-metadata-v4.webp tells you what it shows and which generation it belongs to. Writing an image naming convention the team will actually follow is the same discipline applied to a case where the payoff is unusually direct, because stale screenshots are a maintenance cost that compounds silently.
Two habits that help disproportionately:
- Record where each one is used. A simple mapping of image to pages means an interface change produces a list of pages to update rather than a hunt.
- Capture consistently. Same window width, same zoom, same theme, same demo account. Consistency makes a set look deliberate, and it makes replacing one image straightforward rather than a re-composition exercise.
Consistent capture conditions are the informational equivalent of a stable style clause in photography. Holding a consistent visual treatment across a library is the same idea whether the images are generated scenes or captured interfaces.
What is in the screenshot that should not be
Screenshots capture whatever was on screen, which regularly includes things nobody intended to publish.
The recurring offenders are real customer names in a list view, email addresses in a header, account identifiers and internal reference numbers, API keys or tokens visible in a developer panel, browser tabs revealing internal tooling, and notification popups arriving mid-capture. Once published, a screenshot is a static image that search engines index and other people save, so the correction is slower and less complete than editing a paragraph.
Two habits remove almost all of this:
- Capture from a dedicated demo account with invented data. Not a scrubbed production account, which is where the one missed field lives. Fabricated names and plausible fake records mean nothing sensitive can appear because nothing sensitive exists.
- Redact by drawing over, not by blurring. Solid blocks are unambiguous. Blurring and pixelation can in some circumstances be reversed, and in any case both look like there is something to recover.
Worth noting that redaction applied in a page overlay rather than in the image file is not redaction at all, since the underlying file remains as it was and is directly reachable by URL.
A periodic sweep is a reasonable precaution for anything published before this became a habit, and a site-wide image audit is the natural place to do it, since you are already enumerating every image on the site.
What they actually do for you
Screenshots and diagrams rarely rank in image search, and optimising them in the hope that they will is misdirected effort.
What they do is make a page genuinely more useful, which supports the page through every mechanism that matters. A tutorial with accurate, current screenshots holds attention, gets referenced, and gets linked. One with screenshots from two redesigns ago quietly tells the reader the page is unmaintained, which is a far more expensive signal than any compression setting.
They also increasingly matter for how content gets summarised and cited elsewhere. A page that demonstrates a process step by step is more quotable than one that asserts it, and how images factor into AI-generated search answers is worth understanding for any site whose traffic comes from explanatory content.
One practical caution: a diagram that exists only as an image is invisible to everything that reads text. If the concept matters, the surrounding prose should convey it too. The image should make the point faster, not be the only place the point is made.
This applies with particular force to anything a reader might need to act on. A configuration shown only in a screenshot cannot be copied, searched for, or quoted, and a reader who needs the exact value has to transcribe it by eye from a picture. Where a screenshot shows settings, listing those settings in text underneath costs two lines and removes the dependency entirely. The screenshot then does what it is good at, which is showing where something lives, while the text does what it is good at, which is saying precisely what it should contain.
None of this is exotic work. It is mostly a matter of not treating a screenshot as though it were a photograph — a different format, a lossless setting, alt text about meaning, and a filename that lets you find it again. The general pre-publish image checklist still applies on top of that, and for the photographic images on the same site, SEOpix handles filenames and metadata at generation time so the manual attention can go where it is actually needed. See how.
Frequently asked questions
How should I write alt text for a screenshot?+
Describe what the screenshot demonstrates rather than listing what is on screen. A reader who cannot see it needs to know which setting is being shown and what state it is in, not an inventory of every menu item. If the screenshot exists to show where a checkbox lives, the alt text should say where that checkbox lives.
What format is best for screenshots?+
Lossless WebP is the usual best answer, with PNG as the fallback. Screenshots are full of hard edges and text, which is precisely what lossy compression handles worst, so a photographic quality setting produces visibly smeared text. If the screenshot is mostly a photograph, such as a video still, treat it as a photograph instead.
How do I write alt text for a chart or graph?+
State the conclusion the chart is there to support, not its visual construction. Saying a line chart shows conversions rising steadily from January to June is more useful than describing axes and colours. Where the exact figures matter, put them in a table or in the surrounding text, because alt text is a poor container for data.
Should diagrams be SVG instead of raster images?+
Yes, wherever the diagram originates as vector artwork. SVG stays sharp at any size, is usually far smaller than an equivalent raster file, and its text can remain real text. The main caveats are sanitising any SVG you did not create yourself and remembering that text inside an SVG is not a substitute for alt text on the element.
Do screenshots help with SEO?+
Indirectly and meaningfully. They rarely rank in image search themselves, but they make a page demonstrably more useful, which supports the page in the ways that actually matter. A tutorial with accurate screenshots keeps readers on the page and earns links in a way a wall of prose does not.
How do I stop screenshots going out of date?+
Name and store them so you can find every instance of a given interface, and record which page each one appears on. The problem is almost never taking a new screenshot, it is discovering six months later that the old one is still live on four pages nobody remembered. A consistent naming scheme turns that from an archaeology exercise into a search.
Should I annotate screenshots with arrows and boxes?+
Yes, when the screenshot is dense and the point is a specific region. Annotation is what turns a confusing full-window capture into a usable instruction. Keep annotation simple and high contrast, and remember that the annotation carries meaning a non-sighted reader cannot access, so the alt text must convey the same point.
Do screenshots of an interface raise copyright or trademark issues?+
Screenshots used to document or instruct are common practice and generally uncontroversial, but terms differ between products and some publishers have explicit guidelines about using their interface imagery. The situation to avoid is one implying endorsement or partnership. If a screenshot of a third-party product is central to commercial material, check that product's brand guidelines.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.
