WordPress image SEO, from the original file to the published page.

1. Review the source image
2. Export a suitable file
3. Upload and set alt text
4. Place it in the page
5. Check the published result

Start with one important page rather than changing the entire Media Library. A product page, a popular article or a page with a large hero image gives you a manageable place to check the process. Keep its current files and record which image appears where before replacing anything.

Use yaSEO to audit the public page or upload the originals. Review missing alt attributes, filenames and measured file sizes. If you want an AI draft, add reliable page context and request a description for the selected image. Check the wording before you apply it, especially when the photograph shows a product variant or text on packaging.

The steps below cover preparation, import and publication. The yaSEO WordPress importer can add optimized images and reviewed alt text to the Media Library from a ZIP. Existing posts, galleries and featured images still need to be updated in the editor. You can also upload files and copy descriptions manually.

A full-width hero, a card thumbnail and a product zoom view need different source sizes. Look at the actual layout before exporting. A file that is much wider than the largest useful display can carry unnecessary pixels, while a file that is too small can become soft on a high-density screen or in a zoom view.

Keep a master outside WordPress and create a publishing copy. In yaSEO, you can set an export width between 100 and 2400 pixels; smaller sources are not enlarged. Check the preview at the size the visitor will use. If a detailed product zoom needs more than the exporter supports, keep a separate workflow for that larger asset rather than enlarging a smaller file.

WordPress normally creates additional sizes after an image upload, with the available sizes influenced by the site and theme. The browser may receive one of those generated files rather than your uploaded original. That is why a screenshot of the Media Library's file size is not enough to confirm what a mobile visitor downloads.

When selecting an image block, check its resolution and dimensions in the editor. The WordPress image block documentation describes these controls. Test a representative page with your actual theme, because a theme or page builder can change which image size is used.

WordPress added WebP support in version 5.8 and AVIF support in version 6.5, but the hosting environment must also support the format through its image-processing libraries. See the official WebP announcement and AVIF announcement for the server requirements.

Upload one test file and confirm that WordPress can display it and create the sizes your site uses. Then insert it into a draft page and preview the result. If the file type is rejected or thumbnail generation fails, inspect the hosting support and any security or media plugins before changing more files.

Compare visual quality as well as bytes. WebP and AVIF use different quality scales, so a shared quality number does not establish equal quality. The yaSEO format test includes original files and measured outputs to show how much settings and source content can affect the result.

If an optimization plugin or CDN already converts images, decide which system owns that conversion. Repeated lossy conversions can alter the result and make troubleshooting harder. Keep one documented path for the publishing copy, then verify what that path actually serves.

Open Media, then Library, and select the image to inspect its attachment details. WordPress exposes separate fields for these purposes; the Media Library documentation shows where they live. Fill the field that matches the job instead of pasting the same promotional sentence into every box.

For a product photograph, a useful description might be 'Green backpack with orange zipper pulls, front view.' A caption could explain the view or give a photo credit. A filename might be green-backpack-front.webp. They refer to the same asset but are not interchangeable metadata fields.

When an image is purely decorative, an intentionally empty alt attribute can be appropriate. When it functions as a link, the accessible name should help explain the destination or action. Review the full page context with the W3C alt decision tree if you are unsure.

Changing the Alternative Text field in the library is a useful step, but do not assume every existing placement has changed with it. A saved image block can contain its own alt value. Page builders and gallery plugins can also manage image markup in different ways.

Open the post or page where the image is already used. Select the image block and review its Alternative Text setting. Update the page, then inspect the public version. The important result is the alt attribute on the image the browser receives, not only the value shown on a separate library screen.

This distinction also matters when reusing one image in different contexts. A photograph that explains a product detail on one page may serve a different purpose in an editorial article. Review each meaningful placement rather than treating one library description as universally correct.

If you are updating a large number of existing placements, choose an importer or integration that explicitly handles them. A tool that updates media records and a tool that rewrites saved post content are performing different operations. Test what is actually supported before running a bulk job.

<img src="/wp-content/uploads/2026/09/green-backpack-front.webp"
     alt="Green backpack with orange zipper pulls, front view"
     width="1200" height="900">

For the importer, choose WordPress under Export for, download the ZIP and keep it intact. Install the free yaSEO Image Importer plugin, then open Tools > yaSEO Image Import. Preview the filenames and descriptions before confirming. The importer reads images.json and creates new attachments with alt text; core WordPress does not understand these instructions without the plugin.

If you prefer a manual upload, extract the images and CSV, upload through the Media Library and apply the reviewed descriptions. If the files are replacing existing assets, confirm which media item and page placement each one should replace. WordPress may change an uploaded filename when a name is already in use, so check the final file URL and media record rather than assuming the name is unchanged.

For a developer-built importer, WordPress exposes an alt_text field on media through its REST API. A reliable integration still needs authentication, a way to match the correct media record, conflict handling and a policy for existing page content. Those are implementation decisions, not properties that a ZIP file supplies on its own.

For either workflow, finish a few images at a time. After each batch, check that every uploaded filename has the description from its own CSV row. Keep the old source files until you have confirmed the replacements on the public pages.

A new filename is a new asset URL. If an image is already referenced by posts, templates, galleries or external pages, changing the file does not automatically update every reference. Before a replacement, identify the page placements and keep a record of the old URL.

For a small edit, replace the image through the relevant block or your site's established replacement workflow. Preview the desktop and mobile crops. A theme may crop thumbnails differently from the main photograph, so a replacement that looks fine in the article body can still cut off a product in a listing card.

Clear the relevant page or CDN cache after the change if your site uses caching, then verify the public response. A stale cached page can keep pointing at the previous image or description. Avoid deleting the original immediately; first check that the pages no longer need it and that your own backup exists.

If you are planning a large migration, test it in a staging environment with a reversible mapping of old and new assets. That is a different project from writing alt text for the next article, and it should have a different level of preparation.

A responsive image can expose several candidate files in srcset. Its sizes attribute should reflect the page layout so the browser can make a sensible choice. Inspect the selected file on a narrow screen as well as a desktop. The web.dev responsive image guide explains the relationship between those attributes.

Reserve the image's layout space with dimensions or an appropriate CSS aspect ratio. This helps the page avoid moving content when an image arrives. A missing width attribute alone does not prove a layout problem, because CSS may already reserve the space. Check the rendered result before treating every audit warning as a defect.

Lazy loading can suit images farther down the page, but the important image visible at the start needs different treatment. Identify the actual Largest Contentful Paint image. Do not mark every image high priority; use that hint where it serves a measured need. The Fetch Priority documentation explains the browser behavior.

Plugins and themes can already set these attributes. Inspect their output before adding another optimization layer. Two features trying to control the same image can make the final behavior harder to understand, even when both sound useful in a settings screen.

Run the image SEO checker again and compare the returned HTML with the earlier report. yaSEO does not render JavaScript or inspect every background image, so use a browser for galleries and page-builder components that are created after load.

Keep the result for one page before moving to the next batch. A small documented workflow is easier to repeat than a library full of partly updated assets. For the wider relationship between images and search, return to the image SEO guide; for wording, use the product image examples.