An <img> tag with no width or height gives the browser nothing to reserve space with while the file downloads. On a fast connection the gap closes quickly enough that nobody notices; on a slower one, the surrounding text and buttons visibly jump down the moment the image finally appears.
What this finding means
Crawl Cove's wp-missing-image-dimensions check only runs on sites identified as WordPress, and it fires on any page carrying at least one <img> where the width or height attribute is missing.
A real finding looks like this:
2 image(s) missing explicit width/height: /wp-content/uploads/2026/01/hero.jpg, /wp-content/uploads/2026/01/banner.jpg
One finding per page, listing the offending image sources so the fix is a direct edit rather than a hunt through the page source.
Why it matters
Without both dimensions, the browser has no way to know how tall an image will be before it finishes downloading, so it lays out the rest of the page as if the image took up no space, then reflows everything below it once the file arrives. That reflow is exactly what Cumulative Layout Shift measures, and Google uses it as one of the three Core Web Vitals it ranks on.
How to fix it
- Re-open the affected images in the WordPress media library and check their listed dimensions.
- Re-insert the image through the block or classic editor rather than a raw
<img>tag, so WordPress writes thewidthandheightattributes itself from the file's real size. - For images already published with neither attribute, add them by hand to match the file's actual pixel dimensions, if the source was a pasted
<img>tag, a page builder, or a hand-edited template rather than the media library. - For a responsive image using
srcset, keepwidthandheightset to the intrinsic size of the base file; the browser still uses them to reserve the correct aspect ratio regardless of whichsrcsetcandidate actually loads. - Re-crawl the site to confirm the finding clears.
Note
CSS that scales an image (width: 100%, for example) does not remove the need for the HTML attributes. Modern browsers use width and height together to compute the image's intrinsic aspect ratio and reserve space accordingly, even when CSS later overrides the rendered size.
False positives and edge cases
- This check only ever runs on a site Crawl Cove has identified as WordPress. A non-WordPress site gets zero findings from this specific check.
- An image missing only one of the two attributes still fires this check. Both
widthandheightare needed for the browser to compute an aspect ratio; a lonewidthorheightis not enough on its own. - This is one cause among several for layout shift, alongside dynamically injected content, font-swap reflow, and layout-affecting animations. Clearing every instance of this finding does not guarantee a passing CLS score by itself; see Cumulative Layout Shift for the full picture.
Related reading
For the Core Web Vital this finding contributes to, and the other common causes of layout shift, see Cumulative Layout Shift: Causes and Fixes.
Google documentation: Optimize Cumulative Layout Shift
This is one of the checks in our step-by-step WordPress SEO audit guide.
Frequently asked questions
- Doesn't WordPress add width and height automatically?
- Yes, when an image is inserted through the media library at its known dimensions. Images added another way, such as pasted HTML, a page builder that strips the attributes, a theme background image swapped in via CSS, or a hand-edited template, can skip that step and ship with neither.
- Is this the same finding as Cumulative Layout Shift?
- No. This check flags the specific cause on WordPress sites, missing width/height attributes, while Cumulative Layout Shift is the Core Web Vital that measures the resulting jump using real or lab data. Fixing this finding is one of the fixes for that wider metric, not a replacement for measuring it.
- Why is this severity low if it affects Core Web Vitals?
- A single missing dimension causes a small, usually one-time shift on that image's page rather than a site-breaking problem, and the fix is mechanical once you know which images to target. Severity reflects the size of a typical instance, not whether the underlying cause is worth fixing.
- Does this check run on non-WordPress sites?
- No. It only fires when Crawl Cove has identified the site as WordPress; a non-WordPress site gets zero findings from this specific check, whatever its images look like.