Written by Nemanja Falb — founder and developer of TinySharp, working on WordPress image optimization, browser-based image workflows and practical website performance tooling.
A redesign can make a site look better while quietly damaging its image search visibility, page performance and content history. The risk usually comes from migration decisions that seem harmless: renaming every uploaded file, changing the CDN hostname, replacing HTML images with CSS backgrounds, removing captions, rebuilding galleries or importing old content without its responsive image metadata.
A pre-redesign image audit is therefore different from a normal “find large files” audit. Its purpose is to answer two questions:
- What image assets and signals are valuable today?
- What must survive, improve or intentionally change during the migration?
Build an image inventory before touching URLs
Start with the current production site, not the design file. Crawl representative page types and record the image resources that users and crawlers can actually encounter.
Your inventory should include:
- the page URL where the image appears;
- the final image URL requested by the browser;
- the original or canonical media URL when different;
- format and file size;
- natural width and height;
- rendered width and height;
- alt text and caption where present;
- whether the image is loaded through
src,srcset,<picture>, CSS or JavaScript; - whether the asset is served from the origin, CDN or third-party host;
- whether it appears above the fold or may be an LCP candidate.
This creates a baseline you can compare against staging. Without it, teams often discover missing images and changed URLs only after launch.
Audit page types, not only the homepage
The homepage is rarely representative of the whole image system. A useful audit samples the templates that create different behavior:
- homepage and major landing pages;
- category or archive pages;
- blog posts from different publishing periods;
- product listing and product detail pages;
- author, tag or taxonomy templates if they receive traffic;
- legacy pages built with an older editor or page builder;
- pages with galleries, sliders or background images.
Old content is especially important because it often contains the largest unoptimized files and the most fragile legacy markup.
Separate performance problems from migration risks
Not every large image should be renamed or replaced during a redesign. Create two issue groups.
Performance issues
- oversized natural dimensions;
- poor compression;
- inappropriate format;
- missing responsive variants;
- offscreen images loaded too early;
- missing dimensions causing layout shifts;
- critical images loaded too late.
Migration risks
- image URLs changing without a mapping plan;
- CDN hostname changes;
- media attachments not copied to the new environment;
- alt text or captions lost during import;
- responsive image markup removed;
- important HTML images converted into decorative CSS backgrounds;
- old image sitemaps or structured data pointing to retired URLs.
This separation helps the team avoid “fixing” a performance issue in a way that creates a search or content migration problem.
Identify image URLs worth preserving or redirecting
Some image URLs may already be indexed, linked, embedded externally or receiving traffic. Search Console, server logs and analytics can help identify valuable assets. The audit should flag URLs that should remain stable when practical.
If an important image URL must change, document the old and new location and implement a permanent redirect where your platform and infrastructure allow it. Do not assume that changing every filename for “SEO” automatically creates a benefit. A descriptive new filename is not worth losing a known, linked or indexed URL without a migration plan.
Google’s image SEO best practices emphasize crawlable images and useful context. The wider principle is continuity: make it easy for crawlers and users to reach the intended asset after the redesign.
Record metadata before content is exported
Image metadata in the CMS can disappear when content is copied through a custom migration script. Save the fields that matter:
- alt text;
- captions;
- attachment titles when used by the site;
- featured image relationships;
- gallery order;
- product variant relationships;
- focal point or crop settings if the CMS stores them.
Do not blindly preserve bad metadata. The point is to avoid accidental loss. The redesign can then intentionally improve weak alt text rather than replacing everything with empty values or filename-derived text.
Measure rendered size versus natural size
A redesign often changes container widths. An image that was correctly sized in the old layout may become too small, while another may still be downloaded at 2000 pixels into a 600-pixel column.
For each important template, compare:
- natural image dimensions;
- rendered CSS dimensions;
- device pixel ratio;
- the actual responsive candidate selected by the browser.
Do this on staging after the responsive breakpoints are implemented. Design specifications alone do not prove which file the browser will select.
Audit CSS and JavaScript image sources
Traditional crawls can miss assets injected by JavaScript or referenced in CSS. Hero backgrounds, pseudo-elements, sliders and component libraries may request images outside the obvious HTML.
Use a browser-level audit for critical templates. The TinySharp guide How to Audit Page Images With a Chrome Extension explains why natural dimensions, rendered dimensions and final browser requests matter.
Create a redesign decision matrix
| Finding | Recommended action |
|---|---|
| Important image URL already performs well | Preserve URL when practical |
| URL must change | Map old to new and redirect where possible |
| Large image displayed much smaller | Create correctly sized responsive variants |
| Hero is likely LCP | Prioritize discovery and avoid lazy-loading it |
| Offscreen gallery loads immediately | Delay loading until appropriate |
| Image has useful existing alt text | Preserve through migration |
| Repeated weak or empty alt text | Rewrite based on page context |
| Modern-format file exists but is not served | Fix frontend delivery, cache or CDN path |
Compare production and staging before launch
Do not wait until launch day. For a representative URL set, compare:
- number of image requests;
- total transferred image bytes;
- largest individual image;
- main above-the-fold image;
- selected responsive candidates;
- alt text and captions;
- broken image requests;
- layout shifts around media;
- old versus new image URLs.
A redesign that looks visually identical can still double the image payload if the new component system chooses larger candidates or removes lazy loading from long pages.
Launch with an image-specific monitoring list
During the first days after migration, check:
- 404s for old media URLs;
- broken CDN or origin paths;
- Search Console indexing and crawl issues;
- top landing pages for unexpected image weight;
- mobile rendering and responsive source selection;
- critical product, category and article templates.
Do not treat the image audit as a one-time spreadsheet that disappears after launch. Keep it as the baseline for post-launch verification.
Frequently asked questions
Should I rename every image during a redesign?
No. Renaming can create unnecessary URL changes. Use descriptive filenames for new assets, but preserve valuable existing URLs when practical and map intentional changes carefully.
Do image redirects matter?
They can matter when important image URLs change. Where your infrastructure supports it, a permanent redirect can help users and crawlers reach the new asset instead of receiving a 404.
What should I audit first on a large site?
Start with high-traffic templates and pages that use many images: category pages, product pages, top articles and major landing pages. Then expand to legacy content and long-tail templates.
Is checking the WordPress Media Library enough?
No. The media library shows stored assets, not necessarily what the browser receives. Themes, CDNs, caches and frontend rewrite rules can change the final request.
When should I run the final image audit?
Run one before the redesign, another on staging when templates are functional, and a final production verification immediately after launch.
Continue the workflow
Use the TinySharp Chrome Extension to inspect live page images, then use the Image Compressor or Bulk Image Converter for the assets that actually need work.
