Alt attributes provide a text alternative for images, used by screen readers when a user cannot see the image and by search engines and multimodal AI models to understand what the image depicts. Fixing this issue means writing concise, descriptive alt text for every meaningful image on the page, and using empty alt for purely decorative images so assistive technology can skip them. The same alt text helps multimodal LLMs and image search tools surface and cite your visuals.

Example

<img src="/images/marathon-shoes.jpg"
     alt="Side view of a lightweight neon-green marathon running shoe">

<img src="/images/divider.svg" alt="">

Where to make the change

• Raw HTML: add the alt attribute to every <img> tag. For decorative images, use alt="" so screen readers skip them.
• WordPress: the media library has an Alt text field on every uploaded image. Fill it once and the value is reused everywhere the image is inserted.
• Shopify: in the product or page editor, click an image and use the Edit alt text option. Theme code that renders product images should pull image.alt.
• Wix or Squarespace: click the image in the editor and use the Alt text or Image description field in the side panel.
• Headless or framework sites: require an alt prop on every image component and lint for missing values during build.

Common causes and how to resolve them

• Attribute missing: add alt="" at minimum so the page validates. Replace with descriptive text on any image that conveys information.
• Alt text is the filename: "IMG_4837.jpg" tells the user nothing. Replace with a description of what is in the image.
• Alt text duplicates the visible caption: screen readers will read both, doubling the user's listening time. Differentiate the alt from the caption or empty the alt.
• Decorative images get descriptive alt text: background patterns and dividers should use alt="", otherwise screen readers narrate noise.
• Bulk imports left alt blank: a one-off audit of the media library or a CMS-side script can fill missing alt values from product names, captions, or asset descriptions.

Best practices

• Describe the function, not just the appearance: for a chart, describe what the chart shows. For a button image, describe what the button does.
• Keep it concise: aim for under 125 characters. Screen readers do not pause mid-sentence, so long alt text is exhausting to listen to.
• Skip "image of" or "picture of": the screen reader already announces it as an image.
• Include the focus keyword when natural: alt text is a minor on-page signal, but stuffing keywords in unnatural alt text harms both accessibility and ranking.

This test fails when the raw HTML document weighs significantly more than necessary, even before counting images, CSS, or JavaScript. Bloated HTML increases time to first byte, slows parsing, and stalls rendering on mobile networks and lower-powered devices. Fixing this issue means trimming inline data, removing legacy markup, and keeping the document focused on what the user needs.

Where to make the change

• Application code or templates: identify which sections produce the most bytes (often a large inline JSON blob, an inline base64 image, or a giant comment block) and refactor them to load externally or be removed.
• WordPress: check for plugins or page builders that emit large inline configurations. Disable unused plugins and prefer themes that ship clean markup.
• Shopify: theme code may inline large product or section JSON. Move heavy data to a fetch-on-demand endpoint when possible.
• Headless or framework sites: review the rendered output for serialized state (for example __NEXT_DATA__ in Next.js) and trim what is sent on first paint by streaming or lazy-loading non-critical chunks.

Common causes and how to resolve them

• Inline base64 images or fonts: move them to external files so the browser can cache them across requests.
• Excessive inline CSS or JavaScript: link to external stylesheets and scripts so they cache. Inline only the truly critical CSS for above-the-fold content.
• Large server-side JSON payloads: ship only the data needed for first render. Fetch the rest on demand.
• Repeating boilerplate or commented-out code: strip comments and dead code in the production build.
• HTML compression disabled: Gzip or Brotli compression often shrinks the response by half or more. Confirm the server sends the appropriate Content-Encoding header.

Best practices

• Aim for under 100 KB of HTML: most pages can comfortably stay under this. Anything beyond a few hundred KB usually indicates structural bloat worth refactoring.
• Enable compression: Gzip is the safe minimum, Brotli is even better for HTML and other text formats.
• Defer non-critical content: rendering only what is needed for the initial viewport keeps both bytes and parse time down.
• Audit periodically: add HTML size to your performance budget so regressions get caught in CI.

This test fails when the page builds a Document Object Model with too many nodes or excessive nesting depth. Large DOMs increase memory usage, lengthen style and layout calculations, and slow rendering, particularly on mobile devices. Fixing this issue means simplifying the markup so the browser has less work to do on every interaction.

Where to make the change

• Application code or templates: identify the heaviest sections (long lists, repeating components, deep grid wrappers) and either paginate them, virtualize them, or flatten the markup.
• WordPress: heavy page-builder themes often emit deeply nested wrapper divs. Consider switching templates or using a theme that emits cleaner markup.
• Headless or framework sites: use a virtualized list component for long item lists so only visible rows are rendered into the DOM.

Common causes and how to resolve them

