When alt text and file names are confirmed unchanged but images have still dropped out of Image Search after a redesign, the cause is almost always something the two obvious checks didn’t cover: a new lazy-loading implementation that doesn’t render image URLs into the DOM Googlebot actually processes, image URLs that changed even though filenames look similar (a different directory path breaking the accumulated signal tied to the old full URL), an image sitemap that wasn’t updated to reflect the new template’s structure, or a robots.txt or CDN configuration change introduced during the redesign that’s now blocking image crawling. The diagnostic path is to check each of these systematically rather than guessing at a single cause, since redesigns typically bundle several changes together and the actual culprit isn’t always the one that seems most obviously related to images.
Why alt text and filenames being unchanged doesn’t rule out the real cause
It’s a reasonable first instinct to assume that if the two most commonly-cited on-page image signals haven’t changed, the images should still rank the same. But alt text and filename are textual content signals; they don’t address whether Googlebot can actually discover, crawl, and render the image in the first place. A redesign frequently changes the technical delivery mechanism around images (how they’re loaded, what URL structure serves them, what markup wraps them) while leaving the textual content itself untouched, and it’s precisely that technical delivery layer, not the content layer, that most commonly breaks after a redesign.
The specific technical culprits to check
Lazy-loading implementation. Many redesigns introduce or change a lazy-loading approach for performance reasons, and not all implementations are equivalent from a crawlability standpoint. Google’s own guidance on lazy-loading recommends either native browser lazy-loading (the loading=”lazy” attribute) or ensuring that images are actually present in the rendered DOM that Googlebot processes during rendering, rather than relying purely on scroll-triggered JavaScript that only populates an image’s src attribute after a user-scroll event Googlebot may not simulate the same way a real user would. If the new template’s lazy-loading approach leaves image URLs absent from the initial HTML and only injects them via a JavaScript event Googlebot’s rendering process doesn’t trigger the same way, images can become effectively invisible to indexing even though they display correctly for every human visitor.
A common variant of this problem worth checking specifically: some lazy-loading libraries use a placeholder attribute (data-src, data-lazy-src, or similar custom attributes) that JavaScript later swaps into the real src attribute once the browser fires whatever event the library listens for. If Googlebot’s rendering pass completes before that swap happens, or if the swap depends on a scroll or intersection event that behaves differently in Google’s rendering environment than in a real browser viewport, Googlebot’s rendered snapshot can end up with the placeholder value still in place, or with no usable image URL at all, rather than the final image URL a human visitor would eventually see. This is also why a purely visual check in a normal browser is not a reliable substitute for checking the actual rendered DOM Google produces, since the same page can look completely correct to a human while the underlying markup Google captured tells a different story.
Structured data and thumbnail-eligibility issues. Beyond straightforward crawling and rendering problems, a redesign can also change or remove structured data markup that previously made an image eligible for certain image-search treatments, or it can change the image’s serving size or aspect ratio in a way that no longer meets Google’s thumbnail or large-image criteria. Google’s documentation on image publishing indicates that eligibility for certain richer image treatments in search results depends partly on the image meeting minimum size and quality thresholds, so a redesign that serves a smaller, more heavily compressed, or differently cropped version of what was previously a qualifying image can result in that image losing eligibility for those specific treatments even while remaining technically indexed. This is a narrower and less common cause than crawling or rendering failures, but it’s worth ruling out when the other checks come back clean and the image appears to be indexed but simply isn’t surfacing the way it previously did.
Changed image URLs despite similar filenames. A redesign migrating from an old directory structure (say /images/products/) to a new one (say /assets/img/products/) can preserve the exact same filename at the end of the path while changing the full URL entirely. Google’s image indexing is tied to the full URL, not just the filename, so even an identical filename at a new path is, to Google, a different resource with no inherited history from the old URL. This is easy to miss because a manual spot-check of “did the filename change” comes back negative, while the actual URL, which is what matters for indexing continuity, did change.
Image sitemap not updated for the new template. If the site maintains a dedicated image sitemap and the redesign changed image URL patterns, page templates, or how images are embedded, but the sitemap generation logic wasn’t updated to match, the sitemap may be submitting stale or now-incorrect URLs, or simply failing to include images that exist under the new template structure. This is a common oversight specifically because sitemap generation is often a separate system from the front-end template, and redesign projects can miss updating the sitemap logic even when the visible front-end change is thoroughly tested.
Robots.txt or CDN blocking introduced during the redesign. Redesigns sometimes involve migrating image hosting to a new path, subdomain, or CDN configuration, and it’s a common and easy-to-miss error to leave an overly broad robots.txt disallow rule in place (sometimes copied from a staging environment robots.txt that was intentionally blocking crawlers) or to introduce a new CDN configuration that inadvertently blocks Googlebot’s user agent or IP ranges. It’s worth remembering that if images moved to a separate hostname or subdomain as part of the redesign, that hostname needs its own robots.txt check entirely, since robots.txt rules are scoped per-hostname; a permissive main-domain robots.txt provides no coverage at all for a new image CDN subdomain that has its own, separately-configured robots.txt file, and it’s easy to assume the main site’s crawl permissions simply carry over when they don’t.
Crawl budget dilution across a large image set. For sites with genuinely large image counts, a redesign that changes URL structure across the whole catalog effectively creates a large batch of new URLs from Google’s perspective, even where the visible image itself hasn’t changed, and Googlebot has to recrawl and reprocess that volume of new URLs before image search results catch up to the new reality. This isn’t a configuration error so much as a natural consequence of scale, but it means that for a large site, some portion of an apparent image-search disappearance immediately following a redesign may simply reflect a recrawl and reprocessing backlog rather than any of the harder failures above, and it’s worth giving that possibility some time to resolve before assuming a technical fix is required, provided the URL Inspection checks described below don’t point to an active blocking or rendering problem.
A hypothetical illustration of the lazy-load trap
Consider a hypothetical furniture retailer, “Cedar & Stone Home,” that relaunches its product listing pages with a new lazy-loading library for performance reasons. Alt text and filenames carry over unchanged from the old templates, so a first-pass review clears both obvious suspects. What the redesign actually changed is that product images now load via a data-src attribute swapped into src only after an intersection-observer event fires on scroll, and Googlebot’s rendering pass, in this scenario, completes before that swap occurs for images positioned below the initial viewport. To a human visitor scrolling the page, every image loads normally and nothing looks wrong. To Google’s rendered snapshot, though, a meaningful share of product images could plausibly show only the placeholder attribute with no usable image URL, which would explain a drop in Image Search visibility that neither an alt-text check nor a casual browser-based look would ever surface.
The diagnostic workflow
Start with Search Console’s URL Inspection tool on a specific affected page, and check the “rendered HTML” or rendered screenshot Google’s tool provides, specifically confirming the image actually appears in what Googlebot rendered, not just what a browser shows a human visitor. If the image is absent from the rendered view Google captured, that points strongly toward the lazy-loading or JavaScript-rendering issue. Next, compare the actual full image URLs before and after the redesign (not just filenames) using a crawl tool or a saved pre-redesign crawl if one exists, to confirm whether URLs genuinely stayed the same or shifted paths. Then check whether the image sitemap, if one exists, reflects the current template’s actual image URLs, and finally check robots.txt and any CDN-level access rules for the image-serving domain or path to confirm Googlebot isn’t being blocked outright.
Practical implication
Don’t stop the investigation after confirming alt text and filenames are unchanged; those checks rule out only the textual-content layer, not the technical delivery layer where redesign-related image indexing problems most commonly originate. Work through URL Inspection’s rendered view first, since that single check often reveals whether the problem is a rendering/lazy-loading issue before you need to dig into sitemap or robots.txt configuration separately.
