Image SEO is mostly good image engineering: send the right file, at the right size, with useful context, without making the page wait for it.
Start with the dimensions the layout actually needs
Uploading a 4000-pixel photo into a 700-pixel card wastes bandwidth even if the file has been compressed. Generate sensible source sizes and use responsive image markup so the browser can choose an appropriate file for the viewport and pixel density.
Set width and height attributes or an aspect ratio so the layout can reserve space before the image arrives. This is a simple way to prevent avoidable layout movement.
Choose format based on the image, not a rule
Modern formats such as AVIF and WebP can be excellent for photographs and many illustrations, but quality and decode cost still matter. SVG is often a better fit for simple logos and icons. PNG can remain useful when lossless detail or transparency is important.
Compare the result visually. A technically smaller file that introduces ugly banding around a product or logo is not an optimization anyone wants.
Write alt text for the reason the image is there
Alt text should convey the useful information a person would miss if the image did not load. A decorative flourish may need an empty alt attribute. A product image may need the product and relevant visual distinction. A chart needs the important takeaway available in text, not a list of every pixel.
Do not turn alt text into a keyword field. Repeating the page title on every image makes the experience worse and says little about the actual image.
Do not lazy-load the image that defines the first screen
Lazy loading is useful below the fold, but applying it blindly to the hero or other likely LCP image can delay the most important visual on the page. Let the browser discover critical imagery early and consider preload or fetch priority only when the trace shows it is warranted.
At the same time, avoid eagerly loading a gallery of off-screen images. Priority should match what the user needs first.
Give search engines enough context to understand the asset
A descriptive filename can help with maintenance and context, but the surrounding page matters more. Put the image near relevant copy, use a caption when it adds meaning, and make sure the page itself is crawlable and indexable.
For image-heavy sites, include image information in the normal sitemap workflow where appropriate and avoid hiding important assets behind inaccessible scripts or URLs.
Monitor images when templates change
A redesign can quietly break image performance by changing crop sizes, removing responsive attributes, or loading desktop assets on mobile. Test representative templates after visual changes and inspect the actual resources downloaded at common viewport sizes.
Image optimization is not a one-time compression pass. It is part of the component system, so it needs to survive future content and design changes.
Treat social preview images as a separate job
The image that works inside a page is not always the image that works when somebody shares the URL. Set a deliberate Open Graph image with a crop that survives common social preview shapes, readable text if you use text at all, and branding that is recognizable at small sizes.
This is not a direct image-search tactic, but it affects how the page travels through messaging apps and social networks. Keep the preview asset crawlable, give it stable dimensions, and update it when a rebrand makes the old graphic misleading.
Before you move on, check these
- Generate image sizes that match real layout widths and use responsive sources.
- Choose AVIF, WebP, SVG, PNG or JPEG based on the asset and visual quality.
- Write alt text for the image’s function; use empty alt for truly decorative images.
- Do not lazy-load likely LCP imagery without checking the performance trace.
- Place important images near relevant crawlable copy and keep asset URLs accessible.
- Retest downloaded image sizes after template and component changes.
Keep reading
Paste a public URL into AEO & GEO Insights and compare the article with what the crawler actually finds: structure, indexing signals, evidence, entities and extractable answers.