• Long lists rendered in full: show a paginated subset or virtualize the list so only on-screen items exist in the DOM.
• Excessive wrapper divs: a stack of layout wrappers ten deep can usually be flattened to two or three with modern CSS layouts (Grid, Flexbox).
• Hidden modals and dropdowns kept in the DOM: render them on demand instead of always emitting them with display: none.
• Third-party widget injecting many nodes: a chat widget or carousel may add hundreds of nodes per page. Lazy-load it after main content renders.

Best practices

• Aim for under 1500 nodes total and a maximum depth of 32: Lighthouse uses these as warning thresholds and they correlate with smooth rendering on mid-tier mobile devices.
• Render only what is visible: long lists, accordions, and modals belong outside the initial DOM until needed.
• Prefer flat semantic markup: a single <article> with a few children is faster than a deeply nested <div> tree.
• Audit with Lighthouse: the DOM size audit reports the worst-offending elements, which often points at a single template that needs rework.

This test fails when image responses lack caching headers that allow browsers to store them for repeat visits. With proper caching directives, returning visitors retrieve images from the local cache instead of refetching them, producing noticeably faster subsequent page loads. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control headers to image responses. A common setting is Cache-Control: public, max-age=31536000, immutable for versioned assets.
• CDN configuration: Cloudflare, Fastly, CloudFront, and similar offer rules to set long cache lifetimes for image MIME types.
• WordPress and plugins: a caching plugin or a CDN integration handles cache headers without server changes.
• Shopify: Shopify serves images with appropriate cache headers automatically; failures usually point to externally hosted images.

Common causes and how to resolve them

• No Cache-Control or Expires header: add one. Browsers will revalidate every request without it.
• Cache-Control: no-cache or no-store: these are correct for HTML responses but wrong for static images. Set a long max-age instead.
• Short max-age (under a day): images change rarely; a max-age of months or a year is typical.
• Cookie-bearing image requests: if the image URL sets cookies or varies by user, browsers cannot cache effectively. Serve images from a cookie-free subdomain or your CDN.

Best practices

• Use versioned filenames: renaming the file when the content changes lets you set near-permanent cache lifetimes without ever serving stale files.
• Mark immutable assets as such: the immutable directive tells browsers to skip even revalidation requests.
• Serve from a CDN: CDNs add caching, compression, and edge delivery in one step.

This test fails when external JavaScript files are served without caching headers that allow browsers to store and reuse them. Cached scripts skip the network on repeat visits, reducing load time and bandwidth for returning users. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control: public, max-age=31536000, immutable to JavaScript responses, paired with versioned filenames.
• CDN configuration: set a default cache rule for *.js assets at the edge.
• Build pipeline: emit hashed filenames (for example app.7f3c1e.js) so cache lifetimes can be long without risking stale code.
• WordPress and plugins: caching and CDN plugins handle JS cache headers automatically.

Common causes and how to resolve them

• No Cache-Control header: add one. Without it, browsers revalidate on every page load.
• Short max-age: bump to a year for versioned files. Use a shorter lifetime only for unversioned scripts that may change in place.
• no-cache or no-store on static JS: remove these directives; they belong on dynamic responses, not static assets.
• Cookies on script requests: serve scripts from a cookie-free subdomain or a CDN to enable shared caching.

Best practices

• Versioned filenames: hashed file names plus immutable caching is the gold standard for cache effectiveness.
• Self-host critical scripts: hosting third-party scripts yourself lets you control cache headers and avoid vendor outages.
• Audit with DevTools: the Network panel's "Disk cache" column shows whether each script is genuinely served from cache on repeat visits.

This test fails when external CSS files are served without caching headers that allow browsers to store and reuse them. Cached stylesheets skip the network on repeat visits, reducing load time for returning users while still allowing updates through versioned filenames. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control: public, max-age=31536000, immutable to CSS responses, paired with versioned filenames.
• CDN configuration: set a default cache rule for *.css assets at the edge.
• Build pipeline: emit hashed filenames so cache lifetimes can be long without risking stale styles.
• WordPress and plugins: caching plugins handle CSS cache headers automatically.

Common causes and how to resolve them

• No Cache-Control header: add one. Without it, browsers revalidate on every page load.
• Short max-age: bump to a year for versioned files; keep it shorter only for unversioned files that may change in place.
• Stylesheets behind authentication: private styles cannot use public caching. Move shared styles to a public path.

Best practices

• Versioned filenames: hashed names plus immutable caching is the gold standard.
• Inline critical CSS: the styles needed for above-the-fold rendering can be inlined while the rest is cached and loaded asynchronously.
• Audit with DevTools: confirm that on repeat visits, the stylesheet is served from disk cache rather than the network.

