Deduplicating Joins Across Citation, Referral, and CRM Data
Website owners comparing citation reports with referrals and customer relationship management (CRM) outcomes need to keep the three record types separate. A…
When you add images to a web page, search engines need to find and understand them, and readers need them to make the page clearer. Image search engine optimization (SEO) means helping search engines connect each image to the page while making sure the image works for people and devices.
Start with the image’s purpose. Use accessible HTML for images that convey information, and describe their relevant content. Place each image beside related text, and make sure it loads without slowing or disrupting the page. These steps support discovery and usability, but no single filename, alt attribute, or sitemap guarantees search visibility.
Google uses several clues to understand an image, including its alt text, the surrounding page content, and computer vision, a technology that analyzes the image itself. It can find images in an HTML <img> element’s src attribute; Google says it does not index images used only as CSS backgrounds. For meaningful content, use an <img> element with a valid image URL rather than relying on a background image alone. Google’s image SEO guidance describes these discovery and interpretation signals.
An image rarely gives readers its full context on its own, so the surrounding page matters. Place it near the passage that discusses it, and use a caption when the caption helps readers identify or interpret it. A product photograph, for example, should appear alongside the product information it illustrates. This gives readers and search engines a clearer connection between the image and the page topic.
Alt text is text that describes an image when someone cannot see it. Write it to convey the image’s relevant information in context, rather than to repeat search phrases. The right description depends on the image’s purpose:
alt="") so screen readers can skip it.The W3C images tutorial shows how to choose alternatives based on an image’s role. Google warns that stuffing alt text with keywords harms the user experience and can be considered spam.
Use a descriptive filename when practical, but do not make it a priority. Google describes filenames as providing only “very light clues” about an image. A clear name is useful housekeeping; it does not replace relevant page text, useful alt text, or crawlable image markup.
Responsive images give the browser a choice of image files, so it can select one that fits the visitor’s screen and the space in the page layout. Use srcset and sizes, or a <picture> element, when you have different image sizes or formats to offer. Keep a valid <img src> fallback. The browser can then select an appropriate option without requiring a needlessly large desktop image on a smaller screen. The responsive image guidance from web.dev explains how these choices reduce unnecessary downloads.
Choose a format and compression level by checking both the file’s transfer size and its visible quality. A smaller file can reduce the time needed to download an image, but compression that makes a product, diagram, or other important detail unclear undermines the image’s purpose. There is no single file-size target or compression setting that suits every image.
Set accurate width and height attributes, or use CSS to reserve space based on the image’s width-to-height ratio. The browser can then make room for the image before it loads, reducing unexpected page movement. That movement contributes to Cumulative Layout Shift (CLS), a measure of how much page content shifts unexpectedly. web.dev’s CLS guidance explains how reserving space helps prevent image-related shifts.
Lazy loading delays an image request until the image is near the visible part of the page. It can reduce early work for images farther down the page, but do not lazy-load an image that is likely to be the largest visible element when the page first opens. That image affects Largest Contentful Paint (LCP), a measure of how long it takes for the largest visible content on the page to appear. Delaying its request can delay LCP. Keep that image discoverable in the initial page markup, and check its loading priority rather than assigning high priority to many images. See web.dev’s LCP recommendations.
For other images that load as readers scroll, check that their URLs appear in the page after the browser displays the content. Google warns against lazy-loading methods that require a visitor to click or scroll before the image URL appears, because Google Search does not interact with pages in those ways. Use Google’s lazy-loaded content guidance and URL Inspection in Search Console when you need to check what Google can render.
For performance, look at real-user data as well as a test on your own device. Google’s Core Web Vitals, a set of measures for page experience, define these thresholds for a good experience: LCP of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and CLS of 0.1 or less. INP measures how quickly a page responds to a visitor’s interactions. These thresholds are assessed at the 75th percentile, separately for mobile and desktop. They describe user experience, not an image-SEO score or a promise of higher rankings. The Web Vitals guidance explains the metrics and their thresholds.
If a page that relies on images has a slow LCP, inspect the browser’s network waterfall, a timeline showing when the browser requests files and how long they take to load. Compression or a different format helps when image download time is a substantial part of the delay. If the browser discovers the image late or JavaScript delays its display, shrinking the file alone will not address the main cause.
For search visibility, check whether the image URL is accessible and whether the page renders it in the way you expect. A sitemap can help Google discover images it might otherwise miss, particularly on large or image-heavy sites. Google’s sitemap guidance says a sitemap entry does not guarantee crawling, indexing, or appearance in search.
Use image metadata such as og:image, or structured data, which labels page information in a format search engines can read, when it suits the page and a supported search feature. These fields can help indicate which image represents a page or qualify content for certain search appearances. Google still selects image previews automatically, and adding metadata does not guarantee a particular image or result.
For each image that matters to a page, check its purpose, its accessibility, and how it loads:
<img> source and useful alt text, and that a decorative image has alt="".Then compare real-user performance data and image-search visibility after making changes. A better metric or a new search appearance shows a change, but by itself does not establish that an image adjustment caused it.
Google says relevant images and video can create opportunities to appear in its generative AI search experiences, and directs site owners to follow its existing search guidance. That supports the same practical work: make images useful, relevant, and accessible to Search. Google does not document a separate image-only optimization method or guarantee that an eligible image will appear in an AI result. Google’s generative AI search guidance explains the opportunity and its limits.
<img> element with a valid source; a CSS background alone is not indexed by Google.Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com