This test fails when different URL variants of the site (apex versus www, HTTP versus HTTPS, with or without trailing slash) do not all resolve consistently to a single canonical version. When the same content is reachable at multiple URLs, search engines may split ranking signals across the variants. Fixing this issue means picking one canonical form for the site and 301-redirecting every other variant to it. See the Google Search Central canonicalization guide for the full specification.

Where to make the change

• Server configuration: add 301 redirects in your web server config (Nginx, Apache, IIS) or via _redirects on Netlify, vercel.json on Vercel, or Cloudflare Page Rules.
• CDN: most CDNs offer redirect rules that fire before the origin is hit, which is the cheapest way to enforce canonicalization.
• Application code: as a backstop, applications can detect the wrong host or scheme and emit a 301 redirect to the canonical URL.

Common causes and how to resolve them

• Both apex and www serve the same content: pick one (most sites prefer apex today) and 301-redirect the other to it permanently.
• HTTP and HTTPS both serve content: redirect all HTTP requests to HTTPS, then add HSTS so browsers stop trying HTTP at all.
• Trailing slash inconsistency: pick one form (with or without) and redirect the other.
• Uppercase or mixed-case URLs: redirect uppercase paths to their lowercase canonical form.
• Index page accessible at multiple paths: for example /index.html, /index.php, and / all serving the same content. Redirect everything to /.

Best practices

• Use 301 (permanent) redirects: they pass the strongest ranking signal and are cached aggressively by browsers.
• Pair with <link rel="canonical">: the canonical tag is a backup signal for cases the redirect cannot cover (parameterized URLs, syndicated content).
• Avoid chains: redirect directly to the final URL in one hop.
• Update internal links to canonical URLs: linking to non-canonical variants triggers unnecessary redirects on every visit.

This test fails when an HTTPS page loads any sub-resources (images, scripts, stylesheets, or fonts) over insecure HTTP. Mixed content weakens the security guarantees of HTTPS, and modern browsers either block the resources outright or warn the user, often breaking the page in the process. Fixing this issue means updating every HTTP resource URL to HTTPS.

Where to make the change

• Application code or templates: search the codebase for http:// URLs in src, href, and inline styles; replace each with https:// or with a protocol-relative path.
• WordPress: use a search-and-replace plugin to update http:// URLs in the database after enabling HTTPS, or rely on a dedicated SSL plugin to handle it.
• CDN: most CDNs offer "Automatic HTTPS Rewrites" or similar features that upgrade insecure asset references on the fly.

Common causes and how to resolve them

• Hard-coded HTTP image URLs in content: rewrite stored URLs to HTTPS or use a relative path that inherits the page protocol.
• Third-party scripts that only support HTTP: drop the script (it should not be on a modern site) or contact the vendor for an HTTPS endpoint.
• Hot-linked images from HTTP sources: host the images yourself or proxy them through your own HTTPS-enabled CDN.
• Mixed content in CSS background images: update the URL inside the stylesheet, then bust the cache.

Best practices

• Add Content Security Policy: the upgrade-insecure-requests directive automatically rewrites HTTP requests to HTTPS, which is a useful safety net.
• Use the browser console to find offenders: mixed content warnings include the file and line of the offending request.
• Audit periodically: new content can reintroduce mixed content. Add an automated check to your CI or monitoring pipeline.

This test fails when the page exposes one or more email addresses in plain text. Spam-harvesting bots scrape pages for plaintext addresses and add them to bulk mailing lists. Fixing this issue means obfuscating contact addresses, using a contact form, or rendering them via JavaScript so simple scrapers cannot read them.

Where to make the change

• Application code or templates: replace plain contact@example.com text with one of the obfuscation techniques below.
• WordPress: a contact form plugin handles email submissions without exposing the address. Some SEO and security plugins also offer email obfuscation.
• Shopify, Wix, Squarespace: use the platform's built-in contact form blocks rather than displaying the email address directly.

Common causes and how to resolve them

• Plain text address in a paragraph or footer: replace with a contact form, an obfuscated rendering (HTML entities, CSS reversal), or a JavaScript-built mailto link.
• Mailto link with the address visible: the visible text is what bots read. Make the visible text a label like "Email us" while the href still works.
• Address baked into images is fine for SEO but bad for accessibility: screen readers cannot read it. Pair an image with a contact form instead.

Best practices

• Prefer contact forms: they reduce spam and make analytics easier.
• Use HTML entity encoding: writing co... for the address defeats the simplest scrapers, though sophisticated ones decode it.
• Render via JavaScript: building the mailto link client-side blocks scrapers that only read static HTML.
• Consider a Cloudflare-style email obfuscation: some CDNs automatically rewrite plaintext emails to obfuscated equivalents.